Andy: 0:00

Kubernetes is not secure or configured perfectly by default. I can get something running in Kubernetes very quickly and the defaults are not any of those things. They're not secure, they're not efficient, they're not necessarily reliable, and what policy can do is turn your Kubernetes environment into something that is secure, reliable and efficient by default.

William: 0:41

Welcome to another episode of the Cloud Gambit podcast, where we weave complex narratives of technology into captivating stories with captivating guests. I'm your host, William, and with me my co-host, the Shakespeare of servers, the Jane Austen of analytics, the Hemingway of cloud native, Yvonne Sharp. How is the plot unfolding for you today, on this beautiful Friday?

Eyvonne: 1:05

It has been a week full of drama in my world. Just kids and extracurriculars and unexpected school closings and all kinds of fun in our world. So we are enduring.

William: 1:21

I continue to do a lot of driving every day, driving kids around to everything, which spend a lot of time in the car. So, other than that, nothing new. On my side With us today, though, we have Andy Suderman, cto at Fairwinds. Welcome to the podcast, andy. How are you doing? I'm doing well. Thanks for having me. Yeah, so for those who may not be familiar with your work, could you tell us a little bit about what you do day to day?

Andy: 1:49

Yeah, so Fairwinds is a managed Kubernetes as a service provider. So we build on top of major cloud provider Kubernetes implementations and provide stable platforms for people to run their applications. Top of that, we build software, we have open source, do a lot of things. We've been in the cloud native space for about eight years now, so just shy of the full time that Kubernetes has been around.

William: 2:18

Right on. So how did you start out in technology in general? None of us started out in Kubernetes, that's for sure.

Andy: 2:24

Well, actually some of us have, because now we're getting the newer generation of folks. I've hired a few folks that say I've never done anything but Kubernetes and it just continues to blow my mind when that happens and I feel old. So I got my start very young. My dad worked in IT and he brought a couple old computers home I think we were running. We had a start. The computers would boot up in Windows like 3.1, and then we'd have to like start the UI for Windows 95. Like it was this weird setup, but anyway we built a network in our house using the IPX protocol not even TCP, ip to play StarCraft. So my intro into technology was playing StarCraft across an IPX network.

William: 3:11

That's awesome, that's the coolest and best way to learn, because then you have this. It's just awesome. It's like an awesome science experiment, like why you're having a lot of fun.

Andy: 3:23

Yeah, yeah, so that was me having a lot of fun, yeah yeah. So that was me at a very young age and then just kind of kept that love all the way through. You know, I worked in like the computer lab in high school and then I went to college for mechanical engineering, which is completely out of the realm of computers Not completely, but mostly and when I got out of school I realized there were a lot more jobs in software and technology than there were in mechanical engineering and I was still pretty good at software and mostly operations type things. So I've always been on the ops side. I worked for a little firm doing IT for them for a little while and then dove fully into the software world.

Eyvonne: 4:02

And can we just pause for a minute and appreciate the value of working for a small IT services firm early in career? I did that as well and you get exposed to such a broad gambit part of the pun of problems and you get to understand users and their challenges and I just think it's a great way to start for anybody who wants to work in technology.

William: 4:34

Yeah, I would agree. The larger the company, the larger. The more teams you have, the more you get into a focus area. But the smaller you are, the more you get touched. You get your hands in multiple cookie jars and you get a really wide range of experience and then you can actually figure out what it is that you want to specialize in.

Andy: 4:52

You can really narrow that down, yeah definitely, at the time I was responsible for everything from desktop support to printers, to servers, and so I really I did get to see all of it.

William: 5:06

Yeah, so how did that translate into you specializing in Kubernetes specifically?

Andy: 5:12

That's a good question. So I went to work for a company in Denver called ReadyTalk they used to build web conferencing software so I got hired as a sysadmin there maintaining servers in a data center as much by hand as with automation. So I got hired as a sysadmin there maintaining servers in a data center as much by hand as with automation so about 50% PUP at 50% SSH and learned a lot really fast about managing larger environments and working with developers directly and hosting actual software instead of just running internal IT for a company. And during that time we were acquired and we had a team of about 11 people. It was like two sysadmins, like two estates, two or three application infrastructure engineers all the different titles we had back then and all kind of working towards the same goal of deploying and automating, deploying the software. And the company that purchased us did a massive layoff and so we went from a team of 11 to a team of five. And so then I started to realize we have to learn this like DevOps thing, right, to realize we have to learn this like devops thing, right? Um, like how do, how do we do more automation but also push more back towards the developer so that they can be more self-service, and so that was my first foray into like devops, and about that time I was introduced to kubernetes. Um.

