Scaling Cloud-Native Vertically and Horizontally | Predict 2023

Hello and welcome to scaling Cloud native vertically and horizontally. I'm your host Mike Buzzard today. We are joined by Austin Parker who is head of developer relations for lightstep?

And then below him on your screen. We have Yasmine rajabi who's head of product for stormforge. And finally we have met butcher who is CEO for Fairmont?

We're gonna be talking about the current state of all things Cloud native where we are on this journey and how long it takes to get here, but more importantly where we are headed next Yasmine. Let's start with you and if you don't mind I'm gonna ask you a question and explain a little bit about your own company and what you guys do as well. They put some context around that but the question of the day is We've been at this thing for a while now, it seems like you know, maybe the better part A half a decade and I guess the first question is are we there yet or and what's coming next?

Yeah, well, thank you for having me as you mentioned. I work at stormforge and we are a kubernetes optimization platform. So essentially we provide right sizing for kubernetes applications.

And we do that by looking at data running machine learning on it coming up with configurations and then automatically deploying those configurations in a user's environment so that we can intelligently help them scale both horizontally and vertically, so but from the people that I talked to I would say we're right in the thick of it we've seen obviously a lot of growth in the adoption of Technologies, like kubernetes container-based Technologies, the move to microservices now, we're starting to see the rise of serverless and webassembly. So I think that growth is gonna continue. It's not like we're gonna slow down but Especially in this next year I think teams are going to kind of take a finer grain.

Look at how they've been doing things. We're right in that middle where it's no longer about. Okay, I'm thinking about adopting container technology or I'm looking at kubernetes.

It's I'm here. I've scaled it. And now I'm dealing with those challenges that come at scale.

So really looking at processes looking at how we did things and trying to do them better. So the first goal is how do we get? How do we adopt Cloud native technology as soon as possible?

How do we deploy? How do we transform our business faster? But I think now that we've reached this this critical mass I'd say more of what I'm hearing now is okay.

I want to relook at how I make my systems more performant how I make them more cost-effective. How do I make them more reliable? So we're kind of dealing with some of those issues that never really gone away, but are at the Forefront with a new form factor.

All right. Great, Austin, do you want to put some perspective on that while I telling us a little bit about what you guys do? Sure first.

Thanks for having me. It's great to be here Mike and I wanted to You know. To start I want to actually Echo what he hasn't said real quick, right?

We're at lightstep. You're part of the service now family and we have had this really amazing opportunity over the past couple years to go and talk to some of the biggest banks right the biggest telecom companies in the world and what we've been hearing from them is that Even in places where you would not expect Cloud native to be you know, that's where it is the most, you know, it's really taken root and it's thriving I was talking to someone that's you know VP of technology for a large financial institution and he what he was telling me is they had spent the last five years. Figuring out what they're gonna do for the next 30 almost and what did they pick they picked kubernetes?

Right? We had people had tons of options and they chose to develop in a cloud native way and What they're seeing now those challenges that he hasn't talked about in terms of scaling terms of right-sizing terms of understanding. Those systems is very large complex Cloud native systems is that they need to observe ability as kind of the next step, right?

I like to explain observability of saying you know, this is all that stuff that you need to really kind of scale up Cloud native into really harness. Its potential. You need a way to kind of Reason about and model these really complex systems and understand their performance and understand how much are they costing you our customers actually happy with what you're doing, you know all these changes you're making are they actually, you know, kind of going in the right direction.

And observability is that thing. It's that sort of sand or air that kind of surrounds your entire Cloud native system to help you answer those and that's what we do at lightstep. Right?

We build Cloud native observability Solutions and it's been really exciting to kind of see that mature over the past three to four years really as Cloud native is kind of come from being very bleeding edge. I would say to being you know, At the not that's not quite the most dominant thing, but you can definitely see it from here, right? man Same question a little slightly different spin, but it's the end of the beginning or is this kind of where are we from your perspective?

