Podcasts about kubectl

At KubeCon + CloudNativeCon North America 2022, Amazon Web Services (AWS) revealed plans to mirror Kubernetes assets hosted on Google Cloud, addressing Cloud Native Computing Foundation's (CNCF) egress costs. A year later, the project, led by AWS's Davanum Srinivas, redirects image requests to the nearest cloud provider, reducing egress costs for users.AWS's Todd Neal and Jonathan Innis discussed this on The New Stack Makers podcast recorded at KubeCon North America 2023. Neal explained the registry's functionality, allowing users to pull images directly from the respective cloud provider, avoiding egress costs.The discussion also highlighted AWS's recent open source contributions, including beta features in Kubectl, prerelease of Containerd 2.0, and Microsoft's support for Karpenter on Azure. Karpenter, an AWS-developed Kubernetes cluster autoscaler, simplifies node group configuration, dynamically selecting instance types and availability zones based on running pods.The AWS team encouraged developers to contribute to Kubernetes ecosystem projects and join the sig-node CI subproject to enhance kubelet reliability. The conversation in this episode emphasized the benefits of open development for rapid feedback and community collaboration.Learn more from The New Stack about AWS and Open Source:Powertools for AWS Lambda Grows with Help of VolunteersAmazon Web Services Open Sources a KVM-Based Fuzzing FrameworkAWS: Why We Support Sustainable Open Source 

On today's Kubernetes Unpacked podcast, Michael and Kristina catch up with Arsh Sharma, Developer Experience Engineer at Okteto. Arsh dives into the key aspects to consider for incorporating a proper developer experience for Kubernetes and the overall cloud-native ecosystem. The post Kubernetes Unpacked 038: The Kubernetes Dev Experience In 2023 appeared first on Packet Pushers.

On today's Kubernetes Unpacked podcast, Michael and Kristina catch up with Arsh Sharma, Developer Experience Engineer at Okteto. Arsh dives into the key aspects to consider for incorporating a proper developer experience for Kubernetes and the overall cloud-native ecosystem. The post Kubernetes Unpacked 038: The Kubernetes Dev Experience In 2023 appeared first on Packet Pushers.

In this sponsored episode of the Kubernetes Unpacked podcast, Kristina and Michael are joined by Adam Frank, SVP of Product and Marketing at Armory, to discuss the role of continuous deployment in the software development lifecycle. They highlight the challenges organizations face in implementing effective continuous integration and continuous deployment (CI/CD) processes and the importance of prioritizing the developer experience. The post Kubernetes Unpacked 037: Improving The Developer Experience With Continuous Deployment (Sponsored) appeared first on Packet Pushers.

In this sponsored episode of the Kubernetes Unpacked podcast, Kristina and Michael are joined by Adam Frank, SVP of Product and Marketing at Armory, to discuss the role of continuous deployment in the software development lifecycle. They highlight the challenges organizations face in implementing effective continuous integration and continuous deployment (CI/CD) processes and the importance of prioritizing the developer experience. The post Kubernetes Unpacked 037: Improving The Developer Experience With Continuous Deployment (Sponsored) appeared first on Packet Pushers.

There are a lot of moving parts to Kubernetes. In today's Kubernetes Unpacked, we get into Ingress with guest Whitney Lee. Whitney breaks down her thoughts on Ingress, how she learned it, and how you can gain more knowledge around Ingress and the open-source CNCF projects around Ingress. The post Kubernetes Unpacked 036: What The Heck Is Ingress? appeared first on Packet Pushers.

There are a lot of moving parts to Kubernetes. In today's Kubernetes Unpacked, we get into Ingress with guest Whitney Lee. Whitney breaks down her thoughts on Ingress, how she learned it, and how you can gain more knowledge around Ingress and the open-source CNCF projects around Ingress. The post Kubernetes Unpacked 036: What The Heck Is Ingress? appeared first on Packet Pushers.

In today's Kubernetes Unpacked, Michael and Kristina catch up with Prithvi Raj and Sayan Mondal to talk about all things Chaos Engineering in the Kubernetes space! We chat about the open source and CNCF incubating project, Litmus, and various other topics  including why Chaos Engineering is important, how it can help all organizations, how every engineer can use it, and more. The post Kubernetes Unpacked 035: Chaos Engineering In Kubernetes And The Litmus Project appeared first on Packet Pushers.

In today's Kubernetes Unpacked, Michael and Kristina catch up with Prithvi Raj and Sayan Mondal to talk about all things Chaos Engineering in the Kubernetes space! We chat about the open source and CNCF incubating project, Litmus, and various other topics  including why Chaos Engineering is important, how it can help all organizations, how every engineer can use it, and more. The post Kubernetes Unpacked 035: Chaos Engineering In Kubernetes And The Litmus Project appeared first on Packet Pushers.

On today's Kubernetes Unpacked, Michael and Kristina catch up with Roberth Strand, Principal Cloud Engineer at Amesto Fortytwo to talk about all things Internal Developer Platform (IDP) on Kubernetes and beyond. Roberth dives into what an IDP is, what it isn't, and how all engineers should be thinking about IDPs. If you're interested in diving into platform engineering, this is the perfect episode for you. The post Kubernetes Unpacked 034: Platform Engineering And Internal Development Platforms On Kubernetes appeared first on Packet Pushers.

On today's Kubernetes Unpacked, Michael and Kristina catch up with Roberth Strand, Principal Cloud Engineer at Amesto Fortytwo to talk about all things Internal Developer Platform (IDP) on Kubernetes and beyond. Roberth dives into what an IDP is, what it isn't, and how all engineers should be thinking about IDPs. If you're interested in diving into platform engineering, this is the perfect episode for you. The post Kubernetes Unpacked 034: Platform Engineering And Internal Development Platforms On Kubernetes appeared first on Packet Pushers.

In today's episode, Michael and Kristina catch up with Saim Safdar to chat about a recent white paper on platform engineering from the Cloud Native Computing Foundation (CNCF). Saim dives into not only the CNCF whitepaper, but how Platform Engineering should be thought about from a Kubernetes perspective in 2023 and beyond. The post Kubernetes Unpacked 033: Platform Engineering And The CNCF White Paper appeared first on Packet Pushers.

In today's episode, Michael and Kristina catch up with Saim Safdar to chat about a recent white paper on platform engineering from the Cloud Native Computing Foundation (CNCF). Saim dives into not only the CNCF whitepaper, but how Platform Engineering should be thought about from a Kubernetes perspective in 2023 and beyond. The post Kubernetes Unpacked 033: Platform Engineering And The CNCF White Paper appeared first on Packet Pushers.

On today's Kubernetes Unpacked we speak with Evis Drenova about whether AI has a role to play in the Kubernetes ecosystem. We discuss everything from using chat-based generative AI tools to interact with Kubernetes to data models and data sets on Kubernetes to Machine Learning with Kubernetes. The post Kubernetes Unpacked 032: AI Use Cases For Kubernetes appeared first on Packet Pushers.

On today's Kubernetes Unpacked we speak with Evis Drenova about whether AI has a role to play in the Kubernetes ecosystem. We discuss everything from using chat-based generative AI tools to interact with Kubernetes to data models and data sets on Kubernetes to Machine Learning with Kubernetes. The post Kubernetes Unpacked 032: AI Use Cases For Kubernetes appeared first on Packet Pushers.

In today's Kubernetes Unpacked, Kristina and Michael talk about whether Kubernetes is getting boring, and how elements such as service mesh, security-centric CNIs, and movements such as GitOps, can keep Kubernetes moving forward. The post Kubernetes Unpacked 031: Is Kubernetes Getting Boring? appeared first on Packet Pushers.

In today's Kubernetes Unpacked, Kristina and Michael talk about whether Kubernetes is getting boring, and how elements such as service mesh, security-centric CNIs, and movements such as GitOps, can keep Kubernetes moving forward. The post Kubernetes Unpacked 031: Is Kubernetes Getting Boring? appeared first on Packet Pushers.

In this episode of Kubernetes Unpacked, Michael and Kristina catch up with with Nigel Poulton, an independent consultant, trainer, and content creator to discuss what Web Assembly (WASM) is, why it's gaining popularity, and whether it can be the future of programming and development. The post Kubernetes Unpacked 030: What’s Up With WASM? – With Nigel Poulton appeared first on Packet Pushers.

In this episode of Kubernetes Unpacked, Michael and Kristina catch up with with Nigel Poulton, an independent consultant, trainer, and content creator to discuss what Web Assembly (WASM) is, why it's gaining popularity, and whether it can be the future of programming and development. The post Kubernetes Unpacked 030: What’s Up With WASM? – With Nigel Poulton appeared first on Packet Pushers.

In this episode, Michael catches up with Anton Smith, Head Of Product at Spectro Cloud. This episode goes outside of the standard engineering conversation and into a conversation of why it makes sense for Technical Product Managers (TPMs) to not only get a certification like the Certified Kubernetes Administrator (CKA), but why staying technical as a TPM in the Kubernetes space helps you with your job. The post Kubernetes Unpacked 029: Kubernetes And Certifications For Product Managers appeared first on Packet Pushers.

In this episode, Michael catches up with Anton Smith, Head Of Product at Spectro Cloud. This episode goes outside of the standard engineering conversation and into a conversation of why it makes sense for Technical Product Managers (TPMs) to not only get a certification like the Certified Kubernetes Administrator (CKA), but why staying technical as a TPM in the Kubernetes space helps you with your job. The post Kubernetes Unpacked 029: Kubernetes And Certifications For Product Managers appeared first on Packet Pushers.

In this episode of the Kubernetes Unpacked podcast, co-hosts Michael Levan and Kristina Devochko interview David Flanagan, a Kubernetes consultant, about his experience running his own consultancy and specializing in a specific technology or platform. David shares his career journey and emphasizes the importance of authenticity, credibility, and long-term thinking in the world of technology consulting. The conversation also touches on the use of AI in Kubernetes, the challenges and rewards of being an independent consultant, and the importance of setting personal boundaries and constraints early on to prevent burnout. David also shares his insights into some of the quirks of Kubernetes. The post Kubernetes Unpacked Episode 028: K8s Consulting-A Journey Of Discovery And Burnout appeared first on Packet Pushers.

In this episode of the Kubernetes Unpacked podcast, co-hosts Michael Levan and Kristina Devochko interview David Flanagan, a Kubernetes consultant, about his experience running his own consultancy and specializing in a specific technology or platform. David shares his career journey and emphasizes the importance of authenticity, credibility, and long-term thinking in the world of technology consulting. The conversation also touches on the use of AI in Kubernetes, the challenges and rewards of being an independent consultant, and the importance of setting personal boundaries and constraints early on to prevent burnout. David also shares his insights into some of the quirks of Kubernetes. The post Kubernetes Unpacked Episode 028: K8s Consulting-A Journey Of Discovery And Burnout appeared first on Packet Pushers.

In today's Kubernetes Unpacked podcast, Michael and Kristina chat about KubeCon EU, which took place in April 2023 in Amsterdam. They explore the latest and greatest technologies that are coming, the value of in-person gatherings, and why conference codes of conduct matter. They also share their top 3 KubeCon takeaways. The post Kubernetes Unpacked 027: KubeCon EU 2023 Recap appeared first on Packet Pushers.

In today's Kubernetes Unpacked podcast, Michael and Kristina chat about KubeCon EU, which took place in April 2023 in Amsterdam. They explore the latest and greatest technologies that are coming, the value of in-person gatherings, and why conference codes of conduct matter. They also share their top 3 KubeCon takeaways. The post Kubernetes Unpacked 027: KubeCon EU 2023 Recap appeared first on Packet Pushers.

On today's Kubernetes Unpacked podcast, Michael and Kristina catch up with with Geoff Burke, Senior Cloud Solutions Architect, to talk about running backups for Kubernetes, how to recover those backups, and which tools to use for backup and disaster recovery. We're also pleased to welcome Kristina Devochko as full-time co-host of the podcast! The post Kubernetes Unpacked 026: Data Backup And Recovery In Kubernetes appeared first on Packet Pushers.

On today's Kubernetes Unpacked podcast, Michael and Kristina catch up with with Geoff Burke, Senior Cloud Solutions Architect, to talk about running backups for Kubernetes, how to recover those backups, and which tools to use for backup and disaster recovery. We're also pleased to welcome Kristina Devochko as full-time co-host of the podcast! The post Kubernetes Unpacked 026: Data Backup And Recovery In Kubernetes appeared first on Packet Pushers.

Michael Levan and Calvin Hendryx-Parker talk about their experience using Kubernetes, the pros and cons of the orchestration platform, and its impact on infrastructure engineers and developers. Calvin offers great tips on how to make the developer experience better and what platform engineering teams can do to make everyone's job flow properly. The post Kubernetes Unpacked 025: The Kubernetes Developer Experience appeared first on Packet Pushers.

Michael Levan and Calvin Hendryx-Parker talk about their experience using Kubernetes, the pros and cons of the orchestration platform, and its impact on infrastructure engineers and developers. Calvin offers great tips on how to make the developer experience better and what platform engineering teams can do to make everyone's job flow properly. The post Kubernetes Unpacked 025: The Kubernetes Developer Experience appeared first on Packet Pushers.

In this episode, Michael catches up with Kristina Devochko, a Senior Software Architect to talk about Day Zero Kubernetes. Originally, Michael thought that it would be similar to Day One and Day Two Ops, but Day Zero is drastically different. Kristina and Michael discuss what engineers need to know to get the job done, how to think about planning Kubernetes architecture, and overall security best practices for what's needed in Day Zero. The post Kubernetes Unpacked 024: Day Zero Kubernetes With Kristina Devochko appeared first on Packet Pushers.

In this episode, Michael catches up with Kristina Devochko, a Senior Software Architect to talk about Day Zero Kubernetes. Originally, Michael thought that it would be similar to Day One and Day Two Ops, but Day Zero is drastically different. Kristina and Michael discuss what engineers need to know to get the job done, how to think about planning Kubernetes architecture, and overall security best practices for what's needed in Day Zero. The post Kubernetes Unpacked 024: Day Zero Kubernetes With Kristina Devochko appeared first on Packet Pushers.

Today's Kubernetes Unpacked discusses essential requirements to secure a Kubernetes environment. The post Kubernetes Unpacked 023: Is Kubernetes Security The Same As Other Security? appeared first on Packet Pushers.

Today's Kubernetes Unpacked discusses essential requirements to secure a Kubernetes environment. The post Kubernetes Unpacked 023: Is Kubernetes Security The Same As Other Security? appeared first on Packet Pushers.

In this episode, Michael catches up with Stephane Karagulmez, Senior Solution Architect at Isovalent (founded by the creators of Cilium). Michael spent a lot of time working with Cilium, which is open-source software that provides networking and observability capabilities for Kubernetes workloads. Cilium is based on another open-source project, eBFP. It's important to understand the details and performance changes when implementing eBPF and removing kube-proxy. The post Kubernetes Unpacked 022: Kubernetes Networking And Abstraction With Cilium And eBPF appeared first on Packet Pushers.

In this episode, Michael catches up with Stephane Karagulmez, Senior Solution Architect at Isovalent (founded by the creators of Cilium). Michael spent a lot of time working with Cilium, which is open-source software that provides networking and observability capabilities for Kubernetes workloads. Cilium is based on another open-source project, eBFP. It's important to understand the details and performance changes when implementing eBPF and removing kube-proxy. The post Kubernetes Unpacked 022: Kubernetes Networking And Abstraction With Cilium And eBPF appeared first on Packet Pushers.

On today's Kubernetes Unpacked, Michael and guests explore Windows containers. A few years ago there was a lot of hype around Nano, which then morphed into Nano Server. We look at the current state of containerized Windows, using Windows containers with Kubernetes, customer scenarios for container adoption, and Microsoft's approach to the container space. The post Kubernetes Unpacked 021: Catching Up With Windows Containers On Kubernetes appeared first on Packet Pushers.

