Podcast appearances and mentions of seth vargo

About SethSeth Vargo is an engineer at Google. Previously he worked at HashiCorp, Chef Software, CustomInk, and some Pittsburgh-based startups. He is the author of Learning Chef and is passionate about reducing inequality in technology. When he is not writing, working on open source, teaching, or speaking at conferences, Seth advises non-profits.Links:Twitter: https://twitter.com/sethvargo TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: The company 0x4447 builds products to increase standardization and security in AWS organizations. They do this with automated pipelines that use well-structured projects to create secure, easy-to-maintain and fail-tolerant solutions, one of which is their VPN product built on top of the popular OpenVPN project which has no license restrictions; you are only limited by the network card in the instance.Corey: Couchbase Capella Database-as-a-Service is flexible, full-featured and fully managed with built in access via key-value, SQL, and full-text search. Flexible JSON documents aligned to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document database. Visit couchbase.com/screaminginthecloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella: make your data sing.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I have a return guest today, though it barely feels like it qualifies because Seth Vargo was guest number three on this podcast. I've had a couple of folks on since then, and for better or worse, I'm no longer quite as scared of the microphone as I was back in those early days. Seth, thank you for joining me.Seth: Yeah, thank you so much for having me back, Corey. Really excited to figure out whatever we're talking about today.Corey: Well, let's start there because last time we spoke, you were if memory serves a developer advocate at Google Cloud.Seth: Correct.Corey: And you've changed jobs, but not companies—but kind of companies because, welcome to large environments—but over the past few years, you have remained at Google. You are no longer at Google Cloud and you're no longer a developer advocate. In fact, your title is simply ‘Engineer at Google.' And what you've been focusing on, to my understanding, is helping Alphabet companies, namely—you know, the Alphabet, always in parentheses in journalistic styles, Google's parent company because no one thinks of it in terms of Alphabet—is—you're effectively helping companies within the conglomerate umbrella securely and privately consume public cloud.Seth: Yes, that is correct. So, I used to work in what we call the Cloud PA—PA stands for product area. Other product areas are like Chrome and Android—and I moved to the Core PA where I'm helping lead and run an initiative that, like you said, is to help Alphabet companies to, you know, securely and privately use public cloud services.Corey: So, I am going to go out on a limb because my position on multi-cloud has always been pick a cloud—I don't particularly care which one—but pick one and focus on that. I'm going to go out on a limb and presume that given that you are not at Google Cloud anymore, but you are at Google, you probably have a slight preference as far as which public cloud these various companies within the umbrella should be consuming.Seth: Yeah. I mean, obviously, I think most viewers will think the answer is GCP. And if you said GCP, you would be, like, 95% correct.Corey: Well, you'd also be slightly less than that correct, because they're doing a whole rebrand and calling it Google Cloud in public, as opposed to GCP. You really don't work for the same org anymore. You're not up-to-date on the very latest messaging talking points.Seth: I missed—ugh, there's so many TLAs that you lose all your TLAs over time.Corey: Oh, yes.Seth: So, Google Cloud would be, like, 95% correct. But what you have to really understand is, Google has its own, you know, cloud—we didn't call it a cloud at the time, you might call it on-prem or legacy infrastructure, if you will—primarily built on a scheduling system called Borg, which is like Kubernetes version zero. And a lot of the Alphabet companies have workloads that run onboard. So, we're actually talking about hybrid cloud here, which, you know, you may not think of Google is like a hybrid cloud customer, but a workload that runs on our production infrastructure called Borg that needs to interact with a workload that runs on Google Cloud, that is hybrid cloud, it's no different than a customer who has their own data center that needs peering to a public cloud provider, you know, whether that's Google Cloud, or AWS, or Azure.I think the other thing is if you look at, like, the regulatory space, particularly a lot of the Alphabet companies operate in, say, like healthcare, or finance, or FinTech, where certain countries and certain jurisdictions have regulations around, like, you must be multi-cloud. You know, some people might say that means you have to run, you know, the same instance of the same app across clouds, or some people say your data can be here, but your workloads can be over there. That's to be interpreted, but you know, I would say 95% of GCP, but there is a—or sorry, 95% is Google Cloud—Corey: There we go.Seth: But there is a small percentage that is definitely going to be other cloud providers and hybrid cloud as well.Corey: My position on multi-cloud has often—people like to throw it in my face of, “See you gave this general guidance, and therefore whenever you say something that goes against it, you're a giant phony.” And it's yeah, Twitter doesn't do so well with the nuance. My position of pick a provider and go all-in is intended as general guidance for the common case. There are exceptions to this and any individual company or customer is going to have more context than that general guidance will. So, if you say you need to be in multiple clouds for certain reasons, you're probably correct.If you say you need to be in multiple clouds because your regulator demands it, you are certainly correct. I am not arguing against that in any way. I do want to disclaim my one of my biases here as well, and that is specifically that if I were building a startup today and I were not me—by which I mean having spent ten years in the AWS ecosystem learning, not just how it works, but how it breaks because that's important in production, and you know, also having a bunch of service owners at AWS on speed dial—and I, were approaching this from the naive, I need to pick a cloud, which one would I go with, my bias is for Google Cloud. And the reason behind that is the developer experience is spectacular as the primary but not only perspective on that. So, I am curious to know that as you're helping what are effectively internal customers move to Google Cloud, is their interaction with Google Cloud as a platform the same as it would be if I as a random outside customer, were using Google Cloud? Is there a bunch of internal backchannels? “Oh, you get the good kind of internal Google Cloud that most of us don't get access to?” Or something else?Seth: Yeah, so that's a great question. So first, you know, thank you for the kind words on the developer experience—Corey: They were honest words, to be clear. Let me be very direct with you, if I thought your developer experience was trash, I might not say it outright in their effort not to be, you know, actively antagonistic to someone I'm having on the show right now, but I would not say it if I didn't believe it.Seth: Yeah. And I totally—I know you, I've known you for many years. I totally believe you. But I do thank you for saying that because that was the team that I was on before this was largely responsible for that across the platform. But back to your original question around, like, what does the support experience look like? So, it's a little bit of both.So, Alphabet companies, they get a technical account manager, very similar to how, you know, reasonable-sized spend customer would get a technical account manager. That account manager has access to the Cloud support channels. So, all that looks the same. I think we're things look a little bit different is because myself and some of our other leads came from Cloud, you know, I generally don't like this phrase, but we know people. So, we tend not to go directly to Cloud when we can, right?We want Alphabet companies to really behave and act as if they were an external entity, but we're able to help the technical account manager navigate the support process a little bit better by saying like, “You need to ask for this person,” right? You need to say these words to get in front of the right person to get this ticket assigned to the right person. So, the process is still the same, but we're able to leverage our pre-existing knowledge with Cloud. The same way, if you had a [unintelligible 00:07:45] or an ex-Googler who worked for your company, would be able to kind of help move that support process along a little bit faster.Corey: I am quite sincere when I say that this is a problem that goes far beyond simply Google. A disturbing portion of my job as a cloud economist helping my clients consists of nothing other than introducing Amazonians to one another. And these are hard problems at scale. I work at a company with a dozen people in it. And it turns out that yeah, it's pretty easy to navigate who's responsible for what. When you have a hyperscale-size company in the trillion-dollar range, a lot of that breaks down super quickly.Seth: And there's just a lot of churn at all levels of the organization. And, you know, we talked about this when I first joined the show, like, I switched roles, I used to be in Cloud, and now I'm in what we call Core. I still get people who are reaching out to me, at Google and externally, who are saying, “Oh, can you answer this question? Hey, how do I do this?” And I, you know, I've gradually over the past couple of months, you know, convinced people that I don't work on that anymore, and I try to be helpful where I can, but the—Corey: You use the old name and everything. They're eventually going to learn, right?Seth: I know. They'll be like, “What do you call this? GCP? Okay, great. We don't need you anymore.” But it's true, right? Like, there's people leave the organization, people join the organization, there's reorgs, there's strategic changes, people, you know, switch roles within the org, and all of that leads to complexity with, you know, navigating, what is the size of a small nation, in some cases.Corey: Your line in your biography says that you enable Alphabet companies to securely and privately consume public cloud. Now, that would make perfect sense and I would really have no further questions based on what we've already said, except for the words securely and privately, and I want to dive into that, first. Let's work backwards with the second one first. What is ‘privately' mean in this context?Seth: So, privately means, like, privacy-preserving for both the Alphabet company and the users or customers that they have. So, when we look at that from the perspective of the Alphabet company, that means protecting their data from the eyes of the cloud provider. So, that's things like customer-managed encryption keys, you know, bring-your-own-encryption, that's making sure that you have things like, actually, transparency so that if at any point the cloud provider is accessing your data, even for a legitimate purpose, like submitting a support ticket or something—or diagnosing a support ticket, that you have visibility into that. Then the privacy-preserving side on the Alphabet company's customers is about providing that same level of visibility to their customers as well as making sure that any data that they're storing is, you know, private, it's not accessible to certain parties, it's following whether it's like, you know, actual legislation around how long data can be persisted, things like GDPR, or if it's just a general, like, data retention, insider risk management, all of that comes into this idea of, like, building a private system or privacy-preserving system.Corey: Let's be very clear that my position on it is that Google's relationship with privacy has been somewhat challenged, in due to no small part to the sheer scale of how large Google has grown. And let's be clear, I believe firmly that at certain points of scale, yeah, you deserve elevated levels of scrutiny. That is how we want society to function, by and large. And there are times where it feels a little odd on the cloud side. For example, as the time is recording, somewhat recently, there was a bug in some of the copyright detection stuff where Google Drive would start flagging files as having copyright challenges if they contained just the character ‘1' in them.Which, okay, clearly a bug, but it was a bit of a reminder for some folks that wait, but that's right, Google does tend to scan these things. Well, when you have a bunch of end-user customers and in the ways that Google does, that stuff is baked in and it shapes how you wind up seeing things. From Amazon's perspective, historically, they basically sold books and then later underpants. And doing e-commerce transactions was basically the extent of their data work with customers. They weren't really running large-scale, file sharing systems and abilities—in collaboration suites, at least not that really had any of those pesky things called customers.So, that is not built into their approach and their needs in the same way. To be clear, I am sympathetic to the problems, but it's also… it's a challenging problem, especially as you continue to evolve and move things into cloud, you absolutely must be able to trust your cloud provider, or you should not be working on that cloud provider, has been my approach.Seth: Yeah, I mean, there's certainly things that you can do to mitigate. But in general, like, there is some level of trust, forget the data, on the availability side, right? Like when the cloud provider says, “This is our SLA.” And you agree to that SLA, like, yeah, you get money back if they mess it up, but ultimately, you're trusting them to adhere to that SLA, right? And you get recompense if they fail to do so, but that's still, like, trust—trust is far more than just on the privacy side, right? It's on… the promise on the roadmap, it's on privacy, it's on the SLA, right?Corey: Yeah. And you see that concern expressed more articulately from enterprise customers, when there's a matter of trusting companies to do what they say, such as the continued investment that Alphabet slash Google is making in Google Cloud. It's easy to take the approach of well, you've turned off a bunch of consumer services, so therefore, you're going to turn off the cloud at some point, too. No, let me be very clear, for the record, I do not believe that you are going to one day flip a switch and turn off Google Cloud. And neither do your customers.Instead, the approach, the way that enterprises express this, it's not about you flipping the switch and turning it off—that's what contracts are for—their question, and they enshrine this in contracts, in some cases, in the event, not that you turn it off, but that you fail to appropriately continue to invest in the platform. Because at enterprise scale, this is how things tend to die. It is not through flipping a switch, in most cases, it's through, “We're just going to basically mothball it, keep it more or less exactly as it is until it slowly fades into irrelevance for a long period of time.” And when you're providing the infrastructure to run things for serious institutions, that part isn't okay. And credit where due, I have seen every indication that Google means it when they say this is an area of strategic and continued ongoing focus for us as a company.Seth: Yeah, I mean, Google is heavily investing in cloud. I mean, this is a brand new group that I'm working in and we're trying to get Alphabet companies onto cloud, so obviously there's some very high-level top-down executive support for this. I will say that the—a hundred percent agree with everything you're saying—the traditional enterprise approach of build this Java app—because let's be honest, it's always Java—build this Java app, compile it into a JAR and run it forever is becoming problematic. We saw this recently with, like, the log4j—Corey: Yeah, to be in a container. What the hell?Seth: [laugh].Corey: I'm kidding. I'm kidding. Please don't send me email, whatever you do.Seth: What's a container? I'm just kidding. Like, the idea of, like, software rotting is very real and it's becoming more and more of a risk to security, to privacy, to public cloud providers, to enterprises, where when you see something like log4j happen and you can't answer the question, like, do we have any code that uses that? Like, if getting the answer to that question takes you six weeks, [sigh] boy like, a lot of stuff can happen in six weeks while that particular thing is exploited. And you know, kind of gets into software supply chain a little bit, but I do agree that, like, secure, private, and stable APIs are super important, and it's an area where Google is investing. At the same time, I think the industry is moving, the enterprise industry is moving away a little bit from set-it-and-forget-it as a strategy.Corey: I want to talk about the security portion as well as far as securely consuming public cloud goes. And let me start off with a disclaimer here because I don't want people to misconstrue what I'm about to say. If you are migrating to one of the big three cloud providers, their security will be better than anything you will be able to achieve as a company yourself. Not you personally because Google is a bit of an asterisk to that statement, given what you have been doing and have been doing since the '90s in your on-prem world with Borg and the rest, but my philosophy on the relative positioning of the security of cloud providers relative to one another has changed. I spent four months beating the crap out of Azure forever having an issue where there was control plane access and then really saying nothing about it.And after I wound up finding—the day after I put out a blog post on that topic because I was tired of the lack of response, it came out that right at the same time AWS had a very similar problem and had not said anything themselves. And they went back and forth, apparently waiting to wind up doing a release until this happened, Orca Security wound up putting one out there, and it was frustrating on a couple of levels. First, the people at both of these companies who work in security are stars. There is no argument, no bones about that. Problems are going to happen, things are going to occur as a result, and the only saving grace then is the transparency and communication around it, and there was none of it from them.I'm also more than a little bit irked that my friends at AWS were aware of this, basically watched me drag Azure for four months knowing that they'd done the same thing and never bothered to say a word. But okay, that's a choice. I've been saying for a while that of the big three, Google's security posture is the most impressive. And it used to be a slight difference. Like, you nosed ahead of AWS in that respect, not by a huge margin, but by a bit.I don't think it's nearly as close these days, in my mind, and talking to other large companies about these things, and people who are paid to worry about these things all day long, I am very far from alone in that perspective. So, I guess my question for you is, as you look at moving the workload securely to Google Cloud, it feels like security is baked into everything that all aspects of your company have done. Why is that a specific area of focus? Or is that how it gets baked into everything you folks do?Seth: So, you kind of like set up the answer for this perfectly. I swear we didn't talk about this extensively beforehand.Corey: You didn't know any of that was coming, by the way, just to be very clear here. I don't sit here and feed, “All right, I'm going to say this. And here's the right res—” No, this is an impromptu, more or less ad hoc show every time I do it.Seth: Yeah. And I'm going to preface this by saying, like, I don't want this to sound, like, egotistical, but I have never found a company that has as rigorous security and privacy policies, reviews, and procedures as Google.Corey: I thought I had and I was wrong.Seth: Yeah. And—Corey: And I have a lot of apologizing to people to do as a result of that.Seth: And honestly, every time I interact with our internal security engineering teams, or our IP protection teams, I'm that Nathan Fillion meme, where he's like, what—you know, like, “Okay, I get it. I get it.” Right?Corey: And then facepalm it, uh, I should say some—I can't—yeah. Oh, yeah.Seth: The reason that it's hard for Alphabet companies to securely and privately move to cloud specifically for security, is because Alphabet's stance is so much more rigorous than anyone else in the industry, to the point where, in some cases, even our own cloud provider doesn't meet the bar for what we require for an internal workload. And that's really what it comes down to is, like, the reason that Google is the most secure cloud is because our bar is so high that sometimes we can't even meet it.Corey: I have to assume that the correct answer on this is that you then wind up talking to those product teams and figure out how to get them to a point where they can support that bar because the alternative is effectively, it's like, “Oh, yeah, this is Google Cloud and it's absolutely right for multinational banks to use, but you know, not Google workloads. That stuff's important.” And I don't think that is necessarily how you folks tend to view these things.Seth: So, it's a bidirectional stream, right? So, a lot of it is working with a product management team to figure out where we can add these additional security properties into the system—I should say, tri-directional. The second area is where the policy is so specific to Google that Google should actually build its own layer on top of it that adds the security because it's not generally applicable to even big, huge cloud customers. And then the third area is Google's a very big company. Sometimes we didn't write stuff down, and sometimes we have policies where no one can really articulate where that policy came from.And something that's new with this approach that we're taking now is, like, we're actually trying to figure out where that policy came from, and get at the impetus of what it was trying to protect against and make sure that it's still applicable. And I don't know if you've ever worked with governments or you know, large companies, right, they have this spreadsheet of hundreds of thousands of lines—Corey: You are basically describing my client list. Please continue.Seth: I mean, like, sometimes they have to use an Access database because they exhaust the number of rows in an Excel spreadsheet. And it's just checklist upon checklist upon checklist. And that's not how Google does security, right? Security is a very all-encompassing, kind of, 360 type of thing. But we do have policies that are difficult to articulate what they're actually protecting against, and we are constantly re-evaluating those, and saying, like, “This made sense on Borg. Does it actually make sense on Cloud?” And in some cases, it may not. We get the same protections using, say, a GCP-native service, and we can omit that requirement for this particular workload.Corey: This episode is sponsored by our friends at Oracle Cloud. Counting the pennies, but still dreaming of deploying apps instead of “Hello, World” demos? Allow me to introduce you to Oracle's Always Free tier. It provides over 20 free services and infrastructure, networking, databases, observability, management, and security. And—let me be clear here—it's actually free. There's no surprise billing until you intentionally and proactively upgrade your account. This means you can provision a virtual machine instance or spin up an autonomous database that manages itself, all while gaining the networking, load balancing, and storage resources that somehow never quite make it into most free tiers needed to support the application that you want to build. With Always Free, you can do things like run small-scale applications or do proof-of-concept testing without spending a dime. You know that I always like to put asterisks next to the word free? This is actually free, no asterisk. Start now. Visit snark.cloud/oci-free that's snark.cloud/oci-free.Corey: I think that when it comes to things like policies that are intelligently crafted around security, you folks—and to be fair, the AWS security engineers as well—have been doing it right in that, okay, we're going to build a security control to make sure that a thing can't happen. That's not enough. Then there's the defense-in-depth. Okay, let's say that control fails for some variety of ways. Here are the other things we're going to do to prevent cross-account access, for example.And that in turn, winds up continuing to feed on itself and build into a culture of assuming that you can always continue to invest in security. How far is enough? Well, for most folks, they haven't gone far enough yet.Seth: Another way to put this is like, how well do you want to sleep at night? You know, there's folks on the Google security engineering team who are so smart, and they work on, like, our offensive security team, so their full-time job is to try to hack Google and then figure out how to prevent that. And, you know, so I've read some of the reports and some of the ways they think and I'm like, “How do you… how do you pick up a mobile phone and go to like, any website confidently knowing what you know?” Right? [laugh] and like, how do you—Corey: Who said anything about confidently? Yeah.Seth: Yeah. Yeah. How do you use self-checkout at a supermarket and, like, not just, like, wear your entire full-body tinfoil hat suit? But you know, I think the bigger risk is not knowing what the risks are. And this is a lot what we're seeing in software supply chain, too, is a lot of security is around threat modeling and not checklists. But we tend to, like, gravitate toward checklists because they're concrete.But you really have to ask yourself, like, do I need the same security properties on my static blog website that is stored on an S3 bucket or a GCS bucket that's public to the internet, that I do on my credit card processing service? And a lot of times we don't treat those differently, we don't apply a different threat model to them, and then everything has to have the same level of security.Corey: And then everything is in-scope for whatever it is you're trying to defend against. And that is a short path to madness.Seth: Yes. Yes. Your static HTML files and your GCS bucket are in scope for SOC 1 and 2 because you didn't have a way to say they weren't.Corey: Yeah. You've also done some—again, the nice thing about being at a company for a while—from what I can tell, given that I've never done until I started this place—is you move around and work on different projects. You were involved as well, personally, in the exposure notifications project, the joint collaboration thing between a number of companies in the somewhat early days of the pandemic that all of our phones talk to one another and anonymously and in a privacy-preserving way, let us know that hey, by the way, someone you were in close contact with has tested positive for Covid 19 in the previous fixed period of time. What did do you do over there?Seth: Yeah, so the exposure notifications project was a joint effort, primarily between Apple and Google to use Android and iOS devices to help stop the spread of Covid or reduce the spread of Covid as much as possible. The idea being because the incubation period is roughly 14 days, at least pre-Omicron, if we could tell you hey, you might have been exposed and get you to stay at home for three or four days, self-isolate, we could dramatically reduce the spread of Covid. And we know from some of the studies that have come out of, like, the UK and European region that, like, the technology actually reduced the spread of cases by, like, fourteen-hundred percent in some cases. I was one of the tech leads for the server-side. So, the way the system works is it uses the low-energy Bluetooth on iOS and Android devices to basically broadcast random IDs.So, I know this is Screaming into the Cloud, but if we can just quickly Screaming into the Void as a rebrand—Corey: Oh, yeah.Seth: —that's basically what's happening. [laugh]. You're generating these random identifiers, and just, like, yelling them, and there's other phones out there who are listening. And they collect these we'll call RPIs—or Rolling Indicators. They have no data in them.They're like literally, like, a UUID or 32 bytes of random data, they aren't at all, like, associated with your device or your person. So, then what happens is, like, let's say you're in a supermarket, you're near someone for, you know, every so often, and your phones exchange these IDs. If you then test positive, those IDs go up to a centralized server, the server again, also has no idea who you are, so the whole thing is privacy-preserving, end-to-end, then the server basically bundles all of what we call the TEKs, or the Temporary Exposure Keys—into a tarball that go up onto a CDN, and then every night, all of the devices that are participating in EN download this into a local key match. So, at no point does the server ever know that you were in a supermarket with someone else, only your phone knows that you came in contact with this TEK in the past 14 days—or 21 days in some jurisdictions—and it'll generate an exposure notification or an exposure alert, which says, like, “Hey, in the past 14 days, you've come in contact with someone who's confirmed positive for Covid.” And then there's guidance kind of varies by state and by health jurisdiction of, like, self-isolate, or go get tested, or whatever. But the idea—Corey: Or go to the bar in some places, apparently.Seth: Oh. Yeah. The server itself is actually—there's a verification component because ideally, like, we don't want people to just be like, oh, I'm Covid positive, and then like, all their friends get an alert, right? There needs to be some kind of verification mechanism where you either have a positive test, or you have a clinician or a physician who issues you code that you can put into your app so you can then release your keys. And then there's the actual key server component, which I kind of already described.So, it's a pretty complex system and actually is entirely serverless. So, the whole thing, including all, like, background job processing, it was designed to be serverless from the beginning. Total greenfield project, right, like, nothing like this exists, so we're really fortunate there. We made some fun and interesting design decisions to keep costs down while, you know, abusing slash using some of the features of serverless like auto-scaling and, you know, being able to fan out across multiple regions and things like that—Corey: And using DNS as a database. My personal favorite approach to things?Seth: We don't use DNS as a database. We do use Postgres—Corey: A missed opportunity.Seth: —a real database. But we do use DNS, just not for storing information.Corey: So, one question I have for you is that you've been at Google for a while and you've done an awful lot of things there, but previously, you've also done things that don't really directly aligne any of this stuff going on there. You were at HashiCorp and you were at Chef, neither of whom, to my understanding are technologies that Google makes extensive use of internally for their own stuff. It seems like—and even when you're at Google, you have been continually reinventing what it is that you do. I find that admirable because very often, when you see people at a company for a protracted period of time, they sort of get more or less pigeonholed into the role that looks fairly similar from year-to-year. You've been incredibly dynamic. Was it intentional and how do you do it?Seth: So, I have a diagnosed medical condition called Career-DHD. I'm just kidding, but I do. I get bored, and it's actually something that I'm really forward with my managers about. I've always been very straight with my managers and the people I work with it, like, 8 to 12 months from now, I will be doing something different. It will be different.Corey: I wish I'd figured that out earlier on. In my case, the way that I wound up solving for that is I've got to come in, I'm going to solve a interesting problem. When I'm done with that, the consulting engagement is over and then I'm going to go away and everyone knows the score going in. Works out way better than, and then I'm going to go cause problems on purpose in other people's parts of the org because I see problems there. That was where I always went off the rails.Seth: [laugh]. Yeah, I mean, I don't take a dissimilar approach. You know, I try to find high-priority, strategic things that also align with my interest. And it's important to me that there's things that I can provide and things that I can learn. I never like to be the smartest person in the room because you shouldn't be in that room anymore; there's no one for you to learn from. And it's great to share knowledge, but—Corey: I'm not convinced I'm the smartest person in the room right now, despite the fact that right now I'm the only person in the room that I'm sitting in.Seth: I mean, that Minecraft store is pretty intelligent.Corey: I saw Chihuahua wandering around here, too, a—Seth: [laugh].Corey: —minute ago, so there is that.Seth: But, you know, I think from, like, a career advice standpoint, I tell everyone, you should interview somewhere else at least once a year. You never know what's out there, and worst-case scenario, you kept your interview skills up to date.Corey: Keeping those skills in tune is so critically important just because it's a unique skill set that, for many folks, does not have a whole lot of applicability in their day-to-day job. So, if you suddenly have to find a new job, great, you're rusty at this, it's been years, and you're trying to remember, like, okay, when someone asks you what you're looking for in your next job, they're not trying to pick a fight. Don't respond as if they were. Like, the basic stuff. It's a skill, like anything else.Seth: Yeah. And, like, the common questions like, you know, “What do you want to do with your life?” Or like, “What accomplishment are you most proud of?” Like, having those not prepared, but like knowing in general what you want to say from those is very important when you're thinking about interviewing for other jobs. But even in a big company, like the transfer process is, pretty similar for, like, applying externally to other roles; like sometimes there's interviews—Corey: Do they make you code on whiteboards to solve algorithm problems?Seth: Not me. But—Corey: Good.Seth: —in general—Corey: Google has evolved its interview process since the last time I went through that particular brand of corporate hazing. Good, good, good.Seth: Yeah. The interview process has definitely been refactored a lot, especially with Covid and remote, but also just trying to be accessible to folks. I know one of the big changes Google has made is we no longer require, like, eight congruent hours of your time. You can split interviews out over multiple days, which has been really accommodating for folks that have, you know, already have a full-time job or have family obligations at home that don't let them just, like, take eight hours away and devote a hundred percent of their time to interviews. So, I think that is, you know, not a whole lot of positive things that come out of Covid, but the flexibility with, like, interviewing has enabled more people to participate in the interview process that otherwise would not have been able to do so.Corey: And there's something to be said, for making this more accessible to folks who come from backgrounds that don't all look identical. It's incredibly important.Seth: Yep.Corey: One thing that I definitely want to make sure we get to before the end of this is something you've been talking about that's a bit orthogonal, but maybe not entirely so, which is software supply chain security. That has been a common thread of discussion in some circles for a while. What is it, for those who are unfamiliar, like me sometimes, and what does it imply?Seth: Yeah, so I mean, in the past year—but if you look back, you'll find more cases of it—. We live in a world where no company—Google, Amazon, the US government—writes every line of code that they run. And even if you do, right, even if you could find a company that doesn't rely on any external dependencies, what language are they using? Did they write that language? Okay, let's say hypothetically, you write every single line of code and you wrote your own language, and only your employees contribute to that language.What operating system are you running on? Because I guarantee you, Linus probably contributed to it, or Gates contributed to it, and they don't work for you. But let's say you wrote your own operating system, right—so we're getting into, like, crazy Google things now, right? Like, only Google would write their own programming language and their own operating system, right? Who manufactured your CPU, right? Like, did you actually—Corey: There's always dependencies all the way down. We see this sometimes with companies talk about oh, yeah, we're going to go to multiple clouds or a different clouds so that we don't get impacted if there's another AWS outage in us-east-1. Cool, great. Power to you, but are you sure your payment providers not going to go down? Are they taking a dependency on us-east-1?Great, let's say that they're not. Are you sure that their vendors who are in the critical path are also not taking critical and core dependencies on that? And are you sure that they're aware of who all of those critical dependencies and those vendors are, and so on and so forth? It is a vast interconnected web. This is a problem. Dependency sprawl is real and I don't think that there's a good way to get to the bottom of it, particularly across company boundaries like that.Seth: Yeah. And this is where if you look at the non-software supply chain, like, if you look at construction, right? If you're working with a reputable construction agency, they're actually able to tell you, given a granite countertop or, you know, a quartz countertop, from what beach and what lot on what date the grains of sand in that countertop came from. That is a reality of that industry that is natural. You think about, like, automotive, like, VIN, the Vehicle Identification Numbers, like, they tell you exactly what manufacturer, and then there's records that show you exactly what human being on the line put that particular part in that machine.And we don't have that in software today. Like, we have some, you know, bastardized versions of, like, Software Bills of Material, or SBOM, but the simple fact of the matter is like because software has grown organically and because this wasn't ingrained in software from the beginning like it was from, you know, traditional manufacturing, you're going to have an insecure software supply chain for most of my life. Now, what does that actually mean, right—insecure has this negative connotation—it means that you need to make sure that you're aware of everything that you're depending on—which is kind of what you were saying is, like, both the technical dependencies and the process or the people dependencies—and you need to have a rigorous process for how you're going to respond to these incidents. And I think log4j was a really good eye-opening moment for folks when they realized that they didn't have a way to make a large-scale dependency update across their entire fleet of applications.Corey: Because who has to do that on a consistent basis? It happens rarely, but when it happens, it's super important.Seth: But I do think that more and more, we're going to see it happened more and more frequently. And ideally, you know, my opinion is that we're going to get to a point where this is inescapable, but ideally, we get to the point where it's like, “Oh, okay, this dependency is vulnerable. I have a playbook. I follow the playbook. Everything is patched in 30 minutes or less, and I can move on with my life.” And it's not a six-week fire drill with people working late and, you know, going super crazy, trying to mitigate these issues.You know, there's a lot of work happening in this space. We have, like, SLSA, which is an open standard—SLSA—for how you declare, kind of like, your software bill of materials and things like binary authorization and attestations. There's, like, Sigstore, there's Chainguard, there's some companies evolving in this space. Every time I talk to GitHub, I tell them, I'm like, “Hey, if this VP and that VP, like, talked together and, like, worked on something, you could do something amazing in this space.” But I think it's going to be quite a while until we get to a point where we can say the software supply chain is secure.Because like I was saying at the beginning, like, until you manufacture your own CPU, like, you're dependent on Intel and AMD. And until you write your own programming language, you're dependent on Ruby, Python, Go, whatever it might be. And until you take no dependencies on some external system—which by the way, might be a bad business decision, like, if someone did the work for you already in an open-source ecosystem, it's probably a better business decision to evaluate and use that than to build it yourself. Until we have the analysis on that supply chain, and we can in a dashboard, or the click of a button, or the run of a command, very easily see the security status of our supply chain—software supply chain—and determine if a particular vulnerability is or is not relevant, I think we're still going to be in this firefighting mode for at least another couple of years.Corey: And I want to say you're wrong, but I know you're not. And that's what, I guess, keeps a lot of us awake at night for unfortunate reasons. Seth, I really want to thank you for taking the time to speak with me. If people want to learn more, where's the best place to find you?Seth: I'm on Twitter. You can find me at—Corey: I'm sorry to hear that. So, am I. It's the experience.Seth: Yeah, you can find me at @sethvargo. If you say mean and hateful things to me, I actually exercise this finger, and you can click the block button real fast. But yeah, I mean, my DMs are open. If you have any questions, comments, complaints, concerns, you can throw the complaints away and come to me for everything else.Corey: Thank you so much for being so generous with your time. I really appreciate it.Seth: Yeah, thanks for having me. It's always a pleasure.Corey: Seth Vargo, engineer at Google. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you've hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment asking how dare I malign the good name of the other cloud provider that isn't Google that also just so coincidentally happens to employ you.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Our old pal Mark Mirchandani is back this week, joining Stephanie Wong and our guests Steve McGhee and Yuri Grinshteyn to talk about Site Reliability Engineering. SRE is Google’s way of helping companies of all sizes create consistent, predictable, and functional projects. It helps clients approach operations from a software engineering stand point so that growing systems can be managed efficiently. We talk about the challenges of implementing best SRE practices and how companies can overcome these. Though the benefits of SRE are many, it can be difficult for clients to grasp. Steve and Yuri tell us the process they go through with customers to help them set realistic goals and work to make reliable, scalable projects with little downtime. By starting small and taking wins early, Steve says clients reap the rewards of SRE and are encouraged to push forward. Yuri’s customer-centric approach encourages companies to prioritize alerts that affect the user experience, thus limiting inbox mayhem and keeping customers happy. Alerts based on symptoms, Steve says, help accomplish this goal. Later, Yuri and Steve describe the best ways for companies to get started with SRE. Realistic goals and specific detailed plans can make the journey less bumpy for clients, and Google’s SRE team can help. Steve McGhee Steve was an SRE at Google for about 10 years, then left to help a company build reliable systems on the Cloud. Now he’s back at Google, helping more companies do that. Yuri Grinshteyn Yuri works with Google Cloud Platform customers to help them design, architect, build, and operate reliable applications and services. He also advocates for SRE principles and practices on YouTube and elsewhere. Cool things of the week Fresh updates: Google Cloud 2021 Summits blog Why you need to explain machine learning models blog GCP Podcast Episode 260: Responsible AI with Craig Wiley and Tracy Frey podcast GCP Podcast Episode 249: ML Lifecycle with Dale Markowitz and Craig Wiley podcast GCP Podcast Episode 214: AI in Healthcare with Dale Markowitz podcast Interview Site Reliability Engineering site Reliability Architecture Framework site Site Reliability Engineering: Measuring and Managing Reliability on Coursera site Developing a Google SRE Culture on Coursera site How Lowe's meets customer demand with Google SRE practices blog GCP Podcast Episode 68: The Home Depot with William Bonnell podcast GCP Podcast Episode 213: The Art of SLOs with Alex Bramley podcast GCP Podcast Episode 127: SRE vs Devops with Liz Fong-Jones and Seth Vargo podcast GCP Podcast Episode 72: Customer Reliability Engineering with Luke Stone podcast GCP Podcast Episode 38: Site Reliability Engineering with Paul Newson podcast GCP Podcast Episode 59: SRE II with Paul Newson podcast What’s something cool you’re working on? Yuri has been working on Engineering for Reliability. Stephanie has been working on her new series What's New in Networking.