Andy: 6:39

So we, uh, being in denver, I was able to go to the Boulder Kubernetes meetup at the old Deus office and Chris Nova gave a presentation on COPs, or KOPs as you can, as a lot of folks say. So I saw that demo and I was like we need this technology. It can do all of the things that we've been struggling to do in the data center We've been struggling to get working, you know, high availability, automatic failover, automatic scaling that we've been attempting to do with this. Like we had this awful homegrown Zen VM set up that we all hated, and anyway, I just saw it and it blew my mind and I was like we have to do this, and that was probably about eight, nine, eight years ago or so, so right in the early days, and just kind of went all in from there, brought it back to the team. The team was all in, started building things on Kubernetes, did that for another year or so, and then that's when I moved over to ReactOps.

William: 7:42

That's awesome, awesome. Yeah, I've had. So I think you mentioned earlier that fairwinds. Did you say that you all really focused on the cloud native provided? Uh, cube services like the eks is and aks is a little world, is that right?

Andy: 7:58

yeah, we do now. Obviously we got our start before eks existed, before eks, so we did other things back then, but nowadays that's our focus.

William: 8:08

Right on. Yeah, I have some experience with those. Well, at least the top three, the AWS, azure and GCP Less Azure, I guess, and more EKS and GKE. But one thing that still stands out in my mind when I was in the enterprise and that was day-to-day life was like oh, this is not easy stuff, like I remember in the beginning days I wanted to like pull my hair out a lot. Um, there was, and there's, a great amount of like technical complexity.

William: 8:33

But a lot of times, if you have the right engineering and you can make the right hires and build the right talent, technical complexity, you can really work through that. But with Kubernetes and even even the cloud managed services, it's, it's a it's a different way of doing so many different things. There's like organizational hurdles, like there's a lot of strategic considerations, especially if you're not Greenfield, like you're not building something new, but you're transitioning, like maybe you're migrating, transitioning data center applications to Kubernetes and Cloud Native. Do you have any, or can you talk about some of the challenges you see with this when adopting Kubernetes even today?

Andy: 9:19

Yeah, definitely, definitely. So you know, going back to my roots at this web conferencing company, obviously we ran everything in the data center. We wanted to use Kubernetes and really the only way to get started was to find something Greenfield. So the company that acquired us was looking to build this particular piece of the stack and it needed to be more regionally located to the users, to be more regionally located to the users, and so this was my opportunity to say hey, maybe Kubernetes is the right choice here because we can deploy quickly, we can update easily across all these various regions that we need to deploy to, and so we built out this brand new project in Kubernetes. But then explaining that, evangelizing that within the company and getting the folks that had been working on this similar technology it's like SIP based you know web audio technology that's been around for 30 years Trying to convince these engineers that have been doing this on you know bare metal for 20 years that we should deploy to Kubernetes is a hurdle.

Andy: 10:25

And it's not a technology problem, in my opinion, it's a people problem, it's a culture problem. You have to be able to sell the idea. You have to be able to bring people around you and get them behind it and build kind of this groundswell movement from the bottom up, at least within that company. That worked. But that's really, it's overcoming fear and uncertainty. It's similar to the move to the cloud, move to Kubernetes.

Eyvonne: 10:53

People are just scared of it, and so getting them to not be scared, I would love to hear more if there were specific either talk tracks or conversations that stand out in your mind that helped move those folks toward a new technology stack, because I find that often that's the greatest hurdle to overcome is getting enough of the organization on board with the potential to actually make the change real. It's not so much the technology, like you said, so I'd love to hear more about specifically what helped to make that transition.

Andy: 11:34