Matty Stratton, Director of Developer Relations at Aiven, joins Corey on Screaming in the Cloud for a friendly debate on whether or not company employees can still be considered community members. Corey says no, but opens up his position to the slings and arrows of Matty in an entertaining change of pace. Matty explains why he feels company employees can still be considered community members, and also explores how that should be done in a way that is transparent and helpful to everyone in the community. Matty and Corey also explore the benefits and drawbacks of talented community members becoming employees.About MattyMatty Stratton is the Director of Developer Relations at Aiven, a well-known member of the DevOps community, founder and co-host of the popular Arrested DevOps podcast, and a global organizer of the DevOpsDays set of conferences.Matty has over 20 years of experience in IT operations and is a sought-after speaker internationally, presenting at Agile, DevOps, and cloud engineering focused events worldwide. Demonstrating his keen insight into the changing landscape of technology, he recently changed his license plate from DEVOPS to KUBECTL.He lives in Chicago and has three awesome kids, whom he loves just a little bit more than he loves Diet Coke. Links Referenced: Aiven: https://aiven.io/ Twitter: https://twitter.com/mattstratton Mastodon: hackyderm.io/@mattstratton LinkedIn: https://www.linkedin.com/in/mattstratton/ 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 brought to us in part by our friends at Min.ioWith more than 1.1 billion docker pulls - Most of which were not due to an unfortunate loop mistake, like the kind I like to make - and more than 37 thousand github stars, (which are admittedly harder to get wrong), MinIO has become the industry standard alternative to S3. It runs everywhere  - public clouds, private clouds, Kubernetes distributions, baremetal, raspberry's pi, colocations - even in AWS Local Zones. The reason people like it comes down to its simplicity, scalability, enterprise features and best in class throughput. Software-defined and capable of running on almost any hardware you can imagine and some you probably can't, MinIO can handle everything you can throw at it - and AWS has imagined a lot of things - from datalakes to databases.Don't take their word for it though - check it out at www.min.io and see for yourself. That's www.min.io Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I am joined today by returning guest, my friend and yours, Matty Stratton, Director of Developer Relations at Aiven. Matty, it's been a hot second. How are you?Matty: It has been a while, but been pretty good. We have to come back to something that just occurred to me when we think about the different things we've talked about. There was a point of contention about prior art of the Corey Quinn face and photos. I don't know if you saw that discourse; we may have to have a conversation. There may be some absent—Corey: I did not see—Matty: Okay.Corey: —discourse, but I also would accept freely that I am not the first person to ever come up with the idea of opening my mouth and looking ridiculous for a photograph either.Matty: That's fair, but the thing that I think was funny—and if you don't mind, I'll just go ahead and throw this out here—is that I didn't put this two and two together. So, I posted a picture on Twitter a week or so ago that was primarily to show off the fact—it was a picture of me in 1993, and the point was that my jeans were French-rolled and were pegged. But in the photo, I am doing kind of the Corey Quinn face and so people said, “Oh, is this prior art?” And I said—you know what? I actually just remembered and I've never thought about this before, but one of my friends in high school, for his senior year ID he took a picture—his picture looks like, you know, that kind of, you know, three-quarters turn with the mouth opening going, “Ah,” you know?And he loved that picture—number one, he loved that picture so much that this guy carried his senior year high school ID in his wallet until we were like 25 because it was his favorite picture of himself. But every photo—and I saw this from looking through my yearbook of my friend Jay when we are seniors, he's doing the Corey Quinn face. And he is anecdotally part of the DevOps community, now a little bit too, and I haven't pointed this out to him. But people were saying that, you know, mine was prior art on yours, I said, “Actually, I was emulating yet someone else.”Corey: I will tell you the actual story of how it started. It was at re:Invent, I want to say 2018 or so, and what happened was is someone, they were a big fan of the newsletter—sort of the start of re:Invent—they said, “Hey, can I get a selfie with you?” And I figured, sure, why not. And the problem I had is I've always looked bad in photographs. And okay, great, so if I'm going to have a photo taken of me, that's going to be ridiculous, why not as a lark, go ahead and do this for fun during the course of re:Invent this year?So, whenever I did that I just slapped—if someone asked for a selfie—I'd slap the big happy open mouth smile on my face. And people thought, “Oh, my God, this is amazing.” And I don't know that it was necessarily worth that level of enthusiasm, but okay. I'll take it. I'm not here to tell people they're wrong when they enjoy a joke that I'm putting out there.And it just sort of stuck. And I think the peak of it that I don't think I'm ever going to be able to beat is I actually managed to pull that expression on my driver's license.Matty: Wow.Corey: Yeah.Matty: That's—Corey: They don't have a sense of humor that they are aware of at the DMV.Matty: No, they really don't. And having been to the San Francisco DMV and knowing how long it takes to get in there, like, that was a bit of a risk on your part because if they decided to change their mind, you wouldn't be able to come back for another four months [laugh].Corey: It amused me to do it, so why not? What else was I going to do? I brought my iPad with me, it has cellular on it, so I just can work remotely from there. It was either that or working in my home office again, and frankly, at the height of the pandemic, I could use the break.Matty: Yes [laugh]. That's saying something when the break you can use is going to the DMV.Corey: Right.Matty: That's a little bit where we were, where we at. I think just real quick thinking about that because there's a lot to be said with that kind of idea of making a—whether it's silly or not, but having a common, especially if you do a lot of photos, do a lot of things, you don't have to think about, like, how do I look? I mean, you have to think about—you know, you can just say I just know what I do. Because if you think about it, it's about cultivating your smile, cultivating your look for your photos, and just sort of having a way so you don't—you just know what to do every time. I guess that's a, you know, maybe a model tip or something. I don't know. But you might be onto something.Corey: I joke that my entire family motto is never be the most uncomfortable person in the room. And there's something to be said for it where if you're going to present a certain way, make it your own. Find a way to at least stand out. If nothing else, it's a bit different. Most people don't do that.Remember, we've all got made fun of, generally women—for some reason—back about 15 years ago or so for duck face, where in all the pictures you're making duck face. And well, there are reasons why that is a flattering way to present your face. But if there's one thing we love as a society, it's telling women they're doing something wrong.Matty: Yeah.Corey: So yeah, there's a whole bunch of ways you're supposed to take selfies or whatnot. Honestly, I'm in no way shape or form pretty enough or young enough to care about any of them. At this point, it's what I do when someone busts out a camera and that's the end of it. Now, am I the only person to do this? Absolutely not. Do I take ownership of it? No. Someone else wants to do it, they need give no credit. The idea probably didn't come from me.Matty: And to be fair, if I'm little bit taking the mickey there or whatever about prior art, it was more than I thought it was funny because I had not even—it was this thing where it was like, this is a good friend of mine, probably some of that I've been friends with longer than anyone in my whole life, and it was a core part [laugh] of his personality when we were 18 and 19, and it just d—I just never direct—like, made that connection. And then it happened to me and went “Oh, my God. Jason and Corey did the same thing.” [laugh]. It was—Corey: No, it feels like parallel evolution.Matty: Yeah, yeah. It was more of me never having connected those dots. And again, you're making that face for your DMV photo amused you, me talking about this for the last three minutes on a podcast amused me. So.Corey: And let's also be realistic here. How many ways are there to hold your face during a selfie that is distinguishable and worthy of comment? Usually, it's like okay, well, he has this weird sardonic half-smile with an eyebrow ar—no. His mouth was wide open. We're gonna go with that.Matty: You know, there's a little—I want to kind of—because I think there's actually quite a bit to the lesson from any of this because I think about—follow me here; maybe I'll get to the right place—like me and karaoke. No one would ever accuse me of being a talented singer, right? I'm not going to sing well in a way where people are going to be moved by my talent. So instead, I have to go a different direction. I have to go funny.But what it boils down to is I can only do—I do karaoke well when it's a song where I can feel like I'm doing an impression of the singer. So, for example, the B-52s. I do a very good impression of Fred Schneider. So, I can sing a B-52 song all day long. I actually could do better with Pearl Jam than I should be able to with my terrible voice because I'm doing an Eddie Vedder impression.So, what I'm getting at is you're sort of taking this thing where you're saying, okay, to your point, you said, “Hey,”—and your words, not mine—[where 00:07:09] somebody say, “The picture is not going to be of me looking like blue steel runway model, so I might as well look goofy.” You know? And take it that way and be funny with it. And also, every time, it's the same way, so I think it's a matter of kind of owning the conversation, you know, and saying, how do you accentuate the thing that you can do. I don't know. There's something about DevOps, somehow in there.Corey: So, I am in that uncomfortable place right now between having finalized a blog post slash podcast that's going out in two days from this recording. So, it will go out before you and I have this discussion publicly, but it's also too late for me to change any of it,m so I figured I will open myself up to the slings and arrows of you, more or less. And you haven't read this thing yet, which is even better, so you're now going to be angry about an imperfect representation of what I said in writing. But the short version is this: if you work for a company as their employee, then you are no longer a part of that company's community, as it were. And yes, that's nuanced and it's an overbroad statement and there are a bunch of ways that you could poke holes in it, but I'm curious to get your take on the overall positioning of it.Matty: So, at face value, I would vehemently disagree with that statement. And by that is, that I have spent years of my life tilting at the opposite windmill, which is just because you work at this company, doesn't mean you do not participate in the community and should not consider yourself a part of the community, first and foremost. That will, again, like everything else, it depends. It depends on a lot of things and I hope we can kind of explore that a little bit because just as much as I would take umbrage if you will, or whatnot, with the statement that if you work at the company, you stop being part of the community, I would also have an issue with, you're just automatically part of the community, right? Because these things take effort.And I feel like I've been as a devreloper, or whatever, Corey—how do you say it?Corey: Yep. No, you're right on. Devreloper.Matty: As a—or I would say, as a DevRel, although people on Twitter are angry about using the word DevRel to discuss—like saying, “I'm a DevRel.” “DevRel is a department.” It's a DevOps engineer thing again, except actually—it's, like, actually wrong. But anyway, you kind of run into this, like for example—I'm going to not name names here—but, like, to say, you know, Twitter for Pets, the—what do you—by the way, Corey, what are you going to do now for your made-up company when what Twitter is not fun for this anymore? You can't have Twitter for Pets anymore.Corey: I know I'm going to have to come up with a new joke. I don't quite know what to do with myself.Matty: This is really hard. While we will pretend Twitter for Pets is still around a little bit, even though its API is getting shut down.Corey: Exactly.Matty: So okay, so we're over here at Twitter for Pets, Inc. And we've got our—Corey: Twitter for Bees, because you know it'll at least have an APIary.Matty: Yeah. Ha. We have our team of devrelopers and community managers and stuff and community engineers that work at Twitter for Pets, and we have all of our software engineers and different people. And a lot of times the assumption—and now we're going to have Twitter for Pets community something, right? We have our community, we have our area, our place that we interact, whether it's in person, it's virtual, whether it's an event, whether it's our Discord or Discourse or Slack or whatever [doodlee 00:10:33] thing we're doing these days, and a lot of times, all those engineers and people whose title does not have the word ‘community' on it are like, “Oh, good. Well, we have people that do that.”So, number one, no because now we have people whose priority is it; like, we have more intentionality. So, if I work on the community team, if I'm a dev advocate or something like that, my priority is communicating and advocating to and for that community. But it's like a little bit of the, you know, the office space, I take the requirements from the [unintelligible 00:11:07] to people, you I give them to the engineers. I've got people—so like, you shouldn't have to have a go-between, right? And there's actually quite a bit of place.So, I think, this sort of assumption that you're not part of it and you have no responsibility towards that community, first of all, you're missing a lot as a person because that's just how you end up with people building a thing they don't understand.Corey: Oh, I think you have tremendous responsibility to the community, but whether you're a part of it and having responsibility to it or not aligned in my mind.Matty: So… maybe let's take a second and what do you mean by being a part of it?Corey: Right. Where very often I'll see a certain, I don't know, very large cloud provider will have an open-source project. Great, so you go and look at the open-source project and the only people with commit access are people who work at that company. That is an easy-to-make-fun-of example of this. Another is when the people who are in a community and talking about how they perceive things and putting out content about how they've interacted with various aspects of it start to work there, you see areas where it starts to call its authenticity into question.AWS is another great example of this. As someone in the community, I can talk about how I would build something on top of AWS, but then move this thing on to Fastly instead of CloudFront because CloudFront is terrible. If you work there, you're not going to be able to say the same thing. So, even if you're not being effusive with praise, there are certain guardrails and constraints that keep you from saying what you might otherwise, just based upon the sheer self-interest that comes from the company whose product or service you're talking about is also signing your paycheck and choosing to continue to do so.Matty: And I think even less about it because that's where your paycheck is coming. It's also just a—there's a gravitational pull towards those solutions because that's just what you're spending your day with, right? You know—Corey: Yeah. And you also don't want to start and admit even to yourself, in some cases, that okay, this aspect of what our company does is terrible, so companies—people shouldn't use it. You want to sort of ignore that, on some level, psychologically because that dissonance becomes harmful.Matty: Yeah. And I think there's—so again, this is where things get nuanced and get to levels. Because if you have the right amount of psychological safety in your organization, the organization understands what it's about to that. Because even people whose job is to be a community person should be able to say, “Hey, this is my actual opinion on this. And it might be contrary to the go-to-market where that comes in.”But it's hard, especially when it gets filtered through multiple layers and now you've got a CEO who doesn't understand that nuance who goes, “Wait, why was Corey on some podcast saying that the Twitter for Pets API is not everything it could possibly be?” So, I do think—I will say this—I do think that organizations and leadership are understanding this more than they might have in the past, so we are maybe putting on ourselves this belief that we can't be as fully honest, but even if it's not about hiding the warts, even if it's just a matter of also, you're just like, hey, chances are—plus also to be quite frank, if I work at the company, I probably have access to way more shit than I would have to pay for or do whatever and I know the right way. But here's the trick, and I won't even say it's a dogfooding thing, but if you are not learning and thinking about things the way that your users do—and I will even say that that's where—it is the users, which are the community, that community or the people that use your product or are connected to it, they don't use it; they may be anecdotal—or not anecdotally, maybe tangentially connected. I will give an example. And there was a place I was working where it was very clear, like, we had a way to you know, do open-source contributions back of a type of a provider plug-in, whatever you want to call it and I worked at the company and I could barely figure out how to follow the instructions.Because it made a lot of sense to someone who built that software all day long and knew the build patterns, knew all that stuff. So, if you were an engineer at this company, “Well, yeah, of course. You just do this.” And anybody who puts the—connects the dots, this has gotten better—and this was understood relatively quickly as, “Oh, this is the problem. Let's fix it.” So, the thing is, the reason why I bring this up is because it's not something anybody does intentionally because you don't know what you don't know. And—Corey: Oh, I'm not accusing anyone of being a nefarious actor in any of this. I also wonder if part of this is comes from your background as being heavily involved in the Chef community as a Chef employee and as part of the community around that, which is inherently focused on an open-source product that a company has been built around, whereas my primary interaction with community these days is the AWS community, where it doesn't matter whether you're large or small, you are not getting much, if anything, for free from AWS; you're all their customers and you don't really have input into how something gets built, beyond begging nicely.Matty: That's definitely true. And I think we saw that and there was things, when we look at, like, how community, kind of, evolved or just sort of happened at Chef and why we can't recreate it the same way is there was a certain inflection point of the industry and the burgeoning DevOps movement, and there wasn't—you know, so a lot of that was there. But one of the big problems, too, is, as Corey said, everybody—I shouldn't say every, but I've from the A—all the way up to AWS to your smaller startups will have this problem of where you end up hiring in—whether you want to or not—all of your champions and advocates and your really strong community members, and then that ends up happening. So, number one, that's going to happen. So frankly, if you don't push towards this idea, you're actually going to have people not want to come work because you should be able to be still the member that you were before.And the other thing is that at certain size, like, at the size of a hyperscaler, or, you know, a Microsoft—well, anybody—well Microsofts not a hyperscaler, but you know what I'm saying. Like, very, very large organization, your community folks are not necessarily the ones doing that hiring away. And as much as they might—you know, and again, I may be the running the community champion program at Microsoft and see that you want—you know, but that Joe Schmo is getting hired over into engineering. Like, I'm not going to hire Joe because it hurts me, but I can't say you can't, you know? It's so this is a problem at the large size.And at the smaller size, when you're growing that community, it happens, too, because it's really exciting. When there's a place that you're part of that community, especially when there's a strong feel, like going to work for the mothership, so to speak is, like, awesome. So again, to give an example, I was a member of the Chef community, I was a user, a community person well, before, you know, I went and, you know, had a paycheck coming out of that Seattle office. And it was, like, the coolest thing in the world to get a job offer from Ch—like, I was like, “Oh, my God. I get to actually go work there now.” Right?And when I was at Pulumi, there quite a few people I could think of who I knew through the community who then get jobs at Pulumi and we're so excited, and I imagine still excited, you know? I mean, that was awesome to do. So, it's hard because when you get really excited about a technology, then being able to say, “Wait, I can work on this all the time?” That sounds awesome, right? So like, you're going to have that happen.So, I think what you have to do is rather than prevent it from happening because number one, like, you don't want to actually prevent that from happening because those people will actually be really great additions to your organization in lots of ways. Also, you're not going to stop it from happening, right? I mean, it's also just a silly way to do it. All you're going to do is piss people off, and say, like, “Hey, you're not allowed to work here because we need you in the community.” Then they're going to be like, “Great. Well, guess what I'm not a part of anymore now, jerk?” Right? You know [laugh] I mean so—Corey: Exactly.Matty: Your [unintelligible 00:18:50] stops me. So, that doesn't work. But I think to your point, you talked about, like, okay, if you have a, ostensibly this a community project, but all the maintainers are from one—are from your company, you know? Or so I'm going to point to an example of, we had—you know, this was at Pulumi, we had a Champions program called Puluminaries, and then there's something similar to like Vox Populi, but it was kind of the community that was not run by Pulumi Inc. In that case.Now, we helped fund it and helped get it started, but there was there were rules about the, you know, the membership of the leadership, steering committee or board or whatever it was called, there was a hard limit on the number of people that could be Pulumi employees who were on that board. And it actually, as I recall when I was leaving—I imagine this is not—[unintelligible 00:19:41] does sometimes have to adjust a couple of things because maybe those board members become employees and now you have to say, you can't do that anymore or we have to take someone down. But the goal was to actually, you know, basically have—you know, Pulumi Corp wanted to have a voice on that board because if for no other reason, they were funding it, but it was just one voice. It wasn't even a majority voice. And that's a hard sell in a lot of places too because you lose control over that.There's things I know with, uh—when I think about, like, running meetup communities, like, we might be—well I mean, this is not a big secret, I mean because it's been announced, but we're—you know, Aiven is helping bootstrap a bunch of data infrastructure meetups around the world. But they're not Aiven meetups. Now, we're starting them because they have to start, but pretty much our approach is, as soon as this is running and there's people, whether they work here, work with us or not, they can take it, right? Like, if that's go—you know? And being able to do that can be really hard because you have to relinquish the control of your community.And I think you don't have to relinquish a hundred percent of that control because you're helping facilitate it because if it doesn't already have its own thing—to make sure that things like code of conduct and funding of it, and there's things that come along with the okay, we as an organization, as a company that has dollars and euros is going to do stuff for this, but it's not ours. And that's the thing to remember is that your community does not belong to you, the company. You are there to facilitate it, you are there to empower it, you're there to force-multiply it, to help protect it. And yeah, you will probably slurp a whole bunch of value out of it, so this is not magnanimous, but if you want it to actually be a place it's going to work, it kind of has to be what it wants to be. But by the same token, you can't just sort of sit there and be like, “I'm going to wait for this community grow up around me without anything”—you know.So, that's why you do have to start one if there is quote-unquote—maybe if there's no shape to one. But yeah, I think that's… it is different when it's something that feels a little—I don't even want to say that it's about being open-source. It's a little bit about it less of it being a SaaS or a service, or if it's something that you—I don't know.Corey: This episode is sponsored in part by Honeycomb. I'm not going to dance around the problem. Your. Engineers. Are. Burned. Out. They're tired from pagers waking them up at 2 am for something that could have waited until after their morning coffee. Ring Ring, Who's There? It's Nagios, the original call of duty! They're fed up with relying on two or three different “monitoring tools” that still require them to manually trudge through logs to decipher what might be wrong. Simply put, there's a better way. Observability tools like Honeycomb (and very little else becau se they do admittedly set the bar) show you the patterns and outliers of how users experience your code in complex and unpredictable environments so you can spend less time firefighting and more time innovating. It's great for your business, great for your engineers, and, most importantly, great for your customers. Try FREE today at honeycomb.io/screaminginthecloud. That's honeycomb.io/screaminginthecloud.Corey: Yeah, I think you're onto something here. I think another aspect where I found it be annoying is when companies view their community as, let's hire them all. And I don't think it ever starts that way. I think that it starts as, well these are people who are super-passionate about this, and they have great ideas and they were great to work with. Could we hire them?And the answer is, “Oh, wait. You can give me money for this thing I've been doing basically for free? Yeah, sure, why not?” And that's great in the individual cases. The problem is, at some point, you start to see scenarios where it feels like, if not everyone, then a significant vocal majority of the community starts to work there.Matty: I think less often than you might think is it done strategically or on purpose. There have been exceptions to that. There's one really clear one where it feels like a certain company a few years ago, hired up all the usual suspects of the DevOps community. All of a sudden, you're like, oh, a dozen people all went to go work at this place all at once. And the fun thing is, I remember feeling a little bit—got my nose a little out of joint because I was not the hiring mana—like, I knew the people.I was like, “Well, why didn't you ask me?” And they said, “Actually, you are more important to us not working here.” Now, that might have just been a way to sell my dude-in-tech ego or not, but whether or not that was actually true for me or not, that is a thing where you say you know, your folks—but I do think that particular example of, like, okay, I'm this, that company, and I'm going to go hire up all the usual suspects, I think that's less. I think a lot of times when you see communities hire up those people, it's not done on purpose and in fact, it's probably not something they actually wanted to do in mass that way. But it happens because people who are passionate about your product, it's like I said before, it actually seems pretty cool to go work on it as your main thing.But I can think of places I've been where we had, you know—again, same thing, we had a Pulumi—we had someone who was probably our strongest, loudest, most vocal community member, and you know, I really wanted to get this person to come join us and that was sort of one of the conversations. Nobody ever said, “We won't offer this person a job if they're great.” Like, that's the thing. I think that's actually kind of would be shitty to be like, “You're a very qualified individual, but you're more important to me out in the community so I'm not going to make your job offer.” But it was like, Ooh, that's the, you know—it'd be super cool to have this person but also, not that that should be part of our calculus of decision, but then you just say, what do you do to mitigate that?Because what I'm concerned about is people hearing this the wrong way and saying, “There's this very qualified individual who wants to come work on my team at my company, but they're also really important to our community and it will hurt our community if they come work here, so sorry, person, we're not going to give you an opportunity to have an awesome job.” Like, that's also thinking about the people involved, too. But I know having talked to folks that lots of these different large organizations that have this problem, generally, those community folks, especially at those places, they don't want this [laugh] happening. They get frustrated by it. So, I mean, I'll tell you, it's you know, the—AWS is one of them, right?They're very excited about a lot of the programs and cool people coming from community builders and stuff and Heroes, you know. On one hand, it's incredibly awesome to have a Hero come work at AWS, but it hurts, right, because now they're not external anymore.Corey: And you stop being a Hero in that case, as well.Matty: Yeah. You do, yeah.Corey: Of course, they also lose the status if they go to one of their major competitors. So like, let me get this straight. You can't be a Hero if you work for AWS or one of its competitors. And okay, how are there any Heroes left at all at some point? And the answer is, they bound it via size and a relatively small list of companies. But okay.Matty: So, thinking back to your point about saying, okay, so if you work at the company, you lose some authenticity, some impartiality, some, you know… I think, rather than just saying, “Well, you're not part”—because that also, honestly, my concern is that your blog post is now going to be ammunition for all the people who don't want to act as members of the community for the company they work for now. They're going to say, well, Corey told me I don't have to. So, like I said, I've been spending the last few years tilting at the opposite windmill, which is getting people that are not on the community team to take part in community summits and discourse and things like that, like, you know, for that's—so I think the thing is, rather than saying, “Well, you can't,” or, “You aren't,” it's like, “Well, what do you do to mitigate those things?”Corey: Yeah, it's a weird thing because taking AWS as the example that I've been beating up on a lot, the vast majority of their employees don't know the community exists in any meaningful sense. Which, no fault to them. The company has so many different things, no one keeps up with at all. But it's kind of nuts to realize that there are huge communities of people out there using a thing you have built and you do not know that those users exist and talk to each other in a particular watering hole. And you of course, as a result, have no presence there. I think that's the wrong direction, too. But—Matty: Mm-hm.Corey: Observing the community and being part of the community, I think there's a difference. Are you a biologist or are you a gorilla?Matty: Okay, but [sigh] I guess that's sort of the difference, too which—and it's hard, it's very hard to not just observe. Because I think that actually even taking the mentality of, “I am here to be Jane Goodall, Dr. Jane Goodall, and observe you while I live amongst you, but I'm not going to actually”—although maybe I'm probably doing disservice—I'm remembering my Goodall is… she was actually more involved. May be a bad example.Corey: Yeah. So, that analogy does fall apart a little bit.Matty: It does fall apart a little bit—Corey: Yeah.Matty: But it's you kind of am I sitting there taking field notes or am I actually engaging with you? Because there is a difference. Even if your main reason for being there is just purely to—I mean, this is not the Prime Directive. It's not Star Trek, right? You're not going to like, hold—you don't need to hold—I mean, do you have to hold yourself aloof and say, “I don't participate in this conversation; I'm just here to take notes?”I think that's very non-genuine at that point. That's over-rotating the other way. But I think it's a matter of in those spaces—I think there's two things. I think you have to have a way to be identified as you are an employee because that's just disclosure.Corey: Oh, I'm not suggesting by any stretch of the imagination, people work somewhere but not admit that they work somewhere when talking about the company. That's called fraud.Matty: Right. No, no, and I don't think it's even—but I'm saying beyond just, if it's not, if you're a cop, you have to tell me, right?Corey: [laugh].Matty: It's like, it's not—if asked, I will tell you I work at AWS. It's like in that place, it should say, “I am an AWS em—” like, I should be badged that way, just so it's clear. I think that's actually helpful in two ways. It's also helpful because it says like, okay, maybe you have a connection you can get for me somehow. Like, you might actually have some different insight or a way to chase something that, you know, it's not necessarily just about disclosure; it's also helpful to know.But I think within those spaces, that disclosure—or not disclosure, but being an employee does not offer you any more authority. And part of that is just having to be very clear about how you're constructing that community, right? And that's sort of the way that I think about it is, like, when we did the Pulumi Community Summit about a year ago, right? It was an online, you know, thing we did, and the timing was such that we didn't have a whole lot of Pulumi engineers were able to join, but when we—and it's hard to say we're going to sit in an open space together and everybody is the same here because people also—here's the difference. You say you want this authority? People will want that authority from the people that work at the company and they will always go to them and say, like, “Well, you should have this answer. Can you tell me about this? Can you do this?”So, it's actually hard on both cases to have that two-way conversation unless you set the rules of that space such as, “Okay, I work at Aiven, but when I'm in this space, short of code of conduct or whatever, if I have to be doing that thing, I have no more authority on this than anyone else.” I'm in this space as the same way everyone else's. You can't let that be assumed.Corey: Oh, and big companies do. It's always someone else's… there's someone else's department. Like, at some level, it feels like when you work in one of those enormous orgs, it's your remit is six inches wide.Matty: Well, right. Right. So, I think it's like your authority exists only so far as it's helpful to somebody. If I'm in a space as an Aivener, I'm there just as Matty the person. But I will say I work at Aiven, so if you're like, “God, I wish that I knew who was the person to ask about this replication issue,” and then I can be like, “Aha, I actually have backchannel. Let me help you with that.” But if I can say, “You know what? This is what I think about Kafka and I think why this is whatever,” like, you can—my opinion carries just as much weight as anybody else's, so to speak. Or—Corey: Yeah. You know, it's also weird. Again, community is such a broad and diverse term, I find myself in scenarios where I will observe and talk to people inside AWS about things, but I never want to come across as gloating somehow, that oh, I know, internal people that talk to you about this and you don't. Like, that's never how I want to come across. And I also, I never see the full picture; it's impossible for me to, so I never make commitments on behalf of other people. That's a good way to get in trouble.Matty: It is. And I think in the case of, like, someone like you who's, you know, got the connections you have or whatever, it's less likely for that to be something that you would advertise for a couple of reasons. Like, nobody should be advertising to gloat, but also, part of my remit as a member of a community team is to actually help people. Like, you're doing it because you want to or because it serves you in a different way. Like, that is literally my job.So like, it shouldn't be, like—like, because same thing, if you offer up your connections, now you are taking on some work to do that. Someone who works at the company, like, yes, you should be taking on that work because this is what we do. We're already getting paid for it, you know, so to speak, so I think that's the—Corey: Yeah.Matty: —maybe a nuance, but—Corey: Every once in a while, I'll check my Twitter spam graveyard, [unintelligible 00:32:01] people asking me technical questions months ago about various things regarding AWS and whatnot. And that's all well and good; the problem I have with it is that I'm not a support vector. I don't represent for the company or work for them. Now, if I worked there, I'd feel obligated to make sure this gets handed to the right person. And that's important.The other part of it, though, is okay, now that that's been done and handed off, like do I shepherd it through the process? Eh. I don't want people to get used to asking people in DMs because again, I consider myself to be a nice guy, but if I'm some nefarious jerk, then I could lead them down a very dark path where I suddenly have access to their accounts. And oh, yeah, go ahead and sign up for this thing and I'll take over their computer or convince them to pay me in iTunes gift cards or something like that. No, no, no. Have those conversations in public or through official channels, just because I don't, I don't think you want to wind up in that scenario.Matty: So, my concern as well, with sort of taking the tack of you are just an observer of the community, not a part of it is, that actually can reinforce some pretty bad behavior from an organization towards how they treat the community. One of the things that bothers me—if we're going to go on a different rant about devrelopers like myself—is I like to say that, you know, we pride ourselves as DevRels as being very empathetic and all this stuff, but very happy to shit all over people that work in sales or marketing, based on their job title, right? And I'm like, “Wow, that's great,” right? We're painting with this broad brush. Whereas in reality, we're not separate from.And so, the thing is, when you treat your community as something separate from you, you are treating it as something separate from you. And then it becomes a lot easier also, to not treat them like people and treat them as just a bunch of numbers and treat them as something to have value extracted from rather than it—this is actually a bunch of humans, right? And if I'm part of that, then I'm in the same Dunbar number a little bit, right? I'm in the same monkey sphere as those people because me, I'm—whoever; I'm the CTO or whatever, but I'm part of this community, just like Joe Smith over there in Paducah, you know, who's just building things for the first time. We're all humans together, and it helps to not treat it as the sort of amorphous blob of value to be extracted.So, I think that's… I think all of the examples you've been giving and those are all valid concerns and things to watch out for, the broad brush if you're not part of the community if you work there, my concern is that that leads towards exacerbating already existing bad behavior. You don't have to convince most of the people that the community is separate from them. That's what I'm sort of getting at. I feel like in this work, we've been spending so much time to try to get people to realize they should be acting like part of their larger community—and also, Corey, I know you well enough to know that, you know, sensationalism to make a point [laugh] works to get somebody to join—Corey: I have my moments.Matty: Yeah, yeah, yeah. I mean, there's I think… I'll put it this way. I'm very interested to see the reaction, the response that comes out in, well now, for us a couple of days, for you the listener, a while ago [laugh] when that hits because I think it is a, I don't want to say it's controversial, but I think it's something that has a lot of, um… put it this way, anything that's simple and black and white is not good for discussion.Corey: It's nuanced. And I know that whenever I wrote in 1200 words is not going to be as nuanced of the conversation we just had, either, so I'm sure people will have opinions on it. That'd be fun. It'd be a good excuse for me to listen.Matty: Exactly [laugh]. And then we'll have to remember to go back and find—I'll have to do a little Twitter search for the dates.Corey: We'll have to do another discussion on this, if anything interesting comes out of it.Matty: Actually, that would be funny. That would be—we could do a little recap.Corey: It would. I want to thank you so much for being so generous with your time. Where can people find you if they want to learn more?Matty: Well, [sigh] for the moment, [sigh] who knows what will be the case when this comes out, but you can still find me on Twitter at @mattstratton. I'm also at hackie-derm dot io—sorry, hackyderm.io. I keep wanting to say hackie-derm, but hackyderm actually works better anyway and it's funnier. But [hackyderm.io/@mattstratton](https://hackyderm.io/@mattstratton) is my Mastodon. LinkedIn; I'm. Around there. I need to play more at that. You will—also again, I don't know when this is coming out, so you won't tell you—you don't find me out traveling as much as you might have before, but DevOpsDays Chicago is coming up August 9th and 10th in Chicago, so at the time of listening to this, I'm sure our program will have been posted. But please come and join us. It will be our ninth time of hosting a DevOpsDay Chicago. And I have decided I'm sticking around for ten, so next year will be my last DevOpsDay that I'm running. So, this is the penultimate. And we always know that the penultimate is the best.Corey: Absolutely. Thanks again for your time. It's appreciated. Matty Stratton, Director of Developer Relations at Aiven. 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 talking about how I completely missed the whole point of this community and failing to disclose that you are in fact one of the producers of the show.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.

On today's Kubernetes Unpacked, Michael and guests explore Windows containers. A few years ago there was a lot of hype around Nano, which then morphed into Nano Server. We look at the current state of containerized Windows, using Windows containers with Kubernetes, customer scenarios for container adoption, and Microsoft's approach to the container space. The post Kubernetes Unpacked 021: Catching Up With Windows Containers On Kubernetes appeared first on Packet Pushers.

The edge is one of those terms that can be shaped to fit almost any use case. On today's Kubernetes Unpacked episode, host Michael Levan talks with Alan Hohn, Director of Software Strategy at Lockheed Martin, about what the defense industry means by the edge, and getting a working definition of the edge we can all live with. The post Kubernetes Unpacked 020: A Working Definition Of Kubernetes At The Edge appeared first on Packet Pushers.

The edge is one of those terms that can be shaped to fit almost any use case. On today's Kubernetes Unpacked episode, host Michael Levan talks with Alan Hohn, Director of Software Strategy at Lockheed Martin, about what the defense industry means by the edge, and getting a working definition of the edge we can all live with. The post Kubernetes Unpacked 020: A Working Definition Of Kubernetes At The Edge appeared first on Packet Pushers.

In today's Kubernetes Unpacked podcast, we explore the concept of a service mesh and why you might want to run one in a Kubernetes cluster. While there are many service meshes to choose from we focus on Linkerd. Linkerd is available under an Apache 2.0 license and hosted by the Cloud Native Computing Foundation (CNCF). The post Kubernetes Unpacked 019: Understanding Service Meshes And Linkerd appeared first on Packet Pushers.

In today's Kubernetes Unpacked podcast, we explore the concept of a service mesh and why you might want to run one in a Kubernetes cluster. While there are many service meshes to choose from we focus on Linkerd. Linkerd is available under an Apache 2.0 license and hosted by the Cloud Native Computing Foundation (CNCF). The post Kubernetes Unpacked 019: Understanding Service Meshes And Linkerd appeared first on Packet Pushers.

In today's Kubernetes Unpacked episode, host Michael Levan and guest Michael Chenetz examine the complexity that comes with Kubernetes and its broader ecosystem, what engineers should expect when diving into it, and why organizations should invest in people not just tech. The post Kubernetes Unpacked 018: Grappling With Kubernetes Complexity appeared first on Packet Pushers.

In today's Kubernetes Unpacked episode, host Michael Levan and guest Michael Chenetz examine the complexity that comes with Kubernetes and its broader ecosystem, what engineers should expect when diving into it, and why organizations should invest in people not just tech. The post Kubernetes Unpacked 018: Grappling With Kubernetes Complexity appeared first on Packet Pushers.

On today's Kubernetes Unpacked podcast, host Michael Levan discusses six big ideas to consider as you build your Kubernetes foundation in 2023. Topics include abstractions, the need to understand what's beneath those abstractions, Kubernetes security, and more. The post Kubernetes Unpacked 017: Kubernetes In 2023 – 6 Things To Think About appeared first on Packet Pushers.

On today's Kubernetes Unpacked podcast, host Michael Levan discusses six big ideas to consider as you build your Kubernetes foundation in 2023. Topics include abstractions, the need to understand what's beneath those abstractions, Kubernetes security, and more. The post Kubernetes Unpacked 017: Kubernetes In 2023 – 6 Things To Think About appeared first on Packet Pushers.

On today's Kubernetes Unpacked podcast we talk about taking on Kubernetes as a young engineer. As all IT pros know, learning Kubernetes isn't the easiest thing, especially when you're first entering the field. Guest Alero Awani, a college student, talks about her transition from Data Engineering to cloud and DevOps, and how and why she came to learn Kubernetes. The post Kubernetes Unpacked 016: Taking On Kubernetes As A New Engineer appeared first on Packet Pushers.

On today's Kubernetes Unpacked podcast we talk about taking on Kubernetes as a young engineer. As all IT pros know, learning Kubernetes isn't the easiest thing, especially when you're first entering the field. Guest Alero Awani, a college student, talks about her transition from Data Engineering to cloud and DevOps, and how and why she came to learn Kubernetes. The post Kubernetes Unpacked 016: Taking On Kubernetes As A New Engineer appeared first on Packet Pushers.

In this episode of the Kubernetes Unpacked podcast, Michael explores the concept of Financial Operations, or FinOps, with guest Chris Love. As CTOs get their cloud bills, they want to know why and how so much money is being spent. Chris introduces Michael to the concept of FinOps for tracking cloud spend, why it's important, and how it can help engineers keep their jobs. The post Kubernetes Unpacked 015: Managing Cloud Costs With FinOps appeared first on Packet Pushers.

In this episode of the Kubernetes Unpacked podcast, Michael explores the concept of Financial Operations, or FinOps, with guest Chris Love. As CTOs get their cloud bills, they want to know why and how so much money is being spent. Chris introduces Michael to the concept of FinOps for tracking cloud spend, why it's important, and how it can help engineers keep their jobs. The post Kubernetes Unpacked 015: Managing Cloud Costs With FinOps appeared first on Packet Pushers.

On today's Day Two Cloud we continue our Kubernetes conversation with guest Michael Levan. Today's show focuses on Kubernetes deployments and managing clusters once they're up and running. We discuss whether Kubernetes is really more complex than traditional application infrastructure; examine management options such as GitOps, manifests, and Kubectl; share useful tools, and talk about why Kubernetes is all about APIs.

On today's Day Two Cloud we continue our Kubernetes conversation with guest Michael Levan. Today's show focuses on Kubernetes deployments and managing clusters once they're up and running. We discuss whether Kubernetes is really more complex than traditional application infrastructure; examine management options such as GitOps, manifests, and Kubectl; share useful tools, and talk about why Kubernetes is all about APIs. The post Day Two Cloud 175: Deploying Kubernetes And Managing Clusters appeared first on Packet Pushers.

On today's Day Two Cloud we continue our Kubernetes conversation with guest Michael Levan. Today's show focuses on Kubernetes deployments and managing clusters once they're up and running. We discuss whether Kubernetes is really more complex than traditional application infrastructure; examine management options such as GitOps, manifests, and Kubectl; share useful tools, and talk about why Kubernetes is all about APIs. The post Day Two Cloud 175: Deploying Kubernetes And Managing Clusters appeared first on Packet Pushers.

On today's Day Two Cloud we continue our Kubernetes conversation with guest Michael Levan. Today's show focuses on Kubernetes deployments and managing clusters once they're up and running. We discuss whether Kubernetes is really more complex than traditional application infrastructure; examine management options such as GitOps, manifests, and Kubectl; share useful tools, and talk about why Kubernetes is all about APIs.

On today's Day Two Cloud we continue our Kubernetes conversation with guest Michael Levan. Today's show focuses on Kubernetes deployments and managing clusters once they're up and running. We discuss whether Kubernetes is really more complex than traditional application infrastructure; examine management options such as GitOps, manifests, and Kubectl; share useful tools, and talk about why Kubernetes is all about APIs.

On today's Day Two Cloud we continue our Kubernetes conversation with guest Michael Levan. Today's show focuses on Kubernetes deployments and managing clusters once they're up and running. We discuss whether Kubernetes is really more complex than traditional application infrastructure; examine management options such as GitOps, manifests, and Kubectl; share useful tools, and talk about why Kubernetes is all about APIs. The post Day Two Cloud 175: Deploying Kubernetes And Managing Clusters appeared first on Packet Pushers.

In today's episode of Kubernetes Unpacked, Michael catches up with Steve Buchanan, Principal Program Manager at Microsoft, to talk about using GitOps and Azure Kubernetes Service (AKS) to automate the building and deployment of applications. Microsoft has been working incredibly hard on AKS, including integrating different tools and platforms to make the lives of DevOps and Platform Engineers easier. The post Kubernetes Unpacked 014: Using GitOps And AKS To Build And Deploy Applications appeared first on Packet Pushers.

In today's episode of Kubernetes Unpacked, Michael catches up with Steve Buchanan, Principal Program Manager at Microsoft, to talk about using GitOps and Azure Kubernetes Service (AKS) to automate the building and deployment of applications. Microsoft has been working incredibly hard on AKS, including integrating different tools and platforms to make the lives of DevOps and Platform Engineers easier. The post Kubernetes Unpacked 014: Using GitOps And AKS To Build And Deploy Applications appeared first on Packet Pushers.

In this episode, Michael Levan catches up Richard Hooper, Microsoft Azure MVP and Azure Architect, to chat about Azure Kubernetes Service (AKS) in production. Richard spends the majority of his time working with organizations that are either using AKS, or are migrating to AKS, so he has a ton of experience in how to actually use AKS in the real-world. The post Kubernetes Unpacked 013: Azure Kubernetes Service (AKS) In Production appeared first on Packet Pushers.

In this episode, Michael Levan catches up Richard Hooper, Microsoft Azure MVP and Azure Architect, to chat about Azure Kubernetes Service (AKS) in production. Richard spends the majority of his time working with organizations that are either using AKS, or are migrating to AKS, so he has a ton of experience in how to actually use AKS in the real-world. The post Kubernetes Unpacked 013: Azure Kubernetes Service (AKS) In Production appeared first on Packet Pushers.

