Google builds platforms for developers and strives to make them happy. There's a team at Google that wakes up every day to make sure developers have great outcomes with its services and products. The team listens to the developers and brings all feedback back into Google. It also spends a lot of time all over the world talking to and connecting with developer communities and showing stuff being worked on. It doesn't do the team any good to build developer products that developers don’t love.
Today, we’re talking to Adam Seligman, vice president of developer relations at Google, where he is responsible for the global developer community across product areas. He is the ears and voice for customers.
Some of the highlights of the show include:
Google tackles everything in an open source way: Shipping feedback, iteration, and building communities
Storytelling - the Tale of Kubernetes: in a short period of time, gone from being open source that Google spearheaded to something sweeping the industry
Rise of containerization inside Linux Kernel is an opportunity for Google to share container management technology and philosophy with the world
Google Next: Knative journey toward lighter-weight serverless-based applications; and GKE On-Prem, customers and teams working with Kubernetes running on premise
Innovation: When logging into GCP console, you can terminate all billable resources assigned to project and access tab for building by hand
GCP's console development strategy includes hard work on documentation, making things easy to use, and building thoughtfulness in grouping services
Google is about design goals, tradeoffs, and metrics; it’s about hyper scale and global footprint of requirements, as well as supporting every developer
Conception 1: Google builds HyperScale Reid-Centric user partitioned apps and don't build globally consistent data driven apps
Conception 2: Software engineers at the top Internet companies do the code and write amazing things instantly
12-Factor App: Opinions of how to architect apps; developers should have choices, but take away some cognitive and operating load complexity
Businesses are running core workloads on Google, which had to put atomic clocks in data centers and private fiber networking to make it all work
Perception that Google focuses on new things, rather than supporting what's been released; industry is on a treadmill chasing shiny things and creating noise
Industry needs to be welcoming and inclusive; a demand for software, apps, and innovation, but number of developers remains because everyone’s not included
Human vs. Technology: More investment and easier onboarding with technology and an obligation to build local communities
Goal: Take database complexity and start removing it for lots of use cases and simplify things for users to deal with replication, charting, and consistency issues
DevFest: Google has about 800 Google developer groups that do a lot of things to build local communities and write code together
Full Episode Transcript:
Corey: This week’s episode of Screaming In The Cloud is generously sponsored by DigitalOcean. I’m going to argue that every cloud platform out there biases for different things. Some bias for having every feature you could possibly want offered as an added service at varying degrees of maturity. Others bias for, “Hey, we heard there’s some money to be made in the cloud space. Can you give us some of it?”
DigitalOcean biases for neither. To me, they optimize for simplicity. I polled some friends of mine who are avid DigitalOcean supporters about why they’re using it for various things, and they all said more or less the same thing. Other offerings have a bunch of shenanigans, root access, and IP addresses. DigitalOcean makes it all simple, “In 60 seconds, you have root access to a Linux box with an IP,” that’s a direct quote albeit with profanity about other providers taken out.
DigitalOcean also offers fixed-price offerings. You always know what you’re going to wind up paying this month, so you don’t wind up having a minor heart issue when the bill comes in. Their services are also understandable, without spending three months going to cloud school. You don’t have to worry about going very deep to understand what you’re doing. Its click a button or making API call, and you receive a cloud resource. They also include very understandable monitoring and alerting.
Lastly, they’re not exactly what I would call small-time. Over 150,000 businesses are using them today. Go ahead and give them a try. Visit do.co/screaming and they’ll give you a free $100 credit to try that. That’s do.co/screaming. Thanks again to DigitalOcean for their support to Screaming In The Cloud.
Corey: Welcome to Screaming in the Cloud, I'm Corey Quinn. I'm joined this week by Adam Seligman the VP of Developer Relations at Google. He is formerly at Salesforce, and before that, he was doing DevRel at Microsoft for a long time, welcome to the show, Adam.
Adam: Good morning.
Corey: Let's dive right in here, what is developer relations at Google about?
Adam: We build platforms for developers at Google, and we love it when developers are happy. There's a whole team of people here that wakes up every day, and make sure developers have great outcomes with our services, products, and also make sure listing them and bring all that feedback back into Google.
Corey: So it's simultaneously an outbound role as well as being the ears for the customer, as well as just the voice?
Adam: Yeah, that's super important, it doesn't do us any good to build developer products that developers don’t love. This whole team is optimized around sitting really close, working closely with product management engineering, and bringing back all those lessons and insights and helping make the products great. We do spend a lot of time out all over the world talking and connecting with developer communities and showing the stuff we're working on, and writing open source. It's not an outbound job, it's a developer relations job.
Corey: So a large part of most developer relations as per people who are very active in that space comes down to storytelling, for lack of a better term. What do you find is the part of the Google story right now that really resonates with the developer community?
Adam: Google's got a lot of products and services used by developers. Everything from Android, and Chrome developer tools, the VA library inside Node.js comes from Google or started from Google open source. Out in the cloud, things like Kubernetes, and Knative, and Tensorflow, all these hot emerging technologies. A lot of what we do is make sure we've got great technologies available to developers. We like to sort of tackle everything in kind of an open source way, shipping it, get feedback, iterate, build communities, that's kind of the heart of it.
Corey: So a story that's really seeming to resonate lately that it goes beyond Google although it didn't start off that way is, I guess the tale of Kubernetes where it's in a very short period of time gone from this open source project that folks from Google really spearheaded and from there it turned into something that is sweeping an industry. We're seeing evolutions of this coming out of large enterprises, we're seeing small startups working on this, we're seeing a host of consulting and technology providers in this space. How does Google view Kubernetes today?
Adam: Well I think that's how I like Kubernetes to be a pretty cool 12-part, like a Viking miniseries on Netflix or something, but I don't know if it's that dramatic. I'm relatively new to Google, but I've learned a lot about through the history of how we got our platforms and how we build our platforms internally. Containerization in global scale is something we needed, and so to see the rise of the containerization technology inside Linux Kernel with great companies like Docker, I think there is opportunity for Google to kind of share some of this container management technology and philosophy out with the world.
It's taken a couple years, like we're still kind of at the beginning of this story. The journey we’re on to containerization, I think from what we learned, what we're seeing from the customers, and from developers out on the market is, it's not just about packaging the app, it's how do fleets of things run at scale, how the team ship code to production and route traffic to it. It's kind of the end of the story is going to look very different than the beginning of the story, I think.
Corey: I think a lot of that story is still being written. I mean right now you can walk into a room with a straight face and tell people that Kubernetes is named after the Greek god of spending money on Cloud services, and most people still don't have enough background on the service to question that. It's an interesting area and we just saw at Google Next, that I believe Knative is how it's pronounced, were effectively being able to deploy Kubernetes workloads back to on prem, am I misunderstanding how that works?
Adam: There's kind of two main announcements at Google Next. The first is Knative and it's this journey towards lighter weight serverless based applications, small lightweight applications can be packaged up, deployed on top of the container infrastructure, an inventing model so you can fire them of events, kind of a nice elegant way. I think the long story is we're seeing everything.
I was kind of thinking if I had a tagline with Google like we run it all, big to small, and Knative is about some of the small stuff working really nicely in that Kubernetes based substrate world. The second thing that we’re seeing with customers, and startups, and developer teams, and ops teams, is a lot of Kubernetes running on premise.
People have the infrastructure and they want to modernize it, they want to manage to serve modern DevOps practices. Kubernetes is open source to let them do that. But once they see that substrate running, they want to run apps that sort of span across these worlds. We show this commercial product, GKE on prem, sort of a hybrid model of our GKE management service managing apps across both cloud and on premise Kubernetes clusters. That's a neat new capability thing, I think a lot of customers will get excited about it.
Corey: I would agree, that really came to my notice when employees of a large competitor who I need not name at the moment, I'd like to point out these are my words, not yours, were more or less mocking Google for the idea of bringing GKE on prem. I find that to be a little unfair in the context of, at first you can tease a large provider for not meeting their customers where they are, but then when they do it, you mock them for going in that particular direction. It really feels like to some extent, whatever you do is going to upset some contingent of people on the internet, and you’ve almost had a point at Google where you can't win.
Adam: I think that in a vendor's play marketing game, so they poke each other, I think we're going to mostly sit out of that. We have a lot of experience networking with large banks, mega retailers, lots of different kinds of companies and they're running a mix. They have infrastructure, it's not going to go away. We're all in the cloud, that's a Google point of view for sure. But if we could use open source and provide services that customers can use on prem to make their infrastructure better today, why not help them on that on that journey?
This is why we do open source. A lot of this innovation, we don't want it locked up in any one particular cloud provider. The mockers are going to mock, I guess, maybe is a good way to say it but containers are going to contain. Containers are going to grow.
Corey: From here in the cheap state, it's always easier to throw scorn and cynicism at people rather than it is to be supportive of something because if you haven't forbid say something nice about the wrong technology that doesn't win, well what might happen from there, in reality, nothing, but it doesn't always feel that way in the moment.
One thing that does strike me as innovative that I wish some of your competitors would copy is that, when I log in to the GCP console, there are two features that are absolutely revolutionary from a customer point of view. The first is anything that I spin up, I can terminate all billable resources assigned to that project. I'm not left with a $0.20 bill in perpetuity for the rest of my life.
The second is, when I click around and build something in the console, there's a tab at the bottom that says, "Here's how you can build what you just built by hand programmatically if you'd like to." Those two things, I get that they're minor features, but from a usability perspective to someone new to the platform, that is transformative.
There isn't anything like that in other providers, and it also gets away from the idea that you have to be conversant with 12 different services that are only tangentially related to the thing you're trying to build before you can get somewhere productive. What is the strategy that goes into GCP's console development?
Adam: The console has been a really neat kind of experience for me getting into working at Google and using the product and understand how we build things. I think I see all the different top cloud providers evolve their point of view and the services they want to be great at, their company DNA start showing through at the developer experience service area.
We're building a great console I think with GCP so that customers can have great experiences, developers have great experience. It's pretty easy to navigate, things are organized well, we take a lot of pride, put a lot of hard work in our documentation to make sure it's all linked really effectively into the console experience.
Some people like CLI, that's totally fine. They want a script and automate, we make everything accessible that way also. Things aren't exclusive, either the web view of the CLI view. I think you're going to see increasing intention in the design in that console experience. Building a lot of thoughtfulness in how services are grouped together.
We have tutorials embedded in there, so you can sort of get started and go learn. Personally, I spend some time with our vision in APIs over the weekend and it was a pretty delightful experience to use AI research in the cloud that are pretty computationally intensive.
You need to go provision your account to go use those services, and I had a good experience with it. I was feeling good about the teams, the dock teams and all the hard work we put in to make those things easy to use.
This is going to be an investment for us, so we're working on the next version of the console right now, iterations and improvements to the console, and I'm really excited about where the team's taking it. I'll say to your readers, if you haven't kicked the tires in the GCB console, check it out, it'll surprise you. I think all the consoles and the different vendors look different, but I think what we've done is we really delight some developers.
Corey: I can absolutely echo that given the fact that I'm not much of a developer myself, to that end, a few years back, I went through a Google interview series, and it turns out that Google has a hiring bar that is set at least at the level of should be able to write code, and if you can't write code like me most days, it turns out you generally don't get hired.
We wind up going out into the world and writing code at other lesser places badly. The challenge with that of course is, I then built an application that's frankly by Google standards, terrible. It takes in none of the Google system design principles into account. It starts entirely with me writing this ridiculous monolith. It's something doesn't wind up falling into any of the traditional 12-factor app style development model. I've written this crappy thing that’s architecturally fragile, and then I try to run it on GCP. How well these days is Google addressing the needs of the workload that is about as unGooglely as it's possible to get?
Adam: Everything about engineering is about design goals, and tradeoffs, and success metrics. There's not one right way to write software and not every application is going to have a billion users.
I think this is a big part of the story arc from Google building a great cloud platform, it has been not just to hit the sort of hyper scale kind of requirements and global footprint kind of requirements, but really supporting every developer. I think we’re on a good path for that, it's definitely in the mindset, if you read our documentation, if you try our console, if you see you're getting started, you’ll see you can stand up a relatively monolithic PHPF and get that up and running, you can write a little Node.js service which uses AI like I did over the weekend. All those doors are open for you for every kind of developer.
How we hire and how we think about the core software engineers we put on staff is different how we think about supporting every developer out there in the universe, and how she's going to write apps, and learn our technology, and try new things. I think it's part of the long story arc, I don't think it's solved overnight, but absolutely Google wants to be welcoming to developers of every single background, and meet them where they are.
Corey: It's a very hard problem to solve specifically because you have an entire world of industry out there where the constraints around what they build don't look anything like any application Google would build internally or would consider building internally.
Writing software in COBOL that runs traffic lights or displays ATM balances globally is very different than building a world spending search engine, or a highly available email service. At times, it seems almost like people who work in those ancient and regulated industries sometimes feel that there's a sense of, I don't want to say condescension because it's too strong, but a sense of being left behind by all of the major providers in this space, just from a perspective of not being able to build something that comports to anything that looks cloudy in those constrained regulated environments. How do you find that bringing those people into the conversation generally plays out?
Adam: I think there's a little bit of maybe different conceptions of how a software is built out there in the world. I think there's a conception that Google and similar companies build HyperScale Reid-Centric user partitioned apps like mail and don't build things like globally consistent data driven apps like banks.
I think there's also a conception that software engineers at the top internet companies do the code jujitsu and just write amazing things instantly, and I think that's a little misconception, too, I would like to maybe address both of those. I'll go to the second one first.
The interesting lesson I've learned, I worked in Heroku and she ran good for a little while, Adam Wiggins wrote the 12-factor application. It’s a lot of like ethos at Heroku from a decade ago, the early days, and was about being opinionated.
Twelve Factors is about an opinion of how apps ought to be architected. Similarly at Google, we're surprisingly opinionated for a lot of things to how we help our internal engineers build things, and so I actually think a lot of what a regular developer faces out in the world trying to build an application is actually a lot of choice. There are not a lot of guidelines on how to go build things, what library should you use? What framework should you use? What should your data to your architecture be? How should you manage partitioning, and scale out, and operations? It's just a world of choices and it's maybe like overwhelming set of choices.
One of the things that’s kind of neat about the sort of container approach is something Google did internally which was just make that stuff really easy for developers. They didn’t have to worry about it. They could scale a workload out, it would load balance traffic against it. It would attach to data services that are scalable data services, and so it was kind of about less choice.
I think that developers always have a choice to use whatever they want. I think if you can take some of the cognitive and operating load of some of this complexity away, and give developers the option to use happy paths that are well paved, and work really well, I think that could be a wonderful thing.
The second thing is the kind of applications––probably all the cloud providers are seeing this, but we're seeing banks run core workloads on Google now. We're seeing retailers run core workloads and Google now. We are shipping databases like Spanner that are not only kind of neat globally consistent and scale elastically and read, but also accept distributed rates which is like a really neat capability.
We had to put atomic clocks in the datacenters and private fiber networking to make this all work, but the end result is, the user doesn't have to worry so much about high scaled relational databases spanning across the world. The card consistency problems are mostly taken care for them.
We wanted to the engineering work and build this great cloud so developers can do whatever they want, but also take advantages of services that just go and work, and simplify that part of the equation for them.
Another example is ML, we did Tensorflow, we did open source, you can do anything you want and run anywhere. But the other end of the spectrum of auto ML where you can throw a bucket of images at it and the cloud will automatically create a model for you and provide it back as a rest service.
I think developers have lots of choice, but I think if we could also provide a world where for many of these use cases, we can make it simpler, I think that's going to be incredibly powerful and kind of liberating for developers.
Corey: I think that one of the easy things to forget is that, Google is at this stage a very large company and I think for some people, they're still sort of stuck in the early 2000's where Google was much smaller, but was in some ways more focused with respect to offering fewer products, and it also tends to lead down paths where people's understanding of Google has not evolved or kept pace with Google itself.
In many ways you still wind up with people living in the past when Google had less than 2,000 engineers and not tens of thousands of engineers. That in many ways seems to be an area where at least personally, I still struggle to think of these giant companies as more than five or six people with ultimate decision making authority.
To that end, you've been at Google for approximately eight months now, have you made any progress on determining the identity of the person who's responsible for killing Google Reader? We're waiting on a very blameful post mortem here.
Adam: Yeah, I think a post mortem needs to be written on that. It's kind of funny how one application that I loved and cherished sort of disappeared from the internet. Although, I like the Feedly product that kind of take up the reins, I imported everything there.
I definitely think the enterprise customers, and I think even developers expect kind of a different level of trust in the provider than maybe just some experimental consumer app. I think Google has been getting its head around that for the last 10 years of doing Google cloud.
Google has definitely had a journey to get the enterprise, and get these sort of long term support and reliability, and sort of the enterprise interface stuff that companies kind of expect. It's pretty fun to see the rapid growth of cloud here, but I think you've got to go out and earn it every day.
I don't think it's as simple as what products or services you offer, it's also like the support, and the high quality documentation, and all that company interface stuff you have to provide, the sales, and support, the customer engineers.
We're doing a lot to do things like teaching our customers AI with like co-laboratory AI model with our customers, we're doing it around SRV. I think you had Liz on talking about SRV and we're doing a lot of work with customers to sort of talk about our point of view in SRV and help adapt it, and help the world kind of embrace these kind of operating models. We're on a journey, I think the company's gotten really big but with all that, we have to say really close with developers, and customers, and start ups, and stuff, and connect to them in a way that makes sense.
Corey: To that end, there's also I guess a natural confusion where users see the name Google and there isn't an internal disambiguation for them of consumer facing service like Reader, and enterprise facing service such as GKE. It seems from the outside as a result that there's more of a focus at Google on developing new and exciting things, than supporting what's already been released.
When I talk to my friends at Google internally, I don't get that sense at all but it’s a difficult message to permeate out into the rest of the industry. Can you speak to that perception?
Adam: The industry is kind of on a treadmill of chasing the shiny things right now. I think when I look at the stats of sort of the rise of container use on GKE, this industry is on a march to containerization. When I look at the consumption of our AI services, the industry is seeing incredible growth of AI services, programming with data across the whole industry.
I think there's a lot of noise out there, and marketers are going to market and talk about new stuff, ultimately what matters is that services get used and developers have great outcomes, and we're listening to them to make those things better. We can't ship a client library and call it done, it's got to be idiomatic.
We can't just have functions we need to support go and cloud functions. We're bracing to go do that. There's definitely like some excitement when you can do breakthrough technology, but I think you've got to follow through and make it real, and make it robust, and make it high quality, and help ensure people have great outcomes with it.
Corey: What do you think right now that the industry's getting wrong in its understanding our perception of GCP?
Adam: I thought you're going to ask me different question like what is the industry doing wrong overall, I actually want to tackle that for a second.
Corey: To be fair, every conference there's someone from a large tech company, if you're not careful it comes across, and now a large tech company tells a bunch of small companies what they're doing.
Adam: Actually, I want to talk about the industry though, because I think the whole industry needs to be more welcoming and inclusive. I'm going to throw it down, too, that Google can fall into this, and all this cutting edge stuff we can all get wrapped up on a treadmill. I'm kind of turning the spotlight back on us, but I want to use it to tell the story of the industry. There's what 20 million or 22 million developers in the world.
There's crushing demand for software, and apps, and innovation. We don't like robo callers. We like to press buttons on our phones, things come to us. We like people to have great jobs so they can work productively and not stamp paper forms.
We like services to be automated, and yet, we're not increasing the number of developers in the world, we're stuck at 22 million. That's because we're not including everyone we can include. There's the human side of that and there's the technology side. On the technology side, more and more investment and easier onboarding for all different kinds of developers in the kind of technology that makes sense for them, web, cloud, function, a mobile app, drag and drop, low code, writing app script in Google Docs, all those are great pads in, and I'd like to see all the vendors make those pads really easy and welcoming.
On the human side, I think there's an obligation for us to go out all over the world and interface developers and build these local communities, and make them really welcoming, no matter which technology company you provide. I think Google falls into this trap like you said, what are we doing wrong? I can give the Spanner example, we built maybe the most sophisticated database on the planet, but now I want to bring it to as many possible users as we possibly can and make it easy for them to consume.
The goal is not just to get them to use our service, the goal is to take this whole world of database complexity and start removing it for lots of use cases and simplify things for users so the developers can go build mega scale applications instead of dealing with replication, charting and consistency issues.
I think if we do this right in a long story arc, we're going to end with tens of millions more developers there, with all different backgrounds from all different places, and all different experiences. I kind of want to see all the tech vendors, and all the hyper clouds, and all the library providers really think about this and work on this.
Corey: I think that you're going to see a lot of challenge in getting too far above the current number of developers for as long as you make developers continue to worry about things like replication delays, how to build out other things, having to do with I guess the general housekeeping that they have to do today before they ever write one line of business logic, or something that solves a problem. I think you're right about meeting people where they are. To that end, you mentioned that there's an event coming up at Dev Fest.
Adam: I'm super excited about this. Google has about 800 Google developer groups around the world. They're community organized, they get together every couple of weeks, they hold meetups, they do study jams, and a lot of different things to kind of build local community and write code together, and the technology really anchor on our web and arrayed around the world as a really big platform and increasingly cloud. The community is holding a series of events this fall called Dev Fest and they're going to happen at 500 cities on the order of 100,000 members of our community.
There's also going to be an online version for people that can't join in person, but I kind of hope everybody that's kind of interested in Google technology gets plugged in locally. Not just at Google necessarily, but to get to hear from other community members and hear what they like and what they don't like.
The Google developer group in Lagos, Nigeria has over 1000 members and Femi who runs that says, it's an absolute thriving startup scene and developer community. All over the world there's this really kind of a neat community that sort of form around Google technologies, and we want to really support them. Dev Fest this fall is going to be a lot of fun.
Corey: Well I'm looking forward to seeing it. I'm definitely going to make it a point to attend if it comes to our city.
Adam: I don't know where you would be, that's a lot of cities, that’s 500 cities, so we'll get you setup. A community is super important to the health of platforms, and so we really want to support our community as they put these things together.
Corey: Well, thank you very much for taking time out of your week to speak with me.
Adam: Yeah, Corey, this was a lot of fun, and I really like that the community is getting its hands around who Google is and who we were growing up to be, and our aspirations, and I think a lot of dialogue and a lot of listing is helping us make our products better and the whole user experience around Google, and Google services even better.
Corey: I would agree. Thank you once again, Adam Seligman VP of DevRel at Google. I'm Corey Quinn and this is Screaming in the Cloud.