App Dev Platforms for Kubernetes

[Music] hello and welcome to appdev platforms for kubernetes i'm your host today mike vizard and we'll be talking about all things related to developing modern applications on one of the more complex platforms ever to come down the proverbial pike these days we will be giving away uh four amazon gift cards today so i encourage you to stay the very end to see who's gonna win those i also am asking you all to participate a little bit with us we have a q a button in there where you guys can be part of our discussion feel free to ask any question you like and we'll either answer you directly or i'll read it out to folks for a bigger larger discussion as we go along our panelists today are samantha wang who is a product manager for influx data they make a database that is widely used to drive observability platforms in real time so we can get those kinds of queries going and as we all know we're shifting left so that's becoming a bigger deal our other panelist is robert brennan who's director of open source for fair winds best known as a provider of managed services around kubernetes and a few other open source platforms and they also are contributors to last time i counted maybe five different open source projects that you guys have watched so um they are players in the space as we say let's get into it um i'm a little perplexed about the whole state of app dev on kubernetes i've been following the space for some time people have been talking about uh platform as a service they've been talking about container as a service there's all kinds of desktop tools and yet when it comes to kubernetes um there's just a lot of people who feel that maybe it's too complex and they don't really like to use kubernetes and there's a lot of resistance shall we say so robert what's your sense of where are we on the maturity of kubernetes for application developers and how far down the path are we and what what is the what is the big hurdle yeah so i mean i would say kubernetes was really designed to solve problems for ops folks rather than developers right it was meant to solve problems around scaling um around consistency around you know being able to reproduce your deployments really really neatly roll back really easily um you know it doesn't really solve problems that developers experience on a day-to-day basis you know as they change code uh make poll requests things like that um so i think that's part of the problem that that we're seeing is that kubernetes was adopted on the op side of the house and now developers are realizing they have to learn more and more about kubernetes in order to be successful and so you're seeing a lot of platforms and open source technologies get kind of tacked on and layered onto the stack to kind of help developers with that transition and we've seen some some great attempts at that but it is still it's a very complex platform it does a lot of things and i think a lot of developers don't really want to have all that context especially as they're developing on a day-to-day basis they don't necessarily want to have to think about all the the nitty-gritty details of how their application actually runs on a host machine they kind of just want to run it locally on their server push the code and then you know hope somebody else takes it over the over the goal line and gets it actually you know behind a production url and serving traffic to real users um but uh that you know the whole the whole shift to devops is is really supposed to start putting more and more of that context on the developer's plate so they have to think about how does my application scale what is the memory and cpu footprint like etc all right samantha do you agree with that because i think what robert just said is basically kubernetes comes from corporate and they say hi we're here to help you and the developers want to drug and go well uh thanks we'll get back to you yeah i guess in kind of how we use kubernetes at influx it is definitely kind of a lot heavier on the op side of maintaining our cloud to our cloud products here at influx um i think kind of kind of to echo what robert said we really want to like make sure that our developers want to be writing code versus kind of kind of kind of doing all the all the nitty gritty little things that they have to do with kubernetes so i think what we try to really emphasize at influx is is is utilizing tools we have like helm charts and we we have even a telegraph operator that helps us kind of that helps kind of these redundant uh operational things that that engineers whether developers or ops ops engineers have to do kind of repeatedly kind of kind of having the tooling around it and making sure kind of charming back into open source making sure that this stuff is open sourced for other people to use as well so um yeah i think we we we've kind of seen that kind of the emphasis on the operational side but i think kind of how how how we've seen at least people here improve it is trying to to to automate any tooling and and and and build i guess build tooling around it if if needed um so yeah i kind of yeah agree with what robert has said what is what does that tooling look like and let me ask the question in this context so docker says that there are somewhere in the neighborhood of uh 10 million people using docker containers to build applications and that represents roughly a little more than half of all people who build applications in the enterprise all right let's just assume that that number is correct for a minute it would seem to me samantha that a large percentage of those folks are not right using app dev tools on kubernetes to build that so are they just building stuff off of kubernetes and then throwing it over the proverbial wall just like we did in the bad all days i mean you know is is is is are my moves so old they're new again kind of emotional i don't i kind of i think i think based off of my experience and experience the things i've seen kind of when you aren't kind of using these tools and having to do like i think that docker to kubernetes percentage that that that you have um kind of just getting frustrated on doing these things kind of one-off and individually and not when you when you don't kind of have that automation and tooling in place on on large scale environments um if you're doing this kind of on on a smaller scope you might be just like i'm gonna figure out kind of how i can do this do this one hour however however however often i need to um so that's kind of maybe what i imagine that that that that i don't know the exact person the exact numbers you gave but that that that weird docker uh to kubernetes discrepancy that you you mentioned um robert any thoughts on that are we just basically you know saying yes to the boss and doing something else all together it definitely happens um you know i think i think in the cases where we've seen kubernetes go wrong that that's typically uh you know kind of the the culture is that the developers just write the code and you know they merge it you know and then it's up to an ops team to kind of figure out how all that code works how it needs to run what kind of memory and cpu it needs to use what the environment should be like how it should scale up and down and the ops team doesn't have all the all the necessary contacts they need in terms of how the application behaves so i think in the best case scenario dev teams are responsible for some of that configuration and the way the way that we've done it internally with our app development team is that for every branch that gets cut for our code we create an ephemeral feature deployment so basically like a preview environment where it's actually running in kubernetes with all of our as close to production as possible but you know with some some things kind of factored out like we have an ephemeral postgres server to serve as our database and things like that but that really at least gives us it forces us as a development team to play with our app inside of a live kubernetes environment to see how it behaves there and that's been a huge help in making sure that we catch any bugs that are going to trip up kubernetes going forward all right we'll follow that up for a minute so despite all these issues that developers are encountering we're clearly using kubernetes and there are benefits to be had including more operational efficiency and all the stuff that the itops team enjoys um from your perspective what is driving kubernetes adoption and does that just kind of force the developers down that path because they're part of the organization and i think i've seen some surveys where i think the primary reason developers were interested as the number one thing checked in the box was career advancement yeah yeah and i i do think it's it's generally an ops driven initiative if they want to adopt kubernetes it's not typically a developer driven initiative usually you're trying to solve problems around the scalability of your infrastructure around uh you know really just how your apps um you know modernizing your application deployment infrastructure right which is typically something that doesn't fall in a typical application developer's plate um as we're following in that devops or ops persona um so i think but i think i think a lot of developers are like you said kind of being forced into that situation by kind of other organizational um uh decisions that are being being made um and i think they they are realizing that they do need to learn about how their applications are getting into production in order to really um stay relevant and uh you know be able to uh operate within their within their organization samantha do you think that maybe we just forgot about the app dev side of this equation because the it ops people drove kubernetes because of all these efficiencies but they don't build applications and they just kind of the whole thing just blew by the developer and there's an assumption on the itop side that somehow our other developers will figure out how to build applications and maybe there is this moment coming in time where organizations will circle back on this side of the equation yeah i guess i hope i hope that we're not completely disregarding kind of that the application developer but i think i think we've seen kind of we've talked a lot about like scalability we've seen how how how operational folks need in order to get what the app developer may be maybe building um kind of on on a smaller scale to get that running globally to get that running um to get it kind of i i don't even know what kind of like cloud usage numbers have like what what that exponential chart may be maybe looking like but to get that to scale i think that's kind of where we've we've been using people have been using kubernetes for for for however however long and that's kind of just in order to get for to get from that smaller that smaller number to to to scale to to to production of what a lot of people need um it's kind of just defaulted into into kubernetes maybe haven't haven't haven't been able to find any kind of other new technology that maybe people are even familiar with i think with that kind of like whatever technology transition time that takes um kind of just defaulting to to kubernetes so i don't think yeah i don't think it's necessary disregarding the app the app developers but once once we kind of hear once people have to kind of go into that scalability perspective they kind of fall into this this existing um kind of just just chain and operation yeah i do think the nice thing for for app developers about kubernetes versus kind of the the days before kubernetes is that um you know before if you wanted to learn at all about how your application is going to go live and scale and you know be actually serve live traffic you probably had to learn some proprietary platform like aws or gcp or azure um or you know maybe something else entirely um so the nice thing about kubernetes is that the world has started to standardize on a particular um you know set of apis for for doing these things and if you learn kubernetes at a gcp shop you can transfer most of those skills to an aws shop no problem and so now it's it's much easier to kind of build your career uh knowing about kubernetes instead of doing these kind of very very um learning these sort of piecemeal operations for different cloud providers or different platforms as a service so then and i feel like maybe we're having a bit of a goldilocks moment here and let me explain um we have these chasses and passes and yet it doesn't seem like people are rushing to adopt all those so maybe those things are too opinionated for the developers are there too much heavy list thing to get into that environment but at the same time when you go talk to them about the people who are building applications using things like docker desktop they will tell you that this is a lot of manual work and a lot of movement of shifting of things and it's difficult and it's not enjoyable per se it gets and they want to express themselves in code not necessarily push around a lot of files so have we just not robert found the right thing yet yeah i mean i would say kubernetes is the right thing if you're at a certain level of complexity right if you if you have a large organization with multiple teams deploying to production uh you know shipping deployments every week um uh you know lots of lots of different changes um you know i think uh at a certain level of complexity kubernetes communities makes a lot of sense if you have a simple application that's just you know basically a cms or you know you're you know serving small amounts of traffic you only need to run on one machine um you don't really scale up and down or see large bursts in traffic uh you probably don't need kubernetes you can probably you know use heroku totally fine if you're if you're operating at a certainly certain scale i think uh what we're still waiting for is that abstraction layer that allows those simple applications to really take advantage of kubernetes and grow into you know a complex ecosystem like kubernetes without having to learn and deal with all that complexity up front when your application is still simple so samantha do you agree with that we're basically an abstraction layer short because if i go look at everywhere else that people build applications there are these frameworks and you work with the frameworks and you probably never see the lower level procedural code anywhere so is that what we need yeah yeah i guess that's interesting that you kind of use this goldilocks that locked metaphor like do we not have this kind of middle middle middle ground and maybe maybe that is kind of the frustration of of of as you mentioned like kind of app developers feeling like they just need to need to learn kubernetes to to make that leap and have it on their resume to to to get to that i don't necessarily know what the goal is like a chair thing like or is it like bigger pot of porridge or whatever the bigger chair um like to be able to to to get to that bigger step so um yeah it is it it does like it like having this this this like we might be forcing these app developers to to kind of to to to learn and really understand this technology that that might be not not fully necessary for what they do on a day-to-day basis like it's like yeah that they're not pushing pushing to production next time x times a day then then they don't need to to know about kubernetes and what is that middle ground of are they just forcing themselves to do it and is there something a little a little less than that that that they can maybe use better i don't know so let me follow up that thought then are we asking too much of developers these days if i look um in addition to kubernetes we want them to figure out how observability platforms work and then we want to throw a little devsecops down that end and these guys are just trying to figure out how to write code and we want them to uh absorb all these tasks that somebody else used to do on their behalf because they might do it better or the first time because if they're responsible for it but that does get in the way of writing code right every minute that i'm managing a platform is a minute that i'm not writing code so are we asking too much of developers and have we considered the productivity implications of that yeah i think that's a great question oh go ahead um i think it's a great question it's uh it's definitely one i struggle with too i manage a team of about nine developers right now and i do ask each of them to have some level of familiarity with being able to go through say our data.logs and the stats and uh if they launch a feature that maybe causes some memory issues being able to go in and look at those things um but you're right it's not what they're trained to do it's not what their um uh with their where their interests lie necessarily um i think it's context that they all need to have but i i'm i'm very lucky that we have also a large team of sres who can really help us dig into these details um and so i i don't feel comfortable really making it their primary responsibility or making the you know the the primary person responsible for for seeing those things a developer um i like having a full-time sre on board to really you know take responsibility for those things but i do think the developers need to at least spend you know say five percent of their time and their brain space knowing that these are issues knowing that you know memory usage is a thing and you can't just you know have leaky memory uh in your application and uh what that looks like in production when you do have that problem because at the end of the day there is always going to be this this gray area between where the application ends and where the infrastructure starts um and uh developers kind of need to meet the ops folks halfway there and that's that's the whole ethos of devops i think is to to help developers kind of start to bridge that gap samantha you want to add anything to that yeah yeah i guess i was going to kind of try and take yeah somewhere some more type of things i don't i don't i don't i don't manage kind of any engineers uh but um i guess we i think at influx we want to always make sure that like our app developers have at least like a core baseline of of of kubernetes and how how that can impact the ops folks or the sre folks like how how what they're developing and building i think yeah as robert mentioned they need to make sure they take into consideration of of of executing these things in kubernetes so making sure yeah i think finding that right balance where they're knowledgeable about about kubernetes and and how their work will will impact and live in it but but but leaving the core of the responsibility to the ops and and um the officers sre folks i think that's probably a fine line and good balance that engineering managers i guess not me but their other like engineering engineering leadership needs to uh needs to find and i think from from my experience kind of as a product person and working with these different teams i think we've managed to do that do that pretty well making sure all our all our our developers are somewhat knowledgeable about about how we're using kubernetes and and how how their work will impact kubernetes but believe in kind of the heavy lifting and kind of expertise to our to our to our ops and srd folks um i'm sort of deploying it so that sounded a little bit to me like rather than shifting left we just all kind of need to lean a little bit more left so that we can kind of figure out how to maybe work together and have that little kumbaya moment robert what's your sense of um what is the challenge in making that cultural bridge between ops and developers i mean we've been on this devops thing now for the better part of a decade and you know it seems like we're still having these issues so what's up yeah i think um i think one of the issues is that you know they're really two different personas ops and development right um the way i've seen it work best i think i think leaning left is is a great way to put it um but i think the way i've seen it work best is um when you have uh you know a pure ops team that's responsible for really the underlying infrastructure of you know making sure kubernetes stays up to date um all the the applications that that focus on things like uh how traffic gets into your cluster certificate management dns like all those really low level things that no developer ever really has to think about having a dedicated ops team for that um but then also having a more devops engineer more co-located with the development team who can focus on okay how does the app get into the cluster you know how does the app scale up and down what kind of memory and cpu does it need so somebody that has a little bit more app contacts and you know basically a person who can service that bridge between the peer development team who's just writing code and the pure ops team who's just providing the infrastructure i think having a person who who's meant to serve as that bridge and who has personal relationships with the people on both sides of that fence really can serve as a conduit for the information that needs to cross between the different sides of that wall samantha how smart will things get in the future i think part of the problem is if i'm a developer i'm expected to know the question to ask to go figure out what is the root cause of some issue and i'm supposed to come up with the queries and the whole nine yards and all i really want is like for some platform to show up and when i sit down i want an email or even a voicemail or whatever it is that says here are the three things that you're likely to get fired for and you should go fix so a smart can smart get and basically just inform the developers that there's a couple of things that you've got in your code base right now that are going to be problematic and you should go fix those three things yeah i imagine i think just i imagine things will get if if something doesn't exist like that already like some some some person will we'll fight we'll figure out what i think we sort of mentioned kind of maybe what like ai capabilities could be implemented in this but but i think what we've focused a lot on is yeah making sure that our app developers are spending time writing code not not not troubleshooting kind of these these operational problems and and and being able to maybe fill in those gaps that that that they are wasting those that they are kind of not spending their time most efficiently on um i imagine that though that that these things will get smart and just just more efficient too i think like whatever tools are out there whatever whatever i think kind of maybe bring this consistently bringing open source back in whatever open source whatever open source kind of software there is to to do that kind of how how it may need to be uh adjusted or kind of any custom code might might need to be adjusted to fit fit to fit a certain person's environment um i imagine kind of kind of the possibilities are are going to be coming out at us sooner than than later so all right robert i think your mic is out can you hear me yeah yeah um well what do you think about that you know can ai save us from ourselves here if i'm a developer should i spend all this time trying to figure out what observability and security is going to be all about only to wake up two years from now and in a in a net in an entirely different world where i don't have to worry about that stuff because it's all taken care of i don't think we're going to wake up in that world anytime soon to be honest i am very excited about about the potential for ai to help on the development and op side of things but there's always going to be um it's always going to be some kind of you know human level real world context that needs to be taken into account like how important is this application versus this other application which one should scale up and what you know which one should get preference for for resources um you know which one has more business value that kind of thing um i think uh you know robots can be you know the the thing that that machines do really well is kind of repetitive tasks that humans don't really want to do what they do poorly is is take into account all that kind of human level context about relative importance and values and things like that and i think you're always going to human in the loop to to help make those decisions so i know i don't i don't think there's any reason to uh you know just hope that ai is going to come and save us i think it's it's important to learn these things today all right let me follow up on that we um would argue that kubernetes is perhaps the most powerful platform i've seen come down the pike in quite some time and it has a lot of benefits it's also the most complex there's a bit of a trade-off and we we live in this age of conspiracy theories so let me give you this one there's a conspiracy theory that says you know we're creating all this kubernetes stuff because it forces organizations to consume it as a managed service they basically don't have the internal expertise to stand it up it's hard to train it's hard to sustain so maybe the path of least resistance here is to just outsource the management of the platform either to a cloud service provider or to somebody like you and um is that more costly at the end of the day or less costly or do you think you know what's the economics of that argument from your perspective um so i i have my own uh sort of conspiracy theory around kubernetes that's similar to that but i think i think kind of its inverse which is that i think google saw aws kind of eating its lunch in terms of uh being able to have all these um basically making tons of money uh serving cloud compute right and i think they created kubernetes as a sort of open source aws as an open uh open platform for an open api for basically deciding and declaring how workloads should run in the cloud how they should communicate with each other how they should scale up and down and that made it really easy for uh if you have kubernetes to move between cloud providers um and i think i think that's the really brilliant thing about about kubernetes is that it creates an open abstraction on top of every cloud provider so that you're not really stuck with one cloud provider you're not stuck uh you know once you've built a whole bunch of infrastructure and tooling on top of aws services you you um you know in the battle days you it would take you you know years to transition all that to a new cloud provider but with kubernetes it makes it really easy to move between cloud providers um it is still very very complex but i think that complexity uh just existed as you know aws primitives and gcp primitives before whereas now it's more of an open thing all right samantha as it relates to kubernetes at least you have any of your own conspiracy theories you want to share or are you good i don't think i don't think i don't think i have any i don't think i i should have i should have i should have thought of something last night but well let me ask you this though um to robert's point we have these highly distributed computing environments that are starting to emerge we have apis everywhere we're going to have kubernetes at the edge we're going to have it in the data center we're going to have it in the cloud are we going to be able to really build those kinds of highly distributed applications and is that sustainable or have we reached beyond the capability of the developer community at the moment and we got that's going to be a big jump from where we are to this highly distributed computing environment because those apps are hard to build with microservices don't make it any easier yeah i think i think kind of focusing on the kind of the distributed aspect of it um i think i think we kind of would have to kind of just just kind of just for for things to kind of grow from a from a from just a single like a smaller scale app develop development to to kind of a broader spectrum type of things i think i think we will and and just the way kind of we've seen applications growing and developing like being able having to do that and finding kind of how how to make this easier for the app developer i think that might be kind of intimidating kind of you you kind of walking through that that that description it does seem probably kind of intimidating for any maybe app developers that are that are on this panel but being able to do that kind of easier and more efficiently and and kind of in a less intimidating manner is something that i think will want to be moving towards i guess maybe is that shifting left towards so um that's where i can see it going all right more shifting left robert follow up on that they say kubernetes is a platform for building platforms so and is the next platform that sits on top of that maybe this it could be the database layer for all i know but there's something that people just write to that masks all the underlying complexity and maybe i'll never see kubernetes if i do this right yeah i mean if you i would i think i think a platform for building platforms is a great way to describe i think the the best potential of kubernetes i think a lot of organizations will just kind of throw a very vanilla kubernetes stack at their development teams and say have at um and that that can be a little daunting for those developers i think the best organizations have a platform development team that actually takes kubernetes you know under the hood and then provides some abstractions that makes sense for their particular business the way their teams are set up um the kind of personas that they have in their development teams and ops teams um and they they have a platform team that's creating these abstractions uh and basically building their own platform on top of kubernetes so the development teams don't end up having to know a whole lot about kubernetes they provide some kind of yaml file or some other kind of manifest that's specific to that company and that goes through some you know uh you know rube goldberg machine of uh you know cicd and their application ends up in uh in production um i've only ever seen that work well in a very organizationally specific context every time somebody tries to do this in a way that's going to be you know applicable across many different types of organizations they end up hiding some complexity that uh some organizations need or you know it never really quite work works out in a way that's uh you know organization agnostic but within particular organizations i think it works really well what do you think samantha can the database kind of help us out here and provide that layer of abstraction so long as we have some sort of to robert's point you know ability to drop out of it to go fix something when it doesn't quite work the way we want it to yeah yeah i guess that's where kind of just kind of the observability kind of my my expertise kind of observability and monitoring of of the of these aspects making sure to to to kind of automate whatever um kind of push to production pipeline your app developers are doing and and and knowing maybe finding where those gaps are maybe where where those those are failing and having to bring in those those expertise expertise on the upside and and um and and being able to implement and improve those changes but i think but i think yeah i think building having the the the tools around and kind of the entire kind of app platform set up to to to kind of to operate all of these things and and to get to get them executed is is is where you might end up piecemealing things together but i think we'll we'll we'll create the kind of the most efficient um kind of operation all right with any luck we just write to the apis and ignore the rest and cross our finger right here we go i guess eventually i guess eventually by now all right robert let me ask you um if i look at what most of the distributions of kubernetes that are out there i think there's over 100 of them but um they're basically all based on the version that google presents or gave and it and that was designed for a web scale company it's huge and my question is do you think that maybe we're not thinking enough about these lighter weight versions of kubernetes that people can just run all the way down to their desktop or on a couple of servers and they don't need all these extra bells and whistles they just get like kubernetes core and maybe that's where we should be going to make it more accessible for developers yes i think i think there's two different places that i've seen those um those other flavors of kubernetes um really uh come in handy uh one is for develop development environments uh so we build an application at fairwinds that is um you know serves kubernetes users so often we need to stand up lots of little kubernetes clusters within our development environment um just to test things out and to have you know kind of a lightweight single machine you know kubernetes api um where we can deploy a helm chart and things like that and and uh kind and mini cube have both been very great um for us to work with in that in that particular environment um another is is i've seen a couple cases where it makes sense to folks really want to deploy applications into like say a raspberry pi or some very small resource constrained environment and having a lightweight version of kubernetes that can run like k3s that can run without a lot of overhead i think is super helpful i do think there is a place for for these kind of lighter distributions of kubernetes are these kind of developer friendly distributions of kubernetes but i think by and large you're going to see most applications that are getting deployed to the cloud getting deployed on um like gke yeah eks aks those um uh managed services are managed kubernetes frameworks samantha do you think that that presents some management issues because if i go back in time the original thought at least around kubernetes was you were going to create kind of one big giant cluster and people would share it and they would deploy their apps on that and we keep it reasonable to manage soon like we're back to square one because it people especially application owners as it turns out you know were absent that day we were all taught to share in fifth grade and they don't like to share and so now we have all these little kubernetes clusters everywhere and now they're going to be out at the edge and are we prepared for the management challenges that go with that both from the perspective of a developer who's trying to build to that and an i.t operations team that's trying to manage that yeah i think i think possibly maybe a little more prepared just kind of like who's more like a little more prepared from the operational perspective i think that's kind of where just having that kubernetes expertise can come and being able to troubleshoot any any any problems that come come up from kind of this large managed service the the operation the operational folks that's kind of where you kind of need that that that balance right is is being able to bring and bring in the experts when when when the time is needed and and and and being able to have that knowledge share back back to those app developers that might have caught that might have like created this this this this expanded kind of managed uh kind of environment and kind of what what lessons learned could could come from that but i think that's kind of where that that that balance of having that expert that expertise on on on the op side but being able to to to kind of teach kind of lesson learn back back to the app developer side can can help resolve resolve those problems or at least kind of figure out how how it can work how you can build whatever application you're doing in the future and have it kind of run seamlessly maybe work out any bugs or kinks um currently in your setup but but resolve those down the line um that's kind of how i see that playing out all right so robert do you think that that ultimately will be the dominant model where there's going to be these fleets of clusters or do you think there'll be instances where people are still trying to get people to share one massive cluster the idea is definitely the one massive cluster or at least maybe maybe a few clusters like a staging cluster and a production cluster so there is at least some separation from production from your development environments but what we're seeing is especially in big enterprises at least every business unit has its own cluster every team has its own cluster and it does kind of make sense at the end of the day it is a very clean division of um uh you know in terms of security in terms of um reliability and things like that if you if you have your own cluster there's no chance what something this other team does is going to take down your application and so i understand why enterprises are going with this this giant fleet thing and i and i do think it's here to stay just because it does make such a clean um break in terms of uh security and all that um is it is a pain to manage though and if you are an ops team who's who's responsible for making sure that you know this cve that just got announced we're not running any vulnerable versions of kubernetes you might have to go in and update you know 50 different clusters 100 i mean i've heard of organizations running hundreds of clusters um and having a team that can go in and update the add-ons into those clusters and update the underlying version of kubernetes know that they're not going to break anything have all the context necessary for what's in those clusters it's uh it becomes an operational nightmare and you really do need something uh something there to help you you know understand what your risk profile is where all these clusters live how to get into them etc all right well let's keep on this theme for a little bit um samantha i think i'm old enough at least to remember you know the year of the land it was back in the 80s and 90s and it was this was going to be the year for sure that the land took off and that went on for about the better part of a decade now i think i'm on year three or four depending on how i want to count of the year of kubernetes and i'm now four years in so when do you think that you know kubernetes is really going to go mainstream in the enterprise and become a dominant platform if i think if i talk to people everybody's got one or two clusters but the bulk of what they're running still is legacy um monolithic applications so how long till we get there as my kids like to say in the back of the car i i don't know i i i i kind of think that we're kind of already on that that train of of getting there from from from my spins and kind of people that that i talk to and other kind of cloud cloud engineers that i've talked to like kind of making sure that everyone i think i don't know just bring back to that like maybe like why people find that they need to have it on like not just having it on their resume like there's kind of like a purpose behind it and the fact that as as we're we're pushing more to the cloud scaling kind of scaling in in the cloud um um kind of building that having more engineers uh um on all levels kind of have not necessarily that expertise but that knowledge base of of of kubernetes and and um yeah i kind of kind of not sure kind of just like when and any kind of new when a developer kind of joins a a a cloud a cloud product out there i'm sure they're kind of getting entered and having to do kind of kind of have to do this kubernetes training or kind of having that that background around it so i think we're definitely moving in in this direction where it becomes kind of kind of pretty pretty normalized in in these these these cloud products and apps of of of having this kind of base knowledge base so um yeah i definitely think we're kind of in that in that direction i don't know if this this three to four years maybe another three to four years it will be kind of pretty pretty pretty widespread knowledge i don't i don't want to give like an exact we're not betting on on time here so that's what i would say robert what do you think about that because if i look at it in history at least i'm hard-pressed to name any technology that didn't take 10 years to wind its way through the enterprise and is that just the nature of the beast yeah i mean it's uh the the difficult thing is like it's it's really easy if you were spinning up a new company today a new application it's pretty easy to design things in a way where it's like okay we're just gonna be on kubernetes it's going to be all cloud native everything but these enterprises have a ton of legacy applications that they're they're probably just finishing up the containerization of um you know maybe haven't even gotten that far so there are you know a lot of applications that were just never designed to be in kubernetes they were never designed to be cloud native and uh you know there's there's a lot of catch-up uh being played right now um most people that i talk to um you know have at least accepted that kubernetes is the way forward you know if if they're not already there or working there they they know in the back of their head once i have some time i want to get there there's very few people i talk to who say you know kubernetes is just not uh it's just a non-starter we're never going to get there um so i think we're we're well on our way as samantha said i think i think we're we're already like well in the heat of this transition uh but there's definitely still a little more a little more work to do well let me follow up on that with you specifically but i feel like there's a little bit of this cloud native whitewashing going on and people are building these or taking a monolithic application that sits on a database and check the whole thing in a container and call the cloud native um you know and then maybe they'll get around to breaking it up later but is that because there's a business value to doing that or is it because you know it's fashionable and i mean i'm just think it's a cool thing to do and i can say that i'm playing with containers yeah to some degree you're right um i think you know a team gets a you know a top down directive of you have to get this into kubernetes and so they take their monolith and they you know wrap it in a container and it's a container that uses you know huge amounts of memory and cpu and it's just it's it's totally not meant for uh kubernetes or cloud native uh but i do think there is value in doing that um one because it just it sets the stage for okay we're now in kubernetes any future apps that get created can get moved into this platform and managed in a consistent way with our big monolith um and it just it um it sets in some some muscle memory around developing around kubernetes uh so i think there's value in it but you're right there there's a lot of work that needs to be done beyond just wrapping your application in a container and sticking it into a kubernetes cluster all right samantha from the observability perspective is that progress because now i've got a monolithic application i've got a semi-monolithic application sitting in containers and then i got a bunch of microservices hanging around the side of it that i got to manage and i think you know we promised people two things right we promised them that they'd be flying cars and that it would get easier to manage and i'm not saying either just yet so you know what's up yeah i think that's actually kind of based off kind of what the work i do day to day is being able to help kind of organizations even not as many kind of single single developers but yeah organizations that have these kind of like broken up systems and being able to observe and have insight into them um kind of kind of as a whole i think i work with with the the product i work with telegraph it's it's the core of it is ingesting data in as many kind of these popular data sources that we need so i think whether like if you're working on a legacy system as well as kind of a newer kubernetes model being able to to make sure you have observability into that entire into your entire infrastructure and stack is what is what at influx db we want to make sure that we're able to do for four four people so if you're not just you're not just looking at your kubernetes customer this this other thing over here is breaking uh but being able to make sure you understand and and and have things as a whole and then maybe and and help is assist that transition i think uh your previous topic talking about how long is that transition going to take being able to still monitor those those legacy infrastructures and platform and devices and platforms um while slowly transitioning over to to maybe your more newer newer cloud tech products um i think those those models kind of exist are much more common than than maybe maybe these this this this new flying car feature we hoped but um and being able to make sure we have those those capabilities to to to hope to to maybe get there eventually but but but but probably not as soon as soon as we we hope but making sure we have the the tools to to to to to work with what what we currently have and what suits suits the best for for not only like small middle middle-sized companies but these large large enterprise businesses all right i think you just said i shouldn't hold my breath for either but we'll go here i've been holding back this question from one of the attendees to now and i thank you for their patience because i think they asked it about eight minutes in but the question is and robert i'm going to throw this your way is how difficult is it to get to kubernetes from legacy.net platforms if you're a developer and you have those kinds of skills and knowledge and in addition to asking that question i'd like to just follow that up at the same time with you know should i really go after developers who have some legacy background or am i better off just going out getting developers and training them from the ground up for this brave new world because maybe the other developers are bringing a legacy mindset that might not be helpful i don't know i'm just asking the question um yeah it's uh it's always it's always a bit of a struggle to get a legacy um a legacy application out into kubernetes um and to get you know legacy developers into into kubernetes i think there's a lot of old ways of thinking about things and old ways of doing things that um you know instincts that aren't going to serve you um so it's definitely it takes it takes not just it's not just like learning a new programming language i would say it's it's a total shift in mindset a shift in a way of thinking about things that um those folks need to need to be able to wrap their heads around and i think it's going to come up to you know a person-to-person decision whether you um you want to kind of rewire your brain to think in a kubernetes way or if you still want there's still you know a you know a large market of enterprises that have not been able to migrate their applications and aren't going to be able to get around to getting their micro their applications migrated um and there's going to be a market for those legacy legacy platform engineers so um i would definitely encourage folks to you know start leveling up on kubernetes and thinking about um application deployment uh in the kubernetes way of things because i think it's it's frankly a better way of doing things and it's i you know i just i kind of geek out on it i think it's just really cool um the way things are deployed these days um uh but it is it's it's not a it's not an easy lift all right sometimes you're better off forgetting what you know and just trying to start that thing all over again all right samantha what's your best advice to folks as they kind of struggle with all this stuff and they look at it and um you know what are your thoughts on where they should get started and and do i need some sort of grand plan or do i just kind of dive in and hope for the best and get there through the school of hard knocks um yeah i don't think i don't think kind of users and developers out there kind of need need a grand plan that that that exists out there and i think even just whenever i'm reading about it and trying to understand how how our organization is using kubernetes i think taking advantage of all the all the not just like information and and and i'm just like documentation videos that are out there but but just the actual tools that that people have built out there that you could that you could that you can hopefully utilize and and fits your fits your application or whatever you're building as well i think that's where i've seen kind of this be kind of the least head the kind of less headachy is is what is being able to to utilize other tools that are out there and and other things that people built maybe building your own tools if that's if that's kind of what what might best suit you for maybe these kind of redundant this redundant work but yeah to not be intimidated by by everything that's out there knowing that that other people are kind of in the same boat and then trying to trying to ease this this headache and and um or are our building or building other other other tools around it to make to make it easier so i think i think yeah not necessarily a grand plan but just keeping yeah keeping an open mind of if you run if you run into roadblock to see to see what else is out there and and knowledge share as well so all right robert what do you think deep end of the pool and the way we go and hope for the best or is there some other more elegant way of thinking about it all right so um i can tell you one of the best things for me as i was ramping up uh on kubernetes was to just go to digitalocean spin up a kubernetes cluster and start self-hosting a few a few projects that are kind of pre-built for kubernetes there's a there's a markdown editor out there that i self-host for myself to take notes um some picture sharing you know type applications and that was just a great um way for me to kind of get a sense for okay what are the fundamental concepts in kubernetes how do applications get deployed it's a great way to kind of start wrapping your head around around all these different uh concepts and um uh get some real hands-on experience you know i can read all day about a new a new topic and i won't learn a thing but if i actually like get my hands dirty and start doing something i think that's that's the best way for me to learn personally all right next question robert i'm going to ask it to you and then semantics uh she's going to have the advantage of a minute to think about it more but um so there's a whole community of folks out there and they contribute to kubernetes and they make all this amazing stuff happen and there's a lot of innovation but let's just pretend that you were king of kubernetes for a day and you could do anything and it would be the one thing that you would say by fiat i want to see this available tomorrow to make the lives of developers and i.t people easier what would it be yes i think you touched on this earlier a little bit but databases and persistent storage are very hard in kubernetes um it uh it's at the point i mean as a company at fairwinds we basically tell people don't do it because it's it's just going to cause headaches it's going to be a pain you want to keep your databases and any persistent data out of kubernetes kubernetes is really meant to be an ephemeral place uh you should be able to just tear down your cluster lose everything and you know start it back up again you know the next day and uh it makes it really hard to to deploy applications in a very kubernete-centric way i still need to deal with a lot of uh aws concepts mainly to interface with rds and s3 it's all the persistent storage that i have to deal with i still have to deal with you know cloud cloud primitives in aws instead of having this nice open abstraction layer that i can deal with so that would be my one wish is if we could get some kind of persistent data into kubernetes all right but otherwise stateless rules right yeah exactly all right samantha you're a queen for the day what are you going to do i think maybe just even speaking on like how this transition from from older legacy systems like ideally if we could people who are kind of really stuck in these like the this is how we've been doing it for x amount of time and kind of can't have that culture shift how we can develop some magical wand that can transition everything that that they do into kubernetes or just have have people being able to convince people with my kind of mind into into being able to go into into this this this newer technology i think would expedite that that that transition time i think we've seen with all these these this this technology adoption um and if there's any kind of kind of method of being able to to to make that transition more more seamless or just kind of more being able to all of a sudden change people's perspectives on it i think i don't know that's kind of my my answer to that magic wand question all right and then i would just say that it's almost a given you're going to have a bad day with kubernetes and building apps you're going to have some level of frustration so when you get to that moment robert what do you think people should do walk away come back keep going do i need to break because i think a lot of people get into this and they decide to go build something and then they throw up their hands and then they give up entirely and they go back to what they know so how do you kind of on the worst day keep that momentum going yeah that's uh that's a great question i think that's that's a problem i've had throughout my career whether it's kubernetes or you know learning javascript for the first time or whatever it is um personally i i i will start just by getting away from the computer for a minute go for a walk or something clear my head but i i think the best thing about kubernetes is that there's a a massive community around it there's a huge slack where people are very helpful and we'll happily give feedback um there's a huge ecosystem of partners if you're like as an organization just stuck we can't get past this you know we don't know how to handle ingress in kubernetes there are plenty of folks out there who can um uh you know operate as consultants and to have seen you know kubernetes go wrong a thousand different ways who've set it up in a production grade way for hundreds of organizations you can get help very easily because it's such a big open framework with with just a huge ecosystem around it so look for help don't don't don't get stuck on your own uh keep uh keep asking around keep asking other people um you know either for free or hire a consultant all right robert said misery loves company samantha what do you think yeah i think yeah i think definitely there's kind of reaching out to to to the kind of the community or or other experts that are out there but yeah or just even i think kubernetes as a whole can kind of just be pretty intimidating in the grand scheme of things and trying to trying to understand the kind of step by step and break coming back to it breaking down breaking it down step by step and looking at kind of trying to tackle these this bigger this big this big mountain kind of kind of hundred feet at a time i think that's kind of would be kind of the the best the best way to approach it if like this one that you might just be stuck in this one roadblock whereas everything everything else um involving it might be a lot more seamless so um yeah i think the combination of those would be would be the best way to approach it you think that people should do this as a hobby before they do anything else and just download it onto my laptop and play with it and start building stuff there so that maybe then i'll get a certification and then in six months to a year i'm actually ready to take on a job or do i wait for somebody a lot of times i talk to developers and they're like well nobody's paying for me to take the training so i didn't do anything should they wait or just keep going robert uh that i mean that's what worked for me honestly was playing with it on my own uh finding reasons to use it um you know even if they were just kind of toy problems that weren't exactly uh you know problems that operated at kubernetes scale um i i totally recommend playing with it on your own it's fun it's uh it's it's a very interesting subject and i think it'll serve you all in your career no matter what you end up doing all right and who knows might lead to your next big raise right yeah all right here we go hey we have four winners for our amazon gift cards today they are jay allen d christopher m allen j i want to thank them for attending along with everybody else today i hope this was helpful i want to thank our guests today for sharing their knowledge and insights it was awesome samantha thanks for being on thank you thank you for having me mike all right and robert thank you for being on robert's like going where'd that hour go man that was just me yeah thanks a bunch mike all right guys thank you all for spending some time with us everybody have a safe day and whatever you do find time to experiment because that's what's fun alright take care guys

Channel: DevOpsTV

Views: 40

Rating: 0 out of 5

Keywords: devops.com, devops, devsecops, continuous delivery, microservices, containers, devopstv

Id: uHuJID1IOgY

Length: 57min 46sec (3466 seconds)

Published: Mon Sep 27 2021