Matty Stratton is the Director of Developer Relations at Aiven, a well-known member of the DevOps community, founder and co-host of the popular Arrested DevOps podcast, and the global chair of the DevOpsDays set of conferences. Matty has over 20 years of experience in IT operations and is a sought-after speaker internationally, presenting at Agile, DevOps, and cloud engineering focused events worldwide. Demonstrating his keen insight into the changing landscape of technology, he recently changed his license plate from DEVOPS to KUBECTL. He lives in Chicago and has three awesome kids, whom he loves just a little bit more than he loves Diet Coke. You can follow Matty on Social Media https://twitter.com/mattstratton https://matty.wtf/ Also take a look at some other links from Matty https://www.arresteddevops.com/ https://devopsdays.org/ PLEASE SUBSCRIBE TO THE PODCAST - Spotify: http://isaacl.dev/podcast-spotify - Apple Podcasts: http://isaacl.dev/podcast-apple - Google Podcasts: http://isaacl.dev/podcast-google - RSS: http://isaacl.dev/podcast-rss You can check out more episodes of Coffee and Open Source on https://www.coffeeandopensource.com/ Coffee and Open Source is hosted by Isaac Levin (https://twitter.com/isaacrlevin) --- Support this podcast: https://podcasters.spotify.com/pod/show/coffeandopensource/support

In this episode, Michael catches up with Chad Crowell to talk about the Certified Kubernetes Administrator (CKA) exam. They talk about why the certification is important, its hands-on emphasis, how you can study for the cert, and what you should know when going in to sit for the exam. The post Kubernetes Unpacked 012: Getting Hands-On For The Certified Kubernetes Administrator (CKA) Cert appeared first on Packet Pushers.

In this episode, Michael catches up with Chad Crowell to talk about the Certified Kubernetes Administrator (CKA) exam. They talk about why the certification is important, its hands-on emphasis, how you can study for the cert, and what you should know when going in to sit for the exam. The post Kubernetes Unpacked 012: Getting Hands-On For The Certified Kubernetes Administrator (CKA) Cert appeared first on Packet Pushers.

No sponsors showroom da KubeCon, o João Brito reuniu todos os brasileiros que encontrou por lá para saber como eles pronunciam “Kubectl” e o que viram de mais legal no terceiro dia de evento!SOBRE O KUBICASTO Kubicast é uma produção da Getup, a única empresa brasileira 100% focada e especializada em Kubernetes. Todos os episódios do podcast estão no site da Getup e nas principais plataformas de áudio digital. Alguns deles estão registrados no YT. O Kubicast é uma produção da Getup, a única empresa brasileira 100% focada e especializada em Kubernetes. Todos os episódios do podcast estão no site da Getup e nas principais plataformas de áudio digital. Alguns deles estão registrados no YT.

On today's Kubernetes Unpacked podcast, Michael catches up with Eric Wright to discuss the current and future of containers and Kubernetes, as well as a look into how the world of containers has evolved. They dive into virtualization, how orchestration actually works, and how to think about ephemeral workloads. The post Kubernetes Unpacked 011: Containers Past, Present And Future appeared first on Packet Pushers.

On today's Kubernetes Unpacked podcast, Michael catches up with Eric Wright to discuss the current and future of containers and Kubernetes, as well as a look into how the world of containers has evolved. They dive into virtualization, how orchestration actually works, and how to think about ephemeral workloads. The post Kubernetes Unpacked 011: Containers Past, Present And Future appeared first on Packet Pushers.

In this episode, Michael catches up with Natan Yellin, CEO of Robusta.dev. Michael and Ned chat about how logging and troubleshooting works in Kubernetes today. They discuss three stages of troubleshooting evolution - manual playbooks, automatic playbooks, and the third stage, which is what you do with logs and how automatic remediation can come into play for any Kubernetes environment. The post Kubernetes Unpacked 010: Troubleshooting And Alerting On Kubernetes appeared first on Packet Pushers.

In this episode, host Michael Levan talks with Ned Bellavance about why orchestration is important in today's world, how the HashiCorp stack (primarily Terraform and Vault) fit into Kubernetes, and more. The post Kubernetes Unpacked 009: Kubernetes Automation And Repeatability appeared first on Packet Pushers.

In this episode, Michael catches up with Josh Duffney, Cloud Developer Advocate at Microsoft to talk about Go (golang). Kubernetes, Docker, and Terraform are all written in Go. Josh and Michael talk about their journey into Kubernetes and Go, some fun projects to play with, how to learn Go, and why understanding certain programming languages is crucial for breaking into Kubernetes. The post Kubernetes Unpacked 008: Go – The Language Of Kubernetes appeared first on Packet Pushers.

Learning Kubernetes isn't easy. In fact, there are so many places to start that people literally don't know where to begin. Do they learn Kubernetes security? Networking? Infrastructure? Development? Michael Levan catches up with Kevin Evans and Robin Smorenburg to talk about their journeys into Kubernetes, how each of them started, links to learning resources, and where they're at now. The post Kubernetes Unpacked 007: Kubernetes From Beginner To Advanced appeared first on Packet Pushers.

Kubernetes is hard. Regardless of what tech marketing says, DevOps teams are still trying to implement and figure out this whole Kubernetes thing. With multi-cloud, hybrid cloud, and on-prem Kubernetes implementations, how can teams start their journey and have an impact? Michael Levan catches up with Jeff Smith, Ops Director and author, to talk about his journey into Kubernetes for his team and what other teams should think about when implementing Kubernetes. The post Kubernetes Unpacked 006: The Impact Of Kubernetes On DevOps Teams appeared first on Packet Pushers.

This interview was recorded for GOTO Unscripted at CodeNode in London.gotopia.techRead the full transcription of this interview hereMark Rendle - Incurable Programmer & Lover of C#, .NET Core, Containers, Clouds & DevOpsMatt Turner - DevOps Leader, Software Engineer at TetrateDESCRIPTIONJoin Mark Rendle, MS Dev Tech MVP, and Matt Turner, DevOps leader, architect, and engineer at Marshall Wace, in a passionate discussion about gRPC's past and future and how it fits in with technologies such as .NET and service meshes. They get deep in the weeds on technology cycles while debating the future of infrastructure as a code and Kubernetes. And Mark has a brilliant idea on how to build an alternative to Facebook.RECOMMENDED BOOKSBurns, Beda & Hightower • Kubernetes: Up & RunningBurns, Villalba, Strebel & Evenson • Kubernetes Best PracticesKasun Indrasiri & Danesh Kuruppu • gRPC: Up and RunningLiz Rice • Container SecurityLiz Rice • Kubernetes SecurityJohn Arundel & Justin Domingus • Cloud Native DevOps with KubernetesHausenblas & Schimanski • Programming KubernetesTwitterLinkedInFacebookLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket at gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily.Discovery MattersA collection of stories and insights on matters of discovery that advance life...Listen on: Apple Podcasts Spotify Health, Wellness & Performance Catalyst w/ Dr. Brad CooperLooking for a catalyst to optimize your health, wellness & performance? You've found it!!Listen on: Apple Podcasts Spotify The New Arab VoiceA podcast from The New Arab, a leading English-language website based in London...Listen on: Apple Podcasts Spotify Being an EngineerIndustry knowledge & best practices that will accelerate your engineering learning curve.Listen on: Apple Podcasts Spotify

Since the inception of Kubernetes, the goal has been to make our lives as engineers easier. But with great power comes great responsibility---which in this case is the need to manage a bunch of control planes and worker nodes! Host Michael Levan catches up with Jason Haley, Microsoft MVP and independent consultant to talk about serverless Kubernetes with Azure Container Apps. The post Kubernetes Unpacked 005: Serverless Kubernetes In Azure appeared first on Packet Pushers.

On today's Kubernetes Unpacked podcast we explore tradeoffs that come with using Terraform to manage Kubernetes. My guest is Luke Orellana, an SRE who uses Kubernetes. He's also a HashiCorp Ambassador. We also discuss differences between managing VMs and Kubernetes, Kubernetes benefits including self-healing, and downsides such as dealing with the complexity that comes from containers and microservices. The post Kubernetes Unpacked 004: Pros And Cons Of Using Terraform With Kubernetes appeared first on Packet Pushers.

Today's Kubernetes Unpacked podcast explores entry-level lab environments for IT professionals interested in learning Kubernetes, including suggestions for simple container-based apps you can run to get familiar with Kubernetes essentials. The post Kubernetes Unpacked 003: Beginner Lab Environments For Learning Kubernetes appeared first on Packet Pushers.

In this episode, Michael Levan chats with Neil Cresswell, CEO and Co-Founder of Portainer.io. They talk about the challenges of Kubernetes and how everyone is trying to navigate its complexities. They also dive into Kubernetes security, networking, and management. The post Kubernetes Unpacked 002: Tackling Container Management And Kubernetes Complexity appeared first on Packet Pushers.

Welcome to the inaugural episode of Kubernetes Unpacked, a new podcast in the Packet Pushers Community Channel. The goal of this podcast is to help IT professionals understand Kubernetes: how it works; how and why it's used; how to deploy, operate, and manage the platform on premises and in the cloud; Kubernetes networking and security concepts; and more. The post Kubernetes Unpacked 001: Prerequisites For Kubernetes Success appeared first on Packet Pushers.

About “Matty”Matt Stratton is a Staff Developer Advocate at Pulumi, founder and co-host of the popular Arrested DevOps podcast, and the global chair of the DevOpsDays set of conferences.Matt has over 20 years of experience in IT operations and is a sought-after speaker internationally, presenting at Agile, DevOps, and cloud engineering focused events worldwide. Demonstrating his keen insight into the changing landscape of technology, he recently changed his license plate from DEVOPS to KUBECTL.He lives in Chicago and has three awesome kids, whom he loves just a little bit more than he loves Diet Coke. Matt is the keeper of the Thought Leaderboard for the DevOps Party Games online game show and you can find him on Twitter at @mattstratton.Links Referenced Pulumi: https://www.pulumi.com/ Arrested DevOps: https://www.arresteddevops.com/ 8bits.tv: https://8bits.tv Twitter: https://twitter.com/mattstratton LinkedIn: https://www.linkedin.com/in/mattstratton/ speaking.mattstratton.com: https://speaking.mattstratton.com twitch.tv/Pulumi: https://twitch.tv/Pulumi 8bit.tv: https://8bit.tv duckbillgroup.com: https://duckbillgroup.com 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 our friends at Vultr. Spelled V-U-L-T-R because they're all about helping save money, including on things like, you know, vowels. So, what they do is they are a cloud provider that provides surprisingly high performance cloud compute at a price that—while sure they claim its better than AWS pricing—and when they say that they mean it is less money. Sure, I don't dispute that but what I find interesting is that it's predictable. They tell you in advance on a monthly basis what it's going to going to cost. They have a bunch of advanced networking features. They have nineteen global locations and scale things elastically. Not to be confused with openly, because apparently elastic and open can mean the same thing sometimes. They have had over a million users. Deployments take less that sixty seconds across twelve pre-selected operating systems. Or, if you're one of those nutters like me, you can bring your own ISO and install basically any operating system you want. Starting with pricing as low as $2.50 a month for Vultr cloud compute they have plans for developers and businesses of all sizes, except maybe Amazon, who stubbornly insists on having something to scale all on their own. Try Vultr today for free by visiting: vultr.com/screaming, and you'll receive a $100 in credit. Thats V-U-L-T-R.com slash screaming.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. Returning today for yet another round on the Screaming in the Cloud podcast is my dear friend, and hopefully yours as well, Matty Stratton. Since the last time we spoke, you've changed jobs, Mattie; you're now a staff developer advocate at Pulumi. I don't believe you were the last time you were on this show, but memory escapes me.Matty: You know, I was just wondering that myself, and I guess we'll have to go back to the archives.Corey: Yes, but that sounds like work, so we're going to roll with it anyway.Matty: Everyone who's listening, go do the homework for us. And, like, just tweet and let us know what my job was last time.Corey: And yell at us if we get it wrong, of course.Matty: Yell at us if we get it right.Corey: In the interest of being, well, I guess a little on the judgey side—because why not I tend to be good at that.Matty: I was hoping to be on the judgey side on this show.Corey: Oh, absolutely. You have a very strange career trajectory, in that—the companies you work for and how that winds up going back and forth. But when we first met, you were at Chef; and Chef, great company. And after that it was PagerDuty; great company.Matty: [laugh].Corey: And then it was IBM Hat, which I—was it Red Hat, was it IBM side?Matty: For me, it was Red Hat.Corey: So, it went from Chef, which is great, and a company that was doing a lot of things on the container side of the world became a thing and mutable infrastructure did sort of change Chef's business model. And then you went to PagerDuty, the wake-you-up-in-the-middle-of-the-night service named after some legacy technologies. And should be very direct in the popular consciousness, IBM views pagers as newfangled technology in some circles, in some areas, so it feels like you were traveling back in time a bit, again and again and again. On the federal side as well which, for excellent reasons, is not usually the absolute bow wave of innovation because you don't usually want your government doing that in some ways. And now you've leapfrogged into Pulumi, which is sort of the bleeding edge of the modern way we think about provisioning cloud infrastructure.It feels like it's a very interesting trajectory. Now, this is speaking as a complete outsider, I'm going to assume that's not how you view basically any characterization of any of those companies I've just named. How do you view it?Matty: You know, I don't know that I necessarily disagree with the way that you've put everything, but there's some nuance and some interesting stuff when it comes to that. So, I'm going to specifically talk about the Red Hat thing; why did I leave PagerDuty? And one of the interesting things is, I actually had an offer from Pulumi at the time that I took the job from Red Hat. So, it actually took me a year to come and work at Pulumi. And the little bit of the short answer is Red Hat backed up a big truck of money. And we all have a price.Corey: Yeah, the dulcet tones of a dump truck full of gold bricks emptying itself into your backyard, it's hard to say no to.Matty: The reason that I want to bring that up is that has nothing to do with specifically Red Hat the company versus other companies. It was the role. It was a sales-oriented role, so if you don't know, sales gets paid a lot of money and there's good reason. One of the reasons—again, if you don't work in sales, you don't necessarily know this—is, the last day of the quarter, you will have your VP of sales talking, he'll be like, “Corey, you are amazing. I love you. Look at this big deal you brought in.” Twenty-four hours later, “What have you done for me lately?”Corey: Mm-hm.Matty: That didn't matter, right? And I remember the CEO of PagerDuty—so Jen Tejada—at one of the sales kickoffs I was at, she said—you know, because salespeople, like, you might know this, like, the top sales reps in the company, they go on trips, they have all this stuff—and Jen said, you know, “I've got engineers here that are like, well, I don't understand.” It's like, “How come the salespeople get to go to Bermuda or do whatever?” And she's like, “Would you like your paycheck to change every quarter based upon specifically what you did and have the stress of what have you done all this stuff? No? Okay, cool. Then you can keep”—you know, there's a trade-off. So, the point of that was—Corey: And as your paycheck gets smaller, you're getting closer and closer to losing your job because a salesperson needs to perform to keep. It's very feast or famine. It's a heck of a role, and I have nothing but respect for people who can do it.Matty: And people can do it well. And I do feel like a lot of people don't understand how sales works, especially in a larger organization, and I think it's really important. So, one of the things that was interesting is we've all—I shouldn't say all, but many of us have worked in jobs that have some form of variable compensation, some kind of annual bonus. So, let's say for example, at x company I'm working at, they're like, “Mattie, your bonus is equal to 10% of your paycheck.” Well, the most it could be, generally speaking, it's like, let's say that your bonus would be, I'm just going to make up a number and say it's a $10,000 bonus.That's the most it could be, and that's if everything is amazing. Maybe I'll get a little more. Now, your commission, your what they call your on-target earnings and sales, they'll tell you a number and they'll say, “Okay, Corey, you're on-target earnings are, say $200,000.” And you're like, “Oh.” But whatever.The thing is, if you're only getting you're on-target earnings, you probably are needing to look for another job. So, you remember, like, we hear it differently, those of us that have done bonuses in a non-sales way. We're like, “But that's not a lot.” You're like, “No, but what they tell you your commission is, it's actually… it better end up being more or else you have trouble.” Anyway, point is—Corey: And in some cases, it could be a significant multiple of that number as well, for top performers.Matty: Absolutely.Corey: The upside is always interesting, and calculating out the nuances of the sales plan is always a challenge, speaking as a business owner. It is a very specific field that has a bunch of nuance to it. Something I learned very early on is that if you manage salespeople as if they were engineers, or manage engineers as if they were salespeople, you are going to have an absolutely terrible time.Matty: I think one of the things that, along those lines, I've have had conversations with people who work in different parts of technology, different parts of the business, who their long-term desire is to be a CEO, and I'm like, you really should go spend some time working in sales because most CEOs—again, this is blunt, but it's true—if you think about it, what is the area of the business that they pay the most attention to? And I don't mean, they don't care about the other stuff, but who is the person on the executive team that the CEO is mostly joined at the hip with, and it's your chief revenue officer, it's your head of sales because you have to understand that, you have to understand pipeline, how that—you have to understand a lot of things as a CEO, but if you don't know how sales works—it doesn't mean know how to sell but know the ideas behind it. I mean, you should know how to sell, but you know what I mean?Corey: Yeah, I think every CEO is selling. It is a sales job, whether that is selling the company to prospective employees, whether it is selling strategic partnerships, whether it's being brought in to help close strategic deals, et cetera, you're always selling in that role.Matty: That's a very good point. I should rephrase that, where I wasn't saying you don't need to know—Corey: CEO who has no idea how to sell [unintelligible 00:07:42] the fundamentals of—like, you put them in a meeting, and they wind up saying the wrong thing and pooching the deal, yeah, they're not CEO for very long.Matty: It's not just knowing how to sell, it's understanding how a sales process works. That's sort of the thing.Corey: I'll take it one step further beyond that, and that is that I believe that every professional is working in sales and is selling something, but not everyone's aware of it“. Well, I'm an engineer, and I don't do any sort of sales work.” Well, I hear about that from folks who are—“I have all these great ideas, but none of them ever get implemented.” Well, you're not doing an effective job of selling the idea. “I keep getting put up for promotion and not getting it,” or, “I'm not doing well in job interviews.” Or, “I'm trying to get a raise and it just isn't working for me.” And every job has elements of sales to it. I'd argue a lot of facets of modern life have sales elements to it.Matty: They do and I think the reason that people get hung out—I agree with you; I could not agree with you more. I have a talk I used to give called “The Five Love Languages of DevOps” but it was really a talk about effecting organizational change, and you have to be a salesperson, right? But I think we have this—and this is a much larger topic because it comes into how people always want to distance themselves from sales—we have this thing in our head that when we think of sales, we think of tricky people. Shysters, right? Someone that's trying to, like, pull a fast one on us, like the used car salesperson thing.And I'm like, that's not most salespeople. Like, salespeople want you to—because when we talk about learning how to sell, it's not learning how to trick somebody. It's actually learning about how to—I mean, here's the biggest thing. You want to know—we talk about DevOps all the time and stuff like that, you know, and empathy. You want to know one of the most important skills of a salesperson is? Freaking empathy.Because you need to be able to understand what your prospect—and that's if you've, you know, there's the book, The Challenger Sale, which like all business books can be summarized in a blog post, right, so you can just go read the blog post about The Challenger Sale; that'll tell you everything you need to know, but a good salesperson that's a challenger-style salesperson knows the customer better than they know themselves and knows there problems they might have that they're not aware of. And it's not because they're smarter; they have a different perspective. So, the same thing is true. So, to Corey's point, we're always selling. And even whether it's figuratively, like, conceptually—but I used to say when I was a Chef I said, the two best sales—most effective salespeople at Chef were Adam Jacob, the founder, and Nathan Harvey, the VP of community.Sales engineers are powerful because a customer will tell things to a sales engineer they won't tell the rep because they think the rep is trying to take advantage of them, which isn't true. Most important conversations that happen are on the walk from the front desk to the conference room. How many conversations would I have with the SRE, or whatever, who was the one who came to get me from reception, and we're just walking to the conference room. I learned so much there than in any other discovery session? You know, and then you use that to be—Corey: And there's not such thing as an easy sale either. And I think that gets overlooked a lot. Like, here at The Duckbill Group, if you bring us in on a consulting engagement to fix your AWS bill, you will turn a profit on that engagement. That has always been true. And we are quite literally selling money.It is effectively one of the easiest possible sales you can make; it is incredibly easy to calculate out what the ROI looks like on any of these things, and it's great, and we still have a full-on enterprise sales force because that is what it takes to wind up getting deals done when you're selling business-to-business. These are not selling t-shirts to the masses. It is a nuanced field, and honestly, when I'm interviewing people, one of the easiest ways for me to discount someone as a potential hire is that they start talking smack about sales because it is clear, first, they lack empathy, and secondly, they don't understand what sales does.Matty: One of the things that I think people who are not connected with it don't understand that again, back to Corey's point about because selling is hard, and selling internally is hard. So, this is the thing. So, you can have a champion inside your prospect who's, like, “I'm all about hiring Duckbill.” But they have to convince other people. So, what are salespeople really good at doing? They're really good at helping you build your business case to be able to get your thing that you want.Corey: How to turn your champion into an effective advocate for the thing that's going to make their job easier because they're not the person that signs off on it.Matty: And they're not the expert. Like, this used to happen when I was at Chef and I would have a customer who was like, “Okay.” They go and buy a bunch of licenses, and they're like, “Well, it didn't get deployed.” And we're like, “Well, how can we help you?” And they're like, “Well, no, it's just internal stuff. We got to convince people or whatever.”And I was like, “So, what you need to do is what you're telling me, what you need to do is sell Chef, right?” “Uh-huh.” There is nobody on this planet better at selling Chef than Chef. So, that's where that comes in because again, that's how everybody wins. So anyway, I went there because I was getting paid like a salesperson.Also, I one thing I wanted to touch on. So, you're right, usually, public sector is not seen as the most cutting edge. One of the things that's interesting at Red Hat, especially on the sales side—and friends of mine who are working on the commercial side may disagree with this, but it's generally not been true—what they call NAPS, so the North America Public Sector, I used to say I was a NAPS specialist, which sounded awesome. Because that was my title, I was NAPS specialist; I specialized in NAPS—is actually—Corey: Your status in the internal messaging system should always be sleeping at that point, why not?Matty: Sleeping. Yeah. But it's sort of known that actually the kind of emergent tech group and sales inside of the public sector, inside Red Hat, is very innovative compared to other ones. So, a lot of stuff was created there. So, it was we were doing something around a transformation office that wasn't being done in the same way anywhere else, so it was very exciting.So, I—also was the opportunity to go and work with people like Andrew Clay Shafer and John Willis and people that were—you know, it was all the people I was going to get to work with. So, that got me excited to be there. And then Covid happened, and I got news for you. Like, my job was to have challenging conversations with people about how they should do work differently. It's pretty easy to tune somebody out on the Zoom, it's a lot harder to tune somebody out when they're challenging you in a room.So, it was very hard to do this job during Covid, so our team really kind of disbanded towards the end of the year. I was really on the fence to join in the first place, and the person who was referring me to come work on the team who wanted to convince me said, you know, “What's holding you back?” And I said, “Well, it's not”—I said, “I really like developer advocacy. I like DevRel. That's not this job.” And he said, “Hey. Come try this for a year, and… if it turns out you didn't like it or wasn't for you, then go back and do DevRel.”And so that's sort of what happened. And I have seen though I am much happier in a smaller organization that's creating—you know, like, I like to feel my impact. I think everybody should spend some time in a large org because if you're going to be working with other people—right, you know what I mean—especially if you're a vendor, if you work on the vendor side like I do and stuff, Corey, you and I've talked before about background and doing developer advocacy, and I always say that, like, I do DevRel on easy mode because it's very easy for me to have empathy for my prospects and community because I did the job for 20 years. It's not impossible to be effective doing this job if you haven't literally done it. It's just that much harder. So, I [crosstalk 00:15:04]—Corey: It's a lot harder. And there's a credibility question and the rest. Yeah.Matty: I do this on easy mode. I can sit there and I can say, “Yes, I feel your pain. I literally did it for 20 years.”Corey: And you're at a point, too, let's be clear here, that you have a gravitas to you. I use you as my default example when I talk about, like, the expression of DevRel in that if you—like back when you were at PagerDuty, which I guess dates the reference a bit, but it was, okay. If you sit down and say you're doing on-call wrong, now I've been around this industry at that point 15 years or so, and I'm pretty sure I'm not. But if you're going to say that you have already got my attention in a constructive way, not in a, “Well, let me just tear this apart.” It's, no, no. I'm about to learn something by whatever it is you're about to say. And it's very hard to have that level of credibility without having done the role.Matty: That's true. Without doing it in that way. I mean, this is [crosstalk 00:15:59]—Corey: In the practitioner way of practicing the thing for which you are advocating. Like, someone telling me that I'm doing on-call wrong, who has never themselves been in a role where they themselves were on call is a little lacking in the authenticity department. It's not impossible and it can't be overcome.Matty: And you have to do it in a different way, right?Corey: Yes.Matty: And this goes back to another thing that I say a lot—my pithy Stratton quote is, “DevRel contains multitudes,” right? So, this is one of the things that we ran into, like, when we're building out our advocacy team at PagerDuty, it was seeing sort of my boss was an amazing dude and everything like that. I love him, but like, we don't scale horizontally. Our team was made up of enough of different kinds of people that, like, the way that I was able to do it because I had a certain experience, you couldn't expect that out of another one of my teammates because they actually had a different way of doing it that was just as effective, but in a different way because they have a different background, they have a different—so that's—Corey: And there's so many ways to do DevRel. Oh, yeah. Like, I'm going to call it my own bias here where when I think about DevRel, I think about it through a lens of the way I approach things, and when I give conference talks, of how I present myself, and the rest. And my approach would absolutely be aligned with what I just described, “So, you're doing AWS billing wrong.” And based upon who I am, and what I do, I can make that claim with some credibility.If I were relatively new to the industry and giving a talk about AWS billing, I would not lead that way because it does not present nearly as well, and it's going to call into question a whole bunch of skepticism. I would instead approach it as, “Here are some interesting facets about AWS billing that you may or may not be aware of.” There are different ways to approach it. Let's also be clear that it's not just conference talks; it can be blog posts, it can be documentation, it can be writing sample code, it can be Twitter, it could be TikTok of all things. There are so many ways to communicate with an audience, and your audience is wherever you happen to find them.Ideally, not in line at the Starbucks harassing the poor person in front who's just trying to order their coffee, but you know, as long as it's all consensual, talk to people who are interested in this stuff, wherever they happen to be.Matty: I think that's a really important statement you said there towards the end, which is meet people where they are, whether that's where you want them to be or not. And this comes up, it's interesting because one of the things—I'm a big believer in repurposing of content, and that's just partially because of effectiveness, but it's like, hey, if I give a talk, I should make that a blog post, I should make it a video, I should do a code example. And it's not so much because then I can hit all my OKRs with my boss.—I mean, that's part of it, right?—but not everybody likes the same kind of content.You know, there are people who really like videos, and there are people who are like, “I don't want to learn from a video at all.” And there's two ways you can approach that. One is you can say, “You're wrong. Videos are better. You should watch all my videos.” And take a guess about how well that's going to work with them getting your information or say, “I'll meet you where you are.”And I learned this even well before doing DevRel when I just thought about internal communication at an organization I was at when I was at Apartments.com and I was like, how do we get information? And you can't just say, like, well, we have this email we send to everybody. Well, everybody doesn't read email, right? So, it could be, maybe some people like RSS feeds, they want to capture it there. And the example I always gave was the most effective way that I ever saw that information was communicated inside our organization was signs in the restroom.Corey: Oh, yeah. That's a well-renowned way of doing it. That I think that Google pioneered this for a while. They had these all these things up about interesting things going on inside the—Matty: Oh—Corey: —company, about the way some systems worked—Matty: —I was at Google office and using the restroom, and I was standing there, and right in front of me with a whole good practice on cross-site scripting vulnerabilities. I guarantee they probably sent that email to everybody, it's probably been in meetings, and the people who saw it, [unintelligible 00:19:53] they saw it in the restroom.Corey: Now, of course, I'm sure they probably sell ads on those sheets, but okay.Matty: Yeah. You know, a little bit of that. When I was at Apartments.com, the floor that I worked on, the main restroom I used was a shared restroom with another office, which meant corporate never put anything up in there, and there was actually a fair amount of stuff that I didn't know about because I ignored it everywhere else and [unintelligible 00:20:14] anyway. So, the point is, back—if you will do work in person, which who is doing that anymore and why bother?—your most effective way to communicate. So, if you can figure out how to do DevRel in signs in a restroom at a conference—ohh, conferences should sell sponsorship of restroom signs.Corey: The jokes write themselves and almost certainly violate the code of conduct of at least four different [unintelligible 00:20:38], but it works. It works.Matty: [laugh]. We'll take those to Twitter.Corey: You've been around the industry for a while. You are one of the cohosts of the Arrested DevOps podcast; you've been instrumental in organizing a number of DevOps Days… or Devs-Ops days, however you want to mis-pluralize that is fine by me; roll with it. Ant—Matty: We argue more about the capitalization than the pluralization.Corey: Very fair. I want to talk to you a little bit of how the DevOps movement slash community slash role has evolved. For a long time now, it's been, “Great. So, where are the DevOps people sitting?” And then when you hear the shouted response of, “It's not a job. It's a culture,” good work. You found them. Now, you can go talk to them and all. What has changed over the past few years in the world of DevOps?Matty: So, I am fond of saying you can't buy DevOps, but I can sell it to you.Corey: Oh, absolutely. You're an exemplary DevOps salesman.Matty: Yeah. So, what happened? When we think back across the decade-plus, you know, back since 2009, one of the things I think that's interesting is, when we look at things like DevSecOps, or the other portmanteaus that are being created. It's a little bit like that meme, right, with the astronaut: “Wait. You mean, it's been DevSecOps all along?” You know, it's, “Yes, always has.”That's the thing. Like, for those who don't know, Andrew Clay Shafer is best known as coining the term. And I love Andrew, but wow, is it the worst name in the world for what we're talking about. Because it makes us all think that it's only about development and operations. And it's always been about cross-functional across all of those things. And if it helps us to give it a different name, great.Corey: It's replacing dysfunction with cross-function.Matty: Yes. There we go. That's DevOps right there. That's the best definition of DevOps I've heard. You heard it here.Corey: That one coins a phrase, in case you wondered.Matty: So, we still use the term CALMS to say what is about: It's about Culture, Automation, Lean, Measurement, and Sharing. That's held up for a reason. For something that was scrawled on a napkin in 2010, there's a reason we still talk that way. It sounds like we talk about culture more than anything else, and it's not because it's more important. It's because it's the one that we have to scream from the rooftops.You don't have to convince engineers to play with automation tools; they're going to do it. That's fine, right? So, they're all equal. Now, that said, what's changed is we have definitely found DevOps to feel a lot more that it's about automation. It's about the technology. We've veered away from the people to your statement about, like, “Oh, it's a culture, not a ti”—well, it's all of these things.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: Well, one thing I do want to call out because the whole point of having you on the show, of course, is to embarrass you with proof-positive, for example, that you are in fact, a good person at heart despite, you know, your dubious friendship with people like me, is we both used to be adamant about the idea of DevOps is not a role, not a job title, and we both stopped, but for different reasons. The reason that I stopped was that I took a job as the director of DevOps at a company because I was trying to solve about five or six different things that were important for me to negotiate for, and job title did not make the cut of impactful changes. You had a far less self-serving reason for no longer picking that particular fight. What was it?Matty: [laugh]. I do want to call out one of my favorite jokes which is not supposed to be gatekeeping, but it's making fun of Corey so it's okay—Corey: Hmm.Matty: —Nathan Harvey said years ago, and it was actually I think, intended as a shot at our friend Pete Cheslock, who also has had the title of director of DevOps, which said, “The only DevOps tool is a person that calls themselves director of DevOps.”Corey: Oh, absolutely. It's super lucrative. I was really insulted by that and cried all the way to the bank.Matty: Uh-huh. Now, I'll tell you there's two reasons that I've changed my tune on—you know, I used to say it's not a tool, title, or team. I still will agree that it's not a tool. The title and team—and the reason for that is twofold, and neither of which are self-serving other than I don't want people to think I'm a jerk. The first reason that deviated me from a little bit was again, to go back to your friend and mine, Pete Cheslock, he gave a talk, I don't remember where it was, but he made the point where he said, “You look at it, the title ‘DevOps engineer' is a 30 to 35% pay bump, so it's like, I don't care what you call yourself. Go get paid.” So, that's that.Corey: Yes.Matty: So, first of all, I was like cool—Corey: J. Paul Reed did a whole talk-pay thing that shined a light on that.Matty: Absolutely. The one that I think is more empathetic and probably was… is maybe a little more important—or equally so—Ian Coldwater has pointed out before, and this really resonated with me, is that when we get on Twitter and are like, “Oh, my God. DevOps engineer is not a real title, blah, blah, blah.” The people that hear that are the people who have that title. They did not give themselves that title. It's very exclusionary, and all that will happen out of that is it doesn't eff—Corey: “I'm going to go quit my job and not be able to make rent this month.” “Why?” “Because Twitter said that my job title was bad.”Matty: Yeah.Corey: All the reasons to quit a job, I promise you job title is not one of them. Unless it is something horrifying, as into the territory of discriminating or belittling. There are always exceptions to every rule, but by and large, “That's a ridiculous job title,” is not the reason to quit a job. Says the self-proclaimed chief cloud economist.Matty: Totally yeah. I mean, like, you know what is very similar? There's a meme about, like, every time people want to make fun of a political figure or something and they'll make fun of them being overweight, or any kind of thing, and the meme is like, the only people who hear that are your friends that have a similar condition, not the actual person you're making fun of, so all you're doing there is hurting people who… so that's a similar thing.Now, I will say—and I think you and I might disagree about this a little bit, so that'll be fine—Corey: I hope so.Matty: So, when I hear—and actually the title doesn't do this, for me; it's actually very specifically a DevOps team. When people say, “We have a DevOps team.” This is not a perfect analogy when I say it's a code smell; I call it an organizational smell. And what I mean by that—it's not as bad as a code smell—what it does is it makes me ask more questions. If it's relevant to me to ask questions. It might be none of my damn business. If you tweet that I'm on the DevOps team, I'm not going to come into your mentions and start questioning your existence, but—Corey: Oh please, I have way better personal attacks than that.Matty: Oh, yeah. But if I'm working with you and we're working on that, or we're having a conversation, and it comes up that you have a team called DevOps Team, I'm going to ask questions because that could be, okay or it could be, [sigh] I want to use the word dangerous lightly; it's not, but like, counter-effective. And the reason for that is if the DevOps team is the one who does all your automation and you haven't really enabled other squads and all you've done is move a silo around, doesn't make you a bad person, but that's not the most effective way you could be. So, it makes me start to ask questions, right? But sometimes DevOps teams are people who lead in the organization, they are empowerment teams, maybe they run dojo, maybe they are subject matter experts that help.As long as there are good bridges still being built, it's not bad, right? So, it just—again, it raises questions. It's not inherently wrong. I am sure that… Pulumi where wo—actually, many of the tools I've worked with have been called DevOps tools; I will still tell you there's no tool that gives you DevOps, right? You can't—Corey: But when other people—like, read as ‘buyers'—refer to you as the ‘DevOps tool company,' well, you can be right or you can make a sale, in some cases.Matty: [laugh]. Yeah, I'm not going to tell you—Corey: On some level, you have to meet people where they are, and this is a part of that. I say that in full sincerity. Same story with the idea of culture. I hear this question all the time, “How do we wind up making all of our engineers aware of AWS billing issues?” And to a point, you should have understanding that when you turn something on it runs forever, bigger things cost more than smaller things, but the knowledge fits on an index card.You shouldn't have every engineer wanting to—or needing to—become deep experts in this space. Having a centralized team that specializes in that, at a sufficient level of org size and maturity, makes an awful lot of sense, and they can float around. But yeah, having the AWS bill team, in some cases is the right answer and others it's the complete wrong answer, and it really does depend. I think the way that we solve this problem, authoritatively, is a way that neither you nor I can argue with it because the only source for authoritative DevOps answers is from the source itself, and that is, of course, Emily Freeman, whose treatise on the subject, DevOps for Dummies, despite the weird title, is absolutely fantastic work that gives insight into all of this. And are you prepared to tell her she's wrong? Because I'm certainly not.Matty: Well, there are plenty of people who will. As we know.Corey: Yes. And we call them shitheads if we're being perfectly honest with you.Matty: Yeah. [laugh].Corey: The internet what a ple—no, Emily is an absolute treasure in the space and I'm continuing to watch her meteoric rise with nothing other than pure admiration. It is just spectacular to see her succeed.Matty: I could not agree more. This is something I struggle with a little bit. I don't think Emily would mind me saying it this way. This is the thing where you don't want to sound condescending, but I always love when I look at people and it's not—it's going to come off a little bit about, like, “I knew them when,” and it's not like I was a Corey Quinn fan before he went pop, but I love to see and remember where we all came from, and it's true of myself and it's true of other people, but that's one of my favorite things is I love to see my friends succeed.Corey, I love to see what you've done. Like, I think back to when we knew each other. I'm not saying you weren't successful, but it's funny, this [unintelligible 00:30:08] sounds a little condescending to be like, oh, I'm so proud of you, but I am. And I'm impressed. It's great to see.And Emily's another example. Like, I remember when I first met Emily, and not like I was any big deal, either, but it's like, everybody comes from somewhere, right? Like Jacquie Grindrod who just recently left Hashi, I remember when she started to get into DevRel and I was talking to her because she's like, “I may be thinking I want to do this thing.” And you look and you see these people. And it's not supposed to be like, “Oh, I remember when you were like the cute little baby DevRel.” It's not like that.And it's like, it's just impressive to see—and not even impressive. It's you like to see people who do good work and have a good heart and want to help people grow and be successful. And I'll tell you something, here—we're going to get real for a second—you can be jealous of them. It's okay. And I'm going to be honest, there are times that—Emily and Corey are both good friends of mine, and there are times that I'm like, “Wow. I'm a little jealous of you. Sometimes I'm a lot jealous of you. Sometimes I'm not at all.” So, I'm telling everybody, it's okay to be jealous. [laugh].Corey: I agree with the sentiment that I changed the word ‘envious' because envy is one of those, like—Matty: Okay.Corey: —“I want that, too,” whereas jealousy is a lot more a shade of, “I want to have it and I don't want them to.” And I don't believe that's the direction you're heading in. [laugh].Matty: No. Thank you. No, you're exactly right. Envy is the better one yeah because it's never—Corey: Now, I recently learned the distinction there by getting very wrong and saying things I didn't intend to imply, which is why I bring it up. Again, let my mistake be something others can learn from. Sometimes the best purpose I can serve in this industry is as a counter-example.Matty: Example. I was going to say, you know, just for everybody, I remember at the beginning, you know, Corey said, “Maybe we'll learn something.” I'm like, I guess that's what we learned [laugh] is the difference between envy and jealousy.Corey: Yeah.Matty: [unintelligible 00:31:50] gotta say, you know, it took us half an hour to get there. But you know.Corey: No no. And I appreciate your friendship throughout the years. Like, you were one of those people that has been something of a guiding star, where it's, sometimes I get it right, sometimes I get it wrong, and you've always been someone who has been very willing to share which side of the divide you think I'm on with anything that I've done. And for lack of a better term, you knew me before I basically bought ink by the barrel. And back when I was just the conference speaker that had to follow one of your ridiculous talks, like, “Oh, God. Those are big shoes to fill. I'd better learn how to give a conference talk.” So, most of what I become is your fault. But I do want to thank you for your guidance over the years on these things.Matty: Can we tell the real story about how I claim ownership of The Duckbill Group?Corey: By all means, take it away.Matty: Oh, okay. So, [[laugh]] I honestly still think that I should have a part ownership in The Duckbill Group because for those of you who don't know, Corey mentioned that I had worked at PagerDuty, and actually that job came down between the two of us and Corey didn't get it. And then went and started his own company and became famous and amazing. So really, it's because of me is what I'm trying to get at. I—Corey: To be fair, they made the right hire. Which one of us do you think makes the better employee, let's be very clear?Matty: [laugh].Corey: And yeah, I am thrilled to deal in you in on ownership of The Duckbill Group because the way we're structured, you cannot have ownership without also assuming liability. So yeah—Matty: [laugh].Corey: I would love to dump legal responsibility for my shenanigans on someone else. Come on in. Yeah, there's always a cutting edge to everything else. But no, you're right. I always wonder what would have happened if that decision had gone differently.And I'm very glad it played out the way that it did. You were the right hire for the company in a way that I never would have been. But I would have given it a good try for a while before they begrudgingly had to fire me or I sensed the axe was coming and left on my own. That is the nature of me as an employee. You have a very different perspective because you're good at things that I'm terrible at.Matty: And vice versa. It was interesting. You just talked about, like, how would things go different? So I—yesterday—just recorded—I don't know when it's going to come out—I was on a podcast called 8 Bits—so it's 8bits.tv—and it's really a show about people's journey through tech.And what was interesting that came out of that conversation was, first of all, how much of how I got to where I am is because of spite. Which you're going to have to go back and listen to the episode to hear the whole story of all the spite. But we did talk about, like, those junction points that happen that seem innocuous. And it's like, I made this one choice that wasn't even necessarily a choice and you follow all the forking logic that gets you to, Corey, you and I are sitting here on a podcast right now. How many decisions that weren't even decisions? There's the alternate universe where this doesn't happen where this doesn't exist, right?Corey: It's weird how this stuff all works. Years before I'd met either one of you, you videotaped my wife's law school musical and burned it to CD. We found that out when you were here over dinner one night.Matty: That was my favorite thing.Corey: It was surreal.Matty: Yeah, I was at dinner with Corey and his wife and we got into a conversation about that she had gone to law school in Chicago. And I was like, “Oh, funny thing. Like, I produced the video of the law school mu”—and she was like, “Wait, what was that?” And I couldn't even remember. I had to, like, dig back into, like, an old blog post. And was that and then yeah, and Bethany, like—Corey: She walks into the other room and comes back with a DVD that you burned, your handwriting on it.Matty: Yeah.Corey: Yeah.Matty: Yeah, pretty much. Yeah. The world is small. Be nice to everybody.Corey: It never hurts. I want to thank you for taking time out of your day to basically tell stories once again. It's always good to talk to you. If people want to learn more about who you are, what you're up to, where's the best place they can find you.Matty: So, really the best place is Twitter. You know, so I'm at @mattstratton on Twitter. If you're not a Twitter person, that's okay. LinkedIn is not great for fi—I don't always remember to post stuff there. If you want to know about upcoming, you know, so if you go to speaking.mattstratton.com, that has all my previous talks, my upcoming talks, and things as hopefully we'll have more and more of that.And yeah, and every week, I stream on twitch.tv/Pulumi on Thursdays. And it's not webinars, it's not slick demos, it's just me screwing around and sometimes having fun people on, and sometimes just proving how little I know about coding. So yeah, good times. Thank you for having me on, again, Corey. It's always fun.Corey: Of course. Links to all that's going on in the [show notes 00:36:20]. And as always, it's a pleasure.Matty: Also, I will say, Corey, I'll give you the link to that 8bit.tv, if you want to put that in the [show notes 00:36:28]—Corey: Oh, of course, we will.Matty: —if people want to go and find that. Because I think it's similar, connected to what we talked about.Corey: Good. I look forward to listening to it myself. Mattie Stratton, staff developer advocate at Pulumi. 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 a long angry comment detailing that DevOps is in fact a role and here's what it means, and then go ahead and describe a sysadmin.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.

