 requirements that you forgot to consider to be stored on private clouds we can do that when we only mingle the song what's that baby that they already have you got it it says on the ends not a problem let's get started good morning good afternoon good evening depending on where you are as you as you listen to us right now I am Steve Belgrade of the co-founder of Redmonk Redmonk if you are unfamiliar with us as a developer focused industry analyst firm and I'm here today with Chuck from Red Hat Chuck you want to introduce yourself yeah thanks Steve Chuck Sabota I am the senior director of cloud services go-to-market at Red Hat helping our customers and Red Hat as a whole make a pivot towards cloud services now it's standing and I think we'll kick off the discussion which with what is I'm sure a controversial statement for some that that you said a couple of times now which is that developers don't care about containers or Kubernetes can you can you take that apart for us a little bit what do you mean yeah although I think the Red Hat container police might pull me out of the room here in a second and I'll be serious this so a bit of history about myself so I I'm a developer by trade right as I started out with years ago went to school for it worked in C Java net it's funny being a being a big dotnet guy even it even a red hat right and one of the things as a developer and a developer leader that I you know really abhorred is that having to worry about all his underlying technical details or implementation details and toiling through them and where I think what happened in the market in the past few years is you know and red hat is partly guilty for it right we just talk so much about tech like containers and cube as a kind of the in-state what's what he caught what a developer should be working with the reality of it is a good developer you know is the epitome of the 10,000 principle which is maximizing work not done is 5a paraphrase and man I mean the job of developers not to worry about writing Docker files or Kubernetes the animal the job of the developer is to implement business logic and break the land speed record of getting to production so that whoever they're coding for can be you know for it both first the market and and best in market so you know that that hook of saying that they don't care you know developers actually do care about containers and cube but they care about enough in such a way that I want someone else to be accountable or responsible for for that I understand what it unlocks for me but man I really wish it was boring and be hidden for me so I can focus on writing my my good business good yeah no I think I think that's fair you know I think you know when we have the conversations you know from a market standpoint here you know practitioners all shapes and sizes different industries and so on you know really what we end up finding is is that I think it's it's developers are they care more about the container right you know just because it's like hey how do I package up my app and make it easy to you know if nothing else sort of deploy to you know from my you know my machine to something else right staging you know test production whatever it might be but do they really want to deal with Kubernetes right in most cases no you know which brings us to sort of the the you know sort of the next question or a topic I guess which is sort of the developer experience associated with Kubernetes and this is obviously evolved over time I didn't think there was a developer experience right well and you know I guess that's part of it in the sense that in the early days you know this was quite clearly not a tool meant for you know the developer right you know because you know for folks I'm sure most of folks in line understand the history here but you know for those of you who are a little new the environment you know where Kubernetes came from originally was that we had containers you know which were you know packaging up a pre-existing Linux technology made it really really easy you know for developers to you know basically encapsulate an app you know something they needed to sort of distribute or use or whatever including all the dependencies everything you need without the overhead of a VM right so you didn't have to wrap up the entire operating system everything goes along with that so the popularity of containers with developers was through the roof and what ended up happening as a consequence of that is is that you know sort of a bunch of folks looked around and said all right if developers are using these we're gonna end up using them in production how does that work right what do we what are we gonna do we need to run a bunch of these you know how do we schedule them orchestrate them etc etc so Kubernetes was one of multiple projects you know sort of intending to be that that sort of solution it clearly emerged as the victor it is now essentially an industry default at this point and anyway so back to the back to beginning like in the early days it was very much a tool meant for operators admin etc you know sort of intended to you know for them to help manage and sort of the sea of containers in production very much not a developer tool and arguably you know at the juxtapoint it still isn't what we have seen however and we'll get to the managed services side of this in a little bit our solutions that have emerged around it to abstract it to make it easier to consume so developers don't necessarily have to deal with all of the bells whistles dials knobs you know switches etc and you know they can more or less get to the point where okay I have a container I want to deploy the container and great you know some other stuff happens I don't necessarily need to worry about that we're not we're not quite to that level simplicity yet at least in most cases but I'm curious you know Chuck from from your standpoint you know that the conversations you're having a red hat you know customers developers you know your own experiences a developer like where do you see the developer experience at present yeah so I think if you back up a bit of history if you look at containerization right you know really when we had to hand it to dig the docker ink for you know really unlocking the power of containers I mean containers have been around you know the classic example so it's like BSD jails I think right you know in what containers are basically taking advantage of Linux primitives what Docker did was create an API around it which is developers we know how critical those are our to our work to make it ubiquitously easy to run you know whatever the heck you wanted to from whether it be a spring boot you know cloud native app dev are doing you know put a database in it which I don't necessarily would recommend off the on day one you know write something going or even hosting a you know big honking monolith but you you want to benefit from the homogeny of the of the Docker API and so that was great you know you mentioned something earlier you know it runs on my laptop right so I you know it's easy to package I can I can you know deploy it out but the reality of it is even with the API if you think about the four levels of lock and you know proprietary versus open source data which includes locality sovereignty gravity the API in the configuration I think was kind of forgot is how important that configuration piece is namely so I could build a container on my laptop right now and deploy try to go deploy to run out open shift service on the AWS it would fail if I was using a root user or I did not take care of security context constraints for XC Linux and things like that right it would also fail and some some cases I just discovered the other day I had an app that had the law for J vulnerability it because I was running advanced cluster security one of my clusters it got it would block me from from the point and I may have that on my laptop right so I think we have to take a step back and understand that from a portability and homogeny perspective there are definitely limits right so containers are enabling technology similarly Kubernetes and enabling technology right the Kubernetes API or the Kubernetes you know the founders of the project you know Joe Craig and Brendan you know it was there were never it was never intended to be used as this as a platform for developers to consume directly right it was always intended to be a orchestration and management framework to control the lifecycle of again that tech call containers for you to build a platform around in a lot of cases that would be like you know Redats for business is to build a platform around Kubernetes most of the customers and you know enterprise no fortune you know 500 whether the automotive you know telco healthcare etc their job really isn't to be building a platform because to build a platform you got to resell it right because it's that's the amount of investment it takes to make you know Kubernetes usable at scale it is pretty high so I think from from that perspective we really see them matured over the years is that even though we've been saying this at since the very beginning that Kubernetes is a is a again a framework a tool set for building platforms you know you go to keep coming on to keep constant so was the thing you hear all these stories about these you know companies doing cool things in Kubernetes but what they didn't tell you is all the you know blood sweat tears and eyeballs are left on the floor to get there and it's scale it breaks right so we see a ton of developers in a lot of cases they're really not developers are actually what I call platform architects or DevOps engineers you know embrace containers and coo but then when you try to expose that raw to the breadth and depth the nine to five developer that makes it the bulk of it it team boy there's a lot of retraining this has to happen and and a lot of process and controls around it you know containerization you thought you thought dealing with seven you know 70 VMs was hard trying to deal with 7,000 containers and making sure that everything has been safe and not breathing the same way right and you know so what you don't want to do is you know think the containers in kube is like a silver bullet you know you don't you definitely don't want to just kind of let that let that open across your organization uh all willy-nilly like else you know and that's what I've experienced working with a lot of customers in the past few years is that when they do that they a lot of times they get a bit right it's good to have a structured turkey application platform just so happens to use container kube that unlocks the power of tech like containers in kube while hiding or reducing the complexity of the tech like containers in kube right so you know I think so we've talked about sort of you know some of the benefits and some of the gaps I think it's worthwhile sort of assessing what developers want right and you know there's a statement you know that the common statement the developers want a platform to be boring right you know oftentimes you hear the the metaphor use like you know they talk about paved roads right where it's like hey you know this is just a you know there's a road that I stay on I have guardrails paved it's very straightforward and I don't have to sort of think about much right you know versus you know I don't know off-roading or I guess sort of under feet you know what's your what what are your thoughts in terms of you know the customers that you talk to and that the either developers or or admins that work for them what are they looking for yes that's actually mentioned roads so I'll go back to one of my you know favorite quotes I like to quote right I'm not very smart I just steal real good ideas from a bunch of other people matching together and there was this quote there was supposedly attributed to Henry for back in the day I said if I asked the people what they wanted they would have said a faster horse right what they cost what the people were actually asking for was not a faster horse they just want a better method a faster method of conveyance right a transit but they're limited by the understanding of the environment that they're in and what they know and what their expectations are um so when a customer says I want something I approach with a bit of the a challenger mentality right if a customer for developer says I want containers I want kubernetes even I want open shift right first thing he says that do you really want the tech or is it that you want a better walk better way to build deploy and manage applications of scale safely reliably that and we usually get to that right there right and then so from a developer's the end point you know specifically again these that that that nine to five coders that the backbone of what it takes to get an application out the backlog owners of items and they're you know what they care about more than anything else and and you know I haven't been a hands-on keyboard developer for a few years but uh I don't think it's changed too much the biggest thing that was that would inspire me to slog through those long days and nights was to see my code in production to see it being used to see value coming from it and if I am distracted by things like containers and kubernetes configuration the same or even you're going back way back when I was thinking about thinking about this like when I build an application I hated dealing with like session replication distributed transactions configuration management HA things like that that wasn't business logic that was all the stuff I had to do just to get at the prod but the reality is that wasn't the actual application that the end users were touching so developers what they really want is they want to see their application and production as quickly as possible but safely and very reliably right because they want as many people touching it as possible and because that one makes them feel valuable yeah no I think that's fair and that brings us to sort of the next I guess topic of discussion which is you know sort of buying usage preferences right so what do you what do you see I mean you know we have our own thoughts on this at Redmonk right you know so what we see you know for example or in a huge preference for self-service a huge preference for you know things that are managed right you know basically I want to take this off my plate you know the running the sort of management in some cases the abstraction Kubernetes and put it on someone else's plate you know sort of as it were but you know what other conversations you're having what do you what are you hearing people looking for a lot of that I think a lot of customers have realized that you know tech is hard right I think we're seeing another renaissance like we saw years ago you know when customers started moving to AWS and Azure you know to Google Alibaba and a lot of other clouds right customers realized that it wasn't in their best interest to you know rack stack cable cool their own infrastructure right and then we went into this but I think we we then rotated into like the past stage but that's old Heroku and Cloud Foundry world right and then due to the limitations of those platforms then there was a swing in the other direction to kind of like a CAS which was not opinionated enough to actually be productive and now we're coming back towards I think that the past side of the house where the customer just really wants to focus on an app and data and so with that specifically for Red Hat you know our our paths and there's tons of arguments I'm sure this isn't flaming some people are watching this of what a past truly is right but you know if you think about I look I look at Red Hat as a open shift specifically as a past in other words it is your entry point is your business code not your run times or containers or anything else the platform handles it well you can put that into your own data center right but if your data center and a lot of them have 10 years of tech that laid in and it's really hard to take something that's cloudy like open shift and ram it in there so we see you know quite a few challenges with that and our customers realize that and when they're fighting their own data center or fighting their own infrastructure they're fighting maybe the configuration they did in open shift that really really kind of shot themselves on the foot they're not focusing on applications right they're doing 24-7 operations instead of nine to five innovation what we're seeing from customers from a cloud services perspective and this is why Red Hat is doing such a big push in that is a lot of customers are again as I said are sick and tired of running it and so now we have options for them to say hey if you want us to manage everything below your application we've got products for you you can sleep better at night you can often you're going to put the risk on the red hat backed by financially our slas to ensure that your platform is ready to go right but if you need to burst down from the cloud or run on you know an edge device or even in your data center uh we have a consistent experience through open shift in terms of you have a real good chance of what you run in the cloud is going to run everywhere else or under the clouds or whatever what starts the foundation of of of rel right that's the container os containers are just nothing but linux primitives remember so the os matters right kubernetes is kind of utility now but our cube is is pretty excellent and then we put the you know abstractions on top again as I said to unlock the power of the you know container cube and other things while hiding is complexity right and so that's kind of full gamut you know I think we're seeing a lot of customers understanding a lot more wanting to have those conversations wanting to you know raise their point of view above you know cube is in front or anything like that to you know again build deploy and manage applications not just deploy containers yeah and I think you know we've we've gotten to this uh implicitly I guess is we're surfacing it explicitly you know which is the idea of um you know basically third party managed services right you know sort of cloud and otherwise you know which is you know we at red monger you know we've been arguing for this for a long time right you know because our our you know sort of um our assertion you know has been for well over a decade is that you know sort of the upside for for most organizations not everyone of course but most organizations the upside to you running your own physical infrastructure the upside to you running um you know sort of the base primitives and sort of running the pieces is pretty limited um and obviously there are you know we can all think of cases you know sort of exception cases where you know one factor or a combination of factors makes it imperative that that you're on site but basically you know what what we see really in category after category after category you know is you know this this huge and accelerating demand uh interestingly from both the sort of practitioners at the at the um you know in the trenches and at the upper level of organizations um for different reasons notably right but basically to say yeah you know hey can you run this for me right can you take this piece manage it um because i've got better things to do with my time you know to the comments at the top you know i don't want to worry about this because i want to go out and write sort of code you know for uh for my own business right where i'm the only one who can write that there are a bunch of different people who can um you know sort of help manage you know sort of this infrastructure so you know like i said we see that category after category after i mean pick a pick a category a technology industry category it doesn't doesn't really make a difference you know from operating systems databases uh everything in between you know platform as a service you know ish spaces as we're talking about here that's what we do with the conversations that you're having you know what would you say you know or how would you characterize these sort of appetite for um you know these these cloud services these third-party managed services yeah uh actually to go off your point earlier um i asked a very similar question right is it competitively advantageous for you to run your own platform to run your own infrastructure right and getting the customer to think about that again that's having a challenging mentality right and you're right in most cases it's not right there are organizations out there where it is and we can support them too but you know kind of tongue in cheek make a joke as part of you know when i when i talk to customers whatever it's like did you hear about that you know Fortune 100 bank that on their earnings call the CEO announces we missed we miss shipping our new product we missed our numbers but it's okay because we adopted open source kubernetes and we're not locked into a cloud that never happened that would never happen right um and so you know with that you know we're seeing huge demand i can't give specific numbers but i mean compared to where we were just a few months ago you know 5x you know in terms of what we're seeing in customers and and actual clusters and cores however you want to slice it are of what we have from a few months ago are here wanting to do cloud services with red hat right um they love the opinionated um the prescriptive way to get again build deploy and manage applications they love you know they want that software supply chain around the runtimes what you get so if you're building in spring and python and corkis and dotnet core and node you know we give you some safe bits those building blocks are super important we abstract the way your developers having to build their applications to containers we provide prescriptive opinionated CICD which is critical to building a soft you know configuring a software factory right observability and service mesh we're at all these higher order level of abstractions all managed by red hat right i mean we're not actually managing your pipeline but we're managing the engine for your pipeline right um and they're kind of i think i think a lot of folks are a lot of our customers are realizing it in fact when you when you look at uh when you look at developers right you said we want to make developers want things to be boring right our most productive and successful customers using open shift this goes all the way back even to self-managed on prim days are the ones where the developers don't even know they're using open shift they're get pushing and then that software factory just takes care of everything well now we can go a step further through cloud services again which we've ever seen such a demand for it that not only developers not know that they're running on open shift but your operations teams are not having to worry about the care and feeding of the cluster either as much don't worry there's a little bit right as much because our site reliability engineers on our side become a virtual extension of their team that enables them to focus on higher order more performant um uh concepts and issues that that may be affecting them including you know what we see too is you know when a customer moves to red at cloud services they're already using something else and they you know on amazon or microsoft or google they're already they already see the value of using like an r.e.s or an azure postgres right and they want to consume that through an opinionated software factory like what what our cloud services provide and they can't right it allows them to focus again on building these applications that goes back to that nine to five innovation yeah so so that's sort of red having managed service side of things what would you tell folks you know what would your advice be you know for organizations that are like planning for future infrastructure and again you know we as i said we have a i don't know a bias is probably too strong a word but you know we think in a lot of you know in a lot of cases in the majority of cases in fact you know managed services make sense but you know when you're out talking to organizations as you say make sense for some of them it doesn't for others you know what what's your advice what would you tell folks you know who are planning for future yeah i think it starts a little bit with are you willing up to willing to give up a little bit of flexibility to move faster right because there's still a lot of uh you know i don't want to shade any any customer i spoke with there's still a lot of folks out there who are control freaks that are kind of like locked into the past of having to turn every not every lever um but i remind them is like if you're comfortable going to aws and not picking out your cooling system and even your blade and your you know spinning spinning disc silicon right in there then you're probably okay again giving up a little bit more choice to to move faster higher up the stack right um so there's that part of it now again this goes back to your saying earlier again earlier like is it competitively advantageous to have full control so if it is then we have an option for you that's our self-managed versions of the software even though our stuff is very configurable right even the cloud services are um then once we determine that like the comfortability of of you know your mindset for adopting cloud services um we look at you know where is your data today like are you doing all that new you know red ad deals with greenfield customers but we also have a ton of customers who are you know brownfield right and working with the customers really understand the importance of data locality data sovereignty data gravity right of where you need to be deployed so it's kind of difficult if you have all your data on prem and you're going to start deploying in amazon you got to really think about that connection how can we how can we minimize costs of doing so and minimize complex which also would be minimizing uh complexity and then probably the big you know uh sphere around all this is if this goes back to the first point I was making about comfortability of going to a hyperscaler like aws uh amazon or sorry aws microsoft or google is you know the cloud that you're betting on or clouds that you're betting on right um you know that will that will help guide the decision of which red hat cloud service that you should be going with right and because you know a lot of the customers you work with have made large commitments to the cloud providers right uh edps or committed spin programs and amazon and microsoft respectively um and those large commitments give them increased buying power but they have to retire it or also they have to chew up in most cases so the beauty of red hat cloud service is specifically again um rosa which is red hat open shift service in nato us and aero which is azure red hat open shift their first party services on those clouds so that they you actually transact you get one bill you turn it on you get one bill and it's there and retires your committed spin you have to have no paper contract of red hat it just it just works right and um i uh i i really think that that's that's becoming more and more valuable to our customers in terms of like maximizing their existing investment and if they want to maximize their existing investment it's almost a no brainer as our investment cloud services uh sorry sorry hyperscalers it's almost no brainer to go with red hat cloud services versus a self-managed offer fair enough now we're just about out of time um is there any anywhere you would point folks you know who want to learn more about well everything i guess we talked about today yeah uh red dot ht forward slash uh open shift cloud services one big word and we can we can definitely post that in there um the other thing is you know go try it you know go to the amazon console go to the go to your uh azure console spin it up part of the another huge benefit of of red hat cloud services is that you don't have to make a large commitment like you used to for a year you you can spin it up for an hour and then turn it down um i quit you know it takes about 30 minutes to spin up a rosa cluster right and i can do it as a as a senior leader at red hat it's easy enough for even me who's who hasn't who isn't in the tech every day to spin up a cluster and actually deploy apps to it and then i can turn it off right so just you know visit that site uh that mentioned earlier just give it give it a try you know and you know really explore what what it means to you know up level yourself to build deploy manage applications rather than you know focusing on container coup makes sense to me and with that i think that's all the time we have for today thanks i've been steve algrady and uh checker appreciate your time today absolutely cheers