Yeah, I I think I think we are nowhere near the end. We we're gonna see a brand new wave of cloud computing come out here that's gonna take many of the things we've got already and begin to transition us into a new one new and exciting phase many of you may know me from the kubernetes world. I created the home project and then I co-authored The Illustrated children's guide to kubernetes series with Karen shoes.

So if you've ever seen the big giraffe characters and stuff like that at kubecon those originally started as posed post photographs of my kids stuffed animals and I I was in the kubernetes ecosystem for a long time, but we began to see some promise in another emerging technology webassembly particularly as webassembly applies to serverless functions and kind of a big promise of serverless computing and that got us really excited. So about 10 12 of us started a company last year called fermione and fermione is building this kind of next wave of cloud computing with webassembly. That we think webassembly plus containers plus VMS is really going to start rounding out the way we think about Cloud compute.

And so, you know as both Yasmin and Austin talk about cost observability performance. There's there's definitely a need to address those problems in in the existing two virtual machines and containers. But one of the really big Promises of webassembly is that all three of those we see massive improvements when we transition, you know, this kind of serverless and serverless function workloads over to web assembly.

All right. Great Yasmine. Let's come back to you for a minute kubernetes itself.

I think everybody agrees. It's probably one of the most powerful platforms to come down the pike in memory. It's also been perceived as one of the most scary and intimidating.

So have we gotten to the point now where maybe it is becoming more accessible to a broader number of people do I have to be a rocket scientist and a programmer to kind of make this thing work or can I be a mere mortal IT professional these days? Well, I think kubernetes is always going to be complex. It's a very flexible technology.

It provides robust orchestration that it would kind of be a joke to say. Oh it's not going to be complex because you need complex solutions for complex problems, but I do think that we've seen a shift where a lot of the users that I speak to now or new to kubernetes. So people that have been working.

Let's say decades in like C++ development. They're now starting to wrap their heads around. How do I deploy applications onto kubernetes?

How do I look at all of the new configuration settings? I need to think about how you thought about memory before is not how you think about memory now with kubernetes and I think that complexity Is gonna remain but I think a lot of the Tooling in the ecosystem has matured to help like us to mentioned observability. You have to know what's going on to be able to reason about it.

And if you look for example with kubernetes, you've all of these configuration lines of settings that you have to manage and they're gonna be different for different Services different and different environments. You need to be able to have the tooling that helps users see the problem so that they can go fix it. And then also tooling around actually helping you fix that and then go deploy those changes so I think I wouldn't say it's gonna get necessarily easier.

I think it'll get simpler because more people will be focused on how do they help onboard the new users to kubernetes the people who necessarily weren't at the Forefront of adopting the technology. Austin right what you know, go ahead. I I think there are when we when we got going at the very beginning of kubernetes Brendan Burns, who was the creator of kubernetes used to talk about kubernetes is Manifest file format things like that is sort of the the assembly that we would Bill upon which we would build higher and higher layers of abstraction and I think it's good to keep in mind that we have both Cloud native platform engineers and devops as one sort of movement and we have Cloud native developers as another and one thing that has been really rewarding and exciting to see in the kubernetes ecosystem is that when it comes to the platform engineering side, A lot of tooling has emerged it has at least as Yasmin said great start to open it up so that people who who are new to the ecosystem.

Don't find it quite as daunting and particularly they can get productive in certain ways fast. I I am concerned that the developer experience has not matured at the rate. We were really hoping early on in kubernetes life cycle.

And that's one of the things I think the surprise for many of us were in kubernetes early was that functions as a service and and I'm done things like that sort of exploded onto the scene and developers like to that more than they liked kubernetes that of course is part of the reason why for us webassembly as a next wave is one where we really try and want to tell like a developer experience. But even while that's my vocal point, I still think there's a lot of room for innovation in the kubernetes ecosystem as well. They're really great developer experience would would attract a really big following of developers who let's be honest are a little they like the container part, right, but they get a little redis and to start working on the yaml and start building home chart.

And yet they have to know a lot of those things to be productive in their in their work life. So there's some strain there still that I think could could use a lot of innovation. All right.

I was good. I want to pile on this train of thought that's interesting to me. I actually see this a lot Matt.