This interview was recorded for the GOTO Book Club.http://gotopia.tech/bookclubBrendan Burns - Co-Author of "Kubernetes: Up & Running" & Co-founder of KubernetesMatt Turner - SRE at Marshall WaceDESCRIPTIONBrendan Burns will take you on a journey through the life of Kubernetes. Where does it stand now, what is its history, and what's waiting for us in the future that you might not expect?The interview is based on Brendan's book "Kubernetes: Up & Running": https://amzn.to/3sueuuIRead the full transcription of the interview here:https://gotopia.tech/bookclub/episodes/kubernetes-a-journeyRECOMMENDED BOOKSBurns, Beda & Hightower • Kubernetes: Up & Running • https://amzn.to/3sueuuIBurns, Villalba, Strebel & Evenson • Kubernetes Best Practices • https://amzn.to/3gBXRsrLiz Rice • Container Security • https://amzn.to/3oU4iJeLiz Rice • Kubernetes Security • https://www.oreilly.com/library/view/kubernetes-security/9781492039075John Arundel & Justin Domingus • Cloud Native DevOps with Kubernetes • https://amzn.to/3hKZvI5Hausenblas & Schimanski • Programming Kubernetes • https://amzn.to/3qTvKchhttps://twitter.com/GOTOconhttps://www.linkedin.com/company/goto-https://www.facebook.com/GOTOConferencesLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket at https://gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted almost daily.https://www.youtube.com/user/GotoConferences/?sub_confirmation=1