Yeah, I don't know that we ever successfully made it at that company. So I can jump further into my history over the last six or so years of working with you know small to large companies in deploying their Kubernetes and it's a much broader experience because we are managed service providers. And I think really you know it depends on your audience when you're talking to the highly technical folks, you're talking to your you know staff engineers, principal engineers or even your senior engineers about why we should switch technologies, really showing the technological benefits. How, like, really for me, like talking about just going back to the data center days we would spend a month every year rotating certificates. Right, we would get a new cert, right, we'd get it issued via the cert provider and it would take us literally like a month to like copy the cert out to all of these servers and restart all the Java, like all the Tomcats, and get them to pick up this new cert.

Eyvonne: 12:34

And so I just saw some PTSD flash through William's eyes. He left us there for a minute and went to another place.

William: 12:45

Yeah, definitely some PTSD in multiple scenarios there. I understand that pain yeah, yeah.

Andy: 12:50

So then you know you build a poc, you spent you spin up cert manager, right, you get it to pull in a cert and you show them how, all of a sudden, we've just taken a month of effort off of our plate for the next year, right, and that you know it might take us a month to migrate all of our stuff to use CertManager, but that's forever. Now we're done. Now we can focus on other things that are more important to us. Those technical demos and those proofs of concept of these are the places where we have pain. This is how we solve that with this. New technology is a huge help with the technical folks with.

William: 13:28

You know any new, new technology that's getting adopted, even if it's even if it's new for you but it's, you know, not new for the rest of the world. You know you tend to step on a few landmines, here and there it happens. Have you seen just top-of-mind mistakes I guess common mistakes that organizations can make when they go hardcore into Kubernetes when they don't have experience there prior.

Andy: 14:02

Yes, I love talking to those people because they make great customers. Um, so some of the things that we see, you know there's two sides of it. There's one, which is very prevalent today, which is massive over provisioning right. They haven't thought about the containerized world. They've taken the settings from their old vms or even their laptops and just applied it you know, resource request limits to their pods and now they just have this massive cloud environment. It's just running away on. That's super common. You hear that story all the time these days. Um, but some of the more interesting ones are folks not understanding some of the underlying complexities of things like probes and auto scaling, and so they've gotten themselves into a state where they're just like sitting there manually scaling a deployment up and down, like every morning somebody will run a kubectl command and scale up, you know, like a deployment.

Andy: 15:00

We're seeing less and less of this these days. This is a lot of. This was more in the early days. Another fun one that I heard one company that we talked to decided to. They wanted to only run one cluster, so they had this like 800, 900 node cluster that was dev stage test prod all in one cluster and they'd written this massive internal tool to deploy to this cluster and they realized eventually that they'd gotten themselves into a hole, like they could not update anything without downtime and prod, like they had massive issues and they were stuck in this tech debt hole because this massive internal tool that they'd written to do their deployments couldn't deploy to multiple clusters. So they could spin up more clusters and they could put stuff in them, but they couldn't actually deploy their app to it and they had like a six month backlog of stuff to fix to get to multiple clusters. And it was just like that. I feel for y'all, like that's tough.

Eyvonne: 16:01

Well, it's the kubernetes. Monolith right so you're? You're taking two different paradigms and trying to munch them together, and then neither of them work right.

William: 16:13

That is such a good one that you point out though that is actually one of my worst experiences with doing this, and not even if you take that monolithic cluster approach and you don't even separate it out per environment. You can't even differentiate between like prod and non-prod. That feeds into like all sorts of funny, like security compliance, just different things that you want to avoid at all costs. But it brings up a good question, because when I was working for an organization, at one point where Kubernetes was new to us, we had some very. It was at the point in the journey of cloud where developers had a lot of power. They had all the power and they also had a lot of budget, so they were pushing for each.

William: 16:59

It just feels funny saying this now, but each development team was basically getting their own EKS cluster. So when you say over provisioning, we were like over provisioned on steroids and we had to rope that sucker back in after a year of blowing out spend. It was. It was quite challenging. So I guess my question is you know there is no one size fits all, I understand that, but do you have any like guidelines or recommendations or things you've seen as far as like? Like we had maybe an MVP. We got our vehicle product here. When is it time, like what are some impending events or things to tell us that we need a new cluster in an environment?

Andy: 17:42

interesting, interesting, I mean for the majority of folks that we work with, one prod, one non-prod is enough. But there are things. There are some clients, like I mean most of the companies that we work with, they're medium to large. Some of the larger ones will have, you know, multiple production clusters. But the medium-sized companies have not reached a scale where one cluster can't cut it for prod, where you start to run into other scenarios DR, data locality, right.

