 Hi everyone. Thank you for being here. My name is Seth McCombs. I am a software engineer focusing on cloud orchestration and Kubernetes things at workday and in the upstream Kubernetes project have also spent some time on the release teams as well as working as parts of SIG docs and SIG release in the past. Today, I'd like to cover a topic some people may have avoided or have some some preconceptions about I'm going to be talking today about managed Kubernetes services and and by managed I mean using a cloud providers kind of Kubernetes as a service offering Now I won't be diving into specifics around any one cloud providers offering. We're not going to get that technical I'm just covering the overall idea of using a Kubernetes managed Kubernetes service why you may want to consider doing so And in the case of some cloud providers, they may only have you know one sort of Kubernetes offering Some may have different levels of kind of abstraction around their their Kubernetes offering So, you know depending on where you may find your infrastructure running you may have some choices there So the original title for this talk was a little more aggressive than than the one I ended up going with It was something along the lines of using a managed Kubernetes service doesn't make you a bad engineer And while I still believe that statement wholeheartedly I thought it was best to lighten up a little bit before my current role in in past various info related roles I found that even though I wanted Kubernetes to be the only thing I was working on you know to be the focus of my day-to-day That wasn't you know, that wasn't the case Kubernetes was the platform I was deploying on and what really mattered where the services I provided to my end users Whether they were the developers the actual, you know Consumers of the product or service the company made the executives that used some sort of service You know the Kubernetes clusters I ran were just a means to an end And it was in one of these roles that I came to terms with using a managed Kubernetes service And it was a service provided by a cloud provider and I found that by offloading a much of the day-to-day overhead Operational stuff I needed to do to keep clusters running It freed me up to work on some other cool stuff toil less and it was it was definitely something that worked for me So that's it right. I found using a managed Kubernetes service worked for me. The story has a happy ending and we're all done Well, I found sometimes folks at cube cons meet-ups other other similar events When I said something along the lines of you know, I'm using a managed Kubernetes service from my cloud provider I often received one response More than others and that response was why why would I use that instead of running my own? And I always thought why not? I've offloaded a bunch of my operational overhead and toil and TDM to a cloud providers team Their sole purpose is to run this cluster and keep it running and I get to focus on building cool stuff on top of it Why wouldn't I want that? So I learned a lot talking to these folks and you know some some whys and why nots for their decisions to not use these services a lot of valid points And so that's what I'm gonna talk about today. I'm gonna try to dispel some myths around using these services with some experience I've had in the past Maybe leave you with some answers to questions you've had and and also because nothing's perfect I'm definitely gonna touch on some negatives you may encounter with the goal being that by the end of this You have enough context to weigh some options about you know using one of these services Maybe moving off of your current platform that you run yourself Or maybe you're an engineering leader or a team lead looking to Greenfield something on Kubernetes and just getting started And and also I know that many people want to run their own cluster They they have valid reasons They've built their own tools adapted and adopted some upstream or open source things and that's totally fine, too I'm not telling I'm not here to tell you you need to use You know one of these these managed services these Kubernetes as a service kind of platforms I'm only here to say that it is totally okay if you do And and you know don't let people get you down and and make you feel like you're any less deserving of space because you You didn't build it all yourself So these days Kubernetes is the go-to buzzword We're sitting at cubecon right now this Kubernetes thing is big if you're not using it You probably want to use it if you don't use it You probably have a valid reason maybe after looking into it that you don't want to use it These days Kubernetes clusters aren't something you take to the bank if you've moved your service from big monoliths to Containers on top of Kubernetes. That's you know something huge to brag about I've done it It's a there's a lot of work involved But what I mean is it's not a bullet point on your sales pitch You know, I'm talking about if you're providing like a SaaS offering here when someone asks Why should I use your product or service your two points for your sales pitch shouldn't be we're lower cost and we run on Kubernetes What really matters is what your clusters allow you to do less downtime faster iterations on the you know software You're developing and deploying if you can deploy your microservice and you know a fraction of the time versus your monolith You can get to market faster, you know things like that I believe it was a few cube cons back that that Liz Rice said something along the lines of Kubernetes is boring. It's it's what you do with it. That's interesting. And so that's how I've started to approach my use of Kubernetes I'm not looking in my day-to-day to run the most customized state-of-the-art You know amazing clusters. I want all the benefits that Kubernetes can bring me But I don't need the bragging rights of building in it all myself So what what is a managed service? What do I mean when I say that we have a few options under that umbrella and all of them revolve around some fact that Someone does it for you To some this is a positive to others. This is a negative before we land on either side. We can break it down Some providers offer you a managed control plane They handle the API servers the controller scheduler all the associated bits there They give you an API endpoint to run your cube cuddle commands against Leaving it up to you to deploy your virtual machines as you see fit Some sort of template they provide or some automation you've built Others have automated this as well It's one or two clicks to deploy your node pools specify size count networking all that stuff Some are completely automated where you are responsible for building your containers You upload them to their registry and they do all the deployment and scaling for you You know so that kind of moves beyond the Kubernetes as a service and is at one extreme of the end of the spectrum there And then you know I also call out some of the companies and consultants service providers that can help you configure clusters On your existing cloud platform, you know, or one of these managed services You know, they help you avoid a lot of pitfalls for setup Definitely not what I was thinking about what I had in mind when I started this talk about using a purely managed service You know, but I I recognize that a lot of companies are still on Primer in colos and so I think it's valuable to keep those in mind So what do you get when you pick a managed service? one of the biggest things in my experience that I always think of was The peace of mind around somebody else running my at CD cluster You could say that about the whole control plane You know, I will that is it is nice to not have to worry about that, but I first thought purely about at CD I I went through running clusters migrating from from at CD version 2 to version 3 That was some fun. I never I hope to never have to do again I've seen what happens when an at CD cluster gets broken and split brains there You know, you start getting different responses back every other time you run a cube cuddle command It's just it's just not fun I've been using Kubernetes for a few years now. I'm still not an expert in running a control plane or an entire cluster So when I can offload things to other specialists, it's something I'm gonna do And so that's that's one of the biggest points. I start out when I start talking about, you know, using a managed service If my cloud provider has a team of experts that can keep this running and that's just a service I subscribe to it takes some some overhead off my plate. That's huge So next up you have more time to do the other the cool stuff, you know, the building the deploying of things actually on Kubernetes You know, I'm not going to market with hey, here's my service and it runs on Kubernetes unless you sell an application that runs on Kubernetes Normally your end users don't care about that. They want your service to be up working Responsive scalable low-cost insert buzzword here. They want all those things. They want new features faster And and you know what really matters is what you build on top of your cluster If we truly talk about Kubernetes as a as a platform that you know democratizes these containers we can deploy anywhere Why wouldn't I let someone else whose sole purpose is to run Kubernetes clusters do it for me? You know, I view it in the similar vein to picking frameworks for coding and things like that, you know Let somebody else simplify it for me and I can do the you know the easy parts So next up, you know, Kubernetes is complex if you ask an engineer that's been using Kubernetes for a few years What's one thing you wish you could change a lot of times? It's it's some form of make it less complex Oftentimes, you know when getting started, but you know just overall I'm all about a couple click process to deploy a new cluster Scaling some people don't have to worry about their API servers handling a surge of requests or ensuring they have sufficient worker nodes If you do have those worries, you know using these managed services can take that off at your plate, you know and just Make it easier for you. I again, I want to keep working on what I'm building There's a great run of security talks at kubecon and you know current and in the past and One call out call out is often that Kubernetes is rather insecure by default, you know So if I have a trusted advisor that can help me set things up can figure things in a way that secures my work loads Gives me a great starting point you know, I'll take it and And why I'm calling these things out is that these are tasks that can easily take days of work from one or more engineers You know and those story points start to add up and all of a sudden your sprints turn into crawls You know, basically, you don't have to be an expert in all these things No one can know everything and that's not a bad thing By and large these services are less complex than doing it myself Have you ever scrolled through the read me and and the docs for one of the services you would use to deploy a cluster? you know, those things get verbose fast and You know, this is no shade to teams that write these docs and these read means, you know They're doing heroes work But there's only so much you can do to make a you know the configuration of a complex service read is less complex and And the source code for kubernetes. There's a lot there, you know So again, I want to build on top of it and let somebody else specialize in running the platform So next up we've talked about what it is. We've talked about some some pros why I like it, you know Why you may like it using these services and just want to call out a couple common complaints that people would have when I would Tell people I used these these types of services And and I know we're all we're all thinking in this one because we're all conscious of our cloud spends So doesn't it cost more, you know, we're all conscious of our cloud spend And and that costs more than a than a self-managed cluster And I think of it this way, you know Cloud bills don't happen in a vacuum if I just look at the bill for my cloud provider or my service provider I'm going to see, you know, whatever the managed api endpoints for my clusters cost per hour And and that may drive my bill up, but on the other side of things, you know There's still someone whose hands-on keyboards automating and setting up You know my self-managed clusters and things like that. There's still people at those keyboards hacking away on stuff So you may have a team of one person. You may have a team of 20 But either way I'm I'm you know, almost 100 percent certain that that person's not working for free and you pay them to do what they do So you have to think, you know, what are you saving in terms of of spend? Are you spending less on your bill but paying your engineer for more time? You need to figure that out in in my past experience. I found that by, you know, unblocking myself to build cool stuff When I was, you know, a team of one at a mobile app startup By making somebody else have to worry about the I want to run kubernetes kind of thing And get me just get to deploy more things on top of it Not only did I sleep better at night, but I was able to get more stuff done And to me that was worth the the increase in our cloud bill and and thus an argument I was able to take to the actual, you know People that paid that bill and say hey, here's why we need this So with most things around cost and money, it's multifaceted, you know What's the cost of running your own versus a managed service? What is the time your engineers spend on these upgrading recovering? You know, what is their time worth and and how do you break that down? Could they be automating something else? You know deploying a new service scaling to a new region all these things add up and I think it's worth looking into, you know, so One call out don't take this as permission, you know If you are some sort of executive or engineering leader Don't take this as permission to fire your engineering team if you move to a managed kubernetes service That's not what I'm saying I'm saying that unless you need the customizations of managing your own clusters Choosing a managed service allows your engineers to focus on higher level higher priority projects You should not be removing those engineers entirely. They should be building the stuff that matters not just the platform So another another thing around Around around cost that that is a little abstract is is what about the the vendor lock-in that that people think of You know, that was the other thing is I don't want to be stuck on this specific provider's platform And that may be your case and I empathize with that So one of the things that I think about with these managed services You know, if you're on a cloud you've already picked your cloud You're using their service for vms or or managed database service. You're letting them handle networking things like that You're all you're pretty invested. So where do you draw the line? This this may be it This may be, you know, where you say no, I will use their their virtual machines But you know, I will configure kubernetes on top of that. I want to have that level of control Maybe this is maybe the line is somewhere past this and you say no, no, let's use their service, you know And and have them run our Our kubernetes clusters, you know, this is the trust you've made with your provider to handle the physical side of things And and where you draw the line with what you deploy on top is is something you need to figure out You know, so you may find that If you want to move from one cloud provider to another there may be some concessions you need to make But you know, I I've never encountered companies that really change cloud providers overnight It's it's definitely not a decision made lightly And and all these managed services are all kubernetes objects at the end of the day It's deployments and pods and stateful sets and volumes all the way down So, you know, you can take your kubernetes stuff from managed service a and deploy it on managed service b It's just the initial setup that might look a little differently Um Now this is different than using what I called out earlier You know one of those fully managed services where you basically upload your containers and they handle all the other things that Pretty much abstracts away kubernetes And and that that may be your serious vendor lock in but it also might be beneficial depending on the size of your operations teams You know, so It depends on what you're looking for, you know, you're writing your your code You're building your container images. You write your helm charts. You break out your ruler to indent your yaml You know, but it's going to be a cluster at the end of the day It's going to be a kubernetes cluster at the end of the day. So, you know, vendor lock in is real This may or may not increase your lock in but but even if it does you're probably already locked in in a few other ways So and even if you're not locked in at all, it's very rare. You're going to change cloud providers overnight So next up You've decided to look into your managed kubernetes service, you know, what are you looking for? What do you want? So, you know, the first thing to call out is does your cloud provider have do you have options? Does your cloud provider have different methodologies of setting this up? Do you only have one? Option and then it kind of comes down to maybe a binary decision to you know, self manage or not, you know So what do you look for? One of the things I was looking for or was intrigued by was You know, how many buttons did it did I have to click to get set up? How long did it take me to deploy these things? You know, there's a decent chance that no matter how many buttons you have to click to get set up It's probably easier than writing these config files on a self managed cluster yourself So this one might not be as important to you depends on how many clusters you deploy and how often if you have five clusters And they're pretty much static You know, the initial setup doesn't really matter to you once you're going if you're constantly tearing down and redeploy Or scaling or you know, things like that that time to having a full cluster up and running might you know, be important to you Um As as you know, is is the buzzword so much as of late rightfully so what does security look like? You know, we've had some some cvs and kubernetes in the past How long do these providers take to get those patched and deployed? And then what does it take for you to uptake that in your cluster? Does it interrupt you? Does it cause downtime? Is there historical records of security issues in the past maybe based on their platform specific setup? You know, that's something to think about and then lastly, you know What do they expose in terms of metrics? You know monitoring and keeping an eye on these these things that you're using to run your infrastructure You know, most cloud providers have some sort of inbuilt visualization tool They let you see some logs and metrics, you know access logs are also important for security So while you may abstract away some of the management of the the Administrative administrative of your cluster, you know, you still want to understand what's going on, you know How how obscure is is to obscure and abstract for these things, you know So like any solution, you know, there's a a lot of these these fun Fun sre related terms uptimes, slo's, sli's things like that What what do they guarantee in terms of availability? How many nines do you get at the end of the day? If that's something you care about what happens if the service goes down, you know, are there Historical records of long outages that that maybe are too much risk for you to take on, you know How does this compare to your existing infrastructure having issues, you know, is it more or less risky? You know, this this is one of those things to think about when thinking about that lock-in You know, if you're if your providers, you know object storage breaks Is it any more or less damaging than if they're kubernetes clusters go walk about, you know, and you start having problems, you know So there's definite trade-offs there and it also depends on just your your Your team power how many hands you have on keyboards to to keep these things running So we want to make sure providers keep up their end of the deal So many people talk about their cloud providers when they have an issue You can get a refund you can get cloud credits and credits are great That's awesome. That's less money to spend on the bill But I bet that oftentimes the credits you get aren't Equal in value to lost revenue or lost productivity. So, you know, weigh the options And lastly, how do they handle just overall upgrading? How how one touch or how how white glove for lack of a better term? Is it how, you know, how Smooth do these things go? Does it does it offer down? Does it make you your clusters take some downtime? Is it a single click, you know, things like that? How do they patch the operating systems and run times? Is that exposed to you? Do you even care? You know, these are some kind of some of the questions to add to your kubernetes shopping list So, you know, there's not one way to do this There's there's a couple paths I've seen taken in the past on how to deploy these services or how to at least begin your investigation I've used I've used both of them You know the first being you you're not using kubernetes. You want to use it. You've heard about this thing You want to check it out the other one being you're already building and deploying your own clusters using some sort of framework Either upstreamed or or in-house You know for the first one you want to see what it's all about Why waste your time diving into the weeds configuring all these These bits and twiddling all these these knobs If you have a platform available from your cloud provider, they probably have a managed kubernetes service So, you know, try it out see how it works. What are the options available and and think about later whether or not you need all the customization You might not know what you're missing and that might be a good thing So, you know, just really this is good enough to make sure kubernetes is right for you Because there's a whole other talk I could give about whether or not you need a kubernetes cluster, but that's not what i'm here for Um, if you're not running on a public cloud, you're in a colo or you, you know, have your own data centers You can still fire up a cluster on a public cloud service Check it out and see if you know at least this this kubernetes mindset works for you, you know And then also this is where those third-party companies can come in and help you deploy your own You know clusters and kind of get you going there, but there's there's probably more hoops to jump through with that So, you know, the big thing that I liked, uh, as I called out was the delay on a lot of the configuration choices I needed to make and just try it out with a managed service and say, hey, I like this this paradigm this declarative syntax And then decide later if you need more customization. There are thousands of blogs Videos conference talks all over the internet how to get more out of your cluster So if you decided later on down the road that customization is what you need Then you can move to a place where you run your own So, you know, the other side of that the flip side of the coin is maybe you're already doing it yourself You hopped on the bandwagon early or late and you know, you've you've got your clusters running and you're ready to go Um You find that your engineering teams spend a lot of time keeping these things up to date keeping them running And you want to find an easier way? Why not take a development environment and stand it up on a managed cluster? Is it easier? Does it work better? Do the devs even notice a difference depending on how you answer these questions? If it looks good move forward um And lastly, it doesn't have to be all or nothing as well Maybe you have some sort of tooling cluster where your cicd stack runs, you know It's where your jankins lives or something like that. Um, you don't need a lot of customization there, but it does need to be rock solid Um, you can use a managed service for that. That's a valid use case You maybe your production environments need to be hyper customizable. You need all those knobs and dials You need to change your api server flags and all that fun stuff Um, but for the dev environments or these admin environments your logging aggregation or monitoring environments You know, maybe those can be managed clusters because they they either change too often or not often enough that it really matters Um, you know It can help to offload some of this setting up and configuring in these environments And you don't have to move your entire workload to a managed services. Maybe move some of your stack um You know, so it's it's different on a case by case basis. Um Maybe you save some money. You probably save some time, you know You unblock your ops and infra teams from, you know Working on everything that they don't want to toil on and they get to spend some time actually keeping the production environments Producing and uh, you know, maybe their devs get the baseline environment with a few, you know mouse clicks and they get to work So As I said at the beginning, maybe it's an easy choice. Uh, you have a cloud provider and they offer a kubernetes service Does it fit your needs? Uh, maybe they have multiple options at different levels of managed, um, or abstractions, you know at the least But no matter which way you go building it brick by brick Or, you know, allowing a provider to do it for you or taking it all in-house and doing it yourself My whole point here has been, um We're all here to build some cool stuff It doesn't matter how you get there from scratch with the head start of a managed service Um, and I don't just, you know Push on this from a kubernetes specific point Build your cool stuff Use the tools you need the tools you like whatever works for you The bragging rights that you self-manage your clusters make you no more skilled than the team that uses cloud provider x's managed kubernetes services Um, and I think this is a big takeaway Especially around these conference times cube cons can be overwhelming the first time the third time every single time There's a fire hose of talks Connections knowledge to gain But you don't ever have to feel bad about how you got from point a to point b and beyond Uh, so if nothing else I want you to take that away From my time with you today is build some cool stuff in a way that works for you All right, and uh, that's that's all I really needed to touch on about some managed clusters again My name is sef and uh, now we'll open it up for some questions. Thank you