Like I see this a ton with open Telemetry, which for people that don't know is a cncf project that is aiming to standardize observability data. So those things like traces and metrics and logs giving you a consistent API and data format to produce this kind of telemetry that's crucial and understanding what's going on your application in your system. And it's extremely low level right?

Like it's built kind of by designed in the similar philosophies kubernetes, which is like, hey, we need to be able to give you these really low level components to let you create and manage this stuff because that's the only way you can do it. Right if you're building a platform. If you're trying to build, you know, one of the things that stuck in my head a while back as I forget I was talking to but they described kubernetes is like kubernetes is just a is a fancy object database right with the reconciliation Loop and that that's true that is what it is and one of the things that we lose out on I think by the way, we talk about these problems is that we do get caught up in like Kubernetes as it exists today as a bunch of yaml and as a bunch of you know, as actual binaries and code and things running on servers on manage service or whatever like we're not able we don't have that abstraction layer yet between what is the developer doing in their day-to-day life?

And what is the actual underlying thing that's deploying this containers making sure they're available restarting them connecting, you know mapping ports and doing all of the really low level things you need to happen in order to make your service available to the world or to other services in an orchestration. So yeah, I I would tend to agree that we're nowhere near the end of kubernetes, but I think that we're going to be talking about kubernetes and I think our children and maybe our children's children are gonna be cursing us for having it because that in 30 or 40 years. They're gonna look at kubernetes the way that maybe we look at like a Mainframe right?

It's gonna still be there and it's gonna be a crucial part of the application you're running. But nobody understands it and it's it's kind of lost into the it's lost to time. Right?

It's a bunch of people. We're all gonna be sitting in book over time somewhere. Hopefully ignoring our virtual cell phones with people asking what exactly is.

You know, how does this work, right? But yeah. God has been how you records.

Well all this get because going back to the title of our panel here. We are starting to see kubernetes outside the cloud. It's gonna be at the end and maybe even Beyond and how will we think about managing this as we go forward because it does seem we're looking at maybe in the coming year kubernetes everywhere.

I think Austin brought an example of a financial company that is doing some really cool things and I That's something I run into a lot of companies that you wouldn't expect to be using kubernetes are using them in the most creative ways out at the edge or deployed almost in places to solve problems that you just wouldn't expect these types of organizations to be doing. So, I do think it's something where from an infrastructure standpoint. We will see it everywhere and to I think automate this point and we'll look back and wonder why but I do see just the growth across the different industries that we work with everyone knows like recently at kubecon before the panel.

We were talking about kubecon in Detroit. So this last year was different where The types of organizations that were there the fortune 1000s that you wouldn't expect were not talking about. Oh, we're thinking about moving to kubernetes at this point.

They're like, we're there. We're trying to figure out how we manage this scale that we've built for ourselves. So it's not even just will.

It be everywhere, but how large of a deployment will people have to start to manage? Right Austin to that point then we hear a lot about the complexity of kubernetes. It's going to be everywhere and observability is one of those terms we're in if you mention it, everybody nods their heads sagely that really understand exactly what that means because I think it's like in their mind substitute word for monitoring.

So maybe you know explain to us. What is observability gonna be as we go forward because it seems like it's just getting harder figure out what's going on in these it environments. It's a great question.

To preface. I mean one thing that I think it's interesting that we didn't talk about a lot when we started this. We really didn't Define Cloud native even right.

We we immediately jumped into kubernetes and all these things that are artifacts of cloud native and I've talked to people where they're like, well, yeah, of course, we're Cloud native. We have a cloud native devops guy over here and their job is to log into the AWS console when someone needs an ec2 instance and they push some buttons and I think it's important that we we step back and we say what is actually Cloud native and the I like to explain so people by saying, you know, a hundred years ago or longer than that even but if you wanted to build something you had to go out and do a lot of work as you know, an entrepreneur is a builder, right you had to go find a river and build a water wheel to produce energy to go grind things or to create power to make widgets and we decided as a society as people that build things. It's like, hey, actually it makes a lot more sense if there's just a big power grid and you plug into the power grid, right?