Andy: 18:13

You have business reasons that require you to have another production cluster or another stack in another place. You know there's also some specific technological requirements. Like I talked about earlier. We worked with a gaming company. You want to have your game servers as close to your end users, to your players, as possible, and so we were running many clusters in many regions and so lots of different topologies there. But then if you've gotten to a sophisticated enough point where you can switch back and forth between clusters, maybe you don't need another one. But maybe blue green kubernetes upgrades is in the cards for you because you have the ability to actually route traffic. Move to another cluster, your data, you've solved your data locality problem and that's where I think folks can really benefit from multiple production clusters.

William: 19:09

Right, okay, yeah, that makes a lot of sense and I don't know if this is a good question or not, but it just popped in my head. I don't mean to put you on the spot, but I think there's a lot of fans out there for each of the cloud providers, kubernetes, services, and I've worked in all three. But I tend to be partial to EKS just because it's where I have more experience. But I do know that when I set up GKE, it seemed much easier. The whole process of onboarding and operationalizing everything within the company I was working for at the time, across a few teams. It was pretty substantial. It was much easier, much less work involved than EKS. So do you have any experiences with kind of like what's easier or a company would use one over the other? I don't know if this is a good question or not, but I'm curious.

Andy: 20:05

In the beginning we only worked with AWS and GKE, with a brief stint with Oli Cloud. I won't talk about that. But so on AWS we were running COPS and then in Google we were running GKE, because EKS didn't exist yet, and I will say I think this still continues to this day. If you want the newest, most cutting edge stuff and features of Kubernetes and you want to upgrade quickly and you want to use all of the newer APIs as they come out, even in beta in some cases, gke is the place to be, because there's still a large chunk of Kubernetes development being done within Google for GKE and for their customers. In fact, one of our old employees, a good friend of mine, rob Scott, works at Google on the Gateway API and that's going to get implemented fully in GKE long before it does anywhere else, unless you're using something else open source that you're adding onto your cluster. So it's less work to get to those things GKE does and can make things a lot easier really quickly. I agree I think a lot of folks default to AWS because they're comfortable with it and EKS has become a very good product.

Andy: 21:28

It did not start out that way. In the early days it was a little rough around the edges, but nowadays we use it to great success and very well. So the other thing I think about a lot is networking. Between the two, google networking and AWS networking are very, very different and if you want to learn like truly cloud native networking and do some really interesting stuff that may feel like magic at sometimes, gcp is awesome right. You can do some cool stuff over there that you just can't do in AWS right now. So I don't know, I kind of feel like you just generally that kind of cutting edge, newer, truly cloud native experience in Google versus the. You know I still have, you know, worked in a data center. I know like all the data center networking and how to build a data center. Aws is going to be the closest analog to that in the cloud and it will feel very comfortable to you.

William: 22:29

Yeah, I can definitely salute that because AWS is just. It's so hierarchical with the way that you build and nest resources, especially with networking, like you're locked in, subnets are in scope. At the availability zone level You're really rigid on okay, this is a regional construct, this is an availability zone construct, but Google sort of like blurs those lines and makes stuff happen under the hood and things just happen to work and you don't have to think about as many of those things on the network side, which is easy, easy sometimes, but then when you want to get in and dig into some details for certain reasons, it can be a little more challenging.

Andy: 23:07

Absolutely yeah. If you want a pod in one cluster to talk directly to another pod in another cluster in a completely different region, use GCP, because that's going to be a nightmare in AWS, but GCP will do it out of the box if you click the right button.

William: 23:24

Yvonne loves to hear this.

Eyvonne: 23:26

I do.

William: 23:27

The GCP hype machine.

Eyvonne: 23:29

Do I speak up or do I just let them keep going? No, yeah, we love the flexibility of GCP networking, global VPCs, all that good stuff. We stitch stuff together under the hood in ways that other folks don't. It's an engineering first mindset, you know from the place where Kubernetes was born. So we just have some technology legs up there, especially in this space.

Andy: 23:56

