 Good morning everybody. We're on. Welcome to Kate's or die and If you were expecting us to stroll out on the skateboard, I'm sorry. We couldn't pull that off over the airplane My name is Ryan. This is my friend Marco. Hey, we have deployed clouds and coops and all sorts of fun things on different architectures over the last few years and We're here to basically talk about Kubernetes and the various combinations of Kubernetes and OpenStack and reasons why you would combine the two and perhaps Whether you should combine the two in some cases We hope to have some good conversation at the end of this. I think our presentation will be Maybe 20-25 minutes and then we invite conversation at the mics and of course If you will deploy Kubernetes When where why and how would you do this? Yeah, right? So I have an open stack multiple open stacks Already deployed. I have all of my applications deployed in a combination of VMs and containers today My control plane on all of my clouds is already containerized and highly available So Marco, why do I need Kubernetes? Yeah, it's such an interesting question It's been fun this whole week kind of watching the conversations that have been spurred about about OpenStack containers the intersection of the two Kubernetes Docker swarm. So I want to talk about Why you might need Kubernetes and really why the need for Kubernetes is such a prevalent prevalent conversation topic these days and so to do that We have to just take a step back and see what computing has been doing for the last couple of years So this will be real short history trip. So We're all familiar with this I imagine It's a it's a server. It's a laptop. It's your computer. It's a Linux machine running Linux It's got processors. It's got processes these beautiful little lines. It's got a some kind of disk SSD Could be spinning rotary. It's got a bunch of networks plugged into the bottom of it. It's a server It's not very exciting. We've had these for years now I mean many many years if you think of the real big Innovation with servers and server spaces was virtual machines now's whole idea of well my app doesn't really need to run that much Need to use the entire box for its app I can actually get a lot of multi-tenancy by just saying hey, I'm gonna take a chunk of this machine I'm gonna go ahead and do the same thing. I've done on my root server. I'm just gonna run a bunch of processes I'm gonna run an operating system It's gonna have a disk it's gonna have a network and it's just gonna physically I'm just gonna basically carve out and virtualize the the IO for this machine on the on the host hardware And that was exciting because well now we have a we have something we're very familiar with its servers You're accessing them your SSH into them. You have developers getting to them You're putting applications on them It's really no different than when you were managing bare metal You've just got a whole bunch more of them now and it was very exciting and so From there we've kind of evolved a little further and this is where things like Process containers come into play The idea about a process container is a bit different than what you'd see in a virtual machine or on a server So if you're not familiar with a process container, this is things like Docker These are things like rockets is things like run see these things that people have been clamoring about This is usually what people mean mention when they talk about containers and the idea behind this is Instead of taking the entire machine and running all those processes and running all of those All those items and your application and having a disk that you write to and manage and having all these network spaces What if we took that a step further? What if instead of taking that and virtualizing all the IO? What if we just confined it so that you just ran your process and you provided just enough OS to run that single process in a constrained confined manner and By doing so you actually get a lot of density a lot more density than you would out of VMs You can run hundreds of thousands of Docker containers where previously you were physically allocating chunks of your hardware to They all kind of share the same processor space. They share the same memory space and they're generally running less processes in general You're not running a knit. You're not running SSH. You don't have cron jobs Executing but there's also comes with some drawbacks and there's some different ways to manage these you don't have a full disk anymore Generally speaking you don't write to that same OS disk Obviously you can in some cases but generally speaking they're more immutable And you're just running that process and you're managing things coming in and pushing output somewhere else And so what's interesting about this is because with virtual machines We have this idea of traditional operations things we've been doing for the whole time since we've had servers You can run the ansible against it you can run configuration management against it You can do virtually anything you can do against a server and a virtual machine When we start talking about process containers, it actually takes on a whole new breed of operations You can't SSH to it You can't just run a playbook against it You can't just go and manage it like you've been doing for traditional machines And this is why we're seeing a bit of a shift in how we do management and why containers are this really big hot topic because It's unfamiliar. It's new and it requires a whole new Breed of tooling to figure out how to manage these at scale much in the way We've come to accomplish managing virtual machines at scale and so because of that we lead into Needing what we call container coordinator So container coordinators are effectively that platform for how do I operate and manage containers and so that is Why we have this stride for kubernetes and things like kubernetes kubernetes Docker swarm and the other projects DCOS and mesosphere that are popping up and they're all claiming to be this container This nebulous container thing and what it really means is how do I operate and manage containers at scale in a same way that I've come to expect when managing things like VMs So what does kubernetes look like when we pull together the architecture and services that it takes to build Yeah, so I guess That was more of the why I guess you're asking what what is a kubernetes actually look like yeah, I manage it What does it look like? Well kubernetes is surprisingly and shockingly just software. It's nothing special. It's not a magic hat It's not a cape that you can wrap around your neck and fly off into the free world Proclaiming DevOps is done and I and and celebrating that kubernetes is software and it's actually From an architecture perspective since kubernetes is a container coordinator what you're really getting is actually the abstraction of those Machine resources those VM primitives those things where kubernetes is running you're getting an abstraction for those for your Docker containers and what it really amounts to is Effectively giving you the abstraction of compute networking and storage for Docker style containers now I'm sure this sounds strikingly familiar to a couple other projects. You might be familiar with But essentially at the end of the day as a kubernetes the platform is just providing that mechanism to say I'm going to run containers I'm going to run them here. They're going to be on this network They're going to have potentially this storage pools attached and they're going to be running on these classes of machines or these types of processors with these compute resources and So because Docker containers are Well generally speaking such a small surface area It's a single process running on a virtually immutable disk with some semblance of networking We actually have a platform that grows a lot of capabilities that were tougher in previous generations of computing Doing things like roll out and roll backs of applications while absolutely that's something you could do today on traditional VMs But it took quite a lot of time to produce a tooling to get to that place Same thing with scaling up and scaling back all these primitives while they are present today They took quite a lot of engineering work to go from I have a VM to I have a VM that I can scale dynamically to a VM that I can upgrade dynamically and be confident in that upgrade or to a VM I can roll back and In addition to that you get things like load balancing Self-healing service discovery things we'll talk about a little bit But basically because the actual idea of what a container is a process container like Docker style containers Because it's so small and so strongly defined as a surface area It's actually easy for platforms to start building these primitives in where previously it was actually quite a difficult feat And so that's what's gotten a lot of buzz around things like kubernetes in these platforms It's because they have these features that took arguably quite a long time to figure out how to solve and there are still some areas where they can improve with operating traditional style of VMs So I want to talk just real briefly about what a kubernetes architecture looks like, you know What does it actually mean to run kubernetes? Does anyone here actually run kubernetes or running kubernetes today? Hey, yes, the brave the brave few hands raised How many people actually interested in running kubernetes like this this next six months like I'm definitely going to get into this kubernetes thing Yeah, everyone's talking about it. I'm sure developers are clamoring for it They're sitting there throwing Docker containers at your ops guys and your ops guys are like stop doing that, please So kubernetes is a platform because again, we're dealing with a very small surface area It's actually quite small from an architecture perspective. It effectively breaks down to a few components You have the kubernetes core software itself You have at CD which is its data backing store and then you have some form of SSL TLS certificates and I mentioned this because I think in this day and age it's Generally imperative that anyone building clusters anyone building production infrastructure should be encrypting that communication from the control plane to the workers to the clients themselves and kubernetes makes it pretty easy to start consuming those types of things building a secure cluster with TLS encryption and such so Those components are basically arranged in this kind of fashion. So you have a TLS certificate authority easy RSA is what upstream recommends It's pretty easy to set up. It just spits out certs And you can just have their kubernetes and your at CD clusters run with those At CD itself is a distributed data store. It's from core OS. It does things like quorum and data protection Does the proper peering and things and it's basically a raft back key value store at the lowest level So it's very robust and reliable and is what at CD what kubernetes uses do its coordination of data Then you have a master control plane service and this is actually pretty small in and of itself as well It's just an API server, which is what you your clients your your users talk to There's a scheduler which does that things like well. I need to make sure I have these number of Workloads running. I need to make sure that if one of these goes down and bring another one up It implements a lot of that logic around auto healing and auto scaling And you have a controller manager, which helps to coordinate all of the different pieces that are moving inside of a deployment Then finally you have your workers And this is where you're actually running your workloads and there you're running. I think called kubelets You're usually running a kube proxy your container runtime docker rockets Ocid there's a whole bunch that are supported now and then some sort of networking SDN some CNI Container networking interface compatible component like flannel like calico weave and there's a bunch others as well At the end of the day, that's typically what an architecture for kubernetes deployment looks like now That'll vary and we'll talk about how that varies a little bit and maybe how that can be utilized to solve and Tackle other problems, but at the end of the day. This is typically what you'll find walking to anyone running a kubernetes cluster today and Because a lot of this stuff is docker eyes because a lot of the stuff is container eyes It actually lends itself to running in a very converged fashion So a lot of times you'll see with just maybe really was just one machine You can run a single kubernetes cluster, but really with three machines You can actually run an ha cluster where you're scheduling workloads You're also running the api control plane services and the data store services So again, this is just an example of architecture these vary quite a bit depending on where you are But that's effectively what you see in most places that are running small clusters You have the most amount of density out of the hardware they're piloting on So yeah, so I mean I'm a kubernetes guy. I don't know if you guys have picked up on that It's kind of that thing. I'm really interested in cloud native architectures and stuff I'm just kind of a cloud consumer actually I just I pay someone a bunch of money to run VM somewhere that I'll never have to go look at In a public cloud, but what I really want to know I think this might be a silly question for this audience I want to know what kubernetes what open stack is and why people keep talking about it here So first of all that was a ton of good information. Thanks. I feel like I know kubernetes now So what is open stack? That is a loaded question. So if we think like 10 years ago before open stack We're Linux saying and virtualizing and doing all of our things with VMs and how are we tracking compute network and storage? How did we manage that what tools were there in the in the pure open-source world? I think that there was a void clearly and that's where open stack fills so, you know, there have been folks Put it akin to basically a fancy spreadsheet that is tracking that compute storage and network if you're talking pure infrastructure as a service so you have open stack as basically a collection of API services as a service oriented architecture and The the actual layout can vary quite a lot there again. This looks a whole lot like Your converged architecture you had a moment ago This is a similar layout to some of the clouds that I've got running where we spread the control plane across compute and storage and It's available as a highly available cloud So I don't think that diving into what is open stack at the open stack summit is probably a good use of time So let's move right along To what it means to combine the two yeah, so where does Five kubernetes. Do I really need open stack and few of open stack? Do you really need kubernetes? Maybe? Well, all right So let's look at some of the combinations that we've seen out there, right? So let's say you have an existing open stack. You have a production cluster. Perhaps you have a dev cloud Maybe you have both staging production all of the various things You can certainly have your tenants stand up kubernetes and have individual clusters that they can consume again Whether those are production workloads or for development So that's like a lot what I do today that if I get an Amazon deploy kubernetes cluster I basically just do it on top of open stack if I had a private cloud. Yeah, right, right? So we do some of the same with with our dev cloud. So another scenario is that You've got an existing open stack. You have some spare bare metal and you stand up your cluster of kubernetes Alongside open stack. I think these each have different use cases. So that's like This guy I work with he does data science stuff and just loves GPUs, right and runs a ton of machine learning with stuff so He always is clamoring for more metal So if he were to dockerize his stuff running that on kubernetes on bare metal makes probably more sense for him It could make a ton of sense. Yeah, yeah access to to virtualized hardware So something that's gaining traction, you know, if you rewind six months and then rewind six months from that there were ideas about dockerizing the open stack control plane and other services and Distributing that and managing that with kubernetes, right? So there are projects out there doing this And so this is an interesting thing. So basically containerizing the control plane in a docker-like Container So these are not mutually exclusive if you have these varying approaches in your organization You may end up with something that looks like this, right? You've got metal You know kubernetes kubernetes sitting on that metal that kubernetes cluster may be delivering multiple applications for your enterprise One of those applications might just be the open stack control plane or other open stack services And then again, you could have your tenants Wanting their own kubernetes cluster. I actually think I saw someone do that this week I think we've seen this a couple of times, right? Yeah, so there there are all kinds of different analogies I think that people whether they're intending to or not were are going to end up with things that look a lot like this and I think that there's you know, each of the projects that deliver these things are maturing and Interesting. Yeah, it is an interesting thing. So let's think about or talk about some of the projects that are out there to Help you achieve these things Whether it's for just exploring Or looking at doing something in production. So naturally there are heat templates I'm not sure if they're community driven or by the heat project that they're centered around Deploying kubernetes on top of open stack the magnum project has kubernetes capabilities and Couple of other things out there the kubernetes charms which are upstream in the kubernetes project Can deploy and manage the life cycle of kubernetes on top of open snack kubernetes naturally pretty much works on anything. That's kind of the The nitty-gritty way to go do some things. Yeah, so it's a so that's for kubernetes like kubernetes an interesting project Because it's tackling kind of how do you self bootstrap a cluster? They're getting very close to being Ready for a stable testing which is exciting. That's cool. So something that's in incubation incubation is the cargo Project and there again it has relevance to the open stack project So some of these have varying degrees of maturity. I think it'll be interesting to watch the ecosystem grow and And some of these things gain traction sure but all these on the right-hand side because obviously heat and magnum Those are open stack projects, right? But charms kubernetes and cargo all those speak to the open stack API natively as I understand So if you're looking to turn up kubernetes cluster, those are kind of upstream kubernetes ways of tackling that problem Yeah, right. So they are specific extreme the kubernetes. Yeah, yeah, so they'll be specific to open stack, right? So if you if you have Automation built around magnum or heat it pretty much predicts that you will be installing this on on open stack So let's take this and flip it around there are a couple of projects That are geared toward putting your open stack control plane and perhaps other services Into docker-style containers on kubernetes It seems there are two kind of in the open stack world that are filling this this role And they might be in some ways in competition with one another Those of you who are not familiar with helm is not a specific open stack project It basically allows you to use charts to deploy applications in your kubernetes cluster There's project called open stack helm that leverages that and I believe call images under the hood Yeah, so call us seems like it's a project call itself an open stack is a project to build docker containers for all of the Services that you can deploy with an open stack and then call kubernetes is taking those images and just using the kubernetes API directly where Helm is more like a package manager for kubernetes. It's a different approach to solving that same problem Yeah, yeah, exactly. So call that actually is not specific to kubernetes There are a couple of different flavors of the call a project the call of kubernetes is just one of them So these will be interesting to watch And and see how these things mature and and perhaps progress over time Finally the scenario that Might be quite common is to take kubernetes directly onto the metal I know we touched on that a minute ago, but the tooling to do this Arguably is is widespread and not very clear. There are a number of things in the Upstream kubernetes docs about how to take and lay down a kubernetes cluster Whether that be any number of config management tools Essentially the ones that you know that that we use and that I've used and Like to use are the kubernetes charms there again. It's these are in the upstream kubernetes project these allow you to Deploy and manage the lifecycle of your kubernetes cluster including upgrades Same with kubernetes again, which kind of works on any VM Where there's a whole process for bootstrapping a cluster having cluster expand and grow and then As they move towards finishing this dev cycle, which should be done pretty soon They'll have all a nice upgrade story as well alongside that. Yeah. Yeah, so Who here has stood up a kubernetes cluster the hard way you should probably I don't well, I don't know so I'm talking about the Who here has gone made a bunch of VMs and then a bunch of W gets and then a bunch of hand configuration of stuff. There we go That's a brave. You're brave. How'd you look? How'd you like so it was I can see where Ryan's going here It's super important because I bet you learned a lot about how kubernetes is actually built under the covers So you went you went even harder. You said, you know what pre-built binaries is that's too easy I have to go compile it by hand For sure and that that's kind of my point is that if I ask the same question of the stackers in the room Who has gone out and done the same on a pile of machines not in Dev stack and stood up a functional open stack by hand? It's worth doing once you probably don't want to do it twice, right? But it is good I think there's a there's a great there's a great great blog series called kubernetes the hard way if you haven't read it And while you may not want to actually go down the adventure of hand-setting these things up because it is going to take you a Few days to get through and get a successful cluster running It's a really good read on understanding how all the components interact with each other how they're built how to design what the Architecture looks like and some of the pitfalls that come commonly with deploying clusters But generally speaking you'll find just like with open stacks you want to find a way to actually start automating that process Yeah, for sure Sure, so the point is is that today kube-atom is not yet a stable production ready tool It's one that they're building towards it's a project. That's also being incubated in the upstream But it does things like it's not ha out of the box or you can't even do ha really Where are the projects like cargo against open stack or charms against open stack or metal? Those take into consideration high availability of database services and control plane features and such But kube-atom is very interesting because it is a It is kind of if you want to do it yourself But don't want to go down the road of compiling everything and then hand configuring everything kube-atom gives you a really nice feel of You're building the cluster. You're making choices. You're doing everything by hand effectively But it does take care of a lot of the more tedious functions of bootstrapping SSL certificates for yourself and Producing other things that make it so you can get a secure cluster running when they're ready and out of development in an HA fashion Yeah, awesome. So when you when you think about, you know abstracting the tooling And you want to have a kubernetes running on any given substrate whether it's a public cloud or open stack or directly on metal Or on your laptop the tooling varies quite a lot and there there are some Pros and cons to each right but in terms of being able to do this across the board These are basically the the two that that kind of spread the gap Yeah, that definitely spread the gap So kubernetes and open stack together It's an interesting combination for sure and there are as we've seen a couple of approaches more than a couple And I think varying reasons for doing one over the other or all of them together so it seems like In our time discussing this what I've come to kind of start accepting is I was always very happy to say You know what the future is containers But I think there's actually a bit of a different story here I think what I've learned after trying to push everything into a container And what I try to do running everything on kubernetes or swarm is really it's going to come down to it's not kubernetes versus open stack But it's really about your architecture and what it boils down to is Whether you're running something that's stateless or whether you're running something that's stateful and this is a loaded term I know Ryan you helped participate in the interop. You want to yeah interop stuff. That was cool Yeah, do you want to explain real quickly sure sure that the interop challenge is an effort where? we take multiple Clouds public private clouds of varying distribution and version and demonstrate that open stack its apis its product is able to Function in the same way regardless of those varying vendors and distributions and versions so the workload this time around for the interop challenge was a Kubernetes cluster on top of open stack with cockroach DB pod Deployed in that and then beyond that these cockroach DB Databases were clustered across these various clouds so This is this is kind of a cool effort But my understanding of databases is that they're very much a stateful thing. So how does that work into this? Yeah, so I liked it very early on the interop challenge everyone one of the people stood up and was like Explain that you're gonna hear people argue about stateful and stateless applications this whole week But cockroach DB is arguably stateful and it runs and Kubernetes fine and does a good job And I think really this slide is a little misleading as well stateful itself is a Very nebulous term. What does it actually mean to be something stateful? I think state is pretty clear, but stateful is really is a really awkward term And what I've kind of found is that there is definitely a generation divide between software being built and we look at cockroach DB If you're not familiar with it, it's pretty cool but what it does is basically gives you a sequel interface against the distributed data store and Cockroach DB was designed to be resilient out of the box It was designed to do clustering peering and stuff and what it's really designed for is really designed for a cloud native architecture an Architecture where if one machine goes down, it's expected to happen And so while you have a consistent state present across all those nodes No one state is no one machine or VM or docker container Has state that will if go if it goes missing will break the cluster and so that's respect It's a distributed stateful application and because of that it actually survives quite well and thrives as we saw interop Inside of a inside of a dockerized container kubernetes deployments Whereas a lot of apps that were written. I'm guilty of this as well Early earlier generations applications are really written to be more tightly coupled than that So if you have an application that depends on being on the same disk and having data Persistent on that disk so that other parts of the application can read that That's a really super stateful application And if you can't just take those components and run them over the network to each other or run the data and store it Externally you're actually I think a quite a lot of engineering effort to actually detangle that and so what results is a lot Of engineering effort to make that application super cloud architecture friendly cloud native architecture whereas a lot of developers today are building Applications with that in mind cockroach TV is a good example of that and a lot of our distributed stores at CD itself again Another data store that persists data But it's designed in a way that if you're running it in resilience more than a couple of nodes running if one goes away You can bring a new one up. It'll rejoin the cluster re get its data It won't lose connectivity to that cluster. It's designed in a way to be resilient in a cloud architecture because Well, frankly clouds are ephemeral and docker containers even more so And so I think that's where we start to see the divide is it's not just all stateful applications as a as a general Blanket statement that you can't or shouldn't run them in inside kubernetes But it's about taking the tasteful discretion to see Which application can I run in kubernetes? Which application should I be running in kubernetes? And a lot of times we'll find that there's a good mix of things where developers want to go really quickly They have an application that suits that architecture But you've also got database operators and you've got general sys admins that are gonna want to make sure that they handcraft VMs and that they manage those VMs and that they do things to persist that data at a Infrastructure level whether it's snapshotting that data whether it's making sure it's backed up and robust or Or running multiple services like cron jobs and other things on that And I think that's fine to sit in a VM. I think that's where you'll find the intersection of Yeah, yeah, I think Bernetti's and certainly for some time structure management. Yeah for some time We'll have a combination no doubt the Sessions that I've attended this week have been some really good ones that dive perhaps a little deeper even then we are into some of These areas and what what I'm seeing overwhelmingly is that the the control plane is is easy, right? These are stateless things. These are services you can cluster Storage Becomes an issue Seth. What do we do with Seth if I'm an old-school? Sefi and I just want myself to do Seth stuff I mean we have things that are happening to help improve that story But it doesn't seem like we're quite there yet Persistent volume claims perhaps is a trend that that will help solve these kind of things So how does how do you think that fits into here? And should I keep my Seth on VMs or on metal? Or should should we be pushing that threshold to try to? Lift and shift as a were that some folks. Yeah, so I think Seth's a super interesting one I don't have a really good answer for people I know it's hard to run in Cupertetti's whereas installing Seth on a VM and configuring it to talk to your Seth Mons is actually quite simple But Seth Mons interesting story because you could potentially run that containerized the monitor for Seth But OSD's probably will live on disk and in the same vein I could see things like horizon Super staple application that makes total sense to run in a container But my SQL seems like it might be slightly more problematic or a more traditional SQL server application Yeah, right. I think we'll see vendors Especially those that are running database services. They'll all work to containerize their applications. In fact I want to point out something real funny Because I've been praising the cockroach DB guys this whole time So I went to go download their software that I spoke cockroach. I did I would go download their software and I said, okay, I'm gonna go grab their Docker container live googling is dangerous So I went to their documentation and I said, okay, I'm gonna go grab. I'm gonna go install it Good gosh, I gotta go figure out the navigation here one second I said, oh, I'll just use Docker and the first thing they say is You probably shouldn't do this in Docker You can but it's actually quite hard and it is it's a hard problem to solve So even something like cockroach DB, which as we see it excels in a platform that's Docker eyes and in a Kubernetes fashion Even they are still having ways to figure out How do we do things right in containers that allows to do persistence of data and stuff? So I'm sure the Docker containers great. It's not a slight I actually haven't run it yet. So I can't really judge it for myself But it's very interesting that you'll see that more vendors cockroach DB. I'm sure my SQL I'm sure Maria DB. I'm sure Postgres will all find ways to containerize their services for those that want to consume it in that fashion But it will take effort for them to re architect their software to be conducive to that fashion And so in the same vein if you're running software today that you've written odds are you'll have to do a lot of work or a Little bit of work to get it in a state that can just run easily on Kubernetes Whereas developing your next applications or run on Kubernetes makes much more sense It's something it's a little more tenable and going back and re-architecturing range and everything and because of that I think in the next five six years. We'll see a nice heterogeneous deployment of things managing VMs and things managing Docker containers and then who knows by then we'll hit serverless We'll probably hit quantum containers by then as well. So the whole world will change and it'll be an ever-evolving landscape Right, right. So we do want to have time for comments questions and Conversation really so the idea here is to You know for folks to be able to share some information experiences things like that I know it's not a fishbowl, but we can make it that yes So if you have a question feel free to just queue up in front of the microphones otherwise I could continue talking about containers for the next eight minutes No, no questions at all So everybody understands why you need Kubernetes and where you're going to use it. I'm still figuring that out By the way, I think everybody is hi guys. Thanks for the great presentation Maybe architectural question How would you model more complex application stacks where you have something? What is really stateful like database which maybe should run in VM? Yeah, and application and web servers which could potentially run in containers Yeah, and how would you orchestrate the whole stack? Would you use heat and some configuration management plus Kubernetes or it's going to be it's honestly going to be Really dependent upon what your team's familiar with I think all of those are great options What you'll likely see is that you'll run and operate your stateful services in VMs And you'll almost make that consumable as a service to your to your doctorized workloads where you'll say hey My db admin or some person's gonna go they're gonna go create you this database this username this password That's what you have and then as your developers roll those things out those containerized Stateless applications. They'll simply just configure them to use that as a service. So to them. It's a black box It's no different than Databases of service effectively the cloud is just that you're maintaining the VMs behind there as well It could also even be databases of service potentially But we'll see that that I think we'll see that SAS model evolve quite a bit more to where Those kind of containers running in these platforms will just consume them as endpoints And they won't really necessarily know or need to coordinate between them It'll be a pre-setup step potentially scripted and then just configured as well either using helm either directly through kubernetes Or some other form of configuration management platform Thanks. Well, thank you Yes, can you talk a bit about where? With the intersection of these things where things like a atomic host and chorus with the mutable architecture fit in Yeah, so those are two super interesting things I Think what we what we see is a general shift into people saying if I'm gonna be running containers I'm gonna be managing these platforms I want the lowest I want to abstract the lowest level possible and kubernetes gives you that abstraction to where you're not even worried About machines anymore placements. You just want to have containers running somewhere So the idea of having a host be completely immutable and inaccessible Not writable at all is super alluring. There are definitely some trade-offs to that So core OS specifically has a platform that is effectively a blob of OS with a bunch of things pre baked into there And then they auto update themselves if reboot the machine to give you that latest platform There are advantages of that. It's secure by nature. You can't break to those root volumes but then again at the same time if you find that You're looking to add additional capabilities to that blob It's not that's a lot harder to do when we really see is people doing things like Secure confinement to the components they care about that have that intersection of potential security vulnerabilities So that's things like confining the actual kubernetes control plane so that the binaries running can only run the binaries enough touch anything else on Disc, but the OS is still accessible. So you can SSH to it. You can install additional software drivers capabilities that you're looking to do It's still a lot to be figured out there. There's still a bit blurry But that's kind of the trend we see is those who are using these immutable OS is eventually comes the point where they say What's in the OS and what I actually need to run is something completely different or there's a there's a overlap of things that I need to install there Great question Yes Hi at the risk of asking you guys to go into holy war territory. I'm ready Can you compare contrast and maybe even provide some decision points on other container orchestrators in particular Docker swarm and Mesa's that is not a holy war actually so we thought to pull it there. Thankfully I thought you're gonna ask me about them or Emax or something That would have been a whole holy unfortunate So each container platform is tackling a separate set of feature sets and it's actually very interesting for consumers today Because you have a lot of choice Docker swarm. I've used a platform at a high level. It's just basically run a VM. Sorry run a container somewhere With Kubernetes you get a lot more facilities to manage what that machine what that VM? Oh my goodness What that container looks like how to maybe modify the scale for those things how it plums into other things So the service discovery aspect it becomes much more like infrastructure platform as a service Whereas when you tip into DC OS and Mesosphere They also do a lot of things that overlap with Kubernetes But they tackle them in different architectural ways so they themselves can actually run more than just Docker containers So the platform for scheduling and management is not just limited to process and Docker style containers So it's really a breed of you have a very simple management of a cluster of machines that are just spinning up Docker processes And that's Docker swarm you've got Kubernetes Which does quite a bit more in the management and lifecycle of containers and then you've got things like DC OS and Mesosphere Which give you the same kind of primitives you get from Kubernetes But be able to run those against potentially different run times and different container types Thank you. Yeah, thank you. I think we have a few more minutes left. Yeah, we've got two minutes till time encourage any questions or conversation for sure so Out of curiosity of those of those still left here Who here is I will be racist of hands earlier, but who here is going to be deploying Kubernetes in the next six months again How many of you are going to be the primary consumers of that or you're doing it for your development teams or another team in the company That's asking for it. Sorry. Sorry. We asked it in a binary fashion Put your hand up if you're doing it for someone else other than you or your team Yeah, interesting So, I mean, what do you what are your general feelings about it? Are you excited about technology? Is it something you're just another thing you have to run as a workload? I'm curious of what what your what's your consensus is of Kubernetes the platform is something that it's being requested upon you No, it has any opinions. It's cool. I get it. It's so early the morning. So I understand Yeah, yeah Yeah I'm here The pioneers Awesome, so I hear that story a lot for sure. Yeah, we're at time. So thank you for coming We we came not with all of the answers on by intention We wanted to spur some conversation and some thought into these Architectures so if you have any questions feel free to reach out to us here is our Twitter handles and a couple of URLs That may be of interest Absolutely, please reach out. Thank you all. Thank you