That to me is cloud native. It's this idea of everything is a utility and you aren't having to kind of go and build everything yourself you're able to leverage this huge network of utilities that exist and that's the cloud native ecosystem now. As that but that inherently breeds complexity and that makes things harder to use because now instead of just being like I had this one vertically integrated thing where I kind of know every single bit every single stick of ram every hard drive, you know kind of racked in a data center somewhere.

And then beyond that I have like a highly integrated software stack right where I maybe I'm using you know all one language or all you know, maybe I'm in the dot net ecosystem the next something right. I have this highly tightly coupled set of software and services that all work in concert. But you can't do that in the utility world, right?

Because that's not how it works anymore. We don't we can we have multiple options and with those options comes complexity and what that complexity comes a challenge of how do I actually know what's happening and that to me is observability observability is The thing that you need in order to understand these complex systems to model these systems to be able to get answers to your questions. Even if you don't necessarily know what the questions are beforehand and to get observability.

It's not just a quick thing of like, oh, I have this particular data source, right or I have metrics and logs and traces it's about being able to unify all these different types of telemetry in a system that can help you kind of both discover answers, you know help you understand like what changed in your system at any given moment but also kind of prompts you and says, okay, you've got a ton of data here, you're gonna need help to narrow it down and as it does that it's able to kind of let you answer those arbitrary questions things like well how much am I actually paying for this? Right? What's the actual you end user experience for people that are like adding something to their basket or you know, trying to make a check out or anything really?

It's about being able to integrate all that different stuff together and get answers versus just Monitoring the system and knowing if something's up or down. Right. It has been you want to jump in on this and I'll add this to what he just said.

I tried to explain this to somebody myself one day and they said that all sounds great. But I have no idea what questions to ask. So will you guys provide tools and things that will make it easier for me to figure out the questions that I need to ask beforehand.

So I don't have to be you know a genius I can just go look at something and go up. I should know that. Totally I think what Austin mentioned is critical observability.

Tools just having access to that data and knowing it will be there is great. But you need to know what you want ahead of time so that you're pulling out the right data and it's kind of similar to some of the users that we talk about but that we talk to at stormforge that are having trouble scaling their applications because it's so easy for them to scale. They're not necessarily asking those questions up front of when I for example, if I set my HPA, how do I know that I'm scaling at the right moment.

You need to know that you're going to collect those metrics to be able to answer the questions down the line versus if you just turn on an auto scale or and then deploy what you need and it does what it's gonna do. You don't know up front that you're gonna want to watch that and you're gonna want to measure it and actually go out and tune it as you need to then it's kind of too late. So you have to go back to kind of square one and I that's a conversation that I find myself having a lot with kubernetes users that are scaling and they're trying to be more efficient at that.

It's are you actually looking into this data? How do you answering the question or the most common thing of how are you setting your requests and your limits? I look at a chart and I pick something.

They're not necessarily asking that question up front of what should I be setting this to based on the data that I've thought through and I've configured. No, it may come as a surprise to some of you but vendors do talk about and users and shockingly and users talk about vendors. It's amazing conversation.

Matt we do here about Watson. I don't think everybody knows what that is. So maybe you might want to walk folks a little bit.

Is this the next thing coming over the cloud native Horizon? What is it? And how does it gonna fit in?

Yeah, I I think there are you can hear some sort of complex descriptions and long contorted kind of explanations of what webassembly is. But really at the end of the day webassembly is is a binary format that can run in sort of a sandboxed environment. net world.

This is gonna sound familiar right the jbm and the dot net CLR were both are both very mature robust examples of that kind of environment but webassembly was built for a different purpose. It was built to be able to allow a binary to execute. We'll call it a guest binary right a guest binary to execute in a host that doesn't trust the guest.