זהו פרק 413 של רברס עם פלטפורמה, הוקלט ב-8 ביולי 2021, וזה הטייק השני - הטייק הראשון היה מוצלח במיוחד, אבל הוא לא הוקלט . . .אז הנה אתם פה, בטייק 2, יחד איתנו - כן, אני יודע שבשבילכם זה הטייק הראשון, בסדר - אז היום אנחנו נמצאים באולפן שלנו ביוקנעם עילית (!), אורי נמצא בחופש ומחליף את אורי יונתן מ-Outbrain - היי יונתן, מה נשמע?(יונתן) היי, מה העניינים?(רן) מצויין, ברוך הבא - ואיתנו נמצא גם ירון מחברת Soluto - היי ירון!(ירון) היי, מה העניינים? נעים מאוד . . . .(רן) טוב שבאת - היום אנחנו הולכים לדבר על GitOps, בפעם הראשונה.ולפני שנדבר על GitOps, נעשה סבב היכרות קצר - יונתן, היית כאן הרבה פעמים בפודקאסט לפני זה [הקדמה והיכרות - בפרק הקודם], אבל בוא ספר לנו בכל זאת עוד קצת על עצמך - (יונתן) אז אני הגעתי ל-Outbrain לפני 10 שנים, כמהנדס Backend, ובחמש השנים האחרונות אני מנהל את הפיתוח.ומאזין ותיק של רברסים [וגם אורח - 328 The tension between Agility and Ownership או Final Class 23: IDEs או 131 uijet או 088 Final Class 2, וכמובן 412 Serverless at Via](רן) מצויין - טוב שאתה פה.ירון - שני משפטים עליך?(ירון) אז אני ירון עידן, אני מוביל את צוות ה-DevOps ב-Solutoאני משחק עם מחשבים כבר יותר מ-20 שנה - התחלתי בצבא בתור DBA ואחרי זה עברתי להיות מפתח.לפני כמה שנים כבר גיליתי את עולם ה-DevOps ועברתי אליו לחלוטין - ומאז אני מאוד נהנה מהעולם הזה.ב-Soluto אני עושה את זה כבר משהו כמו חמש שנים.אני אספר גם קצת על Soluto, החברה שבה אני עובד - Soluto היא חברה שרוצה להפוך את הטכנולוגיה לדבר יותר ידידותי, בעיקר עבור אנשים שעבורם טכנולוגיה “זו לא השפה הראשונה שלהם”.אז המשתמשים שלנו יכולים לגשת לממשקים ב-Web או ב-Mobile ובעצם לקבל את המיטב מהמנויים הדיגיטליים שלהםלוודא שכל המידע שלהם מאובטח ושמוראם יש להם איזושהי מכונת כביסה חכמה בבית אז הם יכולים לוודא שהמכונה מתפקדת כמו שצריך ושהם מצליחים להשתמש בה . . .ובצד השני - יש להם גם את היכולת לפתוח איזשהו צ'אט, איזשהו Session של Chat עם Expert-ים - וגם הם משתמשים בפלטפורמה שאנחנו מפתחים בתל אביב, שנקראית Anywhere Expert, והיא מאפשרת לתומכים טכניים להיות מסוגלים לעשות את הסשנים האלה מהבית שלהם, מתוך איזושהי אפליקציה, כמו ב-Uberכבר לא צריכים לשבת בתוך איזה Cubical עם אוזניית מדונה ב-Setting קצת אפרורי - אלא ממש להשתחרר ולעשות את זה בתנאים שלהם.זה מייצר Disruption ענק לכל התעשייה הזאת של Tech-support בארה”ב - שם נמצאים רוב הלקוחות שלנו.(רן) אז זה, למעשה, Marketplace של תומכים ונתמכים - מצד אחד יש את הנתמכים, שאלו אנשים שיש להם, לצורך העניין, בעיה עם הטלפון או עם מכונת הכביסה או כל מכשיר אחרומצד שני התומכים, שבזמנם . . . אולי בנוסף על עבודתם, כמו שאמרת כמו ב-Uber, עושים השלמת הכנסה בזמנם החופשי.(ירון) כן - אנחנו אוהבים לחשוב על זה שאנחנו מצליחים לתרום לשני הצדדים הרבה מאודגם לגרום לאנשים להרגיש שהם מוציאים את המיטב ממה שהם שילמו עליו כסףוגם לגרום לאנשים לעשות את העבודה שלהם בתנאים יותר משחררים [אה . . . ](רן) אז הנה שאלה מפתיעה, שהרבה זמן לא שאלו אותך - אמרת שאתה כבר מתכנת הרבה זמן, אז תהיתי מה היה המעבד הראשון שסבל את נחת זרועך?(ירון) אז יש לי Deja Vu . . . אני חושב שזה היה 386 לדעתי? אבל נראה לי שעברתי על כל הסדרה, ואיפשהו בילדות מצאתי מצאתי איזושהי חוברת כזאת בעברית שמלמדת לתכנת ב-Basic, התחלתי לפתוח אותה - ומאז לא הפסקתי.(רן) עדיין ב-Basic?(ירון) התקדמתי מאז - עכשיו אני ב-Pascal . . . [אין יותר טוב מזה](רן) יפה . . . Turbo Pascal [אוקיי, יש יותר טוב…], Object Pascal . . . נחמד - הכחול והתכלת הזה, מקסים, הנדסת אנוש למופת.[אתה לא ציני, נכון? זה היה נפלא]בסדר - אז אנחנו התכנסנו היום כדי לדבר על GitOps.כולם, פחות או יותר, יודעים מה זה Git, וכולם, פחות או יותר, יודעים מה זה Ops - החלק המעניין של DevOps, להזכירכם . . . אבל מה זה GitOps? מה זה השילוב הזה ביניהם?(ירון) אז כן - דבר ראשון, הטרנד היום זה באמת לשים סיומת של Ops על הכל . . . יש DataOps ויש MLOps, אז עכשיו יש גם Buzzword חדש שהוא GitOps.אנחנו ב-Soluto עושים את זה כבר הרבה שנים, בלי לתת לזה את השם הזה, אבל אני כן אתן את ההרחבה של “מה זה בעצם אומר?”אז GitOps היא איזושהי מכניקה של CD, איזושהי אימפלמנטציה (Implementation), שמאפשרת למפתח לדלבר (Deliver) את המוצר שלו ל-Production בצורה שבה Git, או הקוד שיושב בתוך Git, ייצג את המצב של Production.אז אם ב-Continuous Delivery רגיל, יש איזושהו מבוך רציני, שהקוד צריך לעבור מהרגע שהוא Committed ל-Branch הראשי, ועד שבאמת אפשר לראות אותו ב-Production - אז GitOps מנסה לחסל כמה שיותר מהמחסומים האלהובאמצעות איזשהו רכיב שעושה פעולה שנקראת Reconciliation, לבדוק מה המצב של הקוד ב-Git, ולראות האם Production עונה על אותן הגדרות - ואם יש צורך אז לסנכרן בין שני הרכיבים האלה.(רן) כשאתה אומר “מבוך” ,אתה מתייחס, נגיד, לפרישה בהתחלה כ-Canary, ואחר כך אולי פרישה של 25% ב-Data Center אחד ואחר כך ב-Data Center אחר? זה המבוך שאליו אתה מתייחס?(ירון) אז האמת שהמבוך הזה יכול להיות קיים גם ב-GitOps, אבל אנחנו, ספציפית ב-Soluto כן משתמשים ב-Canaryהוא אפילו ניהיה הרבה יותר נגיש עבורנו בזכות השימוש שלנו ב-GitOpsשני הדברים האלו הם לא Mutually-exclusiveהמבוך שאני מתאר זה בעיקר להיכנס לתשתית של ה-CI, ללחוץ על “Deploy”, לראות שמשהו נתקע, להיזכר שהיה צריך לשדרג את ה-Script שעושה את זה . . .(רן) כן . . . בעצם אתה מדבר על ההתערבות האנושית שנדרשת אחרי שהקוד כבר נמצא ב-Master . . .(ירון) נכון - וגם זיהוי של טעויות שמתרחשות בזמן ה-Deployment - נניח, אצלנו ראינו הרבה פעמים שבגלל התאימות היחסית של Pipelines של Deployment, הרבה פעמים יש שגיאה ב-Production, והיא לא משתקפת חזרה ל-Pipeline של ה-Continuous Delivery - ואז המפתח פשוט יושב ואומר “טוב, זה כנראה לוקח לו הרבה זמן . . . זה כנראה הגמדים שלוקחים את הקופסאות ל-AWS התעכבו בדרך . . . “ורק אחרי 20 דקות או 30 דקות יש איזושהי הבנה שמשהו השתבש בצורה נוראית . . . (רן) זאת אומרת - ברגע שאני עושה Merge של Branch ל-Master - אני אף פעם לא אעשה הרי Commit ל-Master, זה אסור . . . - ברגע שאני עושה עושה Merge ל-Master, אני צריך להניח שהכל, כאילו, ב-Production, נכון?(ירון) לאו דווקאיש כלים של GitOps שלוקחים את זה בתור ה-First Class Citizen, הם באמת בונים על זה שתיהיה סדרה של הגנותבין אם זה טסטים ו-Smoke Tests או Canary ו-Gradual releases, כמו שהזכרתוהם פשוט מניחים שהמשתמש עושה בהם שימוש.אנחנו מעדיפים Deployments יותר קונטקסטואליים, ובגלל זה בהתחלה התחלנו להשתמש ב-Flux, שהוא כלי של WeaveWorks שלוקח את המתודלוגיה הזאת קדימה, ומנסה באמת “לאסור על ה-user” ליצור שינויים . . . ליצור הבדלים בין Production לקוד.ועברנו ל-Argo - כלי של Intuit - שחולק איתו הרבה מהקוד, אבל משנה הרבה מהדינמיקה והמכניקה.הוא מאפשר באמת קודם כל להכניס את הקוד לתוך ה-Master - ורק אחר כך להגיד למפתח “תעשה את הסנכרון שלך בצורה מודעת”.יש גם אופציה ליצור Sync אוטומטי, ואז ברגע שההגנות האלו נמצאות ובאמת יש את הבטחון לדעת שמה שנכנס ל-Master יכול להגיע ל-Production, ניתן להדליק את ה-Flag הזה ולהינות מחיים עם הרבה פחות Toil, הרבה פחות עבודה ידנית.(רן) אז דיברת על Reconciliation ועל זה שיש הפרשים בין מה שקיים ב-Master, שאמור לתאר את סביבת ה-Production, לבין סביבת ה-Production האמיתית, וההפרשים האלה יכולים לנבוע מכמה דברים - קוד שנכנס ל-Master, אבל עדיין לא עבר Deployment, אבל זה יכול גם להיות לנבוע מזה שהלך איזשהו איש Ops ושינה את ה-Production . . . נכנס ל-AWS או עשה SSH לאיזשהו שרת ושינה שם משהוואולי יש Drift-ים מכל מיני סוגים, ואני בטוח שכל מי שנמצא בעולם האופרציה נתקל בדברים האלה.אבל איך . . . מתי זה הגיע לנקודה שבה זה ממש הפריע לכם, ואמרתם “עד כאן! פה אנחנו חייבים לקום ולעשות איזשהו מעשה! אצלנו לא יהיה הבדל בין Master ל-Production!” . . . היה איזשהו אירוע מכונן שגרם לכם לעשות את זה?(ירון) אז היה . . . לפני שאני אסביר את האירוע הזה, אני גם אסביר איך הגענו למקום שבו אפשר לחשוב בכלל על הקונספט הזה.כמו שאמרתי - עשינו את זה עוד הרבה לפני שקראו לזה GitOps, והתחלנו במקומות הרבה יותר Low-stakes מסביבת ה-Production, שמגישה תוכן לקרוב למאה מיליון משתמשים היום . . .איפה שהתחלנו זה בתשתית הניטור שלנו - זה היה כבר לפני יותר מחמש שנים.רצינו לעשות דמוקרטיזציה של הניטור, לא רצינו שזה יהיה משהו שמפתח אומר “אני רוצה לנטר בבקשה . . . קח את השליפה הזו ושים אותה בבקשה על הכלי”וכדי שזה יקרה, יצרנו איזשהו Repository, שמנו בו קובץ JSON ענק ואמרנו למפתחים: “פשוט תכתבו פה את כל מה שאתם רוצים לנטר, וזה יגיע “בדרך קסם” אל התשתית”.אז זה היה ה-Production הראשון אצלנו שבעצם כל Commit ל-Master הסתנכרן עם הקוד, והיופי של זה היה שבאמת יכולנו לשחק פה ב-Stakes יותר נמוכים.שבירה של תשתית ניטור זו בעיה מסדר שני - משהו שיכול לקרות לדקה-שתיים בלי שהמשתמשים ירגישוזה בדרך כלל קורה בצורה מבוקרת, כשהמפתחים במשרדולכן זה היה משהו שנתן לנו להתנסות עם זה בצורה בטוחה.(רן) אז למעשה, המוטיבציה הראשונית שלכם הייתה לספק חווייית-מפתח יותר טובה - במקום שהוא ילך ויפנה אליכם ויבקש “תוסיפו לי בבקשה Monitoring” או שבמקום שיצטרך להכיר את כל החוכמות של כלי הניטור, הוא יכול לערוך איזשהו קובץ JSON ולעשות Commit - ומבחינתו זה ממשק העריכה - ועכשיו הוא מבין שברגע שהוא עשה Commit, יש איזשהו Hook שלוקח את הקובץ הזה ועושה לו Apply ל-Production.אז מבחינתך זה איזושהי חוויית מפתח יותר טובה - אבל זה עדיין . . . זאת אומרת, אני לא רואה עדיין איך זה בא ומטפל בתקלות Production . . . (יונתן) לכאורה, יכולת לממש את זה גם, נניח, עם CI/CD רגיל, נכון? בלי “הקונץ” הזה של הסנכרון או לבדוק את הפערים?(ירון) נכון - ואני אפילו אגיד שבאיזשהו שלב עברנו לזה: היה לנו Repository אחד מרכזי ואז הכנסנו איזושהי תשתית “כמו CD”, שלוקחת Commit-ים מ-Repository אחד ומזריקה אותם ל-Repo המרכזי הזה.ושם כבר התחילו להרגיש את החסרונות שאמרתי - הכלי היה נשבר הרבה פעמיםהיו נוצרים מצבים שבהם ה-Pipeline הקלאסי הזה, שמנסה להגיע למקום ה-GitOps-י, נתקע בגלל כל מיני טעיות שלא חזינו מראש, והיה קשה לקבל Visibility על דבר כזה.זה דורש יצירה של המון כלים, רק כדי שהדבר הזה יעבוד בצורה שהיא Flowless.(יונתן) עוד משהו שרציתי לשאול - איך ה-GitOps אל מול Infra-as-a-Code - זה משלים את זה? זה השלב הבא של זה?(ירון) זאת שאלה מעולה, כי באמת הרבה פעמים, את ה-Infra-as-a-Code אנחנו עדיין עושים עם כלים שהם יותר “Push-יים” כאלהאנחנו עבדנו קצת עם Terraform, נטינו יותר לכלי שנקרא Pulumi, שהוא סוג-של-כזה-Wrapper סביב Terraform, עם שפות תכנות יותר נפוצות.ושם מרגישים בדיוק את העניין הזה - שכדי עכשיו לשנות את ה-Infrastructure שלי, אני צריך לעשות Apply . . .ולפני שאני צריך לעשות Apply, אני ארצה לעשות איזשהו Preview, ולהציג אותו למפתחים, כדי שהם יבינו איזה שינוי הולך לקרות.ואז המנגנון הכמעט-אימפרטיבי (Imperative) הזה הוא נורא מורגש - נורא מורגש שהולך להיות איזשהו שינוי, וצריך לעשות איזושהי פעולה כדי שזה יקרה.ואחד הכלים שאנחנו מסתכלים עליהם יותר ויותר נקרא Xstate, וזה כלי שבאמת שם את ה-Infrastructure שרוצים ליצור כ-Custom resources בתוך Cluster של Kubernetes, ואז יש איזשהו Reconciliator, שבמקום לעבור עם ה-API של Kubernetes, הוא עובד עם ה-API של AWS או Azure או GCP - יוצר שם את אובייקטים.וזה שוב - שינוי תפיסה יחסית מאסיבי, כי זה אומר שברגע שמפתח עשה commit ל-Master, אז Xstate תופס אותו ומסנכרן אותו לענן אין איזשהו שלב באמצע של Apply, של Preview . . . כל הדברים האלה חייבים לקרות ב-PR, לפני שהקוד משתנה.(רן) מצד אחד - זה נשמע נורא אלגנטי . . . כאילו פיהם וליבם של Production ו-Master שווים. מגניב, נורא סימטרי כזה, נורא פשוט . . .מצד שני - גם נשמע נורא מסוכן: עשיתי Commit . . . סליחה - עשיתי Merge ל-Master, לא עשיתי Commit ל-Master. . . עשיתי Merge ל-Master, ואולי אני לא כל כך יודע מה זה הולך לייצר, זאת אומרת - אני לא יודע שזה עכשיו אולי הולך לייצר בלגאן לא נורמלי בתוך Production. . . אין לי איזשהו מקום קטן שבו אני יכול ככה להתנסות, בקטנה, לפני שאני עושה את ה-Commit? איך מטפלים? איך עושים מיטיגציה (Mitigation) למוטת הכנף הענקית שפתאום כל אחד מקבל?(ירון) זו שאלה נהדרת, כי היא מחזירה לשאלה הקודמת ששאלת - של בעצם “איזו בעיה ניסינו לפתור?”כי דווקא בניגוד או בהיפוך כזה של התמונה הזאת, החוסר ביטחון הגיע לפני שהיה לנו את ה-GitOpsהייתה לנו בעיה שהתשתית… פשוט כשעובדים עם תשתיות כמו Kubernetes אז התשתית נהיית מאוד מאוד מורכבתהיא גם נהיית במצב שכדי להרים Cluster חדש, במקרה של איזושהי בעית Production, בנאדם צריך לעשות פעולה ידנית, שיכול להיות שיכולה לארוך כמה שעות - וזה היה מצב מאוד לא נוח.קשה היה לדעת, כשיש לי מספר מוגבל של Cluster-ים - במקרה שלנו שניים - ואם עכשיו אחד מהם נופל אז אני צריך להיכנס למרוץ נגד השעון כדי ש-Cluster חדש יעלה.וזה גם עיכב אותנו מלייצר, אולי, את מה שרמזת אליו - שזה איזשהו מקום, איזשהו “מגרש משחקים” או ארגז חול בצד, שבו אפשר לעשות את כל השינויים בצורה בטוחה, ולדעת שלא משנה מה אני אשבור - Production לא ידע מזה.וזאת בעיה אחת שבאמת נאבקנו בה הרבה לפני שהגענו לעולם ה-GitOps המובטח.בעיה נוספת, שגם אותה אני אסביר איך GitOps פתר עבורנו, זה הארגונומיה של המפתחים מול Kubernetesכי מפתחים אצלנו היו רגילים לעבוד מול אילו-שהם Self-contained Services, שרצים על PaaS, כמו Herokuבמקרה שלנו זה היה Azure, אבל זו הייתה איזושהי סביבה סגורה, מכונות וירטואליות שכל מפתח קיבל, שמריצות את ה-Services שלו.ופתאום לעבור ל-Cluster שהוא Multi-tenant, שכולם עובדים ביחד, שצריך לדעת לא “לדרוך אחד לשני על הבהונות” . . . שיש בהם הרבה-הרבה אובייקטים חדשים שהמפתחים לא מכירים - יצר שינוי פרספקטיבה, שלא היה קל להנחיל לצוותי הפיתוח.אנחנו בצוות עבדנו עם Kubernetes הרבה, אבל המפתחים לא תמיד רצו להבין את המורכבות הזאת, והיה קשה לחשוף אותם לזה בצורה שתפגע איפשהו באיזון הזה . . .(רן) אז גם בהקשר הזה, זה נשמע כאילו אתה בעצם מייצר ממשק למפתחים עבור Kubernetes . . . זאת אומרת: “אתם לא צריכים ללכת ולהשתמש ב-Kubectl או בכלים אחרים” אלא אתם צריכים, לצורך העניין, “לעשות Commit לאיזשהו קובץ JSON ומשם אנחנו כבר נטפל בזה”.(ירון) נכון . . . אז היום הכל YAML, אבל כן - זה השינוי המרכזי שעשינו . . .(רן) . . . השתדרגנו . . . (ירון) . . . עכשיו יש מקפים במקום סוגריים מסולסלים . . .(יונתן) תזהיר את אבישי - יש לו איזה משהו נגד YAML-ים . . (רן) מאזיננו אבישי - תסתום רגע את האוזניים . . . כל העולם YAML כבר, אין מה לעשות . . .(ירון) בהרבה מקומות ראיתי שכבר מגייסים מפתחי YAML . . . (רן) כן - אולי המפתחי XML בפנסיה יהפכו למפתחי YAML . . . נחזור רגע אחורה - דיברת קודם על המוצר שלכם, ואמרת שהמוצר הזה יודע לתת תמיכה למכונות כביסה למחשבים אישיים וכו'. אז כל פעם שאני עושה Commit ל-Master, נגיד לאפלקיציה ה . . .(יונתן) אתה לא עושה Commit ל-Master, רן . . . . תזכור - עוד פעם, אני אעשה לך Reject . . . (רן) איך נפלתי . . . זה הפרוידיאני בי שמדבר . . . אז כל פעם שאני עושה Commit ל-Branch, ו-Merge ל-Master, אחרי Code review, כמובן, ומתקן את כל ההערות, ועובר CI - אז לאפליקציה האחרונה המגניבה שכתבתי למכונת הכביסה של סבתי - אז זה מיד הולך לכל מכונות הכביסה בעולם? לכל הטלפונים בעולם? זאת אומרת - זה באמת מה שאנחנו רוצים?(ירון) אז התשובה היא “לא” . . . כמו שאמרתי, יש לנו מידה מאוד חזקה של Control, כי ככה רצינו לבצע את השינוי הזהלא רצינו להפחיד אנשים ולהגיד לכל מי שעובד על הקוד אצלנו “תזהרו מאוד מה-Master!”הרעיון היה באמת לאפשר לאנשים יותר Visibility, יותר שקיפות - ולאט-לאט להגיע למודל הבגרות הזה, שבו אנחנו מרגישים בנוח לסנכרן דברים בצורה אוטומטית.זה אומר שהיום, רב שירותי ה-Backend שלנו נפרשים באמצעות כלי GitOpsבאמצעות Argo, שציינתי קודםמה שהמפתחים מקבלים מזה זה להחליף את ה-Pipeline המסועף והקשה להבנה באיזשהו Commit ל-Masterעכשיו, במקום לעשות את ה-Deployment בשלב הזה של ה-Pipeline, יש רק Commit אחד, שמשנה את ה-Version ש-Argo מסתכל עליו.ברגע שנעשה שינוי ה-Version הזה, המפתח הולך ל-UI אחר, של Argo - הוא רואה בצורה מאוד מאוד ברורה שהשתנה שדה מסויים ב-YAML של ה-Deployment שלו, עם ה-Tag.וזה מייצר הרבה דברים מאוד טובים עבורנו - כי גם אם עכשיו מבצעים סנכרון של הדבר הזה, אז זה כבר לא איזשהו Context-switch של לעבור עכשיו ולהסתכל מה המצב - Argo ממש מראה יפה, עם לבבות ירוקים או לבבות אדומים-שבורים , מה הסטטוס של הגרסא הישנה והגרסא החדשה.וזה נותן פידבק מאוד מהיר - האם השינוי הזה כרגע עובד? האם השינוי הזה נכשל? האם צריך לחזור רגע לשולחן השרטוטים ולתקן אותו?במצב הנוכחי, זה דווקא הגביר מאוד את ה-Control ואת השליטה שלנו ב-Production, ולא יצר אי-יציבות וחסר ודאות.(יונתן) ה-State הזה, נניח של שינוי הגרסא - נניח שאני מהנדס, ויש לי גרסא חדשה - אתה אומר, בעצם, שדבר ראשון אני צריך לעשות Branch ו-Commit ו-Merge, בגלל שאני רוצה גרסא חדשה, עם איזשהו Tag - זה ב-Repository של האפליקציה שלי או שזה ב-Repository של האפליקציה שמנהלת את ה-GitOps?(ירון) זו שאלה נהדרת, כי באמת אנחנו עושים משהו לא מסורתי שם - אנחנו כן עושים את כל השינויים האלו ב-Repository של הקוד, ובדרך כלל - אני מקשיב בכנסים, קראתי פוסט יפה של מישהי מ-Riskified שכותבת איך הם עובדים עם Argo - וראיתי שהקונצנזוס, פחות או יותר, הוא להפריד את ה-Repository שהמכונות קוראות וה-Repository שבני האדם קוראים . . . אז בדרך כלל, מה שמקובל זה ליצור, נגיד, את “Yaron-API”, להגיד שזה הולך להיות ה-Service שלי, ופה אני, כבן אדם, כותב קוד - ואז לתת למכונה לעשות את ה-Commit לאיזשהו Repository אחר, שיקרה “Yaron-API-Deployment”, ומשם לקחת את ה-State שה-Argo מסתכל עליו.אנחנו, פשוט בגלל שרצינו את הנושא הזה שאמרתי קודם - רצינו לשפר ארגונומיה של מפתחים - לא רצינו שיהיה להם את ה-Context-Switch הזה, את המעבר כל הזמן בין ה-Repo שבו הקוד כתוב לבין ה-Repo שבו ה-Deployment קורה . . .(יונתן) גם יש עוד יתרון - אתה תעשה git-log ותראה את ה-Deployments ולא . . . הרבה אנשים אומרים הפוך . . . הם אומרים “אני לא רוצה לראות Commit-ים של מכונה” [אחלה שם לפודקאסט, אגב], זה לא קדוש.אבל אנחנו מאמינים שה-Commit-ים האלה באמת, כמו שאתה אומר, מייצגים את השינוי של ה-State.(רן) אני מניח שהויכוח הזה, או הדילמה הזו, במצב של Mono-Repo היא פחות רלוונטית - עדיין יש התלבטות, נניח שאנחנו בעולם של Mono-Repo, ואני מבין שאתם לא - יש את ההתלבטות של האם לשים את הקונפיגורציה קרוב לקוד, או את כל הקונפיגורציה במקום אחד, לצורך העניין באיזשהו Branch או תת-עץ של ה-Mono-Repo.גם אני הייתי בהתלבטות הזאת הרבה פעמים, ואני חושב שיש פה Trade-off - מצד אחד זה נחמד שהקונפיגורציה קרובה לקוד, ולפעמים ממש בתוך הקוד; ומצד שני, זה גם נחמד לקבל איזשהו מבט על כל הקונפיגורציה של כל ה-Service-ים השונים, וככה להבין איך הדברים קורים.אז אני מבין שאתם יותר נוטים לשים את הקונפיגורציה קרוב לקוד, אם אפשר לקרוא לזה “קונפיגורציה”, בוא נקרא לזה . . .?(ירון) אז גם פה יש כמה תשובות . . . דבר ראשון - אנחנו לא נגד Mono-Repo, אנחנו מאוד-מאוד בגישה של “לתת למפתחים ולמפתחות פשוט להחליט מה הכי טוב ב-Context של המשימה הנוכחית” ולכן יש אצלנו קבוצה שלמה שעובדת בתוך Mono-Repo אחד, שמחזיק את כל ה-Service-ים, בלי שום קונטקסטויש לנו קבוצה שעובדת עם Repo-per-Serviceויש קבוצה שלישית, שעובדת עם Mono-Repos קונטקסטואליים . . . (יונתן) אתם לא נגד Mono-Repo - פשוט יש לכם הרבה כאלה, זה מה שאתה אומר . . . [“רבים מידידי הטובים ביותר” וכו'…](ירון) בדיוק . . . אנחנו אוליגו-Repo . . .(רן) לא, יש לזה גם שם - Multi-Mono-Repo . . . כתבו את זה לפנינו . . .(ירון) כן . . . אז לא הגענו למצב שבאמת אנחנו יכולים להגיע לרמות של Facebook, והקסמים שהם עשו עם Mono-Repos שם.בסוף, Mono-Repo ענק שמחזיק את כל הקוד זו לדעתי משימה הנדסית כבירה, וצריך לעשות אותה בצורה מאוד מחושבת.ושוב - בגלל הצורה ה-Distributed והלא-פרספקטיבית שאנחנו עובדים בה, שאנחנו לא רוצים להגיד לאנשים איך לעבוד, אז כמעט בלתי אפשרי לחשוב על “כל המפתחים ב-Soluto כותבים ל-Repository אחד”,כי דברים קמים, אנשים רוצים לשנות דברים, להתנסות עם משהו חדשוברגע שאנחנו מאפשרים את זה, אז לא נקבל אף פעם את השליטה של להגיד לאנשים “כל ה-Commit-ים שלכם עכשיו יהיו רק ב-Soluto-Code” [וגם אז - רק אם הם טובים]וזה נחמד, כי זה כן גורם לנו להתקדם קדימה . . .(רן) כן . . . אני חייב להעיר שאם כל זה שאני מכבד את שיקול דעתם של המפתחים, ואני הרבה פעמים גם לא רוצה להגיד למפתחים אחרים מה לעשות - אני חייב להגיד שלפעמים יש הרבה חוכמה בכן להגיד למפתחים מה לעשות, כי אני חושב שהרבה פעמים ההחלטות הן שרירותיות, והחלטה אחת טובה כהחלטה אחרת - הבעיה שכששתי החלטות, ששתיהן שקולות, אבל כששתי החלטות נלקחות, אז אתה בבלגן . . . אז דווקא בקטע הזה אני נוטה להיות קצת יותר הדוק, ולבוא ולהגיד “חבר'ה, נכון - יש פה שתי דעות, אבל אני בוחר את זאת, “כי ככה” - ובואו נתגלגל עם זה הלאה”כי אחרת פשוט נוצר בלגאן - וראיתי את זה קורה בחברות גדולות . . . ראיתי את זה קורה ב-Google,אני מבין ממה שאתה אומר שזה קורה גם ב-Facebook . . . מתקבלות החלטות שרירותיות, וכל המפתחים לפעמים אולי מקטרים - אבל הולכים לפיהןוזה עושה הרבה טוב, בסופו של דבר - “המסר שלי לאומה” הוא של “לא לפחד לקבל החלטות בשביל המפתחים”, ובסופו של דבר, בשורה התחתונה, אני חושב שזה עושה טובה, כי זה יותר קל כשדברים הם אחידים.(ירון) זה מעניין מאוד - ואני חושב שמה שאתה מציין הוא גם פונקציה של גדילה.אני חושב שיש שלב מסויים שבו חברה יכולה להרשות לעצמה להתפזר יותר ולנסות יותר דברים, ויש שלב מסויים שבו צריך להתכנס ולהגיד “אוקיי, ה-Business הגיע ל-SLA מאוד גבוה שהוא צריך לספק, החברה גדולה מספיק כדי שלא נוכל לתת ל-15 Frankenstein-ים לרוץ במקביל, המפלצות של . . .(רן) כל מפלצת טובה . . . כל מפלצת לכשלעצמה היא בסדר . . . אני לא אומר שההחלטות הן לא נכונות, הבעיה שיש החלטות אחרות, והחלטות סותרות לפעמים, החלטות שלא עובדות טוב אחת עם השנייהאו אפילו אם לא סותרות - לייצר Infrastructure שמתאים גם . . . לצורך העניין אפשר לקחת שפות תכנות - Infrastructure שמתאים גם ל-Python וגם ל-Ruby וגם ל-Java זה אפשרי, אני בטוח שזה אפשרי - זה רק יותר קשה.אז אתה יודע - שפות תכנות אפשר בדרך כלל, רוב החברות מתקבעות, זו לא הבעיה - אבל עדיין יש עוד הרבה בחירות אחרות:איך עושים Messaging, איך שומרים, באיזה Database משתמשים וכו'.(יונתן) אני חושב שאני מסכים - מבחינתי, המדד של מתי צריך לקחת כזאת החלטה או “דיקטטורה נאורה” שכזאת זה כשאתה צריך “לעבוד לרוחב”דיברת על תשתיות - ברגע שאתה צריך להתחיל . . . כשתשתיות נהייה “עניין”, אז קשה לתמוך בוריאנטים השונים . . . [כן . . .](רן) בוא נחזור רגע אחורה ל-GitOps . . . אז נלך, שנייה, Back-to-Basics: הבנו את הקונספט של “Mater ו-Production צריכים להיות שווים”. אז אני, אתה יודע, מתחיל ככה ב-Back-to-Basics ואני רוצה לעשות GitOps, אוקיי? אז מה אני עושה? אני מייצר Git-Hook, ובעצם אני צריך לדאוג לשני דברים . . .אחד זה שיהיה לי קוד שיודע לתאר את סביבת ה-Production, נגיד - כמה Server-ים, כמה Services, מה ה-Multiplicity שלהם, כל מיני דברים . . . מה שיודע. . . לצורך העניין קובץ YAML שיודע לתאר את סביבת ה-Production, ובטח יש שפות למכביר שיודעות לעשות את זה.אז אני צריך קוד שיודע לתאר את סביבת ה-Productionושתיים - אני צריך לדעת לעשות איזשהו Git-Hook, נגיד, שכל פעם שעושים Commit אז Production מתעדכן לפי מה השינוי האחרון.אז זה אולי GitOps בממש-ככה-30,000 רגל - ואתה הזכרת שיש כמה כלים שיודעים לעשות את זה - הזכרת קודם את Flux של WeaveWorks והזכרת את Argo של Intuit - ואני מניח שיש עוד כלים אחרים בשכונה.אז אם קם הבנאדם בבוקר ואומר “יאללה - בא לי GitOps!” [חמור מאוד] או “אני חייב GitOps!” [תופעת לוואי חדשה?] או “המנהלים שלי אומרים לי שאני צריך GitOps . . . “ [המקרה היותר נפוץ?] - איך אתה ממליץ לו להתחיל?(ירון) אז אני אזכיר פה את Kelsey Hightower, שהוא מן בחור כזה שאוהב לדבר על Kubernetes, מ-Google [בדיוק זז שם קצת], ואני מאוד אוהב גם את הצורה שבה הוא מנגיש ידע מורכבנגיד, לפני הרבה שנים הוא כתב את Kubernetes-the-hard-way [אבל כבר קישרתי לזה…], שזה מעיין מדריך על איך להרים את Kubernetes מ-Scratch, לעשות את כל הפעולות שעשויות, עבורנו, בצורה ידנית - וכשעברתי דרכו הרגשתי היכרות הרבה יותר טובה עם התשתית הזו, שהיום מעירה אותי בלילה אם יש לה בעיה . . .והוא עושה הרצאה מדהימה - יש כבר כנסים שנקראים GitOps Days מרוב שהדבר הזה טרנדי - הוא עשה הרצאה ממש מעניינת בכנס שהיה בשנה שעברה, שבה הוא מראה איך עושים Reconciliation Loop מ-Scratch . . . הוא ממש כזה . . . מראים קוד שהוא כותב ב-Go תוך כדי על המסך, תוך כדי הכנס - והדבר הזה מייצר, במקרה שלו, פונקציות של Cloud Run, שזה איזשהו Serverless כזה של Google.אני חושב שההרצאה הזאת היא פתיח מדהים בשביל לעשות דימיסטיפיקציה (Demystify) למשהו שבאמת, כמו שאמרת, יכול להישמע מורכב ויכול להישמע אפילו די מפחיד, כי זה מראה שהדבר הזה יכול להיות מאוד נשלט.אחרי שעוברים את המשוכה הזאת, של להבין את הקונספט, הייתי כן ממליץ לבחור את אחד מהכלים הגדולים - בין אם זה Argo או Flux, כי הם כרגע הכלים ששולטים בשוקאבל גם חשוב מאוד, כנראה, להבין את הבעיה - אם Argo ו-Flux מתאימים מאוד לתחזוקה של Kubernetes, אז אם רוצים לתחזק משהו שהוא מחוץ ל-Kubernetes, צריך לבחור משהו שהוא כלי שיודע לעשות את זה גם בלי הכוח הזה.וכמו שאמרתי - גם Puppet ו-Chef יודעים לעשות את זה עבור מכונות Linux, ויש כלי שנקרא Atlantis, שיודע לעשות את זה עבור Terraformואז בעצם כל אחד מהכלים האלה יכול להיות Entry-point ל-GitOps, לא משנה מה האתגר שכרגע עומד מולכם.(רן) נזכיר, אני חושב ששווה אולי לבוא ולמצוא את המקבילות בין הכלים השונים - אז גם מי שמכיר את Puppet ואת Chef - הם כולם עובדים באיזשהו Mode של Reconciliation Loopזאת אומרת - מסתכלים מה המצב הרצוי ועושים Apply, וכל פעם עושים Reconciliationזאת אומרת שאם משהו שהגדרת, לצורך העניין, שצריך להיות קובץ במערכת על מחשב והוא לא שם - אז הוא בכל פעם ייצר אותו מחדש אם הוא ימחק.גם Puppet וגם Chef עובדים באותה צורה - וגם Kubernetes הרבה פעמים עובד באותה צורה, זאת אומרת שגם ל Kubernetes יש Reconciliation Loop שמסתכל על ה-Resource-ים ועושה Apply ל-Resource מחדש בכל פעם שצריךכמובן שלא סתם . . . אז בהקשר הזה, המוטיב הזה של ה-Reconciliation Loop עובר, כנראה, בהרבה מאוד מהכלים שהזכרת.(יונתן) לפי מה שירון . . . לפי מה שתיארת, יש יכולת גם לעדכון מהצד השני - יכול להיות שזה לא שב-Production, לא רק שחסר קובץ, אלא שמישהו, לא יודע, שינה אותו, או שמישהו נכנס ל-UI של ה- Management של Kubernetes ושינה את ה-State Loader - איך ה-Flow המרכזי . . . מה יקרה אז?(ירון) זה בעיני הדבר . . . זה ממש ה-Added-Value, אולי אפילו ה-Killer-Feature של GitOps, כי אלו הפתעות שתמיד היו תופסות אותנו במקום הכי לא מוכן, ואני מאמין שזה קרה להרבה צוותי Production [מה?! מה פתאום?]שפשוט איזשהו שינוי נעשה בזמן של מקרה חירום, או אולי כלאחר-יד מתוך איזשהו חוסר הבנה, ולא הייתה לדבר הזה שום נוטיפיקציה (Notification)ואז בדרך כלל מגלים את זה חודשים, אם לא שנים, אחר כך, כשהידע כבר נשכח . . . יש את הפתגם הזה - שקוד שכתבת אחרי חצי שנה הוא כמו קוד שנכתב על ידי מישהו אחר [יש לזה אפילו שם - Eagleson's law] . . . אז גם עבור שינויים ב-Production הדבר הזה תקף - מה גם שהם הרבה פחות מתועדים . . .ב-GitOps, בצורה שאנחנו עובדים, Argo מחובר ל-Slack - וכל פעם שמישהו עושה Deployment יש הודעה חמודה כזו עם שאומרת “הקוד שלך שינה בהצלחה את ה-Production”אם במקרה, נגיד, הקוד שלי מסתמך על איזשהו Redis חיצוני, וה-Redis הזה פתאום נפל, אז אני אקבל “לב שבור ועצוב ” שאומר לי “רוץ מהר! משהו השתנה, זה כבר לא נראה כמו ה-Production, אני שבור וקשה לי” . . . (יונתן) אוקיי . . .(רן) מה ה-Hack החביב עליך? נגיד, מסוג הדברים שהתעוררת בשתיים-שלוש בלילה, וגילית “מי לעזאזל עשה את זה?!”? . . . אני אתחיל עם שלי - נניח שאתה נכנס ואתה מגלה שמישהו, לפני חצי שנה, כמו שאתה אומר, ערך את קובץ ה-Host והוסיף שם איזשהו Entry, כי כנראה פעם זה תיקן לו איזשהו משהו . . . עכשיו את מגלה ש Name Resolution מחוץ ל-Host עובד שונה לחלוטין ממה ש-Name Resolution עושה בתוך ה-Host - וזה מסביר הרבה דברים, בדרך כלל . . . (יונתן) סתם, פתאום התחלתי לחשוב האם זה יכול לעזור באילו-שהן בעיות של Security? או של מישהו ששינה משהו עקיף ב-Production, והוא לא עשה Git-Merge וכל הסיפור הזה . . . .(ירון) אז בהחלט . . . אני רק אגיד על ה-Hack-ים - שזה תמיד יהיה נס, אין ספק . . .ה-Hack החביב עלי זה שכשעובדים ב-High Availability, שולחים גרסא אחת של Production ל-Site אחד וגרסא שנייה ל-Site אחר - ועכשיו לך תבין למה חצי מה-Traffic מחזיר תשובה אחת וחצי מחזיר משהו אחר . . .(רן) יש את הסיפור המפורסם על ה-Trading. . . (ירון) כן, Knight - מסכנים . . .(רן) . . . שהם עדכנו גרסא, אבל כנראה נשאר שרת אחד או שניים, שאולי היו Offline בזמן עדכון הגרסא - וזה גרם לחברה לפשוט את הרגל, חברה של שווי, בגדול, של מיליארד דולר, שהפסידו ב-Algo-Trading את כל הכסף שלהם בגלל איזה Deployment שלא עלה נכון . . .(ירון) כן, זה סיפור נורא כשקוראים אותו, ופרקי הידיים מלבינים כי אתה חושב שאולי זה קורה לך עכשיו . . . (רן) ממש עכשיו . . . אבל ממש ממש עכשיו . . .(יונתן) . . תן לי רגע רק לבדוק את ה-Inspection . . .אז בנוגע ל-Security - יש כאן באמת יתרון אדיר, כי גם - ב-Continuous Delivery מסורתי, אני חייב לתת לתשתית שלי את היכולת לגשת ל-Production, ונגיד, אם זה Jenkins שיושב אצלך בשרת, אז לא אכפת לך כנראה לשים שם איזושהי גישת-כתיבה ל-Productionאנחנו עובדים עם SaaS, עם codefresh - חברה ישראלית שעושה CI ממש נחמד לדברים שהם Docker ו-Kubernetesועדיין, עם כל האהבה והרצון הטוב - אנחנו מעדיפים שהם לא יוכלו לגשת ל-Production . . . ברגע שאנחנו עושים את ההפרדה הזאת, הם יכולים לגשת רק עד הקוד - והמוצר היחיד שיכול לגשת ל-Production הוא ה-Reconciler של GitOps, שבמקרה שלנו זה שרת של Argo שיושב על ה-Clusterואז ה-Attack surface הוא הרבה יותר נמוך - כי הוא מלכתחילה יושב שם ומלכתחילה עושה שינויים, וזה טבעי שאצלו ישבו המפתחות [חביתוש?].ואני אעשה גם איזה Shout-out לפרויקט Open-Source שכתבנו ב-Soluto ושנקרא kamus - והוא גם מתבסס על GitOpsהרעיון שעשינו שם הוא שהראינו שה-Secret-ים ב-Kubernetes הם עוד לא בשלים, פחות או יותר - Secrets ב-Kubernetes הוא פשוט איזשהו אובייקט מקודד ב-Base 64, וזה אומר שכל מי שניגש ל-UI ב-Kubernetes ולוחץ על הכפתור של העין פשוט רואה את ה-Secret, פשוט רואה את ה-Plain-text, ולא הרגשנו עם זה בנוח . . .אז כתבנו Controller, שאפשר להתקין על כל Cluster, ומה שה-Controller הזה עושה הוא לאפשר למפתחים להצפין את הערכים מקומית אצלם על המחשב, לעשות להם Commit ל-Gitואז לכל Container נוסף איזשהו Init-Container, שעושה Encryption על ה-Cluster.זה גם מאוד מחזק את ה-Security, כי ה-Decryption יכול לקרות מעכשיו רק בסביבת ה-Productionזה דומה, נגיד, ל-Vault, אבל מגיע עם Operation overhead הרבה יותר נמוך.(רן) הזכרת מקודם - ואולי בזה, ככה, נסיים את הערב - הזכרת מקודם שעם המעבר ל-Kubernetes, מפתחים הרגישו איזושהי עלייה ברמת המורכבות, שהם פתאום צריכים להבין יותר Production, ואז יצרתם ממשק משתמש, או לפחות אני תיארתי את זה ככה - יצרתם ממשק משתמש, ממשק מפתח, באמצעות GitOps.האבחנה שרציתי להגיד זהש-Kubernetes מאפשר GitOps, נכון? אולי זה לא הכלי היחיד שמאפשר GitOps, אבל בהחלט אחד הכלים שמאפשרים GitOps.כי הוא נותן לך לתאר את סביבת ה-Production ולעשות לה Apply יחסית בקלותאז Kubernetes אמנם מאפשר GitOpsמצד שני, לפני Kubernetes אולי לא היה צריך GitOps, כי הדברים היו יותר פשוטים . . .אז אני סתם תוהה האם זו אבחנה שנראית לך מוצדקת, נכונה?(ירון) אני חושב שכולם מכירים את ה-Death-Star של Netflix, שמראה פשוט מיליארד שירותי microService שמדברים אחד עם השניוהם כתבו את Spinnaker, שזה כלי שהוא מזכיר . . . הוא מאוד מאפשר את הסיבוכיות שיכולה להגיע בדברים של Continuous Deliveryעם כל היופי והאלגנטיות של הכלי הזה, אני חושב שהוא בא לשרת משהו שאם לא צריך אותו, אז זה יהיה נחמד להיפטר ממנו.ושוב אני אצטט את Kelsey Hightower שאומר שהקסם והחידוש ב-Kubernetes זה שהתשתית מתוארת כדאטה, לא כקונפיגורציה (Configuration)זו לא סדרה ל צעדים אימפרטיביים (Imperative) שדרושים כדי שמכונת Linux תוכל להגיש קוד ב-Ruby - זה תמיד יהיה דאטה - זה תמיד יהיה קבצים ב-YAML שנשמרים ב-Database, והם אלה שמאפשרים את העלייה של Production.(רן) כן - וזה אולי אחד מהדברים שמאפשרים לעשות GitOps בצורה יחסית פשוטה, כי כל מה שצריך לעשות זה Commit לקובץ YAML - ולעשות Apply . . .(ירון) בהחלט(רן) טוב - אז תודה רבה, ירון, היה סופר-סופר מרתק. יש משהו שהיית רוצה עוד להגיד לפני שנסיים?(ירון) אז אני אשמח להגיד שאנחנו מגייסים - גם לצוות שלי וגם למגוון תפקידים ב-Solutoאם כל מה ששמעתם פה נשמע לכם מעניין, מבחינת החזון של החברה או מבחינת הדברים היותר Geek-יים - בואו, תתראיינו, תתקבלו . . . (רן) מעולה . . .(יונתן) אה, אפשר למסור ד”ש, רן?(רן) קדימה, נו . . . עם איזה שיר? רגע, שאני אכין את התקליטייה . . .(יונתן) שנכין בתקליטייה . . . אז למאזין אורי להב, ששט לו בדוגית בחופי הים התיכון . . . (רן) אורי - מתגעגעים אליך, חזור הביתה!טוב - אז תודה רבה לשניכם, ויאללה, נשתמע . . . להתראות.ובהצלחה ל-Reversim Summit 2021 . . . הקובץ נמצא כאן, האזנה נעימה ותודה רבה לעופר פורר על התמלול