So yeah, as a business leader, I have to like raise an eyebrow on occasion at Google right, because they are a little riskier from like hey, is this product going to exist in 12 months, kind of thing. But I don't think GKE is going anywhere, so I'm pretty safe with GKE.

Eyvonne: 24:13

Yeah, like the GCP network and GKE are foundational solutions and we've got bigger problems if those things go away. Right?

William: 24:23

Yeah, I remember going through some of those talks when we adopted GCP at a in an organization and I think one of the things we and you know sort of came to the conclusion of is yeah, I mean, some products are going to go away. But if you look at, like, what Google's core business model is, if you look at the ads, you know the ad business and you know look at the cloud computing business and how it's grown and like the amount of investment they've put in, I mean I think I could be totally wrong, but I think that's a huge part of the future and that means, like the core services of their, their cloud offering, the standard stuff like vp, subnet, some of the platform as a service, databases, banner, all those things, and then GKE like the things that everybody's using that are pretty core to running GCP are probably going to be around for the long haul.

Eyvonne: 25:18

Well, and we can't go a podcast without mentioning AI, right. So the ability to run AI infrastructure and attach that to your you know Kubernetes environment to be able to do inference or whatever. Like all that's there too. So yeah, I couldn't help myself, sorry.

William: 25:39

Yeah, it's a feature, it's not a product, it's a feature, it's not a product.

William: 25:50

Yes, yes, I love it. So you're co-chair of the Kubernetes Policy Working Group, a part of the CNCF. Yvonne and I have actually been really interested in just sort of the work that the CNCF and the Linux Foundation has been doing, especially with a lot of the licensing changes like new products I love, like I love OpenToku and I still use and love Terraform. But just seeing kind of how the CNCF is helping out and really like instead of I'm going to tread carefully here but I guess instead of dividing community, just bringing community together, it's pretty awesome. But can you tell us a little bit about what this group that you co-chair focuses on? Yeah, for sure.

Andy: 26:40

So the group was started primarily by Jim Buguadia from Nirmata, who's the creators of Kiberno. We have an open source policy engine. Kiberno is also an open source policy engine. I have to give them kudos because they built a really great product and the.

Andy: 26:59

You know they looked around kind of a CNCF landscape and realized there was no group sort of talking about how to implement and use policy in Kubernetes. Right, because really you know, in the whole of technology, kubernetes is a relatively immature technology that's changing obviously rapidly. But you know, you compare it to other things that have been around for 30 years. It's relatively new. And so policy was when this started probably I don't know when the actual startup was. It's probably like four, three, four years ago. Policy was brand new on the scene.

Andy: 27:33

Opa had been around for a little while but OPA or OPA, nobody had been really using it, nobody wanted to write Rego. And so they said you know, we kind of we want to get this group together to talk about, to give advice to the community, to put out information about the best ways to implement and use policy, why you should implement and use policy and things like that. So that's been really our charter. I can't speak it from memory, unfortunately, but it's probably not a good thing as a co-chair, but we spend a lot of time just working with the community, putting out white papers, talking to folks about their policy implementations, how that ties into governance, risk compliance and really trying to be tool agnostic and talk about the how and the why of policy as a whole.

William: 28:28

That's great. Why so like? Just for the audience that's not as familiar with like policy management with Kubernetes. Why is policy management so daggone important in Kubernetes in the first place?

Andy: 28:41

I mean there's a lot of reasons, but I think the primary one that I like to talk about because I think it hits home for most engineers is at least most ops engineers is that Kubernetes is not secure or configured perfectly by default. I can get something running in Kubernetes very quickly. Something running in Kubernetes very quickly, it might not scale, it might not bin pack well, it might not be secure right, because I can just throw some stuff at Kubernetes and the defaults are not any of those things. They're not secure, they're not efficient, they're not necessarily reliable. So you really have to know what you're doing to get to that point and what policy can do is turn your Kubernetes environment into something that is secure, reliable and efficient by default, because you're enforcing all of those rules about how you use Kubernetes up front rather than trying to go back and fix them afterwards. So that's kind of the dream of policy for me.

William: 29:44

Love it. Any cool initiatives or projects like in focus with the working group or anything in the future that we get a sneak peek of, or is it just kind of what you already outlined?

Andy: 29:58