So when you think about the way virtual machines and containers work, that's the same security profile they have and the whole notion of cloud computing is based on this idea that I as a cloud operator should allow you as a as a cloud user to be able to upload your application and run on my infrastructure and I'm making you a promise Some other customer on the same cluster is not going to be able to gain access to your compute and your data and do dastardly things with it. Right? So webassembly is a new kind of execution environment like those other two virtual machines and containers, but it's it's different in kind and that it's really built more to compile applications directly to that format.

So the virtual machine you have a big giant virtual machine image we can think of that as like the kind of heavy weight class of cloud computing you have everything from kernel and drivers to the entire operating system up to the application at the top. When you think about a container you think about it as sort of like a slice of that pie, right the middleweight class where you don't the kernel is shared you don't have to worry about the drivers. You're just sharing a little bit of the file system that your application needs and then you're dropping your application in there.

And you've got your containerized environment webassembly, you just drop the application in with the files the application needs and the system handles the rest. So there's no Little slice of file system that Bio sizes or the binary sizes for webassembly then tend to be much smaller than containers which in turn are much smaller than virtual machines the virtues of webassembly when it comes to the cloud though. Is it webassembly starts up really fast?

I like like we're talking virtual machine takes a couple minutes container takes a dozen or so seconds a webassembly module. We are in our environment ours begin execution and less than a millisecond. So so they are blazingly fast and also very very secure on the security model side and the binaries are small so they can be moved around a cluster very efficiently without necessarily requiring large amounts of bandwidth or long transit times.

And so that's why we're excited about webassembly as the next wave of cloud computing because that particular runtime profile is going to solve some very specific problems that we haven't done a great job of solving with containers and virtual machines, but it doesn't require that. We you know, throw all the containers in Virtual machines away right virtual machines when containers came along virtual machines still continue to grow continue to matures and ecosystem still continue to gain new users and and new instances. And we think that the same is true with webassembly.

It's just going to solve a different class of problems. So first solving a different classic problems in this our fact is not replacing all the other artifacts that went before Austin is our like gonna get harder or easier as a result of all this stuff because it seems like it's yet another artifact. I mean, I think that it the great thing about Wasim, is that ultimately to actually take us back to kubernetes right like there's it's a really good object database and it sounds like to me Wasim is just an object.

Right? What's the difference between a wasm binary and an oci container spec from the perspective of kubernetes once kubernetes and knows about that object. It doesn't strike me that there is a huge one.

I guess to that end. I would point out that Docker recently announced support for running laws and Docker desktop, and I would Again, not a wasm expert. I think it just adds more.

It's almost like an adds more flavor. Right? Like we're adding more optionality for people.

I don't know much about Wasim on the server. I'm a huge booster of actually was them as a for clients. I think there's a lot of things that we have forced JavaScript to do over the years that boy howdy it's not great at and wasm As an execution environment on the browser will really help the revolutionize a lot of especially productivity applications and things like that.

But on the server, I mean I you know, how's it deal with dependencies? There are things that you want VMS for right? There are things you want containers for and now they'll be things that you want was them for if perhaps you have something that's small enough that can be statically linked and bundled all your dependencies together and that right like hey, that's a perfect use case for this and now you can take advantage of kind of going into what he hasn't talked about right with you're picking the right run time.

You're picking the right deployment strategy that helps make sense for you cost wise like we're probably we're certainly entering into a phase where it doesn't seem like there's gonna be able to throw infinite money at things forever. So you'll need to make decisions about do we have a service that maybe be to better better written and deployed as you know, a set of laws of applications versus kind of this heavy weight container. And that really just adds optionality to your you know, architecture two years and things like that.

And also same, you know selfishly enough. This is just another argument for observability, right like yeah you now you have more complexity. Guess what you do more observability.

Now, you need to be able to have the tool, you know, observability platforms that can handle just this huge overwhelmingly amount of data and help you make sense of it. Matt you agree? Yes.

Please continue to add more complexity to kubernetes. Thank you. And I mean and I should have I shouldn't have you got it inside and we are also I consider myself now post kubernetes but observability is is a huge thing here, right?

And and one thing that's nice about starting on this was I'm trying after seeing the kubernetes stuff reach a certain level of maturity has been that we already understand quite well that this whole story of metrics plus a story equals observability and I can more I can reason better about this complex group of things. We knew that going into webassembly. So we start talking right out of the gate about okay.