Youtube: https://youtu.be/_Bm2Zpe6GuUKubernetes EcosystemDeclarative deploymentYAML FormatManifests Manipulation00:00 Intro01:45 Agenda04:53 Kubernetes Ecosystem05:45 Anton babenko Episode06:09 Terraform13:13 Helm18:40 Ambassador25:23 Istio Service Mesh29:55 Monitoring & Logging45:07 Operator Framework50:00 Yaml56:45 Run K3S on GCP59:18 Kubectl verbose output01:03:05 livenessProbe01:06:30 readinessProbe01:08:35 Secrets in env01:17:37 Secrets in file01:21:48 Volumes mount01:23:44 Multi Container Pod01:31:00 "I've got the power!"01:32:35 Kubectl port-forwarding01:35:45 Kubernetes jobs01:40:30 Resume

We are joined by Ellen Körbes for this episode, where we focus on Kubernetes and its tooling. Ellen has a position at Tilt where they work in developer relations. Before Tilt, they were doing closely related kinds of work at Garden, a similar company! Both companies are directly related to working with Kubernetes and Ellen is here to talk to us about why Kubernetes does not have to be the difficult thing that it is made out to be. According to her, this mostly comes down to tooling. Ellen believes that with the right set of tools at your disposal it is not actually necessary to completely understand all of Kubernetes or even be familiar with a lot of its functions. You do not have to start from the bottom every time you start a new project and developers who are new to Kubernetes need not becomes experts in it in order to take advantage of its benefits.The major goal for Ellen and Tilt is to get developers code up, running and live in as quick a time as possible. When the system is standing in the way this process can take much longer, whereas, with Tilt, Ellen believes the process should be around two seconds! Ellen comments on who should be using Kubernetes and who it would most benefit. We also discuss where Kubernetes should be run, either locally or externally, for best results and Tilt's part in the process of unit testing and feedback. We finish off peering into the future of Kubernetes, so make sure to join us for this highly informative and empowering chat! Follow us: https://twitter.com/thepodlets Website: https://thepodlets.io Feeback: info@thepodlets.io https://www.notion.so/thepodlets/The-Podlets-Guest-Central-9cec18726e924863b559ef278cf695c9 Guest: Ellen Körbes https://twitter.com/ellenkorbes Hosts: Carlisia Campos Bryan Liles Olive Power Key Points From This Episode: Ellen's work at Tilt and the jumping-off point for today's discussion. The projects and companies that Ellen and Tilt work with, that they are allowed to mention! Who Ellen is referring to when they say 'developers' in this context. Tilt's goal of getting all developers' code up and running in the two seconds range. Who should be using Kubernetes? Is it necessary in development if it is used in production? Operating and deploying Kubernetes — who is it that does this? Where developers seem to be running Kubernetes; considerations around space and speed. Possible security concerns using Tilt; avoiding damage through Kubernetes options. Allowing greater possibilities for developers through useful shortcuts. VS Code extensions and IDE integrations that are possible with Kubernetes at present. Where to start with Kubernetes and getting a handle on the tooling like Tilt. Using unit testing for feedback and Tilt's part in this process. The future of Kubernetes tooling and looking across possible developments in the space. Quotes: “You're not meant to edit Kubernetes YAML by hand.” — @ellenkorbes [0:07:43] “I think from the point of view of a developer, you should try and stay away from Kubernetes for as long as you can.” — @ellenkorbes [0:11:50] “I've heard from many companies that the main reason they decided to use Kubernetes in development is that they wanted to mimic production as closely as possible.” — @ellenkorbes [0:13:21] Links Mentioned in Today’s Episode: Ellen Körbes — http://ellenkorbes.com/ Ellen Körbes on Twitter — https://twitter.com/ellenkorbes?lang=en Tilt — https://tilt.dev/ Garden — https://garden.io/ Cluster API — https://cluster-api.sigs.k8s.io/ Lyft — https://www.lyft.com/ KubeCon — https://events19.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2019/ Unu Motors — https://unumotors.com/en Mindspace — https://www.mindspace.me/ Docker — https://www.docker.com/ Netflix — https://www.netflix.com/ GCP — https://cloud.google.com/ Azure — https://azure.microsoft.com/en-us/ AWS — https://aws.amazon.com/ ksonnet — https://ksonnet.io/ Ruby on Rails — https://rubyonrails.org/ Lambda – https://aws.amazon.com/lambda/ DynamoDB — https://aws.amazon.com/dynamodb/ Telepresence — https://www.telepresence.io/ Skaffold Google — https://cloud.google.com/blog/products/application-development/kubernetes-development-simplified-skaffold-is-now-ga Python — https://www.python.org/ REPL — https://repl.it/ Spring — https://spring.io/community Go — https://golang.org/ Helm — https://helm.sh/ Pulumi — https://www.pulumi.com/ Starlark — https://github.com/bazelbuild/starlark Transcript: EPISODE 22 [ANNOUNCER] Welcome to The Podlets Podcast, a weekly show that explores cloud native one buzzword at a time. Each week, experts in the field will discuss and contrast distributed systems concepts, practices, tradeoffs and lessons learned to help you on your cloud native journey. This space moves fast and we shouldn’t reinvent the wheel. If you’re an engineer, operator or technically minded decision-maker, this podcast is for you. [EPISODE] [0:00:41.8] CC: Hi, everybody. This is The Podlets. We are back this week with a special guest, Ellen Körbes. Ellen will introduce themselves in a little bit. Also on the show, it’s myself, Carlisia Campos, Michael Gasch and Duffie Cooley. [0:00:57.9] DC: Hey, everybody. [0:00:59.2] CC: Today’s topic is Kubernetes Sucks for Developers, right? No. Ellen is going to introduce themselves now and tell us all about what that even means. [0:01:11.7] EK: Hi. I’m L. I do developer relations at Tilt. Tilt is a company whose main focus is development experience when it comes to Kubernetes and multi-service development. Before Tilt, I used to work at Garden. They basically do the same thing, it's just a different approach. That is basically the topic that we're going to discuss, the fact that Kubernetes does not have to suck for developers. You just need to – you need some hacks and fixes and tools and then things get better. [0:01:46.4] DC: Yeah, I’m looking forward to this one. I've actually seen Tilt being used in some pretty high-profile open source projects. I've seen it being used in Cluster API and some of the work we've seen there and some of the other ones. What are some of the larger projects that you are aware of that are using it today? [0:02:02.6] EK: Oh, boy. That's complicated, because every company has a different policy as to whether I can name them publicly or not. Let's go around that question a little bit. You might notice that Lyft has a talk at KubeCon, where they're going to talk about Tilt. I can't tell you right now that they use Tilt, but there's that. Hopefully, I found a legal loophole here. I think they're the biggest name that you can find right now. Cluster API is of course huge and Cluster API is fun, because the way they're doing things is very different. We're used to seeing mostly companies that do apps in some way or another, like websites, phone apps, etc. Then Cluster API is completely insane. It's something else totally. There's tons of other companies. I'm not sure which ones that are large I can name specifically. There are smaller companies. Unu Motors, they do electric motorcycles. It's a company here in Berlin. They have 25 developers. They’re using Tilt. We have very tiny companies, like Mindspace, their studio in Tucson, Arizona. They also use Tilt and it's a three-person team. We have the whole spectrum, from very, very tiny companies that are using Docker for Mac and pretty happy with it, all the way up to huge companies with their own fleet of development clusters and all of that and they're using Tilt as well. [0:03:38.2] DC: That field is awesome. [0:03:39.3] MG: Quick question, Ellen. The title says ‘developers’. Developers is a pretty broad name. I have people saying that okay, Kubernetes is too raw. It's more like a Linux kernel that we want this past experience. Our business developers, our application developers are developing in there. How would you do describe developer interfacing with Kubernetes using the tools that you just mentioned? Is it the traditional enterprise developer, or more Kubernetes developers developing on Kubernetes? [0:04:10.4] EK: No. I specifically mean not Kubernetes developers. You have people work in Kubernetes. For example, the Cluster API folks, they're doing stuff that is Kubernetes specific. That is not my focus. The focus is you’re a back-end developer, you’re a front-end developer, you're the person configuring, I don't know the databases or whatever. Basically, you work at a company, you have your own business logic, you have your own product, your own app, your own internal stuff, all of that, but you're not a Kubernetes developer.It just so happens that if the stuff you are working on is going to be pointing at Kubernetes, it's going to target Kubernetes, then one, you're the target developer for me, for my work. Two, usually you're going to have a hard time doing your job. We can talk a bit about why. One issue is development clusters. If you're using Kubernetes in prod, rule of thumb, you should be using Kubernetes in dev, because you don't want completely separate environments where things work in your environment as a developer and then you push them and they break. You don't want that. You need some development cluster. The type of cluster that that's going to be is going to vary according to the level of complexity that you want and that you can deal with. Like I said, some people are pretty happy with Docker for Mac. I hear all the time these complaints that, “Oh, you're running Kubernetes on your machine. It's going to catch fire.” Okay, there's some truth to that, but also it depends on what you're doing. No one tries to run Netflix, let's say the whole Netflix on their laptop, because we all know that's not reasonable. People try to do similar things on their mini-Kube, or Docker for Mac. Then it doesn't work and they say, “Oh, Kubernetes on the laptop doesn't work.” No. Yeah, it does. Just not for you. That's a complaint I particularly dislike, because it comes from a – it's a blanket statement that has no – let's say, no facts behind it. Yeah, if you're a small company, Docker for Mac is going to work fine for you. Let's say you have a beefy laptop with 30 gigs of ram, you can put a lot of software in 30 gigs. You can put a lot of microservices in 30 gigs. That's going to work up to a point and then it's going to break. When it breaks, you're going to need to move to a cloud, you're going to need to do remote development and then you're going to Go to GCP, or Azure, or Amazon. You're going to set up a cluster there. Some people use the managed Kubernetes options. Some people just spin up a bunch of machines and wire up Kubernetes by themselves. That's going to depend on basically how much you have in terms of resources and in terms of needs. Usually, keeping up a remote cluster that works is going to demand more infrastructure work. You're going to need people who know how to do that, to keep an eye on that. There's all the billing aspect, which is you can run Docker for Mac all day and you're not going to pay extra. If you leave a bunch of stuff running on Google, you're going to have a bill at the end of the month that you need to pay attention to. That is one thing for people to think about. Another aspect that I see very often that people don't know what to do with is config files. You scroll Twitter, you scroll Kubernetes Twitter for five minutes and there's a joke about YAML. We all hate editing YAML. Again, the same way people make jokes about using about Kubernetes setting your laptop on fire, I would argue that you're not meant to edit Kubernetes YAML by hand. The tooling for that is arguably not as mature as the tooling when it comes to Kubernetes clusters to run on your laptop. You have stuff like YAML templates, you have ksonnet. I think there's one called customize, but I haven't used it myself. What I see in every company from the two-person team to the 600 person team is no one writes Kubernetes YAML by hand. Everyone uses a template solution, a templating solution of some sort. That is the first thing that I always tell people when they start making jokes about YAML, is if you’re editing YAML by hand, you're doing it wrong. You shouldn't do that in the first place. It's something that you set up once at some point and you look at it whenever you need to. On your day-to-day when you're writing your code, you should not touch those files, not by hand. [0:08:40.6] CC: We're five minutes in and you threw so much at us. We need to start breaking some of this stuff down. [0:08:45.9] EK: Okay. Let me throw you one last thing then, because that is what I do personally. One more thing that we can discuss is the development feedback loop. You're writing your code, you're working on your application, you make a change to your code. How much work is it for you to see that new line of code that you just wrote live and running? For most people, it's a very long journey. I asked that on Twitter, a lot of people said it was over half an hour. A very tiny amount of people said it was between five minutes and half an hour and only a very tiny fraction of people said it was two seconds or less. The goal of my job, of my work, the goal of Tilt, the tool, which is made by the company I work for, also called Tilt, is to get everyone in that two seconds range. I've done that on stage and talks, where we take an application and we go from, “Okay, every time you make a change, you need to build a new Docker image. You need to push it to a registry. You need to update your cluster, blah, blah, blah, and that's going to take minutes, whole minutes.” We take that from all that long and we dial it down to a couple seconds. You make a change, or save your file, snap your fingers and poof, it's up and running, the new version of your app. It's basically a real-time, perceptually real-time, just like back and when everyone was doing Ruby on Rails and you would just save your file and see if it worked basically instantly. That is the part of this discussion that personally I focus more on. [0:10:20.7] CC: I'm going to love to jump to the how in a little bit. I want to circle back to the beginning. I love the question that Michael asked at the beginning, what is considered developer, because that really makes a difference, first to understand who we are talking about. I think this conversation can go in circles and not that I'm saying we are going circles, but this conversation out in the wild can go in circles. Until we have an understanding of the difference between can you as a developer use Kubernetes in a somewhat not painful way, but should you? I'm very interested to get your take and Michael and Duffie’s take as well as far as should we be doing this and should all of the developers will be using Kubernetes through the development process? Then we also have to consider people who are not using Kubernetes, because a lot of people out there are not using communities. For developers and special, they hear Kubernetes is painful and definitely enough for developers. Obviously, that is not going to qualify Kubernetes as a tool that they’re going to look into. It's just not motivating. If there is anything that that would make people motivated to look into Kubernetes that would be beneficial for them not just for using Kubernetes for Kubernetes sake, but would it be useful? Basically why? Why would it be useful? [0:11:50.7] EK: I think from the point of view of a developer, you should try and stay away from Kubernetes for as long as you can. Kubernetes comes in when you start having issues of scale. It's a production matter, it's not a development matter. I don't know, like a DevOps issue, operations issue. Ideally, you put off moving your application to Kubernetes as long as possible. This is an opinion. We can argue about this forever. Just because it introduces a lot of complexity and if you don't need that complexity, you should probably stay away from it. To get to the other half of the question, which is if you're using Kubernetes in production, should you use Kubernetes in development? Now here, I'm going to say yes a 100% of the time. Blanket statement of course, we can argue about minutiae, but I think so. Because if you don't, you end up having separate environments. Let's say you're using Docker Compose, because you don't like Kubernetes. You’re using Kubernetes in production, so in development you are going to need containers of some sort. Let's say you're using Docker Compose. Now you're maintaining two different environments. You update something here, you have to update it there. One day, it's going to be Friday, you're going to be tired, you're going to update something here, you're going to forget to update something there, or you're going to update something there and it's going to be slightly different. Or maybe you're doing something that has no equivalent between what you're using locally and what you're using in production. Then basically, you're in trouble. I've heard from many companies that the main reason they decided to use Kubernetes in development is that they wanted to mimic production as closely as possible. One argument we can have here is that – oh, but if you're using Kubernetes in development, that's going to add a lot of overhead and you're not going to be able to do your job right. I agree that that was true for a while, but right now we have enough tooling that you can basically make Kubernetes disappear and you just focus on being a developer, writing your code, doing all of that stuff. Kubernetes is sitting there in the background. You don't have to think about it and you can just go on about your business with the advantage that now, your development environment and your production environment are going to very closely mimic each other, so you're not going to have issues with those potential disparities. [0:14:10.0] CC: All right. Another thing too is that I think we're making an assumption that the developers we are talking about are the developers that are also responsible for deployment. Sometimes that's the case, sometimes that's not the case and I'm going to shut up now. It would be interesting to talk about that too between all of us, is that what we see? Is that the case that now developers are responsible? It's like, developers DevOps is just so ubiquitous that we don't even consider differentiating between developers and ops people? All right? [0:14:45.2] DC: I think I have a different spin on that. I think that it's not necessarily that developers are the ones operating the infrastructure. The problem is that if your infrastructure is operated by a platform that may require some integration at the application layer to really hit its stride, then the question becomes how do you as a developer become more familiar? What is the user experience as of, or what I should say, what's the developer experience around that integration? What can you do to improve that, so that the developer can understand better, or play with how service discovery works, or understand better, or play with how the different services in their application will be able to interact without having to redefine that in different environments? Which is I think what Ellen point was. [0:15:33.0] EK: Yeah. At the most basic level, you have issues as such as you made a change to a service here, let's say on your local Docker Compose. Now you need to update your Kubernetes manifest on your cluster for things to make sense. Let's say, I don't know, you change the name of a service, something as simple as that. Even those kinds of things that sounds silly to even describe, when you're doing that every day, one day you're going to forget it, things are going to explode, you're not going to know why, you're going to lose hours trying to figure out where things went wrong. [0:16:08.7] MG: Also the same with [inaudible] maybe. Even if you use Kubernetes locally, you might run a later version of Kubernetes, maybe use kind for local development, but then your cluster, your remote cluster is on three or four versions behind. Shouldn't be because of the versions of product policy, but it might happen, right? Then APIs might be deprecated, or you're using different API. I totally agree with you, Ellen, that your development environment should reflect production as close as possible. Even there, you have to make sure that prod, like your APIs matches, API types matches and all the stuff right, because they could also break. [0:16:42.4] EK: You were definitely right that bugs are not going away anytime soon. [0:16:47.1] MG: Yeah. I think this discussion also remembers me of the discussion that the folks in the cloud will have with AWS Lambda for example, because there's similar, even though there are tools to simulate, or mimic these platforms, like serverless platforms locally, the general recommendation there is to embrace the cloud and develop in the cloud natively in the cloud, because that's something you cannot resemble. You cannot run DynamoDB locally. You could mimic it. You could mimic lambda runtimes locally. Essentially, it's going to be different. That's also a common complaint in the world of AWS and cloud development, which is it's really not that easy to develop locally, where you're supposed to develop on the platform that the code is being shipped and run on to, because you cannot run the cloud locally. It sounds crazy, but it is. I think the same is with Kubernetes, even though we have the tools. I don't think that every developer runs Kubernetes locally. Most of them maybe doesn't even have Docker locally, so they use some spring tools and then they have some pipeline and eventually it gets shipped as a container part in Kubernetes. That's what I wanted to throw in here as more like a question experience, especially for you Ellen with these customers that you work with, what are the different profiles that you see from the maturity perspective and these customers large enterprises might be different and the smaller ones that you mentioned. How do you see them having different requirements, as also Carlisia said, do they do ops, or DevOps, or is it strictly separated there, especially in large enterprises? [0:18:21.9] EK: What I see the most, let's get the last part first. [0:18:24.6] MG: Yeah, it was a lot of questions. Sorry for that. [0:18:27.7] EK: Yeah. When it comes to who operates Kubernetes, who deploys Kubernetes, definitely most developers push their code to Kubernetes themselves. Of course, this involves CI and testing and PRs and all of that, so it's not you can just go crazy and break everything. When it comes to operating the production cluster, then that's separate. Usually, you have someone writing code and someone else operating clusters and infrastructure. Sometimes it's the same person, but they're clearly separate roles, even if it's the same person doing it. Usually, you go from your IDE to PR and that goes straight into production once the whole process is done. Now we were talking about workflows and Lambda and all of that. I don't see a good solution for lambda, a good development experience for Lambda just yet. It feels a bit like it needs some refinement still. When it comes to Kubernetes, you asked do most developers run Kubernetes locally? Do they not? I don't know about the numbers, the absolute numbers. Is it most doing this, or most doing that? I'm not sure. I only know the companies I'm in touch with. Definitely not all developers run Kubernetes on their laptops, because it's a problem of scale. Right now, we are basically stuck with 30 gigs of RAM on our laptops. If your app is bigger than that, tough luck, you're not going to run it on the laptop. What most developers do is they still maintain a local development environment, where they can do development without going to CI. I think that is the main question. They maintain agility in their development process. What we usually see when you don't have Kubernetes on your laptop and you're using remote Kubernetes, so a remote development cluster in some cloud provider. What most people do and this is not the companies I talk to. This is basically everyone else. What most people will do is they make their development environment be the same, or work the same way as their production environment. You make a change to your code, you have to push a PR that has to get tested by CI. It has to get approved. Then it ends up in the Kubernetes cluster. Your feedback loop as a developer is insanely slow, because there's so much red tape between you changing a line of code and you getting a new process running in your cluster. Now when you use tools, I call the category MDX. I basically coined that category name myself. MDX is a multi-service development experience tooling. When you use MDX tools, and that's not just Tilt; it’s Tilt, it’s Garden where I used to work, people use telepresence like that. There is Scaffold from Google and so on. There's a bunch of tools. When you use a tool like that, you can have your feedback loop down to a second like I said before. I think that is the major improvement developers can do if they're using Kubernetes remotely and even if they’re using Kubernetes locally. I would guess most people do not run Kubernetes locally. They use remotely. We have clients who have clients — we have users who don't even have Docker on their local machines, because if you have the right tooling, you can change the files on your machine. You have tooling running that detects those five changes. It syncs those five changes to your cluster. The cluster then rebuilds images, or restarts containers, or syncs live code that's already running. Then you can see those changes reflected in your development cluster right, away even though you don't even have Docker in your machine. There's all of those possibilities. [0:22:28.4] MG: Do you see security issues with that approach with not knowing the architecture of Tilt? Even though it's just the development clusters, there might be stuff that could break, or you could break by bypassing the red tape as you said? [0:22:42.3] EK: Usually, we assign one user per namespace. Usually, every developer has a namespace. Kubernetes itself has enough options that if that's a concern to you, you can make it secure. Most people don't worry about it that much, because it's development clusters. They're not accessible to the public. Usually, there's – you can only access it through a VPN or something of that sort. We haven't heard about security issues so far. I'm sure they’re going to pop out at some point. I'm not sure how severe it’s going to be, or how hard it's going to be to fix. I am assuming, because none of this stuff is meant to be accessible to the wider Internet that it's not going to be a hard problem to tackle. [0:23:26.7] DC: I would like to back up for a second, because I feel we're pretty far down the road on what the value of this particular pattern is without really explaining what it is. I want to back this up for just a minute and talk about some of the things that a tooling like this is trying to solve in a use case model, right? Back in the day when I was learning Python, I remember really struggling with the idea of being able to debug Python live. I came across iPython, which is a REPL and that was – which was hugely eye-opening, because it gave me the ability to interact with my code live and also open me up to the idea that it was an improve over things like having to commit a new log line against a particular function and then push that new function up to a place where it would actually get some use and then be able to go look at that log line and see what's coming out of it, or do I actually have enough logs to even put together what went wrong. That whole set of use case is I think is somewhat addressed by tooling like this. I do think we should talk about how did we get here and how does that actually and how does like this address some of those things, and which use cases specifically is it looking to address. I guess where I'm going with this is to your point, so a tooling like Tilt, for example, is the idea that you can, as far as I understand it, inject into a running application, a new instance that would be able to – that you would have a local development control over. If you make a change to that code, then the instance running inside of your target environment would be represented by that new code change very quickly, right? Basically, solving the problem of making sure that you have some very quick feedback loop. I mean, functionally, that's the killer feature here. I think it’s really interesting to see tooling like that start to develop, right? Another example of that tooling would be the REPL thing, wherein instead of writing your code and compiling your code and seeing the output, you could do a thing where you're actually inside, running as a thread inside of the code and you can dump a data structure and you can modify that data structure and you can see if your function actually does the right thing, without having to go back and write that code while imagining all those data structures in your head. Basic tooling like this, I think is pretty killer. [0:25:56.8] EK: Yeah. I think one area where that is still partially untapped right now where this tooling could go, and I'm pushing it, but it's a process. It's not something we can do overnight, is to have very high-level patterns, the let's say codified. For example, everyone's copying Docker files and Kubernetes manifests and Terraform can take files, which I forgot what they're called. Everyone's copying that stuff from the Internet from other websites. That's cool. Oh, you need a container that does such-and-such and sets up this environment and provides these tools. Just download this image and everything is all set up for you. One area where I see things going is for us to have that same portability, but for development environments. For example, I did this whole talk about how to take your Go code, your Go application from I don't know, a 30-seconds feedback loop where you're rebuilding an image every time you make a code change and all of that, down to 1 second. There's a lot of hacks in there that span all kinds of stuff, like should you use Go vendor, or should you keep your dependencies cached inside a Docker layer? Those kinds of things. Then I went down a bunch of those things and eventually came up with a workflow that was basically the best I could find in terms of development experience. What is the snappiest workflow? Or for example, you could have what is a workflow that makes it really easy to debug my Go app? You would use applications like Squash and that's a debugger that you can connect to a process running in a large container. Those kinds of things. If we can prepackage those and offer those to users and not just for Go and not just for debugging, but for all kinds of development workflows, I think that would be really great. We can offer those types of experiences to people who don't necessarily have the inclination to develop those workflows themselves. [0:28:06.8] DC: Yeah, I agree. I mean, it is interesting. I've had a few conversations lately about the fact that the abstraction layer of coding in the way that we think about it really hasn't changed over time, right? It's the same thing. That's actually a really relevant point. It's also interesting to think about with these sorts of frameworks and this tooling, it might be interesting to think of what else we can – what else we can enable the developer to have a feedback loop on more quickly, right? To your point, right? We talked about how these different environments, your development environment and your production environment, the general consensus is they should be as close as you can get them reasonably, so that the behavior in one should somewhat mimic the behavior in the other. At least that's the story we tell ourselves. Given that, it would also be interesting if the developer was getting feedback from effectively how the security posture of that particular cluster might affect the work that they're doing. You do actually have to define network policy. Maybe you don't necessarily have to think about it if we can provide tooling that can abstract that away, but at least you should be aware that it's happening so that you understand if it's not working correctly, this is where you might be able to see the sharp edges pop up, you know what I mean? That sort of thing. [0:29:26.0] EK: Yeah. At the last KubeCon, where was it? In San Diego. There was this running joke. I was running around with the security crowd and there was this joke about KubeCon applies security.yaml. It was in a mocking tone. I'm not disparaging their joke. It was a good joke. Then I was thinking, “What if we can make this real?” I mean, maybe it is real. I don't know. I don't do security myself. What if we can apply a comprehensive enough set of security measures, security monitoring, security scanning, all of that stuff, we prepackage it, we allow users to access all of that with one command, or even less than that, maybe you pre-configure it as a team lead and then everyone else in your team can just use it without even knowing that it's there. Then it just lets you know like, “Oh, hey. This thing you just did, this is a potential security issue that you should know about.” Yeah, I think coming up with these developer shortcuts, it's my hobby. [0:30:38.4] MG: That's cool. What you just mentioned Ellen and Duffie remembers me on – reminds me on the Spring community, the Spring framework, where a lot of the boilerplate, or beat security stuff, or connections, integrations, etc., is being abstracted away and you just annotate your code a bit and then some framework and Spring obviously, it's a spring framework. In your case Ellen, what you were hinting to is maybe this build environment that gives me these integration hooks where I just annotate. Or even those annotations could be enforced. Standards could be enforced if I don't annotate at all, right? I could maybe override them. Then this build environment would just pick it up, because it scans the code, right? It has the source code access, so I could just scan it and hook into it and then apply security policies, lock it down, see ports being used, maybe just open them up to the application, the other ones will automatically get blocked, etc., etc. It just came to my mind. I have not done any research there, or whether there's already some place or activity. [0:31:42.2] EK: Yeah. Because I won't shut up about this stuff, because I just love it, we are doing a – it's in a very early stage right now. We are doing a thing at Tile, we're calling extensions. Very creative name, I suppose. It's basically Go in parts, but for those were closed. It's still at a very early stage. We still have some road ahead of us. For example, we have – let's say this one user and they did some very special integration of Helm and Tilt. You don't have to use Helm by hand anymore. You can just make all of your Helm stuff happen automatically when you're using Tilt. Usually, you would have to copy I don't know, a 100 lines of code from your Tilt config file and copy that around for other developers to be able to use it. Now we have this thing that it's basically going parts where you can just say load extension and give it a name, it fetches it from a repository and it's running. I think that is basically an early stage of what you just described with Spring, but more geared towards let's say an infra-Kubernetes, like how do you tie infra-Kubernetes, that stuff with a higher level functionality that you might want to use? [0:33:07.5] MG: Cool. I have another one. Speaking of which, is there any other integrations for IDEs with Tilt? Because I know that VS code for example, has Kubernetes integrations, does the fabric aid and may even plugin, which handles some stuff under the covers. [0:33:24.3] EK: Usually, Tilt watches your code files and it doesn't care which IDEs you use. It has its own dashboard, which is just a page that you open on your browser. I have just heard this week. Someone mentioned on Slack that they wrote an extension for Tilt. I'm not sure if it was for VS code or the other VS code-like .NET editors. I don't remember what it’s called, but they have a family of those. I just heard that someone wrote one of those and they shared the repo. We have someone looking into that. I haven't seen it myself. The idea has come up when I was working at Garden, which is in the same area as Tilt. I think it's pertinent. We also had the idea of a VS code extension. I think the question is what do you put in the extension? What do you make the VS code extension do? Because both Tilt and Garden. They have their own web dashboards that show users what should be shown and in the manner that we think should be shown. If you're going to create a VS code extension, you either replicate that completely and you basically take this stuff that was in the browser and put it in the IDE. I don't particularly see much benefit in that. If enough people ask, maybe we'll do it, but it's not something that I find particularly useful. Either you do that and you replicate the functionality, or you come up with new functionality. In both cases, I just don't see a very strong point as to what different and IDE-specific functionality should you want. [0:35:09.0] MG: Yes. The reason why I was asking is that we see all these Pulumi, CDKs, AWS CDKs coming up, where you basically use a programming language to write your application/application infrastructure code and your IDE and then all the templating, that YAML stuff, etc., gets generated under covers. Just this week, AWS announced the CDKs, like the CDK basically for Kubernetes. I was thinking, with this happening where some of these providers abstract the scaffolding as well, including the build. You don't even have to build, because it's abstracted away under the covers. I was seeing this trend. Then obviously, we still have Helm and the templating and the customize and then you still have the manual as I mentioned in the beginning. I do like the IDE integration, because that's where I spend most of my time. Whenever I have to leave the IDE, it's a context switch that I have to go through. Even if it's just for opening another file also that I need to edit somewhere. That's why I think having IDE integration is useful for developers, because that's where they most spend up their time. As you said, there might be reasons to not do it in an IDE, because it's just replicating functionality that might not be useful there. [0:36:29.8] EK: Yeah. In the case of Tilt, all the config is written in Starlark, which is a language and it's basically Python. If your IDE can syntax highlight Python, it can syntax highlight the Tilt config files. About Pulumi and that stuff, I'm not that familiar. It's stuff that I know how it works, but I haven't used it myself. I'm not familiar with the browse and the IDE integration side of it. The thing about tools like Tilt is that usually, if you set it up right, you can just write your code all day and you don't have to look at the tool. You just switch from your IDE to let's say, your browser where your app is running, so you get feedback and that kind of thing. Once you configure it, you don't really spend much time looking at it. You're going to look at it when there are errors. You try to refresh your application and it fails. You need to find that error. By the time that happened, you already lost focus from your code anyway. Whether you're going to look for your error on a terminal, or on the Tilt dashboard, that's not much an issue. [0:37:37.7] MG: That's right. That’s right. I agree. [0:37:39.8] CC: All this talk about tooling and IDEs is making me think to ask you Ellen. If I'm a developer and let's say, my company decides that we’re going to use Kubernetes. What we are advocating here with this episode is to think about well, if you're going to be the point to Kubernetes in production, you should consider running Kubernetes as a local development environment. Now for those developers who don't even – haven't even worked with Kubernetes, where do you suggest they jump in? Should they get a handle on – because it's too many things. I mean, Kubernetes already is so big and there are so many toolings around to how to operate Kubernetes itself. For a developer who is, “Okay, I like this idea of having my own local Kubernetes environment, or a development environment somehow may also be in the cloud,” should they start with a tooling like Tilt, or something similar? Would that make it easier for them to wrap their head around Kubernetes and what Kubernetes does? Or should they first get a handle on Kubernetes and then look at a tool like this? [0:38:56.2] EK: Okay. There are a few sides to this question. If you have a very large team, ideally you should get one or a few people to actually really learn Kubernetes and then make it so that everyone else doesn't have to. Something we have seen is very large company, they are going to do Kubernetes in development. They set up a developer experience team and then for example, they have their own wrapper around Kubectl and then basically, they automate a bunch of stuff so that everyone in the team doesn't have to take a certified Kubernetes application development certificate. Because for people who don't know that certificate, it's basically how much Kubectl can you do off top of your head? That is basically what that certificate is about, because Kubectl is an insanely huge and powerful tool. On the one hand, you should do that. If you have a big team, take a few people, learn all that you can about Kubernetes, write some wrappers so that people don't have to do Kubectl or something, something by hand. Just make very easy functions, like Kubectl, let’s say you know a name of your wrapper, context and the name and then that's going to switch you to a namespace let's say, where some version of your app is running, so that thing. Now about the tooling. Once you have your development environment set up and you're going to need someone who has some experience with Kubernetes to set that up in the first place, but once that is set up, if you have the right tooling, you don't really have to know everything that Kubernetes does. You should have at least a conceptual overview. I can tell you for sure, that there's hundreds of developers out there writing code that is going to be deployed to Kubernetes, writing codes that whenever they make a change to their code, it goes to a Kubernetes development cluster and they don't have the first – well, I’m not going to say the first clue, but they are not experienced Kubernetes users. That's because of all the tooling that you can put around. [0:41:10.5] CC: Yeah, that makes sense. [0:41:12.2] EK: Yeah. You can abstract a bunch of stuff with basically good sense, so that you know the common operations that need to be done for your team and then you just abstract them away, so that people don't have to become Kubectl experts. On the other side, you can also abstract a bunch of stuff away with tooling. Basically, as long as your developer has the basic grasp of containers and basics of Kubernetes, that stuff, they don't need to know how to operate it, with any depth. [0:41:44.0] MG: Hey Ellen, in the beginning you said that it's all about this feedback loop and iterating fast. Part of a feedback loop for a developer is unit testing, integration testing, or all sorts of testing. How do you see that changing, or benefiting from tools like Tilt, especially when it comes to integration testing? Unit tests usually locally, but the integration testing. [0:42:05.8] EK: One thing that people can do when they're using Tilt is once you have Tilt running, you basically have all of your application running. You can just set up one-off tasks with Tilt. You could basically set up a script that there's a bunch of stuff, which would basically be what your test does. If it returns zero, it succeeded. If it doesn’t, it failed. You can set something up like that. It's not something that we have right now in a prepackaged farm that you can use right away. You would basically just say, “Hey Tilt, run this thing for me,” and then you would see if it worked or not. I have to make a plug to the competition right now. Garden has more of that part of it, that part of things set up. They have tests as a separate primitive right next to building and deploying, which is what you usually see. They also have testing. It does basically what I just said about Tilt, but they have a special little framework around it. With Garden, you would say, “Oh, here's a test. Here's how you run the test. Here's what the test depends on, etc.” Then it runs it and it tells you if it failed or not. With Tilt, it would be a more generic approach where you would just say, “Hey Tilt, run this and tell me if it fails or not,” but without the little wrapping around it that's specific for testing. When it comes to how things work, like when you're trying to push the production, let's say you did a bunch of stuff locally, you're happy with it, now it's time to push the production. Then there's all that headache with CI and waiting for tests to run and flaky tests and all of that, that I don't know. That is a big open question that everyone's unhappy about and no one really knows which way to run to. [0:43:57.5] DC: That’s awesome. Where do you see this space going in the future? I mean, as you look at the tooling that’s out there, maybe not specifically to the Tilt particular service or capability, but where do you see some other people exploring that space? We were talking about AWS dropping and CDK and there are different people trying to solve the YAML problem, but more from the developer user experience tooling way, where do you see that space going? [0:44:23.9] EK: For me, it's all about higher level abstractions and well-defined best practices. Right now, everyone is fumbling around in the dark not knowing what to do, trying to figure out what works and what doesn't. The main thing that I see changing is that given enough time, best practices are going to emerge and it's going to be clear for everyone. If you're doing this thing, you should use this workflow. If you're doing that thing, you should use that workflow. Basically, what happened when IDEs emerged and became a thing, that is the best practice aside. [0:44:57.1] DC: That's a great example. [0:44:58.4] EK: Yeah. What I see in terms of things being offered for me tomorrow of — in terms of prepackaged higher level abstractions. I don't think developers should, everyone know how to deal with Kubernetes at a deeper level, the same way as I don't know how to build the Linux kernel even though I use Linux every day. I think things should be wrapped up in a way that developers can focus on what matters to them, which is right now basically writing code. Developers should be able to get to the office in the morning, open up their computer, start writing code, or doing whatever else they want to do and not worry about Kubernetes, not worry about lambda, not worry about how is this getting built and how is this getting deployed and how is this getting tested, what's the underlying mechanism. I'd love for higher-level patterns of those to emerge and be very easy to use for everyone. [0:45:53.3] CC: Yeah, it's going to be very interesting. I think best practices is such an interesting thing to think about, because somebody could sit down and write, “Oh, these are the best practices we should be following in the space.” I think, my opinion it's really going to come out of what worked historically when we have enough data to look at over the years. I think it's going to be as far as tooling goes, like a survival of the fittest. Whatever tool has been used the most, that's what's going to be the best practice way to do things. Yeah, we know today there are so many tools, but I think probably we're going to get to a point where we know what to use for what in the future. With that, we have to wrap-up, because we are at the top of the hour. It was so great to have Ellen, or L, how they I think prefer to be called and to have you on the show, Elle. Thank you so much. I mean, L. See, I can't even follow my own. You're very active on Twitter. We're going to have all the information for how to reach you on the show notes. We're going to have a transcript. As always people, subscribe, follow us on Twitter, so you can be up to date with what we are doing and suggest episodes too on our github repo. With that, thank you everybody. Thank you L. [0:47:23.1] DC: Thank you, everybody. [0:47:23.3] CC: Thank you, Michael and – [0:47:24.3] MG: Thank you. [0:47:24.8] CC: - thank you, Duffie. [0:47:26.2] EK: Thank you. It was great. [0:47:26.8] MG: Until next time. [0:47:27.0] CC: Until next week. [0:47:27.7] MG: Bye-bye. [0:47:28.5] EK: Bye. [0:47:28.6] CC: It really was. [END OF EPISODE] [0:47:31.0] ANNOUNCER: Thank you for listening to the Podlets Cloud Native Podcast. Find us on Twitter @thepodlets and on thepodlets.io website. That is ThePodlets, altogether, where you will find transcripts and show notes. We’ll be back next week. Stay tuned by subscribing. [END]See omnystudio.com/listener for privacy information.