I mean, all of our meetings are completely public, so there's nothing hiding in there that I can reveal. I think some of the more interesting things we're working on can reveal. I think some of the more interesting things we're working on. I know Poonam Lamba from I think I said her name right. I apologize if I didn't. I don't know her last name, but from Google is working with the rest of the group a white paper on what they're calling shift down security. So we have shift left security, but we're talking about shifting it down in the stack. So I think that's interesting.

Andy: 30:30

I haven't had a whole lot of time to review it, but it sounds like a very interesting paper. I'm currently working slowly on putting together a policy survey to understand better how folks are using policy right now, because I think we've moved away from the days where nobody knows what policy is, but I think we're still in the time where very few people are actually utilizing it to great effect. And then, on top of that, we have a few members of the working group who are also members of other SIGs and TAGs and things that are working very hard on the compliance angle, and so I know the folks at Defense Unicorns are doing a lot of really cool stuff. I think there's even a new channel for Lula, which is a tool for basically tying your compliance to your policy, because policy enforcement is not compliance, but it can be used to feed compliance, and so they're working on using some actual like automated tools to do compliance and tie it to your policy engine.

Eyvonne: 31:34

Just you know, your friendly PSA Policy enforcement is not compliance, is not security. Yes, those are all very different domains. They do inform and intersect and overlap in some interesting places, but they are distinct and it's important to know and understand those distinctions.

Andy: 31:54

Absolutely. Compliance can never. I've been saying lately, compliance can never create good security, but good security can make compliance easier.

Eyvonne: 32:05

That's right. That's a great way to say it, and you know you can be compliant and follow the process and have a rule created that's permit IP any, any, that would comply with your policies because it was approved by all the right people and implemented according to your standards.

William: 32:26

That is also secure secure I wonder how many times that's been done I've.

William: 32:33

I've sort of stood in the gap and kept it from happening a time or two yeah, and, as andy said, like these meetings are public and also the, the cncf has an amazing slack channel that is anybody can join, as I'm creeping in there all the time looking at stuff. It's great. So if you want to know really what's going on, not just with this working group, but lots of other work that the CNCF is doing, join the Slack channel. Add some of the channels in there, the groups, and just kind of peek around. It's good stuff.

Andy: 33:08

Yeah, both the CNCF Slack and the Kubernetes Slack. The organizational structure is a little bit confusing, but tags are CNCF, sigs are Kubernetes and both of them have working groups Very confusing, but both Slacks are great. Be careful how many channels you add, because it will create a lot of noise.

William: 33:31

yeah, it does the time to wax philosophical? I guess a little bit, but you know, things are always changing in tech. We know that the only the only thing that's consistent is change, and sometimes it's a bit overwhelming. Kubernetes is no stranger to this, as it changes very rapidly. Is Kubernetes sort of going, you know, when you started working in the Kubernetes space and you started learning, is it sort of going in the direction that you thought it would? Do you think that, like, where do you see it headed from here on out? What do you see Kubernetes becoming in the next five years?

Andy: 34:10

I get asked this question so often.

William: 34:13

It's like the unanswerable question.

Andy: 34:15

It is too. It's impossible. I know we do this thing every year, like our marketing folks love putting together like what are your predictions for the next year? And I always my boss at the time is like I hate doing these. It's like I feel like such a charlatan, just like spouting off this, this knowledge that is, you know, we, we have no way, but I do have thoughts, of course. So, like the first question you asked, which is is it going the way that I thought it would from eight years ago? And I think absolutely yes.

Andy: 34:51

It's definitely seeing much more adoption. The cloud providers are all heavily involved with it. A Kubernetes offering right, your DigitalOceans, your Linodes, your Sivos built almost entirely on the idea of having a Kubernetes offering all these cloud providers. So I think that's super cool. The one thing I think is interesting is that adoption has been maybe slower than I had anticipated, I think partly just because of the hype. Early on, we were getting these reports that were saying, like every major corporation is using Kubernetes and I said, well, sure, but it's like five people within the whole organization that are using Kubernetes and the rest of it's all still running on whatever they were running before. That's slowly starting to change, but it's very slow and of course the adoption of any newer technology is going to be slow. There's that to answer your first question. The second answer much harder, but I think we're starting to see echoes of it already.

Andy: 36:00