Well we need to make sure we can collect metrics on how fast these things are executing where they're executing. You know, what the fault rate is what the memory consumption is, and and observerability is really I wouldn't say it's a passion right? Nothing.

Nothing is a pass yet, but it's a huge step to being able to understand things and and if you're going to introduce complexity increasing the way you can understand the information that's how information is moving around and Resources are being impacted. That's what's going to make the edifice stand up. Right?

That's how we build the Taj Mahal instead of a bunch of small little hunts because we can understand that architecture at depth. So observably absolutely key to this success of all things Cloud native including this kind of emerging webassembly ecosystem. He has been coming up a few layers here.

We talk about developers and then we talked about it operations folks and we even went after this mythical unicorn called the full stack developer and we was going to magically managing. Do we need to rethink the way it is organized though In This Cloud native era or in you know are the ways that we have approached this in the past not gonna service going forward and you know, are we moving everybody's cheeses it were and how should we think about? Um, I I really like what Matt just mentioned of how kind of webassembly took some of the learnings and made sure that observability was in there at the start.

I think that's a great learning we had from kubernetes and kubernetes built a lot of things at the start that we learned from VMS and so on and I think technology tends to learn and improve itself and the same should be applied to humans. I think you could argue that we don't always apply it and you can see that when you look at the different titles or I constantly get ads about platform engineering is a new devops devops is dead. It's just it's just another way to wrap around the same problem.

The problems that haven't changed is teams need to look at how they're scaling their delivery. They need to look at how they're empowering and growing the skills of the humans that are working on these problems and how they're reducing their operational costs their efficiencies. And so I think as technology changes what it operation teams need to make sure is there's still trying to solve Core problems and they're organizing teams around that versus this team is responsible for this set of Technology.

This seems responsible for this set of Technology. What are the business goals? And what are they trying to accomplish and then Going off of that is what will make them the most successful.

And so I think it's very easy to get distracted by new technology that comes out. But how do I actually solve the problem? I want to solve and making sure it's abilities in there.

Obviously. I'm a little biased towards machine learning but I think augmenting humans ability with machine learning not replacing it. I don't think that machine learning will replace any sort of it operations person ever.

But if you look at kubernetes in the thousands and thousands of configurations and All across your deployment. How do you reason about that? How do you reason about all the observability data that you have machine learning is a great application for that that topic you don't necessarily need to apply it to everything but be very specific about what you're trying to get out of it and let computers help you not necessarily replace you but but help you.

Awesome, you have any thoughts on that? So I just take all the humans in the robots and throw them in a room and lock the door and they'll figure it out. I think I mean you get before we were on air.

We had a very interesting sidebar about the effect, you know efficacy of machine learning and things like chat GPT and AI as it were and The biggest problem is garbage in garbage out. Right? Like if you have a machine learning model or an AI or whatever that only gives you the right answer 70% of the time then people.

People tend to distrust it from personal experience what I've seen in my, you know time in the observability field. Is that if you're going to give a developer something that is a tool that's supposed to help them, right? It uses.

Even if it's using just very simple statistical analysis. It only takes one time for that machine to be wrong before they just to say they can't trust it. Right.

We have a pretty high threshold, you know with people with human beings like you can be wrong a lot and people will still trust you right or at least they'll like Be okay with you, you know, your coworker makes one mistake. You don't throw them into the garbage and say I'm never listening to you again, at least I hope you don't because humans are fallible. But with you know, when we start adding in machine learning we start adding in AI we start adding in all these kind of Advanced Technologies especially ones that are sort of a black box then we have to be as an industry and as like technologists and as people evaluating this we have to just be like super super precise that we understand what the limitations are what can actually do for us how it's coming to these answers and conclusions and where we're driving the value from right absolutely machine learning is a part of your observability strategy.

It's a part of the future of technology in general. Right? It's going to impact all of us.

