How do you encourage businesses to pick Google Cloud over Amazon and other providers? How do you advocate for selecting Google Cloud to be successful on that platform? Google Cloud is not just a toy with fun features, but is a a capable Cloud service.
Today, we’re talking to Seth Vargo, a Senior Staff Developer Advocate at Google. Previously, he worked at HashiCorp in a similar advocacy role and worked very closely with Terraform, Vault, Consul, Nomad, and other tools. He left HashiCorp to join Google Cloud and talk about those tools and his experiences with Chef and Puppet, as well as communities surrounding them. He wants to share with you how to use these tools to integrate with Google Cloud and help drive product direction.
Some of the highlights of the show include:
- Strengths related to Google Cloud include its billing aspect. You can work on Cloud bills and terminate all billable resources.
- You can expose that from other people’s accounts because turning off someone else’s Website as a service can be beneficial. You can invite anyone with a Google account, not just ‘@gmail.com’ but ‘@’ any domain and give them admin or editor permissions across a project. They’re effectively part of your organization within the scope of that project.
- Google is a household name. However, it’s important to recognize that advocacy is not just external advocacy, there’s an internal component to it. As an advocate, Seth’s job is to help people win.
- Besides showing people how they can be successful on Google Cloud, Seth focuses on strategic complaining. He is deeply ingrained in several DevOps and configuration management communities, which provide him with positive and negative feedback. It’s his job to take that feedback and convert it into meaningful action items for product teams to prioritize and put on roadmaps.
- For a long time, Google was perceived as being late to the party and not able to offer as comprehensive and experienced services as Amazon. Now, people view Google Cloud as not being substandard, but not where serious business happens. It’s a fully feature platform and it comes down to preferences and pre-existing features, not capability.
- Small and mid-size companies typically pick a Cloud provider and stick with their choice. Larger companies and enterprises, such as Fortune 50 and Fortune 500 companies, pick multiple Clouds. This is usually due to some type of legal compliance issues, or there are Cloud providers that have specific features.
- Externally at Google, there is the Deployment Manager tool at cloud.google.com. It’s the equivalent of CloudFormation, and teams at Google are staffed full time to perform engineering work on it. Every API that you get by clicking a button on cloud.google.com are viewing the API Docs accessible via the Deployment Manager.
- According to Seth, there’s five key pillars of DevOps: 1) Reduce organizational silos and break down barriers between teams; 2) Accept failures; 3) Implement gradual change; 4) Tooling and automation; and 5) Measure everything.
- With the SRE discipline, there’s a prescribed way for performing those five pillars of DevOps. Specific tools and technologies used within Google, some of which are exposed publicly as part of Google Cloud, enable the kind of DevOps culture and DevOps mindset that occur.
- The book, Site Reliability Engineering, describes how Google does SRE, which tried to be evangelized with the world because it can help people improve operations. The flip side of that is that organizations need to be cognizant of their own requirements.
- Those going to Google Cloud to ‘move and improve’ tend to be a mix of those from other Cloud providers and those from on-premise data center deployments. Move and improve is where there are VMs in a data center, and they need to be moved to the Cloud.
Site Reliability Engineering book for O’Reilly
Full Episode Transcript
Corey: Hello and welcome to Screaming in the Cloud. Today I’m joined by Seth Vargo, a Senior Staff Developer Advocate at Google. Thanks for joining me, Seth.
Seth: Thanks for having me Corey, excited to be here today.
Corey: Always a pleasure to talk to you. You until very recently were at HashiCorp for a while to do effectively the same type of advocacy work, to my understanding.
Seth: Yeah. I left HashiCorp a few months ago to join Google Cloud. I was working very closely with tools like Terraform, Vault, Consul, and Nomad. Part of the reason that I left HashiCorp was that I have the opportunity to talk about those tools and some of my former experiences with tools like Chef, and Puppet, and the communities that surround those tools, and how you can use these tools to integrate with Google Cloud, and to help drive some product direction around how we can make Google Cloud a great provider to integrate with those different tools.
Corey: Fantastic. I have to confess, I personally only started working with GCP for a test project about a month or so ago, and until then, it was always this thing that was sort of hanging around the periphery of what I’d been doing.
Historically, I was a [inaudible 00:09:16] AWS person just because it’s what I encountered in the wild. I have to say as I went through the process, I was extremely impressed by some of the nice features that GCP has worked into it. Two that leap to mind even now left a strong expression.
The first is the billing aspect of it. All I do is work on Cloud bills and terminate all billable resources in this project is a godsend as far as the Consul goes. The second is the way that it presents anything that you’ve done in the Consul by clicking and pointing. It gives you what that looks like in code form and for those of us who are of the terrible breed of programmer, is just spectacular.
Seth: Oh, I’m glad you liked it. I don’t know if you know this or not, but that button that you click in the UI to disable billing across an entire project and delete all billable resources, there’s an API for that too. You could build a chat bot or a script that does that as well. Everything we do on Google Cloud is API First. Anytime you click a button in that Web UI, there is a corresponding API call, which means you can build automation, compliance, and testing around these various aspects.
Corey: Wonderful. Can you expose that from other people’s accounts? Because frankly, turning off someone else’s website as a service is something I would definitely pay for.
Seth: It’s definitely possible. The IAM and permission management in Google Cloud is incredibly powerful. It leverages the same IAM permissions that G Suite has which is hosted Gmail, Calendar, and all of those other things.
You can invite effectively anyone with a Google account, not just ‘@gmail.com’ but ‘@’ any domain and give them admin or editor permissions across a project and then they’re effectively part of your organization within the scope of that project. This was really useful when you think about things like training, or as a consultant being able to see all of your different clients in one dashboard when you log in but your clients can’t see each other.
Corey: That definitely opens up some possibilities with respect to being able to manage multiple accounts simultaneously, work on different environments. I definitely see the appeal.
You are a Staff Developer Advocate at Google. Historically, advocacy in some companies is, “Here’s who we are, this is what we do.” You could have spent the last 15 years living in a cave and odds are you still know who Google is and what they do. How does that manifest itself at a company that has long ago become a household name?
Seth: Definitely, I think that’s a great question. It’s important to recognize that advocacy is not just external advocacy, there’s an internal component to it. Yes, everyone knows that Google is a household name. I looked when I left here and I have a Google home sitting right there, but there’s many parts of Google and many features of Google Cloud that people aren’t aware of. My job as an advocate, I view it as help people win.
How do I get people who want to use Google Cloud or don’t know about Google Cloud? The ability to be successful on the platform. The flip side of that is what I call strategic complaining.
I am deeply ingrained in a number of communities, the DevOps communities, the configuration management communities, and people are gonna come to me with feedback. They’re gonna say, “Hey, this thing is great.” They’re gonna say, “Hey, this thing is pretty terrible,” and it’s my job as an advocate to take that feedback and convert it into meaningful action items for our product teams, and say, “Hey, I’ve heard this repeating pattern that this particular service’s documentation isn’t up to snuff,” or, “This service is missing a key feature.” Work with the product teams to get that prioritized on the roadmaps so that the voice of the community is being echoed in the features and the products that are being developed internally.
Corey: That tends to make a lot of sense. I mean no disrespect by this, but Amazon was in the cloud space by itself for a long time as far as public cloud availability goes and all of the other providers, Google included, were for a long time sort of perceived as late to the party and not able to offer anything approaching as comprehensive and experienced. I think that that narrative to some extent is something that Google is still struggling with.
Again, I’ve been deep into the woods on AWS for a long time, when I view GCP now, I am not left with the impression that it is substandard. I’m not left with a perception that, “Oh, this is a fun toy but it’s not where serious business happens.” It’s a fully feature platform and at this point, it really comes down to preferences and what’s pre-existing in most environments, not a capability story.
Do you find that that is a general perception of how the entire world is working or am I frankly too stuck off in my AWS world at this point?
Seth: No, Corey, I don’t think you’re stuck on anything. I think we are moving to a world where small companies, and maybe they’re mid-size companies, are gonna pick a cloud provider and they’re gonna stick with it. But when we look at large companies, enterprises, Fortune 50, Fortune 500 companies, they’re gonna pick multiple clouds actually, and they’re gonna do it for one of two reasons.
The first is some type of legal compliance issues. When you think about finance and trading, legally they are required to not have dependencies on one provider, but the bigger reasons is that each cloud providers can have things that they are good at and things that they’re not so good at.
Google for example, we have the best Kubernetes engine because we wrote Kubernetes, we have the folks who run Kubernetes, and have been running Kubernetes for a while, running GKE which is our hosted Kubernetes offering. We also have of the best ML in the world. We just launched AutoML which allows you to use our models with your data so you don’t have to do training.
But then, there are other cloud providers that have specific features where they shine, and organizations are gonna be able to pick and choose, “Hey, I wanna use this from AWS, this from Azure, and this from Google Cloud.” Being able to link those things up and really leverage the true power and elasticity of the public cloud is very, very important for these mid-size and large organization’s long term success.
Corey: When I conducted a survey somewhat recently, last year in AWS, I wound up asking a bunch of snarky questions to a bunch of people. Almost everyone who answered the survey had some workloads in AWS. I’m sure there was no selection bias whatsoever in that, but there was also a very decent showing of other cloud providers along the way.
What I found fascinating and I wished I’d built in more questions around this but in a pure AWS context, the breakdown between who was using CloudFormation and who was using Terraform, to step back into your previous role for a second, was neck and neck. It was effectively a 50-50 split which is incredible even though the official word from Amazon has always been CloudFormation is the way and the light.
Does GCP offer some equivalent of that? Is the official marching order there, “if you wanna automate these use Terraform?” Is there something else I’m just not aware of?
Seth: That’s a great question, Corey. Externally at Google, we have a tool called the Deployment Manager, you can check it out at cloud.google.com. It’s kind of the equivalent of CloudFormation, there are teams at Google that are staffed full time to do engineering work on that. Every API that you get on by clicking a button on cloud.google.com were viewing the API Docs is accessible via the Deployment Manager.
However, in addition to that, Google Cloud has partnered very closely with a number of open source tools and the companies that correspond to them, one of which being Terraform. There’s a team, I’d like to give a shout out to the Cloud Graphite Team, Eric Johnson, Dana Hoffman, Emily Ye, and the team over there who are doing these integrations with third party tools. To put it in perspective, there are people at Google who are paid by Google who work full time on open source tools like Terraform, Chef, and Puppet so that you can provision GCP resources using the tools that you love.
We offer Deployment Manager and if you’re only gonna use Google and you’re never gonna use another cloud, then by all means, use Deployment Manager, it’s going to work best, it integrates everywhere. But if you’re thinking going multi cloud or you already have experience with tools likes Chef, or Puppet, or Terraform, or Ansible, we wanna meet you where you are. If you’re in Ansible shop, we want Ansible to be the tool that you use to provision infrastructure. If you’re in Terraform shop, we want Terraform to be the tool that you use to to provision infrastructure, and the way that we support that is by having the Cloud Graphite Team work on these tools and make sure that the GCP integrations run on deep.
Corey: Perfect. That’s useful to know and it’s something that I think a lot of different shops don’t quite have a full awareness of. Do you happen to have any numbers you can share or just general sense of shops that are using GCP? Are they using these or are they intended to go on a Terraform direction? What is the general [00:19:18] these days?
Seth: I don’t have numbers on the Deployment Manager side of things, but there are a few different customers who are using Terraform. I can’t go into specifics but it’s non zero and it’s significant enough that we have multiple full time people devoted to working on these integrations. If we weren’t seeing adoption and it wasn’t important to us as a company to support those ecosystems, we wouldn’t be investing people in it.
Corey: At a number of DevOps events where there are people from Google talking about how you folks do DevOps internally and right around here is the point where I get interrupted by someone who works at Google, “We don’t do DevOps, we do SRE.” What is the difference and what is the breakdown as far as how Google sees things?
Seth: That’s a great question, Corey. This is actually something that I’m focused on and I’m working closely with the SRE team internally at Google to make sure that we’re getting the right message out there. To just kind of backpedal just a little bit, there’s kind of five key pillars of DevOps. The first is to reduce organizational silos and breakdown the barriers between teams.
The second is that we have to accept failures the norm, that’s things like blameless post-mortems, we have to accept that computers are inherently unreliable, we can’t expect perfection, and when we introduce humans into that we get even more imperfection.
The third is implementing gradual change. We wanna reduce the mean time to recover or the MTTR and we realize that small incremental changes are much easier to review and roll back in the event of failure.
The fourth piece is tooling and automation, write these entire conferences like Monitorama. They gather people from the DevOps communities around monitoring, tooling, automation; Chef, Puppet, and Terraform obviously fit in that pillar.
Then the fifth is to measure everything. No matter what we do in the first four categories, if we’re not measuring it, we don’t have clear gauges for success, we don’t know if we’ve been successful. When you think about it, these are actually abstract topics. Nowhere in here did I say use Chef, or use Puppet, and nowhere in here did I say that you should hold more meetings to breakdown the silos or that you should use an Elk Stack for your measurement, monitoring, and logging.
For these reasons, you can think of DevOps as an interface in our programming language like Java, or a type language where it doesn’t actually define what you do, instead it gives you a very high level of what the function is supposed to implement. There is a function in the interface that says reduce organizational silos and the way that you implement that is kind of like a class. SRE, as I am learning, because I’m also new to Google, but the way that I view this is that SRE is a class that implements DevOps. Just like you can have multiple classes that implement collection or sortable, it’s possible to have multiple classes that implements DevOps.
In the SRE discipline, there’s a very prescribed way for performing those five pillars of DevOps. Things like sharing ownership, SLIs, and SLOs, moving fast by reducing cause of failure, sharing ownership among product teams, and automation, and very specific tools and technologies that we use within Google, some of which are exposed publicly as part of Google Cloud that enable the kind of the DevOps culture and the DevOps mindset to take place.
I think for a while, because there are definitely some folks at Google who have been at Google for many years and aren’t deeply involved in these communities like myself, they thought that SRE was the only way. Some of the advocation that I’m doing internally is saying, “SRE satisfies this interface, but to a certain extent, so do these agile practices over here, and so do these other technologies that other companies are using.”
Part of the work that I’m doing is getting people to realize that we can meet in the middle. Part of the reason why we have abstract classes in programming is that there’s more than one way to solve a problem, and SRE is just one of those ways, and it’s the way that has worked best for Google, and it has worked best for a number of customers that Google is working with, but there are some other ways too. We need to be able to support those ways and recognize that there isn’t one true path and light to the operational success of the system, but there are in fact many ways to reach that prosperity.
Corey: There was an entire book written by a team of SREs at Google for O’Reilly, entirely on the practice of Site Reliability Engineering. It’s a fantastic book and the people who wrote it are incredibly skilled, but it almost felt like that book could have been subtitled, “How to build Google,” to some extent where a lot of what Google does, and how they operate, and how they think presupposes not only the tremendous investment in infrastructure that Google has made since its inception, but also Google culture.
You take that and you drop it on a mid-size credit union in the midwest for example, and almost every pre-existing condition that Google has no longer applies. How do you wind up thriving that sort of cultural change to an environment that looks nothing like Google?
Seth: I think that’s a great question. One of the things that I got out of reading the SRE book was this is how Google does SRE. I’ve read the book a number of times and I struggled to see this viewpoint. There’s a group of people that believe that book is Google telling the world how to do DevOps, and that’s simply not the case. I know many of the authors, that is in no way what they were trying to get across with that book. It was actually a storytelling exercise.
How Google does SRE was the thing that we wanted to evangelize with the world because we think think that it can help people improve their operations. The flip side of that is that organizations need to be cognizant of their own requirements. If I’m a small start up of say, less than 25 people, and operations is someone’s part time job, the SRE kind of playbook isn’t relevant yet. It doesn’t become relevant until we have enough users, and we have a team, and we have these barriers that exist between the product organization and the engineer organization, and the site reliability engineer organization that these practices come into play.
When we talk to, say, a mid-size credit union from the midwest, the conversation can’t be, “Use this tool with this technology, and do exactly this,” because there is a cultural component to SRE, just like there is a cultural component to DevOps that we have to solve first. It’s okay to kind of pick and choose. We might choose the part of the SRE story which is SLOs and SLIs, which are very strict defined measurements of uptime and availability for a system, but we might not use the kind of monitoring and metrics that are recommended, we might use our own technology and it’s about picking what’s best for the organization.
When we go into these companies and we try to say, “Hey, you need to change if you wanna innovate.” We have to be aware of their own reblocks and their own hurdles, and find ways to work around them, and that’s why executive buy-in is really key in these situations.
If you have a couple developers who just wanna move faster, they are never gonna be able to push these initiatives. But if you have top level executives and VPs who are saying, “Okay we’re losing market share, we need to find a way to deliver faster,” you’ll get a lot more buy-in because it truly is, as you said, an organizational culture and that’s true for both DevOps and SRE.
Corey: I wanna be very clear that this next question is not explicitly aimed at Google. I feel the need that I have to warn you first on that one. Google is always held up along with several other companies as a shining beacon of how infrastructure management could be.
You see conference talks conducted by Googlers, you talk to people about what they’re working on and they paint a very compelling picture. A lot of other companies do this and a lot of these other companies I’ve later gone in and done projects there, and it is a very polite fiction. Internally, I have never yet found a company that didn’t think its own infrastructure was to some extent a song of ice and tire fire where you’re always going to have things breaking, it feels like you’re skating at the edge of a disaster, but that doesn’t make for a compelling keynote at these events.
After I’ve poured significant amount of alcohol into various Google people, they start to nod and smile and say, “Yeah, there’s still problems in our infrastructure even after 20 somewhat years and billions invested. It feels like to some extent it’s never a solved problem, there’s always more to improve. First off, would you agree that that’s true?
Seth: I’ve only been at Google a couple months now, I would definitely say that any company you work at, whether the recruiter tells you that it’s all sunshine and rainbows and there’s nothing ever wrong is a lie. Every company has problems, some of them technical, some of them cultural. I don’t think Google is an exception to that rule. Being a company that’s been around for a very long time, there is certainly technical debt. There have certainly been outages while I’ve been here.
The one key difference is the way that Google handles that from a cultural perspective. We focus on fixing the problem and making sure it doesn’t happen again as opposed to finding out who did what, and why they did it, and what were they thinking. There’s a very blameless culture which I found very unique to Google. It’s like a top priority in anytime there’s an outage and the way they mitigate those outages. Having the ability to say, “Oh, this particular cluster is not having a good day, let’s shift in real time all of the workloads from that cluster to a new one.
A great example of something like that is whenever we have the meltdown inspector vulnerabilities here a few months ago, Google was able to migrate people’s workloads in real time without down time as they were applying the patches for these CPUs vulnerabilities and that’s a technology, that’s not a culture, that’s a technology that’s unique to Google.
We wrote about it on the Cloud platform blog and that’s something that makes Google in a unique precision where we can prioritize availability and reliability for our customers, even if behind the scenes there are some fires going on.
Corey: I think that’s very fair. The counter point too and the reason I keep harping on that particular area of things is I did this myself and I’ve talked to other people who continue to do it now. They’ll go to a conference and they’ll see you talk that is presented by one of these bright lights of tech, and then they go back to their own jobs at the end of the conference and they feel sad because their environments are, from their perspective, far worse than what was just described. It feels like there’s not an ongoing sense of empathy or awareness in many cases that everyone’s environment has problems, that everyone’s culture has problems, and this is built on a continuing series of incremental change. How do you find that is being addressed these days?
Seth: I don’t think it is. You and I are both on keynotes at big conferences and there’s a lot of hand waving, there’s a lot of storytelling that goes on. Maybe as an industry we need to tell more war stories instead of the pleasure stories.
I spoke at an event that Fastly did, the CDN Company, and they asked me to speak about an outage that we had. It was different for me. I didn’t feel comfortable doing it. I don’t feel like talking about failure publicly without a resolution as often a negative connotation. As an industry, maybe we need to start talking more about failure and if at the end of the talk the answer is it just never happened again and we don’t know why, that’s okay to talk about. But I also think that that’s not gonna get accepted into a CFP process.
People, as conference organizers, they wanna see sunshine and rainbows because that sells tickets that makes people happy. It is a bit of a systemic problem is how do we talk about these things in the open without putting people in this like, “What was the resolution or how did you fix it?” Because sometime computers are weird.
Corey: I feel like there’s an opportunity here for failure con or something similar where all we talk about is the failures that we’ve seen in various infrastructures and some of them don’t have resolutions. I also feel like there needs to be a standing rule for a conference like that, “Well actually, have you considered,” is not a valid question to ask during the Q&A portion.
After listening to this for 45 minutes, I’m sure you have the answer to a problem that has stymied and retired teams of engineers for months, based upon the window I’ve given you into this, and that’s always a challenge too. But you’re right. I think that it is a negative thing that companies, and organizers don’t necessarily wants to see, but it’s the real world. It’s how these things work.
There’s a whole laundry list of things I have that I do not understand about why my systems behave in certain ways under certain conditions, and if they’re not causing down time or not painful enough, I’m never going to have the time to dig into them or maybe not even have the intellect to dig in and figure out why it does that. The answer I put around, I just draw a circle around all of them and caption it ‘computers are terrible.’ The end.
Seth: That’s actually interesting because what you just described is actually a key component of the SRE discipline which is this thing called Toil. Its work tied to systems that either we don’t understand or it doesn’t make sense to automate a way.
If there’s that one service that goes down once a year but it’s highly available so it doesn’t matter, and someone has to connect to a system and restart it or kick it to reboot, there is no point in investing 10-15 hours to build automation and detection around that, instead let’s just invest 15 minutes every year and do it.
Part of the SRE discipline is about mitigating that. When that system goes down, another one automatically picks up so that we’re not rushing to get it back online and then we can kick it kind of in our spare time. I have a similar bubble, I don’t call it ‘computers are terrible, mine is that ‘computers are unpredictable’ because sometimes they do things in the opposite direction which we fail to recognize.
For example, I have my blog hosted on a cloud instance that is rated for a certain amount of traffic and it was on the front page of Hacker News one day and I got way more traffic than it was rated to receive and it never died or melted down and the CPU didn’t even go above 80%, that was one of those where computers aren’t terrible, they’re just unexplained, or inexplicable in some ways where it was like the metrics clearly dictate that this machine should have melted but it didn’t, and I’m not gonna question it, we’re gonna move on with our lives.
Corey: One last topic I wanna get into before we call it an episode. As you see customers coming into GCP, and I understand you haven’t been there very long and your experience may not be representative. First, are they generally coming from other cloud providers or are they coming from on premise data center deployments?
Seth: I think there’s a healthy mix, like you said, I don’t have much insight but I do think that there’s a number of folks who are trying to do ‘lift and shift’ which I personally don’t work a lot with ‘lift and shift’. My team in particular works with what we call ‘move and improve’, that’s a trademark. It’s not actually a trademark but you heard it here first.
Corey: And I may be stealing it later and claiming it as my own.
Seth: Move and improve is this idea that we have VMs in a data center and we want to move them to the cloud, we could ‘lift and shift’ and use something like a VM on the cloud on any cloud provider, or we could make them cognitive in the process and leverage clouds provider specific technologies like Google functions, or hosted Kubernetes engine, or just re architect the application and make it cognitive so that it behaves well in a highly available environment where the network isn’t always 100% reliable, or the machine might be moved, the application might be killed and restarted.
My team is focused a lot on ‘move and improve’, not so much about ‘lift and shift.’ We have folks at Google who are definitely dedicated to ‘lift and shift’ and making those customers successful. But I focus particularly more on the ‘move and improve’ scenario for those customers in their own data centers.
For customers that are coming from another cloud provider or are coming greenfield, they have an idea and they wanna run it somewhere, I work with them pretty closely as well. That’s where tools and our integrations with things like Terraform, Chef, Puppet, and Cloud Foundry, etc. run deep because they already have experience from another company, or already have something running somewhere else, we wanna make sure to meet them where they are.
Corey: Which makes an awful lot of sense, but as a company goes to a cloud selection process and they look at the big four in the space, Google, Microsoft, Amazon, and Alibaba, all four of those companies have very different cultures and very different ways of managing infrastructure.
Does that have any bearing or have an impact on how they’re going to manage their environment once it moves into one of those providers’ clouds? In other words, if you’re moving something into Azure, are you likely to manage it differently, from a philosophical standpoint, than if you’re moving it into GCP?
Seth: I think that’s a good question. Realistically, there are tiny differences but the cloud native paradigm, there’s some few key pillars here like does it handle restarts well? Is it highly available? Can it be containerized even though containers aren’t necessarily required for cloud native? Does it package all of its dependencies with it? Can it run on different operating systems? All of these things are generic, they’re not specific to a cloud provider.
When we start leveraging providers specific technologies, AWS, Lambda, and Google Functions are similar technologies, they’re both serveralist technologies, but there’s a little bit of configuration differences, something’s here, something’s there, so there’s not a pure mapping. From the application level, I don’t think that there’s cloud providers specific things. At the infrastructure level, there are definitely certain things, but I don’t think that they’re specific enough that it would actually hinder you from moving from one to the other.
Corey: Okay, thank you. It’s always been a strange question and on the one hand you could approach a cloud provider as more or less, “Oh, they just provide us virtual computers.” What they do internally, and as a culture, and how they think about the world really doesn’t matter all that much to how you run your environment once you understand the constraints, versus if you go something in a full cloud native direction, then it turns into something that’s very, well, how do they think about this? How should I be architecting this? To some extent, if you gaze long enough into the Google abyss, do you become Google in some small way as far as how you think about operations, how you think about the responsible running of environments?
Seth: I think it depends on what you’re running too. One of Google’s big market segments is high performance computing. People doing like Genomics research, etc. or they might have some on premise data, and then they need elasticity of the cloud, like you said, there just launching VMs, and they view the cloud as an extension of compute and they’re launching them for a couple of hours, they’re running very complex genomic simulations or DNA stuff that I don’t understand because I haven’t taken a Biology class in 12 years.
But it’s very important, don’t get me wrong, the work is important but I just don’t understand it. What they look for in a cloud is very different than someone who’s looking to run microservices for example. That concept there, it’s different, it’s not just about what does the cloud provider offer, it’s also what problem are you trying to solve? That’s a key thing that I think we forget about every once in a while.
Corey: Perfect. Thank you very much for your time, Seth. Before we wind up calling it an episode, is there anything that you are working on that you’d like to draw attention to and have people check out?
Seth: In the short term not so much, in the long term you should look for a lot of the stuff that Google’s gonna be doing in the DevOps space. The things I talked about specifically with SRE and how SRE relates to DevOps. You should see some content coming out shortly, we’ll hopefully explain that a lot clearer.
Corey: Perfect. Thank you very much for your time, Seth, and enjoy the rest of the day.
Seth: Thanks Corey, you too.
Corey: This has been Screaming in the Cloud and I’m Corey Quinn.