About NathenNathen Harvey, Cloud Developer Advocate at Google, helps the community understand and apply DevOps and SRE practices in the cloud.  Nathen formerly led the Chef community, co-hosted the Food Fight Show, and managed operations and infrastructure for a diverse range of web applications. Links: cloud.google.com/devops: https://cloud.google.com/devops 97 Things every Cloud Engineer Should Know: https://shop.aer.io/oreilly/p/97-things-every/9781492076735-9149 Twitter: https://twitter.com/nathenharvey TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by Thinkst. This is going to take a minute to explain, so bear with me. I linked against an early version of their tool, canarytokens.org in the very early days of my newsletter, and what it does is relatively simple and straightforward. It winds up embedding credentials, files, that sort of thing in various parts of your environment, wherever you want to; it gives you fake AWS API credentials, for example. And the only thing that these things do is alert you whenever someone attempts to use those things. It’s an awesome approach. I’ve used something similar for years. Check them out. But wait, there’s more. They also have an enterprise option that you should be very much aware of canary.tools. You can take a look at this, but what it does is it provides an enterprise approach to drive these things throughout your entire environment. You can get a physical device that hangs out on your network and impersonates whatever you want to. When it gets Nmap scanned, or someone attempts to log into it, or access files on it, you get instant alerts. It’s awesome. If you don’t do something like this, you’re likely to find out that you’ve gotten breached, the hard way. Take a look at this. It’s one of those few things that I look at and say, “Wow, that is an amazing idea. I love it.” That’s canarytokens.org and canary.tools. The first one is free. The second one is enterprise-y. Take a look. I’m a big fan of this. More from them in the coming weeks.Corey: This episode is sponsored in part by our friends at Lumigo. If you've built anything from serverless, you know that if there's one thing that can be said universally about these applications, it's that it turns every outage into a murder mystery. Lumigo helps make sense of all of the various functions that wind up tying together to build applications.It offers one-click distributed tracing so you can effortlessly find and fix issues in your serverless and microservices environment. You've created more problems for yourself. Make one of them go away. To learn more, visit lumigo.io.Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. I’m joined this week by Nathen Harvey, a cloud developer advocate at a small startup called Google. Nathen, thank you for joining me.Nathen: Hey, Corey. It’s really great to be here.Corey: We’ll get to the Google bits in a little, but first, I want to start back in the beginning with your origin story. It turns out, for example, that you were at a lot of places, and the first thing going through your history that I really recognized was way back at the end of 2009, where you were the web operations manager at Custom Ink. They’re a t-shirt company—and other apparel—that I’ve been using for three years now for the charity t-shirt drive here, as well as other sundry things. Longtime listeners of the show might remember we had Ken Collins on to talk about Ruby in Lambda and other horrifying things, before it was cool.Nathen: Yes, indeed, I was at Custom Ink. And, you know, you talk about them being a t-shirt company, and I don’t know… maybe I’m still a shill for Custom Ink, but I really look at them as an experience company. And you’ve recognized that yourself. They produce and help people, really encourage that group and experiences, and really drive what does it mean to connect with other humans, and how can you do that through custom apparel? To me, that’s what Custom Ink has always been about. They’re not selling t-shirts; they are selling an experience.Corey: In my case, I view them as a t-shirt company because, let’s be fair here, I wind up doing charity t-shirt drives, and they’ve always been extremely supportive of—well, there’s really no other way to put this—my ridiculous nonsense. The year I had linked campaigns of the ‘AMI has three syllables’ shirt that was on sale, and then for the Amazonians, ‘ah-mi’ is how it’s pronounced instead and that one was $10 more because there’s a price to being wrong. And all proceeds, of course, went to benefit the charity of the year. And that was a fun thing. And I talked to a number of other folks on this, and they look at me very strangely, and Custom Ink didn’t even blink.Nathen: Right, right. Absolutely. Absolutely.Corey: And yes, they said lots of other apparel, but for whatever reason, it seems that sending out complicated multiple options of things that need each hit minimum order quantities to print during a fundraiser, and the fact that I don’t have to deal with the money because they just wind up sending it over directly. It’s just easier. It’s one of those things where back when I was a single person who was doing this stuff, I didn’t have to worry about it. Now that I’ve grown and my needs have multiplied, I still like doing business with them. Great folks.Nathen: Absolutely. And that’s exactly what I mean by—like, they’ve sold you on that experience. That’s why you continue to do business with them. It’s not just because of the t-shirts. It’s the whole package that goes along with it.Corey: And then in 2012, the world didn’t end. But yours kind of did because you stopped working at Custom Ink and went to another company called Chef. You were there for a little over six years. You started off as a community director and then became the VP of Community Development. And I think you did an amazing job, but first tell me about that, then I will give my hot take.Nathen: All right, great. I’m always up for the hot takes. So listen, Chef was an amazing community of people. Oh, it was also a company. And so I really fell in love with—while I was at Custom Ink, actually, we were using Chef, and I fell in love with the community.And I was doing a lot of community support, running my own podcast, or participating with some co-hosts on a podcast called the Food Fight Show back in the day—it was all about Chef—running meetups and so forth. And at one point I decided, you know, what I should do maybe is stop being on call and start supporting this community full time. And that’s exactly what I did. I went to Chef and yes, as you mentioned, spent just over six years there, or just about six years there, and it was really, really an incredible time. Lots of hugs to be given, and just a great community in the DevOps space.Corey: I took a somewhat, I guess, agreeing or disagreeing position. I was on the Puppet side of the configuration management debate, and it was challenging. And then, ah, I was one of the very early developers behind SaltStack because clearly, the problem with all of these things was that no one had written it correctly, and we were going to fix that. And it turns out no, no, the problem was customers the whole time. But that’s a separate debate.So, I was never in the Chef ecosystem. That was the one system I never really touched in anger. And it’s easy to turn this into a, “Oh, you folks were the competition,” despite the fact I’ve never actually worked directly for either of those companies. But it was never like that because our real enemies were people configuring things by hand, for one because that’s unnecessary toil; don’t do it, and it was also just such an uplifting sense of community. Some of the best people I knew were in the Chef ecosystem, in the Chef orbit.For a while, they’re, on some level—and this is something I’d love to get your thoughts on—it seems that a failure mode that Chef exhibited was hiring directly from its community, where if someone was a big fan of Chef, start a stopwatch, they’re going to be working there before the month is out.Nathen: I think that Chef, the company definitely pulled a lot of community members into the organization. And frankly, when the company started, that was really, really great because it was an early startup. And as the company grew, it was still wonderful, of course, to pull in people from the community to really help drive the future direction, how our customers are using it. But like you said, there is a little bit of a challenge or concern when you start pulling too many of your most vocal supporters out of the community and putting them into the company, sometimes in places or roles where they didn’t have the opportunity to be as vocal, as big a champions for the product, for the services.Corey: I think at some level, it was—again, it helps to have people who are passionate about the product working there, but on the other, it felt like over time, it wound up weakening the community in some respects, just because everyone who worked there eventually found themselves in a scenario of well, I work here, it’s what we do, and now I have to say nice things. It winds up weakening the grassroot story.Nathen: Mmm. There’s definitely some truth to that, but I think there’s also some truths to just the evolution of community as you went from a community in the early days where there were a lot of contributors to over time—gratefully so—the community that—or sort of the proportion of the community that were consumers of Chef versus contributors to Chef, that balance changed. And so you had a lot more customers using the product. So, I don’t disagree with you, but I do think that it’s part of the natural evolution of community as well.Corey: And all things must end. And of course, Chef got acquired, I believe, after you left. So, I mean, at that point, you left, they were rudderless and what else were they to do? And you went to Google. And that is always an interesting story because Google’s community interaction before the time you wound up there, and after—I don’t know that you were necessarily the proximate cause, but I’m going to hang that around your neck because it’s all been a positive change since then—look radically different.Nathen: Yeah. Well, thank you. It is definitely not something that I should wear or carry alone, but going to Google was an interesting choice for me and I recognize that. And, you know, honestly, Corey, one of the things that drove me to Google was a good friend of mine, Seth Vargo. And just to kind of tie the complete throughline here, Seth and I worked together at Custom Ink, we’ve worked together at Chef, he left Chef and went to Hashi, and then went to Google. And the day after I knew that he was going to Google, I called him up and I said, “Seth, come on. Google’s so big. Why? Why? And how? I don’t understand. I don’t understand the move.”Corey: I asked him many of the same questions back in episode three of this show. He was a very early guest when I was scared speechless having conversations. It’s improved since then, a couple hundred in. But yeah, very friendly; very open; very warm.Nathen: Yeah. And, you know—Corey: “Why are you at Google?” was sort of the next follow-on question there in that era.Nathen: [laugh]. Yes, indeed. And I do think that Google, and specifically Google Cloud, has really taken to heart this idea that there’s a lot that we can learn from each other. And I don’t mean from each other within Google. Although, of course, we can learn a lot from each other.But we can also learn a lot from our community, from our customer base. How are they using Google Cloud? How are they using technology to drive their business forward? These are all things that we can learn. It turns out, not every company has Google, and that’s a good thing.Not every company should be Google or Google-sized, and certainly don’t have Google customers. And I think that it’s really important that we recognize that when we work with a customer, they’re the experts in their customers, and in their systems, and so forth.Corey: A lot has changed with Google’s approach to, well, basically everything. It turns out that when you’re a company that is, what, 26 years old now—27, something like that—starting with humble beginnings and then becoming a trillion-dollar entity, things change. Culture change, your community changes, what you do changes, and that becomes something that I think is not necessarily fully appreciated or fully understood in some corners. But then 2018 hit. You went to Google; what did you do then?Because it is such a large company that it is very difficult to know what any individual is up to there, and the primary means that I engage in the DevRel community space—specifically via aggressively shitposting on Twitter—isn’t really your means of interacting with the community. So, from that particular point of view, it’s, “Oh, yeah, he went to Google, and no one ever heard from him again.” What is it you say it is you do there?Nathen: Yeah. So, for sure. What I do here as a cloud advocate, is I really focus in on kind of two areas, I would say: DevOps—and I recognize that is a terrible, terrible word because when I say it, we all think of different things, but I definitely focus on the DevOps—and then SRE practices as well, or Site Reliability Engineering. And specifically what I work on is how do we bring the principles and practices of DevOps, of SRE, into our customer base and into the community at large? How do we drive what is the state of the art?How do we approach these particular topics? And so that’s really what I’ve been focused on since joining Google. Well, frankly, I was focused on that while at Chef, as well, maybe without the SRE bend so much, but certainly at Google SRE comes in, but it’s always—for the past decade for me—been about DevOps and how do we use technology to align the humans and work towards the business outcomes that we’re driving for?Corey: And business outcomes become an interesting story in the world of cloud because it distills down, for a cloud service provider is, we would like people to use our cloud, more of it, in perpetuity. It is not a complicated business model—if I can be direct—because business models inherently are not. “Whatever it is your company does, we would like you to do it here.” And that turns into a bunch of differentiated services across the spectrum, in some cases hilariously so, when it turns into basically pick an English word, and there’s a 50/50 shot that’s part of a service name somewhere. But a lot of it distills down to baseline distinct primitives.You’re talking about the DevOps aspect of it, which is—we talk about, is it culture? Is it tools? No, it’s a means to sell conferences, and books, and things like that. But what is it in the context of a cloud service provider? Specifically, Google because let’s be clear here, DevOps apparently for other providers is Azure DevOps. That’s right. It’s a service name, and DevOps Guru on the AWS side because everything is terrible.Nathen: Absolutely. Look, I think that I used to snark that the only DevOps tool was the manager of DevOps. But the truth is that DevOps is… it is tooling, and it is culture, and to separate the two is really a fool’s errand. I think that your tooling amplifies your culture, your culture amplifies your tooling. Together, this is how we make progress.Now, when it comes to Google, what do we mean when we say DevOps? Well, one of the good things is, shortly after I joined Google Cloud, Google Cloud acquired DORA, the DevOps Research and Assessment Organization.Corey: Jez Humble, and Dr. Nicole Forsgren. And then, for all intents and purposes, they googled it. Relatively shortly thereafter, by which I mean, we never really heard from DORA again. In 2020, the “State of DevOps Report” didn’t exist, which was what they were famous for doing. And it was, “Oh, yep. That’s a Google acquisition all right.” Is that what happened? Did I miss some nuance there?Nathen: Yeah. Let’s talk about that. So first, you’re right, it was Dr. Nicole Forsgren, who founded DORA. So, when the acquisition happened, she came along to Google Cloud, Jez Humble came along through that acquisition as well. And frankly, what happened in 2020? Well, Corey, I don’t know if you noticed, but there was a lot happening in 2020, much of it not very good. I think when we look at the global scale, like, 2020 was not a great year for us—Corey: It was a rebuilding year.Nathen: Oh, all right, fair enough. Fair enough. [laugh]. A rebuilding year. But so here’s what happened with DORA, quite frankly. We—Google Cloud—continue to invest in that research program. And really, in a sense, 2020 was a rebuilding year, in that our focus was really about how do we help our customers and our community apply the lessons of DORA?And so one of the things that we’ve done is we’ve released much of the research under cloud.google.com/devops, including right there, a DevOps quick check where, as a team you can go in and, using the metrics and the research program from DORA, you can assess, are you a low, medium, high, or elite performer?And then beyond that assessment, actually use the research to help you identify which capabilities should my team invest in improving. So, those capabilities might be technical capabilities, things like continuous integration; it might be process or measurement capabilities, or in fact, cultural capabilities. So, all of these capabilities come together to help you improve your overall software delivery and operations performance. And so in 2020, the big thing that we did was release and continue to update this Quick Check, release the research, make it fully available. We’ve also spent some time internally on the program that, you know, is not super interesting to talk about on the podcast.But the other thing that we did in 2020 with the DORA research program was update the ROI research, the return on investment research. This is something that maybe your listeners don’t care about, but their managers might care about, their CIOs, CTOs, CFOs might care about. How do we get money back on this transformation thing? And the research paper really digs into exactly that. How do we measure that? What returns can we expect? And so forth. So, that was released in 2020.Corey: I have a whole bunch of angry thoughts about a lot of takes in that space, but this is neither the time nor the place for me to begin ranting incoherently for an hour and a half. But yeah, I get that it was a year that was off, and now you’re doing it again, apparently, in 2021. And the one thing I never really saw historically because I don’t know if I’m playing in the wrong environments, or I’m certainly not the target [laugh] audience now, if I ever really was, but most years, I missed the release of the survey of where people can go to fill in these questions. I would be interested to know where that is now. And then I would be interested to know, how have you been socializing in that in the past? In other words, where are you finding these people?Nathen: Yeah, for sure. So, the place you go to find the survey right now is cloud.google.com/devops, you’ll find a button on the page that says something like, “Take the survey,” or, “Take the 2021 survey.”And what we’ve done in the past, and really what DORA has done in the past is use a number of different ways to get out information about the survey, when the survey is open, and so forth. Primarily Twitter, but also we have partners, and DORA historically has used partners as well to help share that the survey itself is open. So, I would absolutely recommend that you go and check out the survey because I’ll tell you what, one of the things that’s really interesting, Corey, over the years, I’ve talked to a bunch of people that have taken the survey, and that have read the State of DevOps Report that comes out each year, and some of the consistent feedback I’ve heard from folks is that simply taking the survey and considering the questions that are asked as part of the survey gives great insight immediately into how their team can improve. What things, what capabilities are they lacking? Or what capabilities are they doing really well with and they don’t need to make investments on? They can immediately see that just by answering and carefully considering the questions that are part of the survey.Corey: This episode is sponsored by ExtraHop. ExtraHop provides threat detection and response for the Enterprise (not the starship). On-prem security doesn’t translate well to cloud or multi-cloud environments, and that’s not even counting IoT. ExtraHop automatically discovers everything inside the perimeter, including your cloud workloads and IoT devices, detects these threats up to 35 percent faster, and helps you act immediately. Ask for a free trial of detection and response for AWS today at extrahop.com/trial.Corey: Very often, in some cases looking at things like maturity models and the like, the actual report is less valuable than the exercise of filling it out and going through the process. I mean, compliance reports, audit framework, et cetera, often lead to the same outcomes. The question is, are you taking it seriously, or are you one of those folks who is filling out a survey because do this and you’ll be entered to win a $25 gift card somewhere? Probably Blockbuster because it no longer exists. I get those in my email constantly of, “Yeah, give half an hour of your time in return for some paltry chance to win something.”No, I have a job to do. And I worry if at that level of that approach, who are you actually getting that’s going to sit down and fill this thing out? That said, the State of DevOps Reports have been for a long time, sort of the gold standard in this space and I would encourage people listening to this to absolutely take the time to fill that out. cloud.google.com/devops.I’m looking forward to seeing what comes out of it. And I love it because of the casual shade you can use to throw at other companies, too. Like, “Are you an elite team?” With the implicit baked-in sentiment being, no, you’re not, but I want to hear you say it.Nathen: Yeah, one of the things that really sets DORA apart, also, I think, is just the—well, two of the things I guess I would say. One is the length of time that the research program has been running. It’s going on seven years now that this research program has been running, and so given that, you have tens of thousands of IT professionals that have taken the survey and provided insights into sort of what’s the state of our industry today, and where are we heading, but it’s also an academically rigorous survey. The survey and the research itself has always and continues to be completely platform and program agnostic. This is not a survey about Google Cloud.This is not a survey where we’re trying to help understand exactly what products on Google Cloud should you use in order to be an elite performer. No. That’s not what this is about. It is about, truly, capabilities that your team needs in order to improve their software delivery and operations performance. And I think that’s really, really important.Dr. Nicole Forsgren who founded DORA, she didn’t come up with all of these ideas: “Hey, I think that you get better by doing this.” No. Instead, she researched all of these ideas. She got this input from across organizations of all sizes, organizations in every industry, and that, I think, really sets it apart.And our ability to really stay committed to that academic rigor, and the platform-agnostic approach to capturing and investigating these capabilities, I think is so important to this research. And again, this is why you should participate in the survey because you truly are going to help us move the state of the art of our industry.Corey: No, historically, there’s been a challenge where the mantle of thought leadership in conjunction with Google have intersected because there’s a common trope—historical—and I think that it is no longer accurately true. It’s an easy cheap shot, but I don’t think it holds water like it once did. Where, “Oh, Googler. It’s another word for condescending.” And there is an element of “Oh, this is how DevOps should be; this is how we’re moving things forward.” How do you distance it from being Google says you should do it like this?Nathen: Yeah. This comes up a lot. And frankly, I get in conversations with customers asking, “How does Google do this? How does Google do that?” And my answer always is, “You know, I can tell you how Google does something, and that might be interesting, but the fact is, it’s not much more than that, much more than interesting. Because what really matters is how are you going to do this? How are you going to improve your outcomes, whether that’s you’re delivering faster, you’re delivering more reliable, you’re running more reliable services? You’re the experts. As I mentioned earlier, you’re the experts in your teams, in your technology, and your customers. So, I’m here to learn right along with you. How are you going to do this? How are you going to improve?” Knowing how Google does it, eh, it’s interesting, but it’s not the path that you will follow.Corey: I think that’s one of those statements that can’t ever be outright stated on a marketing website, somewhere; it’s one of those shifts that you have to live. And I think that Google’s done a pretty decent job of that. The condescending Googler jokes are dated at this point, and it’s not because there was ever an ad campaign about, we’re not condescending anymore. It was a very subtle shift in the way that Google spoke to its customers, spoke about themselves. I no longer feel the need to stand up in a blinding white rage in the Q&A portion of conference talks given by Google employees.A lot has changed, and it’s not one thing that I can point to, it’s a bunch of different things that all add up to dramatically shifted credibility models. Realistically, I feel like that is a microcosm of a DevOps transformation. It’s not a tool; it’s not a single person being hired; it’s not, we’re taking an agile class for three days for all of engineering, and now things will be better. It’s a whole bunch of sustained work with a whole bunch of thought, and effort put into making it an actual transformation, which is such a toxically overloaded term, I dare not use it.Nathen: Indeed. And there’s no maturity model that shows, are you there yet? And it is something that you don’t flip on or flip off like a switch, right? It doesn’t happen overnight. It takes iteration and iterative change across the entire organization.And just like every change that you have across an organization, there are places where it’s going better than other places. And how do you learn from that? I think that’s really, really important. And to recognize and to bring some of that humility to the table is so important.Corey: So, what’s interesting about folks that I talk to on this show—well, there are many interesting things, but one of the interesting things is, is that they have a higher rate than the general population of having at one point in their careers, written a book of some form, and you are, of course, no exception. You and Emily Freeman co-authored recently, a book entitled 97 Things every Cloud Engineer Should Know. And it’s interesting because it only has one nine in the title. Okay, that is at least an attempt at being available. I know it’s available wherever most books are sold. Tell me more.Nathen: Yeah, so first, let’s start with the 97. Why 97? Corey, I don’t know if this or not, but 100% is the wrong reliability target for just about everything. So, 97. That feels achievable.Corey: It also feels like three people said they would do it and then backed out at the last minute, but that’s my cynicism speaking.Nathen: Well, for better or worse, O’Reilly. Has a whole 97 Things series and this is part of it. So, it is, in fact, 97 things. The other thing that I think is really important about the book: you mentioned that Emily and I wrote it, and the beauty is, for a long time, I’ve wanted to have written a book, and I have never wanted to be writing a book.Corey: That is what every author has ever said. It’s, no one wants to write a book; they want to have written one. And then you get a couple of beers into people and ask them, “So, I’m debating writing a book. Should I?” The response is, “No. Absolutely not. No.” And at some point, when you calmed them down again, and they stop screaming, they tell you the horrifying stories, and you realize, “Oh, wow, I really never want to write a book.”Nathen: [laugh]. Yes. Well, the beauty of 97 Things and this book in particular, or the whole series, really, is its subtitle is Collective Wisdom from the Experts. So, in fact, we had over 80 different contributors sharing things that other cloud engineers should know. And I think this is also really, really important because having 80-plus contributors to this book gave us, not 97 things that Emily and Nathen think every cloud engineer should know, but instead, a wide variety of experience levels, a wide variety of perspectives, and so I think that is the thing that makes the book really powerful.It also means that those 80-some folks that contributed to the book, had to write a very short article. So, of course, with 80 authors and 97 Things, the book is not—it doesn’t weigh 27 pounds, right? It’s less than 300 pages long, where you get these 97 tidbits. But really, the hope and the intent behind the book is to give you an idea about what should you explore deeper and, just as importantly, who are some people that you can, maybe, reach out to and talk to about a particular topic, a particular thing that a cloud engineer should know. Here are 80 people that are here, helping you and really cheering you on as you take this journey into cloud engineering.Corey: I think there’s something to be said from having the stories for this is what we do, this is how we do it. But the lessons learned stories, those are the great ones, and it’s harder to get people on stage to talk about that without turning into, “And that’s how we snagged victory from the jaws of defeat.” No one ever gets on stage and says and that’s why the entire project was a boondoggle and four years later, we’re still struggling to recover. Especially, you know, publicly traded companies tend not to say those things. But it’s true.You wind up with people getting on stage and talking instead about these high-level amazing things that they’ve done in the project went flawlessly, and you turn to the person next to you and say, “Yeah, I wish I could work in a place like that.” And they say, “Yeah, me too.” And you check, and they work at the same place as the presenter. Because it’s conference-ware; it’s never a real story. I’m hoping that these stories go a bit more in-depth into the nitty-gritty of what worked, what didn’t work, and it’s not always ‘author as hero protagonist.’Nathen: Oh, you will definitely find that in this book. These are true stories. These are stories of pain, of heartache, of victory and success, and learnings along the way. Absolutely. And frankly, in the DevOps space, we do an okay job of talking openly about our failures.We often talk about things that we tried that went wrong, or epic failures in our systems, and then how we recovered from them. And yes, oftentimes, those stories have a great sort of storybook ending to them, but there’s a lot of truth in a lot of those stories as well because we all know that no organization is uniformly good at everything. That may be the stories that they want to share most, but, you know, there’s some truth in those stories that hopefully we can find. And certainly, in this book, you will find the good, the bad, the ugly, the learnings, and all of the lessons there.Corey: Where can people find it if they want to buy it?Nathen: Oh, you know, you can find it wherever you buy books. There are of course, ebooks, O’Reilly’s website, you know with the—Corey: Wherever fine books are pirated. Yes, yes.Nathen: That’s a good place to go for books, yeah. For sure.Corey: And we will, of course, throw a link to the book in the [show notes 00:29:12]. Thank you so much for taking the time to speak with me. If people want to learn more about the rest of what you’re up to, how you’re thinking about it, what wise wisdom you have for the rest of us, okay can they find you, other than the book?Nathen: Yeah, a great place to reach out to me is on Twitter. I am at @nathenharvey. But I should warn you, my father misspelled my name. So, it’s N-A-T-H-E-N-H-A-R-V-E-Y. So, you can find me on Twitter; reach out to me there.Corey: And we will of course include links to all of that in the [show notes 00:29:43] as well. Thank you so much for speaking to me today. I really appreciate it.Nathen: Thank you, Corey. It’s been a pleasure.Corey: Nathen Harvey, cloud developer advocate at Google. I’m Cloud Economist Corey Quinn and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry comment telling me that I’m completely wrong. You can instantly get DevOps in your environment if I only purchase whatever crap it is your company sells.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