The question of diving into Kubernetes is something that faces us all in different ways. Whether you are already on the platform, are considering transitioning, or are thinking about what is best for your team moving forward, the possibilities and the learning-curve make it a somewhat difficult question to answer. In this episode, we discuss the topic and ultimately believe that an individual is the only one who can answer that question well. That being said, the capabilities of Kubernetes can be quite persuasive and if you are tempted then it is most definitely worth considering very seriously, at least. In our discussion, we cover some of the problems that Kubernetes solves, as well as some of the issues that might arise when moving into the Kubernetes space. The panel shares their thoughts on learning a new platform and compare it with other tricky installations and adoption periods. From there, we look at platforms and how Kubernetes fits and does not fit into a traditional definition of what a platform constitutes. The last part of this episode is spent considering the future of Kubernetes and how fast that future just might arrive. So for all this and a bunch more, join us on The Podlets Podcast, today! Follow us: https://twitter.com/thepodlets Website: https://thepodlets.io Feeback: info@thepodlets.io https://github.com/vmware-tanzu/thepodlets/issues Hosts: Carlisia Campos Josh Rosso Duffie Cooley Bryan Liles Key Points From This Episode: The main problems that Kubernetes solves and poses. Why you do not need to understand distributed systems in order to use Kubernetes. How to get around some of the concerns about installing and learning a new platform. The work that goes into readying a Kubernetes production cluster. What constitutes a platform and can we consider Kubernetes to be one? The two ways to approach the apparent value of employing Kubernetes. Making the leap to Kubernetes is a personal question that only you can answer. Looking to the future of Kubernetes and its possible trajectories. The possibility of more visual tools in the UI of Kubernetes. Understanding the concept of conditions in Kubernetes and its objects. Considering appropriate times to introduce a team to Kubernetes. Quotes: “I can use different tools and it might look different and they will have different commands but what I’m actually doing, it doesn’t change and my understanding of what I’m doing doesn’t change.” — @carlisia [0:04:31] “Kubernetes is a distributed system, we need people with expertise across that field, across that whole grouping of technologies.” — @mauilion [0:10:09] “Kubernetes is not just a platform. Kubernetes is a platform for building platforms.” — @bryanl [0:18:12] Links Mentioned in Today’s Episode: Weave — https://www.weave.works/docs/net/latest/overview/ AWS — https://aws.amazon.com/ DigitalOcean — https://www.digitalocean.com/ Heroku — https://www.heroku.com/ Red Hat — https://www.redhat.com/en Debian — https://www.debian.org/ Canonical — https://canonical.com/ Kelsey Hightower — https://github.com/kelseyhightower Joe Beda — https://www.vmware.com/latam/company/leadership/joe-beda.html Azure — https://azure.microsoft.com/en-us/ CloudFoundry — https://www.cloudfoundry.org/ JAY Z — https://lifeandtimes.com/ OpenStack — https://www.openstack.org/ OpenShift — https://www.openshift.com/ KubeVirt — https://kubevirt.io/ VMware — https://www.vmware.com/ Chef and Puppet — https://www.chef.io/puppet/ tgik.io — https://www.youtube.com/playlist?list=PL7bmigfV0EqQzxcNpmcdTJ9eFRPBe-iZa Matthias Endler: Maybe You Don't Need Kubernetes - https://endler.dev/2019/maybe-you-dont-need-kubernetes Martin Tournoij: You (probably) don’t need Kubernetes - https://www.arp242.net/dont-need-k8s.html Scalar Software: Why most companies don't need Kubernetes - https://scalarsoftware.com/blog/why-most-companies-dont-need-kubernetes GitHub: Kubernetes at GitHub - https://github.blog/2017-08-16-kubernetes-at-github Debugging network stalls on Kubernetes - https://github.blog/2019-11-21-debugging-network-stalls-on-kubernetes/ One year using Kubernetes in production: Lessons learned - https://techbeacon.com/devops/one-year-using-kubernetes-production-lessons-learned Kelsey Hightower Tweet: Kubernetes is a platform for building platforms. It's a better place to start; not the endgame - https://twitter.com/kelseyhightower/status/935252923721793536?s=2 Transcript: EPISODE 18 [INTRODUCTION] [0:00:08.7] ANNOUNCER: Welcome to The Podlets Podcast, a weekly show that explores Cloud Native one buzzword at a time. Each week, experts in the field will discuss and contrast distributed systems concepts, practices, tradeoffs and lessons learned to help you on your cloud native journey. This space moves fast and we shouldn’t reinvent the wheel. If you’re an engineer, operator or technically minded decision maker, this podcast is for you. [EPISODE] [0:00:41.9] JR: Hello everyone and welcome to The Podlets Podcast where we are going to be talking about should I Kubernetes? My name is Josh Rosso and I am very pleased to be joined by, Carlisia Campos. [0:00:55.3] CC: Hi everybody. [0:00:56.3] JR: Duffy Cooley. [0:00:57.6] DC: Hey folks. [0:00:58.5] JR: And Brian Lyles. [0:01:00.2] BL: Hi. [0:01:03.1] JR: All right everyone. I’m really excited about this episode because I feel like as Kubernetes has been gaining popularity over time, it’s been getting its fair share of promoters and detractors. That’s fair for any piece of software, right? I’ve pulled up some articles and we put them in the show notes about some of the different perspectives on both success and perhaps failures with Kub. But before we dissect some of those, I was thinking we could open it up more generically and think about based on our experience with Kubernetes, what are some of the most important things that we think Kubernetes solves for? [0:01:44.4] DC: All right, my list is very short and what Kubernetes solves for my point of view is that it allows or it actually presents an interface that knows how to run software and the best part about it is that it doesn’t – the standard interface. I can target Kubernetes rather than targeting the underlying hardware. I know certain things are going to be there, I know certain networking’s going to be there. I know how to control memory and actually, that’s the only reason that I really would give, say for Kubernetes, we need that standardization and you don’t want to set up VM’s, I mean, assuming you already have a cluster. This simplifies so much. [0:02:29.7] BL: For my part, I think it’s life cycle stuff that’s really the biggest driver for my use of it and for my particular fascination with it. I’ve been in roles in the past where I was responsible for ensuring that some magical mold of application on a thousand machines would magically work and I would have all the dependencies necessary and they would all agree on what those dependencies were and it would actually just work and that was really hard. I mean, getting to like a known state in that situation, it’s very difficult. Having something where either both the abstractions of containers and the abstraction of container orchestration, the ability to deploy those applications and all those dependencies together and the ability to change that application and its dependencies, using an API. That’s the killer part for me. [0:03:17.9] CC: For me, from a perspective of a developer is very much what Duffy just said but more so the uniformity that comes with all those bells and whistles that we get by having that API and all of the features of Kubernetes. We get such a uniformity across such a really large surface and so if I’m going to deploy apps, if I’m going to allow containers, what I have to do for one application is the same for another application. If I go work for another company, that uses Kubernetes, it is the same and if that Kubernetes is a hosted Kubernetes or if it’s a self-managed, it will be the same. I love that consistency and that uniformity that even so I can – there are many tools that help, they are customized, there’s help if you installing and composing specific things for your needs. But the understanding of what you were doing is it’s the same, right? I can use different tools and it might look different and they will have different commands but what I’m actually doing, it doesn’t change and my understanding of what I’m doing doesn’t change. I love that. Being able to do my work in the same way, I wish, you know, if that alone for me makes it worthwhile. [0:04:56.0] JR: Yeah, I think like my perspective is pretty much the same as what you all said and I think the one way that I kind of look at it too is Kubernetes does a better job of solving the concerns you just listed, then I would probably be able to build myself or my team would be able to solve for ourselves in a lot of cases. I’m not trying to say that specialization around your business case or your teams isn’t appropriate at times, it’s just at least for me, to your point Carlisia, I love that abstraction that’s consistent across environments. It handles a lot of the things, like Brian was saying, about CPU, memory, resources and thinking through all those different pieces. I wanted to take what we just said and maybe turn it a bit at some of the common things that people run in to with Kubernetes and just to maybe hit on a piece of low hanging fruit that I think is oftentimes a really fair perspective is Kubernetes is really hard to operate. Sure, it gives you all the benefits we just talked about but managing a Kubernetes cluster? That is not a trivial task. And I just wanted to kind of open that perspective up to all of us, you know? What are your thoughts on that? [0:06:01.8] DC: Well, the first thought is it doesn’t have to be that way. I think that’s a fallacy that a lot of people fall into, it’s hard. Guess what? That’s fine, we’re in the sixth year of Kubernetes, we’re not in the sixth year of stability of a stable release. It’s hard to get started with Kubernetes and what happens is we use that as an excuse to say well, you know what? It’s hard to get started with so it’s a failure. You know something else that was hard to get started with? Whenever I started with it in the 90s? Linux. You download it and downloading it on 30 floppy disks. There was the download corruption, real things, Z modem, X modem, Y modem. This is real, a lot of people don’t know about this. And then, you had to find 30 working flopping disk and you had to transfer 30, you know, one and a half megabyte — and it still took a long time to floppy disk and then you had to run the installer. And then most likely, you had to build a kernel. Downloading, transferring, installing, building a kernel, there was four places where just before you didn’t have windows, this was just to get you to a log in prompt, that could fail. With Kubernetes, we had this issue. People were installing Kubernetes, there’s cloud vendors who are installing it and then there’s people who were installing it on who knows what hardware. Guess what? That’s hard and it’s not even now, it’s not even they physical servers that’s networking. Well, how are you going to create a network that works across all your servers, well you’re going to need an overlay, which one are you going to use, Calico? Use Weave? You’re going to need something else that you created or something else if it works. Yeah, just we’re still figuring out where we need to be but these problems are getting solved. This will go away. [0:07:43.7] BL: I’m living that life right now, I just got a new laptop and I’m a Linux desktop kind of guy and so I’m doing it right now. What does it take to actually get a recent enough kernel that the hardware that is shipped with this laptop is supported, you know? It’s like, those problems continue, even though Linux has been around and considered stable and it’s the underpinning of much of what we do on the internet today, we still run into these things, it’s still a very much a thing. [0:08:08.1] CC: I think also, there’s a factor of experience, for example. This is not the first time you have to deal with this problem, right Duffy? Been using Linux on a desktop so this is not the first hardware that you had to setup Linux on. So you know where to go to find that information. Yeah, it’s sort of a pain but it’s manageable. I think a lot of us are suffering from gosh, I’ve never seen Kubernetes before, where do I even start and – or, I learned Kubernetes but it’s quite burdensome to keep up with everything as opposed to let’s say, if 10 years from now, we are still doing Kubernetes. You’ll be like yeah, okay, whatever. This is no big deal. So because we have done these things for a few years that we were not possibly say that it’s hard. I don’t’ think we would describe it that way. [0:09:05.7] DC: I think there will still be some difficulty to it but to your point, it’s interesting, if I look back like, five years ago, I was telling all of my friends. Look, if you’re a system’s administrator, go learn how to do other things, go learn how to be, go learn an API centric model, go play with AWS, go play with tools like this, right? If you’re a network administrator, learn to be a system’s administrator but you got to branch out. You got to figure out how to ensure that you’re relevant in the coming time. With all the things that are changing, right? This is true, I was telling my friend this five years ago, 10 years ago, continues, I continue to tell my friends that today. If I look at the Kubernetes platform, the complexity that represents in operating it is almost tailor made to those people though did do that, that decided to actually branch out and to understand why API’s are interesting and to understand, you know, can they have enough of an understanding in a generalist way to become a reasonable systems administrator and a network administrator and you know, start actually understanding the paradigms around distributed systems because those people are what we need to operate this stuff right now, we’re building – I mean, Kubernetes is a distributed system, we need people with expertise across that field, across that whole grouping of technologies. [0:10:17.0] BL: Or, don’t. Don’t do any of that. [0:10:19.8] CC: Brian, let me follow up on that because I think it’s great that you pointed that out Duffy. I was thinking precisely in terms of being a generalist and understanding how Kubernetes works and being able to do most of it but it is so true that some parts of it will always be very complex and it will require expertise. For example, security. Dealing with certificates and making sure that that’s working, if you want to – if you have particular needs for networking, but, understanding the whole idea of this systems, as it sits on top of Kubernetes, grasping that I think is going to – have years of experience under their belt. Become relatively simple, sorry Brian that I cut you off. [0:11:10.3] BL: That’s fine but now you gave me something else to say in addition to what I was going to say before. Here’s the killer. You don’t need to know distributed systems to use Kubernetes. Not at all. You can use a deployment, you can use a [inaudible] set, you can run a job, you can get workloads up on Kubernetes without having to understand that. But, Kubernetes also gives you some good constructs either in the Kubernetes API's itself or in its client libraries where you could build distributed systems in easier way but what I was going to say before that though is I can’t build a cluster. Well don’t. You know what you should do? Use a cloud vendor, use AWS, use Google, use Microsoft or no, I mean, did I say Microsoft? Google and Microsoft. Use Digital Ocean. There’s other people out there that do it as well, they can take care of all the hard things for you and three, four minutes or 10 minutes if you’re on certain clouds, you can have Kubernetes up and running and you don’t even have to think about a lot of these networking concerns to get started. I think that’s a little bit of the thud that we hear, "It’s hard to install." Well, don’t install it, you install it whenever you have to manage your own data centers. Guess what? When you have to manage your own data centers and you’re managing networking and storage, there’s a set of expertise that you already have on staff and maybe they don’t want to learn a new thing, that’s a personal problem, that’s not really a Kubernetes problem. Let’s separate those concerns and not use our lack or not wanting to, to stop us from actually moving forward. [0:12:39.2] DC: Yeah. Maybe even taking that example step forward. I think where this problem compounds or this perspective sometimes compounds about Kubernetes being hard to operate is coming from of some shops who have the perspective of are operational concerns today, aren’t that complex. Why are we introducing this overhead, this thing that we maybe don’t need and you know, to your point Brian, I wonder if we’d all entertain the idea, I’m sure we would that maybe even, speaking to the cloud vendors, maybe even just a Heroku or something. Something that doesn’t even concern itself with Kube but can get your workload up and running and successful as quickly as possible. Especially if you’re like, maybe a small startup type persona, even that’s adequate, right? It could have been not a failure of Kubernetes but more so choosing the wrong tool for the job, does that resonate with you all as well, does that make sense? [0:13:32.9 DC: Yeah, you know, you can’t build a house with a screwdriver. I mean, you probably could, it would hurt and it would take a long time. That’s what we’re running into. What you’re really feeling is that operationally, you cannot bridge the gap between running your application and running your application in Kubernetes and I think that’s fair, that’s actually a great thing, we prove that the foundations are stable enough that now, we can actually do research and figure out the best ways to run things because guess what? RPM’s from Red Hat and then you have devs from the Debian project, different ways of getting things, you have Snap from Canonical, it works and sometimes it doesn’t, we need to actually figure out those constructs in Kubernetes, they’re not free. These things did not exist because someone says, "Hey, I think we should do this." Many years. I was using RPM in the 90s and we need to remember that. [0:14:25.8] JR: On that front, I want to maybe point a question to you Duffy, if you don’t mind. Another big concern that I know you deal with a lot is that Kubernetes is great. Maybe I can get it up no problem. But to make it a viable deployment target at my organization, there’s a lot of work that goes into it to make a Kubernetes cluster production ready, right? That could be involving how you integrate storage and networking and security and on and on. I feel like we end up at this tradeoff of it’s so great that Kubernetes is super extensible and customizable but there is a certain amount of work that that kind of comes with, right? I’m curious Duff, what’s your perspective on that? [0:15:07.3] DC: I want to make a point that bring back to something Brian mentioned earlier, real quick, before I go on to that one. The point is that, I completely agree that yo do not have to actually be a distributed systems person to understand how to use Kubernetes and if that were a bar, we would have set that bar and incredibly, the inappropriate place. But from the operational perspective, that’s what we were referring to. I completely also agree that especially when we think about productionalizing clusters, if you’re just getting into this Kubernetes thing, it may be that you want to actually farm that out to another entity to create and productionalize those clusters, right? You have a choice to make just like you had a choice to make what when AWS came along. Just like you had a choice to make — we’re thinking of virtual machines, right? You have a choice and you continue to have a choice about how far down that rabbit hole as an engineering team of an engineering effort your company wants to go, right? Do you want farm everything out to the cloud and not have to deal with the operations, the day to day operations of those virtual machines and take the constraints that have been defined by that platformer, or do you want to operate that stuff locally, are you required by the law to operate locally? What does production really mean to you and like, what are the constraints that you actually have to satisfy, right? I think that given that choice, when we think about how to production Alize Kubernetes, it comes down to exactly that same set of things, right? Frequently, productionalizing – I’ve seen a number of different takes on this and it’s interesting because I think it’s actually going to move on to our next topic in line here. Frequently I see that productionizing or productionalizing Kubernetes means to provide some set of constraints around the consumption of the platform such that your developers or the focus that are consuming that platform have to operate within those rails, right? They could only define deployments and they can only define deployments that look like this. We’re going to ask them a varied subset of questions and then fill out all the rest of it for them on top of Kubernetes. The entry point might be CICD, it might be a repository, it might be code repository, very similar to a Heroku, right? The entry point could be anywhere along that thing and I’ve seen a number of different enterprises explore different ways to implement that. [0:17:17.8] JR: Cool. Another concept that I wanted to maybe have us define and think about, because I’ve heard the term platform quite a bit, right? I was thinking a little bit about you know, what the term platform means exactly? Then eventually, whether Kubernetes itself should be considered a platform. Backing u, maybe we could just start with a simple question, for all of us, what makes something a platform exactly? [0:17:46.8] BL: Well, a platform is something that provides something. That is a Brian Lyles exclusive. But really, what it is, what is a platform, a platform provides some kind of service that can be used to accomplish some task and Kubernetes is a platform and that thing, it provides constructs through its API to allow you to perform tasks. But, Kubernetes is not just a platform. Kubernetes is a platform for building platforms. The things that Kubernetes provides, the workload API, the networking API, the configuration and storage API’s. What they provide is a facility for you to build higher level constructs that control how you want to run the code and then how you want to connect the applications. Yeah, Kubernetes is actually a platform for platforms. [0:18:42.4] CC: Wait, just to make sure, Brian. You’re saying, because Kelsey Hightower for example is someone who says Kubernetes is a platform of platforms. Now, is Kubernetes both a platform of platforms, at the same time that it’s also a platform to run apps on? [0:18:59.4] BL: It’s both. Kelsey tweeted that there is some controversy on who said that first, it could have been Joe Beda, it could have been Kelsey. I think it was one of those two so I want to give a shout out to both of those for thinking in the same line and really thinking about this problem. But to go back to what you said, Carlisia, is it a platform for providing platforms and a platform? Yes, I will explain how. If you have Kubernetes running and what you can do is you can actually talk to the API, create a deployment. That is platform for running a workload. But, also what you can do is you can create through Kubernetes API mechanisms, ie. CRD’s, custom resource definitions. You can create custom resources that I want to have something called an application. You can basically extend the Kubernetes API. Not only is Kubernetes allowing you to run your workloads, it’s allowing you to specify, extend the API, which then in turn can be run with another controller that’s running on your platform that then gives you this thing when you cleared an application. Now, it creates deployment which creates a replica set, which creates a pod, which creates containers, which downloads images from a container registry. It actually is both. [0:20:17.8] DC: Yeah, I agree with that. Another quote that I remember being fascinated by which I think kind of also helps define what a platform is Kelsey put on out quote that said, Everybody wants platform at a service with the only requirement being that they’ve built it themselves." Which I think is awesome and it also kind of speaks, in my opinion to what I think the definition of a platform is, right? It’s an interface through which we can define services or applications and that interface typically will have some set of constraints or some set of workflows or some defined user experience on top of it. To Brian's point, I think that Kubernetes is a platform because it provides you a bunch of primitive s on the back end that you can use to express what that user experience might be. As we were talking earlier about what does it take to actually – you might move the entry point into this platform from the API, the Kubernetes API server, back down into CICD, right? Perhaps you're not actually defining us and called it a deployment, you’re just saying, I want so many instances off this, I don’t want it to be able to communicate with this other thing, right? It becomes – so my opinion, the definition about of a platform it is that user experience interface. It’s the constraints that we know things that you're going to put on top of that platform. [0:21:33.9] BL: I like that. I want to throw out a disclaimer right here because we’re here, because we’re talking about platforms. Kubernetes is not a platform, it’s as surface. That is actually, that’s different, a platform as a service is – from the way that we look at it, is basically a platform that can run your code, can actually make your code available to external users, can scale it up, can scale it down and manages all the nuances required for that operation to happen. Kubernetes does not do that out of the box but you can build a platform as a surface on Kubernetes. That’s actually, I think, where we’ll be going next is actually people, stepping out of the onesy-twosy, I can deploy a workload, but let’s actually work on thinking about this level. And I’ll tell you what. DEUS who got bought by Azure a few years ago, they actually did that, they built a pass that looks like Heroku. Microsoft and Azure thought that was a good idea so they purchased them and they’re still over there, thinking about great ideas but I think as we move forward, we will definitely see different types of paths on Kubernetes. The best thing is that I don’t think we’ll see them in the conventional sense of what we think now. We have a Heroku, which is like the git-push Heroku master, we share code through git. And then we have CloudFoundry idea of a paths which is, you can run CFPush and that actually is more of an extension of our old school Java applications, where we could just push [inaudible] here but I think at least I am hoping and this is something that I am actually working on not to toot my own horn too much but actually thinking about how do we actually – can we build a platform as a service toolkit? Can I actually just build something that’s tailing to my operation? And that is something that I think we’ll see a lot more in the next 18 months. At least you will see it from me and people that I am influencing. [0:23:24.4] CC: One thing I wanted to mention before we move onto anything else, in answering “Is Kubernetes right for me?” We are so biased. We need to play devil’s advocate at some point. But in answering that question that is the same as in when we need to answer, “Is technology x right for me?” and I think there is at a higher level there are two camps. One camp is very much of the thinking that, "I need to deliver value. I need to allow my software and if the tools I have are solving my problem I don’t need to use something else. I don’t need to use the fancy, shiny thing that’s the hype and the new thing." And that is so right. You definitely shouldn't be doing that. I am divided on this way of thinking because at the same time at that is so right. You do have to be conscious of how much money you’re spending on things and anyway, you have to be efficient with your resources. But at the same time, I think that a lot of people who don’t fully understand what Kubernetes really can do and if you are listening to this, if you maybe could rewind and listen to what Brian and Duffy were just saying in terms of workflows and the Kubernetes primitives. Because those things they are so powerful. They allow you to be so creative with what you can do, right? With your development process, with your roll out process and maybe you don’t need it now. Because you are not using those things but once you understand what it is, what it can do for your used case, you might start having ideas like, “Wow, that could actually make X, Y and Z better or I could create something else that could use these things and therefore add value to my enterprise and I didn’t even think about this before.” So you know two ways of looking at things. [0:25:40.0] BL: Actually, so the topic of this session was, “Should I Kubernetes” and my answer to that is I don’t know. That is something for you to figure out. If you have to ask somebody else I would probably say no. But on the other side, if you are looking for great networking across a lot of servers. If you are looking for service discovery, if you are looking for a system that can restart workloads when they fail, well now you should probably start thinking about Kubernetes. Because Kubernetes provides all of these things out of the box and are they easy to get started with though? Some of these things are harder. Service discovery is really easy but some of these things are a little bit harder but what Kubernetes does is here comes my hip-hop quote, Jay Z said this, basically he’s talking about difficult things and he basically wants difficult things to take a little bit of time and impossible things or things we thought that were impossible to take a week. So basically making difficult things easy and making things that you could not even imagine doing, attainable. And I think that is what Kubernetes brings to the table then I’ll go back and say this one more time. Should you use Kubernetes? I don’t know that is a personal problem that is something you need to answer but if you’re looking for what Kubernetes provides, yes definitely you should use it. [0:26:58.0] DC: Yeah, I agree with that I think it is a good summary there. But I also think you know coming back to whether you should Kubernetes part, from my perspective the reason that I Kubernetes, if you will, I love that as a verb is that when I look around at the different projects in the infrastructure space, as an operations person, one of the first things I look for is that API that pattern around consumption, what's actually out there and what’s developing that API. Is it a the business that is interested in selling me a new thing or is it an API that’s being developed by people who are actually trying to solve real problems, is there a reasonable way to go about this. I mean when I look at open stack, OpenStack was exactly the same sort of model, right? OpenStack existed as an API to help you consume infrastructure and I look at Kubernetes and I realize, “Wow, okay well now we are developing an API that allows us to think about the life cycle and management of applications." Which moves us up the stack, right? So for my part, the reason I am in this community, the reason I am interested in this product, the reason I am totally Kubernetes-ing is because of that. I realized that fundamentally infrastructure has to change to be able to support the kind of load that we are seeing. So whether you should Kubernetes, is the API valuable to you? Do you see the value in that or is there more value in continuing whatever paradigm you’re in currently, right? And judging that equally I think is important. [0:28:21.2] JR: Two schools of thoughts that I run into a lot on the API side of thing is whether overtime Kubernetes will become this implementation detail, where 99% of users aren’t even aware of the API to any extent. And then another one that kind of talks about the API is consistent abstraction with tons of flexibility and I think companies are going in both directions like OpenShift from Red Hat is perhaps a good example. Maybe that is one of those layer two platforms more so Brian that you were talking about, right? Where Kubernetes is the platform that was used to build it but the average person that interacts with it might not actually be aware of some of the Kubernetes primitives and things like that. So if we could all get out of our crystal balls for a second here, what do you all think in the future? Do you see the Kubernetes API becoming just a more prevalent industry standard or do you see it fading away in favor of some other abstraction that makes it easier? [0:29:18.3] BL: Oh wow, well I already see it as I don’t have to look too far in the future, right? I can see the Kubernetes API being used in ways that we could not imagine. The idea that I will think of is like KubeVirt. KubeVirt allows you to boot basically pods on whatever implements that it looks like a Kubelet. So it looks like something that could run pods. But the neat thing is that you can use something like KubeVirt with a virtual Kubelet and now you can boot them on other things. So ideas in that space, I don’t know VMware is actually going on that, “Wow, what if we can make virtual machines look like pods inside of Kubernetes? Pretty neat." Azure has definitely led work on this as now, we can just bring up either bring up containers, we can bring up VM’s and you don’t actually need a Kube server anymore. Now but the crazy part is that you can still use a workloads API’s, storage API’s with Kubernetes and it does not matter what backs it. And I’ll throw out one more suggestion. So there is also projects like AWS operators in [inaudible] point and what they allow you to do is to use the Kubernetes API or actually in cluster API, I'll use all three. But I use the Kubernetes API to boot things that aren’t even in the cluster and this will be AWS services or this could be databases across multiple clouds or guess what? More Kubernetes services. Yeah, so we are on that path but I just can’t wait to see what people are going to do with that. The power of Kubernetes is this API, it is just so amazing. [0:30:50.8] DC: For my part, I think is that I agree that the API itself is being extended in all kinds of amazing ways but I think that as I look around in the crystal ball, I think that the API will continue to be foundational to what is happening. If I look at the level two or level three platforms that are coming, I think those will continue to be a thing for enterprises because they will continue to innovate in that space and then they will continue to consume the underlying API structure and that portability Kubernetes exposes to define what that platform might look like for their own purpose, right? Giving them the ability to effectively have a platform as a service that they define themselves but using and under – you know, using a foundational layer that it’s like consistent and extensible and extensive I think that that’s where things are headed. [0:31:38.2] CC: And also more visual tools, I think is in our future. Better, actual visual UI's that people can use I think that’s definitely going to be in our future. [0:31:54.0] BL: So can I talk about that for a second? [0:31:55.9] CC: Please, Brian. [0:31:56.8] BL: I am wearing my octant hoodie today, which is a visual tool for Kubernetes and I will talk now as someone who has gone down this path to actually figure this problem out. As a prediction for the future, I think we’ll start creating better API’s in Kubernetes to allow for more visual things and the reason that I say that this is going to happen and it can’t really happen now is because for inside of an octant and whenever creating new eye views, pretty much happened now what that optic is. But what is going to happen and I see the rumblings from the community, I see the rumblings from K-native community as well is that we are going to start standardizing on conditions and using conditions as a way that we can actually say what’s going on. So let me back it up for a second so I can explain to people what conditions are. So Kubernetes, we think of Kubernetes as YAML and in a typical object in Kubernetes, you are going to have your type meta data. What is this, you are going to have your object meta data, what’s name this and then you are going to have a spec, how is this thing configured and then you are going to have a status and the status generally will say, “Well what is the status of this object? Is it deployment? How many references out? If it is a pod, am I ready to go?" But there is also this concept and status called conditions, which are a list of things that say how your thing, how your object is working. And right now, Kubernetes uses them in two ways, they use them in the negative way and the positive way. I think we are actually going to figure out which one we want to use and we are going to see more API’s just say conditions. And now from a UI developer, from my point of view, now I can just say, “I don’t really care what your optic is. You are going to give me conditions in a format that I know and I can just basically report on those in the status and I can tell you if the thing is working or not.” That is going to come too. And that will be neat because that means that we get basically, we can start building UI’s for free because we just have to learn the pattern. [0:33:52.2] CC: Can you talk a little bit more about conditions? Because this is not something I hear frequently and that I might know but then not know what you are talking about by this name. [0:34:01.1] BL: Oh yeah, I will give you the most popular one. So everything in Kubernetes is an object and that even means that the nodes that your workloads run on, are objects. If you run KubeControl, KubeCuddle, Kube whatever, git nodes, it will show you all the nodes in your cluster if you have permission to see that and if you do KubeCTL, gitnode, node name and then you actually have the YAML output what you will see in the bottom is an object called 'conditions'. And inside of there it will be something like is there sufficient memory, is the node – I actually don’t remember all of them but really what it is, they’re line items that say how this particular object is working. So do I have enough memory? Do I have enough storage? Am I out of actual pods that can be launched on me and what conditions are? It is basically saying, “Hey Brian, what is the weather outside?” I could say it's nice. Or I could be like, “Well, it’s 75 degrees, the wind is light but variable. It is not humid and these are what the conditions are.” They allow the object to specify things about itself that might be useful to someone who is consuming it. [0:35:11.1] CC: All right that was useful. I am actually trying to bring one up here. I never paid attention to that. [0:35:18.6] BL: Yeah and you will see it. So the two ones that are most common right now, there is some competition going on in Kubernetes architecture, trying to figure out how they are going to standardize on this but with pods and nodes you will see conditions on there and those are just telling you what is going on but the problem is that a condition is a type, a message, a status and something else but the problem is that the status can be true of false — oh and a reason, the status can be true or false but sometimes the type is a negative type where it would be like “node not ready”. And then it will say false because it is. And now whenever you’re inspecting that with automated code, you really want the positive condition to be true and the negative condition to be false and this is something that the K-native community is really working on now. They have the whole facility of this thing called duck typing. Which they can actually now pattern-match inside of optics to find all of these neat things. It is actually pretty intriguing. [0:36:19.5] CC: All right, it is interesting because I very much status is everything for objects and that is very much a part of my work flow. But I never noticed that there was some of the objects had conditions. I never noticed that and just a plug, we are very much going to have the K-native folks here to talk about duck typing. I am really excited about that. [0:36:39.9] BL: Yeah, they’re on my team. They’ll be happy to come. [0:36:42.2] CC: Oh yes, they are awesome. [0:36:44.5] JR: So I was thinking maybe we could wrap this conversation up and I think we have acknowledged that “Should I Kubernetes?” is a ridiculously hard question for us to answer for you and we should clearly not be the ones answering it for you but I was wondering if we could give some thoughts around — for the Podlet listener who is sitting at their desk right now thinking like, “Is now the right time for my organization to bring this in?” And I will start with some thought and then open it all up to you. So one common thing I think that I run into a lot is you know your current state and you know your desired state to steal a Kubernetes concept for a moment. And the desired state might be more decoupled services that are more scalable and so on and I think oftentimes at orgs we get a little bit too obsessed with the desired state that we forget about how far the gap is between the current state and the desired state. So as an example, you know maybe your shop’s biggest issue is the primary revenue generating application is a massive dot-net framework monolith, which isn’t exactly that easy to just port over into Kubernetes, right? So if a lot of your friction right now is teams collaborating on this tool, updating this tool, scaling this tool, maybe before even thinking about Kubernetes, being honest with the fact that a lot of value can be derived right now from some amount of application architecture changes. Or even sorry to use a buzzword but some amount of modernization of aspects of that application before you even get to the part of introducing Kubernetes. So that is one common one that I run into with orgs. What are some other kind of suggestion you have for people who are thinking about, “Is it the right time to introduce Kube?” [0:38:28.0] BL: So here is my thought, if you work for a small startup and you’re working on shipping value and you have no Kubernetes experience and staff and you don’t want to use for some reason you don’t want to use the cloud, you know go figure out your other problems then come back. But if you are an enterprise and especially if you work in a central enterprise group and you are thinking about “modernization”, I actually do suggest that you look at Kubernetes and here is the reason why. My guess is that if you’re a business of a certain size, you run VMware in your data center. I am just guessing that because I haven’t been to a company that doesn’t. Because we learned a long time ago that using virtual machines in many cases is way more efficient than just running hardware because what happens is we can’t use our compute capacity. So if you are working for a big company or even like a medium sized company, I don’t think – I am not telling you to run for it but I am telling you to at least have someone go look at it and investigate if this could ultimately be something that could make your stack easier to run. [0:39:31.7] DC: I think I am going to take the kind of the operations perspective. I think if you are in the business of coming up with a way to deploy applications on the servers and you are looking at trying to handle the lifecycle of that and you’re pretty fed up with the tooling that is out there and things like Puppet and Chef and tooling like that and you are looking to try and understand is there something in Kubernetes for me? Is there some model that could help me improve the way that I actually handle a lifecycle of those applications, be they databases or monoliths or compostable services? Any which way you want to look at it like are there tools there that can be expressed. Is the API expressive enough to help me solve some of those problems? In my opinion the answer is yes. I look at things like DaemonSet and the things like scheduling [inaudible] that are exposed by Kubernetes. And there is actually quite a lot of power there, quite a lot of capability in just the traditional model of how do I get this set of applications onto that set of servers or some subset they’re in. So I think it is worth evaluating if that is the place you’re in as an organization and if you are looking at fleets of equipment and trying to handle that magical recipe of multiple applications and dependencies and stuff. See what is the water is like on this side, it is not so bad. [0:40:43.1] CC: Yes, I don’t think there is a way to answer this question. It is Kubernetes for me without actually trying it, giving it a try yourself like really running something of maybe low risk. We can read blogposts to the end of the world but until you actually do it and explore the boundaries is what I would say, try to learn what else can you do that maybe you don’t even need but maybe might become useful once you know you can use. Yeah and another thing is maybe if you are a shop that has one or two apps and you don’t need full blown, everything that Kubernetes has to offer and there is a much more scaled down tool that will help you deploy and run your apps, that’s fine. But if you have more, a certain number, I don’t know what that number would be but multiple apps and multiple services just think about having that uniformity across everything. Because for example, I’ve worked in shops where the QA machines were taking care by a group of dev ops people and the production machines, oh my god they were taken care by other groups and now the different group of people and the two sides of these groups used were different and I as a developer, I had to know everything, you know? How to deploy here, how to deploy there and I had to have my little notes and recipes because whenever I did it – First of all I wasn’t doing that multiple times a day. I had to read through the notes to know what to do. I mean just imagine if it was one platform that I was deploying to with the CLI comments there, it is very easy to use like Kubernetes has, gives us with Kubes ETL. You know you have to think outside of the box. Think about these other operations that you have that people in your company are going to have to do. How is this going to be taught in the future? Having someone who knows your stack because your stack is the same that people in your industry are also using. I think about all of these things not just – I think people have to take it across the entire set of problems. [0:43:01.3] BL: I wanted to mention one more thing and this is we are producing lots of content here with The Podlets and with our coworkers. So I want to actually give a shout out to the TGIK. We want to know what you can do in Kubernetes and you want to have your imagination expanded a little bit. Every Friday we make a new video and actually funny enough, three fourths of the people on this call have actually done this. Where, on Friday, we pick a topic and we go in and it might be something that would be interesting to you or it might not and we are all over the place. We are not just doing applications but we are applications low level, mapping applications on Kubernetes, new things that just came out. We have been doing this for a 101 episodes now. Wow. So you can go look at that if you need some examples of what things you could do on Kubernetes. [0:43:51.4] CC: I am so glad to tgik.io maybe somebody, an English speaker should repeat that because of my accent but let me just say I am so glad you mentioned that Brian because I was sitting here as we are talking and thinking there should be a catalog of used cases of what Kubernetes can do not just like the rice and beans but a lot of different used cases, maybe things that are unique that people don’t think about to use because they haven’t run into that need yet. But they could use it as a pause, okay that would enable me to do these thing that I didn’t even think about. That is such a great catalog of used cases. It is probably the best resource. Somebody say the website again? Duffy what is it? [0:44:38.0] DC: tgik.io and it is every Friday at 1 PM Pacific. [0:44:43.2] CC: And it is live. It’s live and it’s recorded, so it is uploaded to the VMware Cloud Native YouTube and everything is going to be on the show notes too. [0:44:52.4] DC: It’s neat, you can come ask us questions there is a live chat inside of that and you can use that live chat. You can ask us questions. You can give us ideas, all kinds of crazy things just like you can with The Podlets. If you have an idea for an episode or something that you want us to cover or if you have something that you are interested in, you can go to thepodlets.io that will link you to our GitHub pages where you can actually open an issue about things you’d love to hear more about. [0:45:15.0] JR: Awesome and then maybe on that note, Podlets, is there anything else you all would like to add on “Should I Kubernetes?” or do you think we’ve – [0:45:22.3] BL: As best as our bias will allow it I would say. [0:45:27.5] JR: As best as we can. [0:45:27.9] CC: We could go another hour. [0:45:29.9] JR: It’s true. [0:45:30.8] CC: Maybe we’ll have “Should I Kubernetes?” Part 2. [0:45:34.9] JR: All right everyone, well that wraps it up for at least Part 1 of “Should I Kubernetes?” and we appreciate you listening. Thanks so much. Be sure to check out the show notes as Duffy mentioned for some of the articles we read preparing for this episode and TGIK links and all that good stuff. So again, I am Josh Russo signing out, with us also Carlisia Campos. [0:45:55.8] CC: Bye everybody, it was great to be here. [0:45:57.7] JR: Duffy Coolie. [0:45:58.5] DC: Thanks you all. [0:45:59.5] JR: And Brian Lyles. [0:46:00.6] BL: Until next time. [0:46:02.1] JR: Bye. [END OF EPISODE] [0:46:03.5] ANNOUNCER: Thank you for listening to The Podlets Cloud Native Podcast. Find us on Twitter at https://twitter.com/ThePodlets and on the http://thepodlets.io/ website, where you'll find transcripts and show notes. We'll be back next week. Stay tuned by subscribing. [END]See omnystudio.com/listener for privacy information.