I think we need to be a lot better as kind of like human beings about. understanding limitations and understanding how it works and being aware. There's a lot of people that are out there trying to sell you snake oil right now.

I'm not saying anyone in this call is certainly but you only have to take it only takes a short trip through Twitter to find people that are pushing, you know Ai and ml is the solution to all of the world's ills and that maybe we should be a little more skeptical about right like I think there's an aphorism about you know proof or needing to see the proof in the pudding. However One thing that I think can't help this to bring it back to observability a little bit is like I started with garbage and garbage out. You need to really high quality data about what's going on.

And this is where I believe the open source, you know, the cloud native Community can really come together and help through projects like open Telemetry which provides clear and consistent Telemetry data like metrics logs and traces from our systems and that is better inputs to machine learning models, right? Because if you have consistent data, then it's gonna a you're able to actually get something more useful out of the machine Learning System at the end. All right about that once and they said, you know, I asked them straight out.

Would you rather do this job? Going forward with or without machine learning algorithms. And eventually they all said with because doing it without is almost impossible.

I think he has one was good. Yes. Sorry.

What you mentioned is honestly my life like most people don't believe machine learning. They think it's a black box and and there has been so much snake oil that you're why would you believe it? And I think constantly what I get stuck with or the conversation I like to have is we need to prove it via software and to your point open until I'm actually making sure that we're showing people how we get to where we get to and opening up that black box is just that building that trust is what computers can't do humans have to do that software can try to do it but humans have to do it and so building that in I think is critical but like what you describe is by that that first hurdle in users that I talk to.

All right, Matt, you talked about I can rip on go ahead and go ahead. Sorry. If I can rip on one thing that Yasmin said a couple a couple minutes ago and it kind of led us through this flow is you know, we can think about system complexity we can think about team and and human working group complexity as well and Telemetry helps a lot and observability then in understanding the the machine aspects of this and there are these social problems that we working together to do things also have to solve that assistant Technologies in many ways shapes and forms are great, right.

I remember when deploying an application as a developer meant packaging things in a tarball and then calling the Ops Team and you know emailing the bundle over and then they would SSH into a certain, you know, unpack it was this big messy ugly thing. And then you know, kubernetes has made many of those things much easier. I think we're still moving even farther toward, you know developer self-service when Developers Services is appropriate like we saw originally with Heroku and all Paz platforms are sort of built on that premise but new and better ways to help engineering teams the developer part of an engineering team and a platform Engineers work together in order to get new applications up manage them on day two continue to keep them running and ideally not have those situations arise where two in the morning somebody on the platform engineering team is trying to wake up anybody on the developer team to say something just broke.

We don't know why we don't know where here's a big log Dom so assistive Technologies, whether it's observability tools or even some of the Mason kind of machine learning algorithms that can help with this or kind of be great because they're gonna help us as humans, you know, do better as humans and that's you know, there's plenty of dystopian approaches to machine learning but this is one area where I think machine learning can really end up helping us live happier lives and have happier lives. Demand you buy this up early and I want to get back to the developer experience. I think mathematically maybe roughly speaking eight million in kubernetes developers, maybe twice as many that know what a container is and there's a total pool of 50 million developers so less than half.

Developers get good companies and containers. Is that gonna get better in the coming year? What are we going to do to fix it?

Yeah, I think. I think that. There is a so CNC have to there and slash data did there annual survey right at the end of 2022 and there were several questions in there about you know, what's the size of each market?

How many developers are familiar with this? How many developers are comfortable with Cloud native development versus traditional development and certainly every year we're seeing the numbers on developers move up and up and up. What we do.

What we need to do is not so much to you know, it's it's a movement from both sides. Right? We can't expect developers to do all the work to get further and further into what what kubernetes is and how it works or what cluster Technologies do and and why or what, you know, take your pick your infrastructure tool.

We shouldn't have the developer have to make this long journey by themselves all the way over to the new technology that's unrealistic. So we need to be converging right we need the those of us who have more of an operational mindset building tooling that's gonna meet the developer and require them to Learn fewer and fewer pieces of the infrastructure in order to be efficient and effective in their jobs. And again, I'm going to get back to webassembly because it's what I'm really passionate about at this moment.