On today's episode, Guy Podjarny, President and cofounder of Snyk, talks to Seth Vargo at DevSecCon Seattle. Seth previously worked at HashiCorp, Chef Software, CustomInk, and a few Pittsburgh-based startups. He is the author of Learning Chef and is passionate about reducing inequality in technology. Today, he is now a developer advocate at Google and is passionate about the human element of security. This discussion is centered around the talk Seth gave at DevSecCon Seattle titled, Secrets in Serverless. In this episode, we flesh out one of the core principles of this talk which is that security is not binary. Here we explore the often-unseen side of security and how developers can prevent or limit attacks by assuming from the get-go that their secrets will be leaked! If you're looking for practical, in-depth advice, as well as a leading, expert strategy that will shift your view on managing secrets in serverless – then this is the episode for you! Show notes and transcript can be found here 

Sponsored By: Panelists Justin Dorfman | Richard Littauer Guest Don Goodman-Wilson (https://twitter.com/DEGoodmanWilson) Maintainerati Foundation Show Notes In this episode we talk with Don Goodman-Wilson, from Amsterdam. He’s a philosopher-engineer experienced in developer advocacy, Founder of Katsudon.tech, and Board Member at Maintainerati Foundation. 1:18 Don explains Maintainerati’s mission and brings up a point about how to create a network of support among maintainers. 04:10 Don talks about having no insight in the Japanese open source community and the challenges must face not being able to communicate with others. 7:03 Justin asks Don what does DevRel means to him and he also explains what “empowerment” means to him as well. 10:26 Don explains what issues he tackled at Slack and GitHub. 16:17 Don wrote a post on open source about how it’s a bit broken. He explains how the current situation is radically skewed in favor of the business interests. 18:50 Richard asks Don to talk about what ethical implications might mean for open source and how do we fix it, work on it, and make it better for the developmental maintainers. 22:21 The panel and Don discuss how a maintainer, Seth Vargo, found out that his code was being used by a subcontractor for ICE and how ICE is currently having major humanitarian issues on the border. 28:21 Justin speaks about open source and section five of no discrimination against persons or groups. 32:10 Don chimed in about a talk he did at FOSDEM that challenged the assumption that open is the right thing. 35:27 Richard explains his views on academic linguistics and saving endangered languages and how to do it properly. Spotlights 38:33 Justin’s spotlight is tickgit (https://www.tickgit.com/) 39:15 Richard’s spotlight is Front Porch Forum (https://frontporchforum.com) 40:16 Don’s spotlight is Grape (https://github.com/ruby-grape/grape) Links Don Goodman-Wilson (https://don.goodman-wilson.com/) Open Source is Broken FOSDEM 2020 (https://don.goodman-wilson.com/talks/fosdem_2020/) katsudon.tech (https://katsudon.tech/) Maintainerati (https://maintainerati.org/) DEVREL (https://devrel.net/) Slack (https://slack.com/) GitHub (https://github.com/) Seth Vargo (https://mashable.com/article/chef-ice-seth-vargo/) Karl Popper (https://www.amazon.com/Open-Society-Its-Enemies-One/dp/0691158134) The Hippocratic License 2.0 (https://firstdonoharm.dev/) Special Guest: Don Goodman-Wilson.

Seth Vargo from Google Cloud joined us to talk about Berglas, an open source library for managing secrets on GCP. Contributors is produced by Rackner, a consultancy focused on cloud native product development, DevSecOps, and Kubernetes - https://www.rackner.com/

On Friday afternoon Chef CEO Barry Crist and CTO Corey Scobie sat down with TechCrunch to defend their contract with ICE after a firestorm on social media called for them to cut ties with the controversial agency. On Sunday, programmer Seth Vargo, the man who removed his open source components, which contributed to a partial shutdown of Chef's commercial business for a time last week, responded.

Happy Holidays, everyone! Melanie and Mark wrap up a great year by reminiscing about some of their favorite episodes! We also talk about the big news of the year, our favorite articles, and what’s coming up for the GCP Podcast in 2019. Cool things of the week Kubernetes and GKE for developers: a year of Cloud Console blog Reducing gender bias in Google Translate blog Cloud Security Command Center is now in beta and ready to use blog Main content Podcast accomplishments! We have awesome new intro and outro music, new website, new YouTube videos! We hit 1 million and then 2 million downloads! Mark and the podcast are celebrating their three year anniversary! Top 10 most downloaded episodes of all time! GCP Podcast Episode 111: Google Cloud Platform with Sam Ramji podcast GCP Podcast Episode 112: Percy.io with Mike Fotinakis podcast GCP Podcast Episode 146: Google AI with Jeff Dean podcast GCP Podcast Episode 127: SRE vs Devops with Liz Fong-Jones and Seth Vargo podcast GCP Podcast Episode 128: Decision Intelligence with Cassie Kozyrkov podcast GCP Podcast Episode 113: Open Source TensorFlow with Yifei Feng podcast GCP Podcast Episode 88: Kubernetes 1.7 with Tim Hockin podcast GCP Podcast Episode 108: Launchpad Studio with Malika Cantor and Peter Norvig podcast GCP Podcast Episode 130: Data Science with Juliet Hougland and Michelle Casbon podcast GCP Podcast Episode 125: Open Source at Google Cloud Platform with Sarah Novotny podcast Top 10 most downloaded episodes for 2018! Exact same list except Tim Hockin is not #7. Following episodes go up a number and we added to #10 spot. GCP Podcast Episode 122: Project Jupyter with Jessica Forde, Yuvi Panda and Chris Holdgraf podcast Mark’s favorite episodes GCP Podcast Episode 129: Developer Relations with Mandy Waite podcast GCP Podcast Episode 121: Kontributing to Kubernetes with Paris Pittman and Garrett Rodrigues podcast GCP Podcast Episode 131: Actions on Google with Mandy Chan podcast GCP Podcast Episode 148: Wellio with Sivan Aldor-Noiman and Erik Andrejko podcast GCP Podcast Episode 110: CPU Vulnerability with Matt Linton and Paul Turner podcast GCP Podcast Episode 125: Open Source at Google Cloud Platform with Sarah Novotny podcast GCP Podcast Episode 140: Container Security with Maya Kaczorowski podcast Melanie’s favorite episodes GCP Podcast Episode 117: Cloud AI Fei-Fei Li was the Chief Scientist of AI/ML at Google podcast GCP Podcast Episode 114: ML Bias & Fairness with Timnit Gebru and Margaret Mitchell podcast GCP Podcast Episode 141: Accessibility in Tech podcast GCP Podcast Episode 136: Robotics with Raia podcast GCP Podcast Episode 150: Strange Loop, Remote Working, and Distributed Systems with KF podcast DL Indaba GCP Podcast Episode 147: DL Indaba: AI Investments in Africa podcast GCP Podcast Episode 149: Deep Learning Research in Africa with Yabebal Fantaye & Jessica Phalafala podcast GCP Podcast Episode 152: AI Corporations and Communities in Africa with Karim Beguir & Muthoni Wanyoike podcast GCP Podcast Episode 157: NeurIPS and AI Research with Anima Anandkumar podcast Favorite announcements, products, and more at Google Cloud Unity and Google Cloud Strategic Alliance blog Open Match blog Cloud TPU site Google Dataset Search is in beta site No tricks, just treats: Globally scaling the Halloween multiplayer Doodle with Open Match on Google Cloud blog GKE On-Prem site Open Source - Knative release, Skaffold, Istio updates, gVisor, etc. Google in Ghana blog Cloud NEXT blog GCP Podcast Episode 137: Next Day 1 podcast GCP Podcast Episode 138: Next Day 2 podcast GCP Podcast Episode 139: Next Day 3 podcast Unity and DeepMind partner to advance AI research blog Introducing PyTorch across Google Cloud blog Question of the week What were your personal highlights for 2018? Mark Agones Introducing Agones: Open-source, multiplayer, dedicated game-server hosting built on Kubernetes blog github The new website Having Melanie join me on the podcast Melanie Bringing Francesc back Meeting Grace GCP Podcast Episode 142: Agones With Mark Mandel and Cyril Tovena podcast Where can you find us next? It’s the holidays! Special thanks! Thank you guests Thank you Jennifer Thank you HD Interactive: James, Trae, Sabrina, and Sean Thank you Greg Thank you Neil, Chuck, and Shana Thank you MBooth for the website overhaul and social media support Thank you Francesc Thank you listeners!

Vincent, Guillaume et Arnaud enfilent leur slip des cast codeurs par dessus leur pantalons pour vous parler d’AdoptOpenJDK, de Spring Boot, de Micronaut, de Kubernetes, de Google App Engine, des vieux pôts de l’écosystème java dans lesquels ont fait les meilleures soupes, de piscem vorat maior minorem et d’un long outil de l’épisode sur TestContainers. Enregistré le 6 novembre 2018 Téléchargement de l’épisode LesCastCodeurs-Episode–198.mp3 News Langages The AdoptOpenJDK Java 11 builds Présentations Java de Oracle Code One listées par Sharat Chandler Running Java code from the source, un article d’Andres Almiray montrant comment on peut lancer du code Java directement sans pré-compilation Focus sur les closures en JavaScript par Wassim Chegham qui continue sa série sur les bases de JavaScript Librairies Spring Boot 2.1.0 est sorti Micronaut 1.0 est sorti Présentation de Micronaut par Graeme Rocher à Oracle Code One et à Voxxed Days Microservices Tutoriel Micronaut sur InfoQ Tutoriel Micronaut sur Medium Infrastructure Kubernetes 1.12 (What’s new by Rancher) Comment dockeriser facilement des applis Java avec Jib (outil que nous avions couvert avec David Gageot) Cloud Github Actions: c’est un peu le IFTTT de Github pour le CI/CD, pour automatiser le workflow de développement Secrets in Serverless par Seth Vargo qui couvre différentes approches pour cacher des secrets (mots de passe, etc) quand on utilise des solutions Serverless . Node 10 sur Google App Engine sorti en beta en même temps que la release de Node 10 Go 1.11 sur Google App Engine également disponible en beta Data Redis modules forked pre-common clause. GoodFORM va-t’il (sur)vivre? MongoDB change sa licence pour tirer parti de la manne des installations cloud de MongoDB Le problème des licences avec Copyleft Outillage JVM Ecosystem Report 2018 - Quel est le plus gros concurrent à JenkinsCI ? Apache Maven 3.6.0 plus CI Friendly avec un usecase pour les releases incrémentales chez Jenkins Sécurité 50 millions de comptes compromis chez Facebook CERTFR–2018-ALE–011 - Vulnérabilité dans le client Git + Nombreux avis de sécurité sur CERT-FR Loi, société et organisation Publicis va acquérir Xébia France IBM va acquérir Red Hat VMware / Pivotal vont acquérir Heptio Outils de l’épisode TestContainers Rubrique débutant Apprendre Apache Maven, l’outil de gestion et d’automatisation de production des projets logiciels sur developpez.com (ou sur GitHub) Conférences DevFest Toulouse le 8 novembre 2018 - sold out. Bdx.io le 9 novembre 2018 - sold out. Devoxx Belgique du 12 au 16 novembre 2018 - sold out. DEVOPS D-DAY 2018 le 15 Novembre à Marseille. Codeurs en Seine le 22 novembre 2018. Snowcamp du 23 au 26 Janvier 2019. CfP DevFest Paris le 8 Février 2019 CfP ConFoo Montreal 2019 du 13 au 15 Mars 2019 CfP Greach (Madrid) du 28 au 30 Mars 2019 Le site du Paris JUG Le CFP de la soirée Young Blood VI Nous contacter Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/  

Mark and Melanie speak with Patrick Flynn and Mike Eltsufin about their exciting new Java products for Google Cloud. Mike tells us all about the new Spring Cloud GCP, a helpful tool that integrates Google Cloud Platform APIs and the Spring Framework. Patrick elaborates on his team’s new tool, Jib, a Java container image builder, and how it helps Java developers. Patrick Flynn Patrick Flynn is a long time Java developer who spent many years in Google Ads, and is now four years into being the tech lead of the Google Cloud Java Tools team. Mike Eltsufin Mike Eltsufin has been an enterprise Java application developer in the banking sector for over a decade before joining Google. Currently, he’s the tech lead of the Cloud Java Frameworks team, focusing on bringing the goodness of Spring Boot to Google Cloud Java developers. Cool things of the week Introducing container-native load balancing on Google Kubernetes Engine blog Simplifying cloud networking for enterprises: announcing Cloud NAT and more blog Store it, analyze it, back it up: Cloud Storage updates bring new replication options blog Postmortems and Retrospectives with Liz and Seth video GCP Podcast Episode 127: SRE vs Devops with Liz Fong-Jones and Seth Vargo podcast Interview App Engine site Kubernetes Engine site Spring Framework site Spring Boot site Spring Cloud GCP site Spring Cloud GCP on GitHub site Cloud Pub/Sub site Spanner site Cloud Sql site Cloud Datastore site Docker site Jib on GitHub site Cloud Tools for IntelliJ Documentation site Introducing Jib — build Java Docker images better blog Bazel site Skaffold on GitHub site Netty site SpringOne site Knative and riff for Spring Developers video Jib Gitter site Sig Apps site Kubernetes Slack site Codelabs site Question of the week What if we have an object in Google Cloud Storage, and I want to automatically change an aspect of it – such as: Downgrade the storage class of objects older than 365 days to Coldline Storage. Delete objects created before January 1, 2013. Keep only the 3 most recent versions of each object in a bucket with versioning enabled. Managing Object Lifecycles docs and guide Where can you find us next? Patrick’s team will be at KubeCon Shanghai and Oracle Code One and he will be at KubeCon Seattle Mark will be at KubeCon in December. Melanie will be at Twilio Signal $BASH event on Thursday and SOCML in November.

This episode of HashiCast features Seth Vargo, Developer Advocate at Google. Join us as we take a dive into Seth's career, past present and future, why Seth is still talking about HashiCorp Vault and his love for technology.

It’s the third and final day for us at NEXT, and Mark and Melanie are wrapping up with some great interviews! First, we spoke with Stephanie Cueto and Vivian San of Techtonica, a San Francisco non-profit. Next, Liz Fong-Jones and Nikhita Raghunath joined us for a quick discussion about open source and Stackdriver and last but not least, Robert Kubis helped us close things sharing what it means to do DevRel at this event. Stephanie Cueto and Vivian San Stephanie Cueto is a Software Engineer and advocate for the Latinx & women community. She has been involved in the Tech community since 2016. Playing with code at an early age and working in education led to my interest in becoming a Software Engineer. Currently she is a Software Engineer Apprentice at Techtonica, where she has gained the skills to build projects in MongoDb, MySQL, Express.js, React, and Node.js. During the program, she created Salient Alert, a platform for reporting ICE Raids and Checkpoints. Vivian San is a highly analytical full-stack software engineer with an educational background in the hard sciences. She is strongly motivated by writing clean, efficient code, and passionate about teaching and giving back to underrepresented individuals and communities. Liz Fong-Jones and Nikhita Raghunath Liz Fong-Jones is a Staff Site Reliability Engineer at Google and works on the Google Cloud Customer Reliability Engineering team in New York. In her 10+ years at Google she has worked across eight different teams spanning the stack from Google Flights to Cloud Bigtable. She lives with her wife, Metamour, and a Samoyed/Golden Retriever mix in Brooklyn. In her spare time she plays classical piano, leads an EVE Online alliance, and advocates for transgender rights. Nikhita Raghunath is an intern at Red Hat and works on the extensibility of Kubernetes. Previously, she was a Google Summer of Code (2017) student for the Cloud Native Computing Foundation (CNCF) and also worked on Kubernetes. She is interested in backend applications, distributed systems and Linux. Nikhita likes programming in Go, C++, C, and Python. She also likes to give talks at conferences and speak about her work. Robert Kubis Robert Kubis is a developer advocate for the Google Cloud Platform based in London, UK, specializing in container, storage, and scalable technologies. Before joining Google, Robert collected over 10 years of experience in software development and architecture. He has driven multiple full-stack application developments at SAP with a passion for distributed systems, containers, and databases. In his spare time he enjoys following tech trends, trying new restaurants, traveling, and improving his photography skills. Interviews Made Here Together: NEXT Developer Keynote video Techtonica site I am Remarkable Workshop site Haben Girma’s accessibility presentation at NEXT video GCPPodcast Episode 127: SRE vs Devops with Liz Fong-Jones and Seth Vargo podcast Red Hat site Kubernetes site Introducing Agones blog Stackdriver site OpenCensus site GCPPodcast Episode 118: OpenCensus with Morgan McLean and JBD podcast Edge TPU site GCPPodcast Episode 135: VirusTotal with Emi Martínez podcast Cloud Spanner site

This week is a clash of titans! Liz Fong-Jones and Seth Vargo join Mark and Melanie, to battle out on which is better: SRE or Devops (hint - everyone wins!). Liz Fong-Jones Liz is a Staff Site Reliability Engineer at Google and works on the Google Cloud Customer Reliability Engineering team in New York. She has worked on services ranging from Google Flights to Cloud Bigtable in her 10+ years at Google. She lives with her wife, metamour, and a Samoyed/Golden Retriever mix in Brooklyn. In her spare time, she plays classical piano, leads an EVE Online alliance, and advocates for transgender rights. Seth Vargo Seth Vargo is a Developer Advocate at Google. Previously he worked at HashiCorp, Chef Software, CustomInk, and a few Pittsburgh-based startups. He is the author of Learning Chef and is passionate about reducing inequality in technology. Seth is an active member of the DevOps community and has written thought-leader-y pieces such as the 10 Myths of DevOps. Cool things of the week Google I/O session youtube What’s new in Firebase at I/O 2018 blog Introducing ML Kit for Firebase blog Jeff Dean is new Head of AI wired Introducing Cloud Memorystore: A fully managed in-memory data store service for Redis blog Google Group Issue tracker Interview class SRE implements DevOps youtube series DevOps wikipedia Site Reliability Engineering (SRE) site Terraform site Chef site Puppet site Ansible site SaltStack site Prometheus site Datadog site Stackdriver site The Site Reliability Workbook: Practical Ways to Implement SRE amazon Seeking SRE o’reilly Customer Reliability Engineering Blog Series blogs Question of the week I’m a researcher at a regionally accredited academic institution and I need compute resources. Does Google Cloud have any programs that can help me out? Google Cloud Platform announces new credits program for researchers blog faq Where can you find us next? Mark will be speaking at the Monthly SF Game Development Community, presenting on You Can’t Just Add More Servers on May the 30th in San Francisco. Melanie is speaking at the Understand Risk Forum on May 17th, in Mexico City.

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. The button you click in the user interface to disable billing across an entire project and delete all billable resources has an API. You can build a chat bot or script, too. It presents anything you’ve done in the Consul by clicking and pointing, as well as gives you what that looks like in code form. 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. For example, this feature is useful for training or if a consultant needs to see all of your different clients in one dashboard, but your clients can’t see each other. 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. There’s many parts of Google and many features of Google Cloud that people aren’t aware of. 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. Then, the voice of the communities are echoed in the features and products being internally developed. Amazon has been in the Cloud business for a long time. What took Google so long? 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. Google Cloud also partners with open source tools and corresponding companies. There are people at Google who are paid by Google who work full time on open source tools, like Terraform, Chef, and Puppet. This allows you to provision Google Cloud resources using the tools that you prefer. 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. Think of DevOps as an interface in programming language, like Java, or a type of language where it doesn’t actually define what you do, but gives you a high level of what the function is supposed to implement. 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. A reason why Google offers abstract classes in programming is that there’s more than one way to solve a problem, and SRE is just one of those ways. 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. Google supports those ways and recognizes that there isn’t just one path to operational success, but many ways to reach that prosperity. 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. Google has always held up along several other companies as a shining beacon of how infrastructure management could be. But some say there’s still problems with its infrastructure, even after 20-some years and billions invested. Every company has problems, some of them technical, some cultural. Google is no exception. The one key difference is the way Google handles issues from a cultural perspective. It focuses on fixing the problem and making sure it doesn’t happen again. There’s a very blameless culture. Conferences tend to include a lot of hand waving and storytelling. But as an industry, more war stories need to be told instead of pleasure stories. Conference organizers want to see sunshine and rainbows because that sells tickets and makes people happy. The systemic problem is how to talk about problems out in the open. Becoming frustrated and trying to figure out why computers do certain things is a key component of the SRE discipline referred to as Toil -  work tied to systems that either we don’t understand or don’t make sense to automate. 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. There are tiny differences around the Cloud-native paradigm and providers. There’s some key pillars: 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. Links: Google Cloud and blog Amazon Web Services HashiCorp Terraform Vault Consul Nomad Chef Puppet Kubernetes AutoML Monitorama Azure CloudFormation Ansible Elk Stack Site Reliability Engineering book for O’Reilly Fastly Hacker News Cloud Foundry Microsoft Cloud Alibaba Cloud Lambda Quotes by Seth: “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.” “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.” “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.” “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.”

Brian talks with Seth Vargo (@sethvargo, Director of Technical Advocacy @HashiCorp) about the evolving security footprint of modern applications, the increasing needs for secrets management with microservices, the challenges of managing encryption, how to maintain highly available environments, and the evolution of Pittsburgh as a tech city. Show Links: [Donations for Hurricane Harvey, Houston Flood Victims] Red Cross Buy Necessary Items, via Amazon, for Hurricane Harvey Victims Use code “PCCLOUD” for 20% of Gold, Silver, Bronze passes at VelocityConf Seth’s projects on GitHub Seth’s book from O’Reilly HashiCorp Vault [website] and GitHub project [O’Reilly Velocity Conference, NYC] Microservices Secrets Management with Vault Interested in ServerlessConf in NYC (Oct 8-11)? 20% Discount on all passes Start Serverless Skills Bundle (4 courses) - (only $49 instead of $79) FREE Alexa Development for Absolute Beginners Show Notes Topic 1 - Welcome to the show. Tell us about your background as a technologist and author. Topic 1a - And since we’re going to talk about Vault, give us the basics of the Vault platform. Topic 2 - Let’s start with the basics. Why are we seeing so many more discussions about secrets management with microservices vs. legacy applications? Topic 3 - What are the core challenges that microservices applications face with regard to secrets? Is it key management, or key rotation or encryption of secrets, or something else? Topic 4 - Since secrets are so central to microservices, and critical to normal operations, how do you make sure that a platform like Vault is highly available? Or what happens if it goes out of service? Topic 5 - If we’re talking about microservices, the conversation typically evolves to deploying them, which leads to discussions about container schedulers. Can you talk about the challenges that schedulers have with secrets and how Vaults helps to manage those challenges? Feedback? Email: show at thecloudcast dot net Twitter: @thecloudcastnet and @ServerlessCast

Seth Vargo, the Director of Technical Advocacy at HashiCorp, joined the show to talk about managing secrets with their open source product called Vault which lets you centrally secure, store, and tightly control access to secrets across distributed infrastructure and applications. We talked about Seth’s back story into open source, use cases, what problem it solves, key features like Data Encryption, why they choose to write it in Go, and how they build tooling around the open core model.

Seth Vargo, the Director of Technical Advocacy at HashiCorp, joined the show to talk about managing secrets with their open source product called Vault which lets you centrally secure, store, and tightly control access to secrets across distributed infrastructure and applications. We talked about Seth’s back story into open source, use cases, what problem it solves, key features like Data Encryption, why they choose to write it in Go, and how they build tooling around the open core model.

Every software application has secrets. User passwords and database credentials must be managed carefully, because poor access controls can lead to disaster scenarios. Vault is a tool for secret management, developed at Hashicorp, a company that builds software tools for application delivery and infrastructure management. Seth Vargo is a software engineer and open source advocate The post Secret Management and Vault with Hashicorp’s Seth Vargo appeared first on Software Engineering Daily.

This 3rd episode of SysCast revolves around secrets: managing API keys, passwords, tokens, … with Hashicorp’s Vault. I’m joined by Seth Vargo from Hashicorp who explains how Vault works, its internals, different use cases, key management & rollover and lots of interesting details about Vault itself. If you’re storing your passwords inside your git repository or managing them by hand in yaml/ini files, listen to this episode to learn how Vault can help store credentials more securely and automate secret management for you. Once again, if you have a minute or 2, leave a rating on iTunes. Shownotes @sethvargo on Twitter VaultProject.io the official website The interactive demo of Vault Consul Template Using HashiCorp’s Vault with Chef (applicable to Puppet/Ansible, too) Feedback? Let me know via syscast@ttias.be or at @mattiasgeniar on Twitter.

Новости Непрерывная поставка ПО в SAP Using Chef to manage your container workflow Книга Customizing Chef Seth Vargo теперь в Hahicorp Как запустить DSC в Amazon Azure support for Docker Зачем нужно использовать Chef и DSC вместе ChefDK 0.3.0. Policyfile Масштабирование с ZooKeeper Using Terraform Могущественная скорлупа Docker в DigitalOcean Docker 1.3 Обсуждение Policyfiles Policyfile У нас в гостях Лев Попов из Spotify Твиттер Льва Github Льва

With everyone returning from Midwest.JS and Steel City Ruby, we reminisce about the conferences, complain about the post office, and debate what Devops is. Midwest.JS 0:15 Steel City Ruby 2:09 Dev>Input 3:50 Stamps.com 4:13 CodeClimate 4:43 Seth Vargo's talks 8:08 Jessica Kerr: Property-based testing: what is it? 8:37 Rantly 9:38 Generatron 10:03 DevOps 10:18 Chef 15:00 Why You Shouldn’t Use Vagrant: Real talk from a Vagrant burn-out 16:30 Test-Kitchen 19:10 Travis CI 20:26 Heroku 22:55 OpenShift 22:55 Continuously deploying your (free) OpenShift site with Travis CI 26:03 What Exactly is DevOps? 29:09

In this episode, we sat down with Miah Johnson, Ranjib Dey, Doug Ireton, Chris McClimans, Joshua Timberman, and Seth Vargo to discuss Libraries, Definitions and LWRPs.