Microsoft Visual Studio Code - https://code.visualstudio.com/Live Share Extension - https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare-packPatrick Chanezon - https://twitter.com/chanezonEpisode TranscriptionWelcome back to The Byte, just made it back from San Francisco, struggling with a little jet lag. I'm sure everyone understands this. In this episode, we're going to talk about Microsoft Visual Studio Live Share. Live Share is a code collaboration tool which allows us to invite people to Microsoft Visual Studio Code, to actually review our code, actually interact with the code. So we can actually see multiple different cursors moving, and we can invite people to our server, we can share our terminals. I mean we can really do a lot of information. We can do a lot of collaboration with this.Now typically people use screen sharing, or talk over the phone, or sending screenshots, and I find Visual Studio Live Share is actually much more collaborative. Because you can actually spawn a call within Live Share. So you can actually have a Skype call going, while you're doing Live Share, and you can actually do live debugging, you can do a collaboration, you can do actually code review. And I quite like it, personally, for doing training. Teaching people how to use something remotely. They can log in, they can see the link, they can actually interact with the code, they can see what I'm doing, how I'm executing things. So it brings a whole new use case to collaboration with editors.Now Live Share is just an extension within Microsoft Visual Studio Code. And you install it like any other extension, you go to extensions, search for Live Share, install it. And you have to connect it to some sort of authentication provider. So I connected mine to GitHub, it's owned by Microsoft anyway, so no problem. And from there, you can then collaborate with people. It installs an additional extension, and then at the bottom of the screen, you see your name usually, your GitHub name. And in here, you can invite others with a link, you can share terminals, you can share servers, and you can stop the collaborations sessions. And you see like little icon next to it, it's like a team icon. And you see how many people are actually viewing your code simultaneously.Now once you have it up and running, I mean it's quite cool, because you can invite somebody in. And they see your code, and you can see everyone's cursor, where everyone's working, you can see the debugging. And I find it quite helpful. I've used it a couple of times where people say, "Oh no, you know this docker composed file or whatever is not running." And we start up a session, I look at it, and like okay, walk me through exactly what you're doing, let me see. And you can identify right away what's going on. And you can actually interact with it, and jump in the terminal, and they see exactly what you're typing, etc. So it actually is a great learning tool. I find it's a great learning tool.Now some of the common use cases, which people say they're using Live Share for is often you see quick assistance. I'm having an error, can you help me? Office hours, I want to demo my project, how about like mob programming, like pair programming, coding competitions, hackathons, school group projects, developer streaming, then interactive education. And I find interactive education is probably the best use case for the Live Share because I see it as really a learning tool. And I'll give you an example, at DockerCon, Patrick Chanezon actually did his session with Live Share. And he invited someone from I to think the UK, and DockerCon was in San Francisco. He called them up with Skype and said, "Hey, we're going to do this really quick." They interacted with Live Share, they were doing actually Kubectl commands, via Live Share, sharing the terminal. And it was really amazing. I mean this is the first time I've seen it in a conference, someone actually doing collaborative editing with the editor. So it was really nice.Other use cases, code reviews, and technical interviews. Maybe someone wants to show you what they're working on and walk you through the code and how it works, which is also quite interesting. Then you can share it with multiple people, you don't have to be in the same room. Especially since we're getting into more of a remote type of context. More people are working remotely. This is really helpful to see the code and understand what their thought process is when they're looking at the code. Because someone just sends you a GitHub link, that's great. But when someone can walk you through the code, interactively, and highlight the different sections, this changes the whole aspect of how the code lives, an how it communicates different people.So I'm using it quite often and I'm going to use it more for my training sessions. I'm going to kick out some workshops, and I'm going to actually do everything through Microsoft Live Share. So people can actually interact, they can see exactly what's going on, then they can try it on their terminals to see what's going on as well. So it's learning by doing a type of thing, but it's very easy to identify exactly what I'm doing, what step I'm in, and it's clear. I actually find it a little bit easier than attending workshops, because you see the code, you see how I'm typing, you see how I'm interacting.The only limitation I find is you definitely need two screens. So you can work on one screen and view the other screen. Now I'm going to start using this more and more, I've used it a couple of times already. I see tons and tons of use cases for it. I highly encourage everyone to go check it out. I mean just go to Microsoft Visual Studio Code, install Live Share, connect it to GitHub. And then within the Live Share client, I mean right when you click your name, you can just copy the link, drop it into Slack, you can email it to anyone. And once this other person clicks this link, they connect to your session. It is that easy. And then you can do Skype calls, or you can do Hangouts, however, you want to talk. So you can have a call going while you're doing the live share.Give it a try, I mean it's very, very helpful. You can see a ton of use cases out of it. I mean to try it out, give me some feedback. Let me know what you think of it, like I said, in DockerCon they demoed it, they demoed part of the session using it. So I can see more and more use cases coming along. And I can see this type of collaborative workshops, code reviews, and just collaboration on projects generally should increase. So we're getting away from screen sharing, we're actually all using the same terminal, same code base, and view exactly what's going on at the same time like we're all sitting in the same room.Well, that's all for this episode, Microsoft Visual Studio Live Share, give it a try. Have a great day and we will see you next time.