I think Kubernetes will become sort of the underpinning of a lot of various offerings. So you're seeing more and more offerings built on top of Kubernetes, that sort of abstract away some of the complexities for you. I've been talking to some folks at like North Flank and a couple other places that are building these like developer platforms for deploying your apps that are built entirely on Kubernetes and then maybe have the option to like take over the full management of Kubernetes. And then we're also seeing things like Cloud Run, fargate not necessarily Kubernetes under the hood, but very Kubernetes-like right Knative stuff like that, where containers and some of the concepts from Kubernetes are still ubiquitous, and so I think this way of running infrastructure will remain into the future, whether we actually use raw Kubernetes in five, 10 years, maybe not. Maybe there will come along another ubiquitous abstraction layer, or so you know, some folks will continue to use just pure kubernetes and a lot of folks will use these abstraction layers, but I don't think it's going anywhere totally agree with that one.

William: 37:19

I think it's here to stay so much, especially startup software these days. I don't want to say it's exclusively built on Kubernetes, but I mean I would love, I mean, if there was some numbers out there of startups, like in the past two years, that are building exclusively on Kubernetes. I bet that number is like very high, Just because the distributed nature, distributed scale of you know the outcome.

Andy: 37:45

It would be interesting. I you know I went to. I did a talk at Boulder Startup Week about infrastructure for startups, and I think a lot of the sentiment in the room was people were scared to use Kubernetes because of the complexity, because of the size, and I think the general recommendation that I've seen from experts is don't use Kubernetes. Use something either built on top of Kubernetes or that allows you to move to Kubernetes when you need that complexity and scale. And so I think it would be interesting to see that survey, because I wonder how many people would say, yes, I'm running on Kubernetes or no, I built entirely on Fargate or Cloud Run or you know some other. You know container as a service type thing, but still fully containerized, using some of the concepts that would allow me to utilize Kubernetes down the road.

Eyvonne: 38:37

When it makes sense. If you're a smart startup and your goal is, like time to value, like you've got to get the thing built and out there. Scale is a concern, but it's a secondary concern, absolutely. And so if you can deploy in a serverless platform, get something up and running, do proofs of concepts, be able to start onboarding customers, that's a huge win. But there are scale and flexibility limitations with serverless platforms that anybody's going to hit once they reach a certain size. So it makes sense to deploy initially in a more managed environment and graduate up as your needs dictateated. But I think ultimately, at scale, anybody who's running a significantly complex enough, demanding enough application is going to end up there eventually.

William: 39:37

Absolutely yeah. What I'm hearing is basically like the right solution for the right problem. So don't use a dump truck when you could use a pickup truck or when you're building your startup, just like, okay, don't just jump immediately into a service mesh until you have service mesh problems out there that you need to solve in general, because that adds even more complexity to the scenario.

Andy: 40:07

I'm writing a talk right now called Kubernetes. As a Big Hammer Is Everything a Nail, and it will be exactly about this topic.

William: 40:14

I love that I have something to add to that. We'll be on the lookout. Is it going to be recorded?

Andy: 40:20

It'll be at Kubernetes Community Day in DC, so I'm sure it will be recorded.

William: 40:28

Awesome, right on. I guess we've hit sort of the unless you have anything else. Do you have anything else you want to throw in there? Yvonne, I'm good.

William: 40:37

Awesome. This has been an excellent conversation. I love conversations like this, just talking about the real you know the meat on the bone as far as the technology and digging in and just kind of figuring out what's out there, what's happening, and especially being able to talk to someone that's an expert like yourself. So this has been an awesome, awesome conversation. We really appreciate your time. Where can the audience find you at? Do you have?

Andy: 41:01

any social media, Mostly on LinkedIn. These days I tend to avoid some of the others. I think I have a Mastodon account that I check on occasion. I'm generally SudermanJR SudermanJr just about everywhere, or Andy Suderman, and I'm definitely active in the Kubernetes, the CNCF Slack. We also have a community Slack for our open source at Fairwinds. You can find it on any of our open source repos. Slack is definitely the best way to get a hold of me.

Eyvonne: 41:33

I'm in it 24-7.

Andy: 41:34

it feels like Awesome.

William: 41:38

I'll put all those in the show notes. Thank you so much, thank you.

Andy: 41:42

It's been a pleasure.