But when we look at the way that serverless has evolved the developer story wasn't terribly great with early serverless platforms and I'm thinking primarily serverless functions right wasn't terribly great there either and actually in that case the operations and developer team really were at odds with each other because it was hard to figure out for the Ops Team what was going inside of say a Lambda style function and it was hard for the developers to communicate how things were strung together in a way that the operations team could understand it. And so once again in a lot of these Cloud native ways, we're starting to see what we have to see right movement from both sides tooling built from both sides. So that in the end we can converge in a space where ideally right the platform engineer understands how to do their operational business, right?

And it's very clear and the developer understands. Where their job ends when it comes to producing an artifact, it's going to run somewhere in Cloud native and to me like the the golden standard and I mentioned it already right is if there's an outage at two in the morning. There there should not be a reverse Dent dependency where the platform Engineers have to rely on the developers because when that when that becomes the case then something is is out of kilter, right you're relying on your people who create something to operate something and that's very disempowering to the platform engineer and conversely very disruptive to the software engineer.

So I I think we're on the right track. Right? Don't get me Ryan observability.

Definitely a huge step toward that focus on many of these tools to expedite debugging and things like that. Definitely on the right track. I still think there's a lot of work to do and Cloud native is not going to be able to reach its potential.

You know, we started with the question. Are we there yet? Right.

We're nowhere close today when we talk about clusters. We're still thinking clusters in a particular data center. We need to get to the point where when we talk about cluster cluster spans, whatever available compute is secure free use right whether it's here your phone or Edge Computing far Edge near Edge and the data center, but we're and distributed computing again.

We're right at the cusp of being able to do real. Distributed computing we've taken the first steps with Technologies like microservices and kubernetes and and serverless functions. But now like the next five years.

This is one we're going to see that kind of thing go from its infancy into real distributed computing in real clusters that are distributed globally in in a real sense of global and observability, you know, I think webassembly serverless functions these kind of tools to help us understand what's going on. Those are all prerequisite for us to even be able to enter this five-year period so are we there yet we might be getting right up to the starting line or I like to use I was a middle distance Runner, right? I like to use the 400 meter dash as an example, right you you spend the first hundred meters of the race just getting up to speed and then you got three quarters of the race to do before you cross the finish line.

I think we're at right at the end of that getting up to speed thing and and we're about to run three quarters of a very very exciting race. All right, Austin, we got three minutes you are now made Lord of All Things Cloud native. What's the one thing you would fix?

Oh God. pricing I I think the the without yeah, that's a weird answer but honestly, like I think the actual one of the actual things that holds us back is as an industry is just this kind of goes to Matt's point about like what is a relationship like you will never get to a real distributed model of computing if there is someone that is standing at every single hop from one service to another asking for a nickel right like billing pricing metering all this sort of stuff. We have to get a better or a different idea about Paying for what we're using or actually be billing what we're using and figuring how much stuff costs, you know, we're actually getting for that money because right now people are just kind of shoveling, you know.

Shoveling money into a furnace and it's you know, and it's kind of a black hole, right? You don't really know what you're getting out of it all the time. And I think that the financial, you know, the economic incentives of providers and the ability for developers and innovators to actually build like interesting new models of computing like these need to align somewhere we have to figure that out.

Otherwise, we're we're gonna just like fall on our face right? We're at the end of the beginning and it's And a lot of the technology is here, right? We have The Primitives we have the underlying components.

We need we need to build better abstractions. We need to figure out better ways to kind of handle the financial and they economic and all this other like actual really human problems in order so that we can actually make the rest of that. You know, that that next two thirds will actually be possible if we can solve that.

All right. Here we are all guaranteed the employment for life because this journey is going to go on for years to come. I want to thank our panelists for being on the show and sharing their knowledge and insights.

Thank you all. Thank you for having us. Thanks for having us.

This was fantastic. Thanks. All right, and we'll hand it back to our main crew and we're gonna close out the whole event soon.

Thank you.