What’s In Store for DevOps In 2023? – DevOps Unbound EP 35
In the past couple of years, businesses have been leveraging DevOps to drive their digital and cloud transformations and enable rapid innovation. Now it’s time to look back at the lessons learned and look forward to the future. With so many changes going on in the industry, what does 2023 have in store for DevOps? What are the DevOps practices and technologies that will shape the future of business?
Mitch Ashley (Techstrong) is joined by our panel of experts Parag Doshi (Tricentis, Lee Atchison (Atchison Technology), Hope Lynch (CloudBees) and Tim Banks (Dell) while they share their predictions for the upcoming year and discuss: The DevOps trends to watch in 2023, DevOps, SRE and the future of software development, DevOps at the edge, the future of automated testing and DevOps, the state of cloud-native application development in 2023, the rise of citizen developers, how AI and ML are transforming DevOps, and more!
Transcript
Hello everybody welcome to another episode of devops and bound I've got a great topic great panel in 2023, where are we going with this thing called devops, so well, we're not not a predictions conversation. We're just kind of talking about the state of the art with what do we think's gonna happen in the evolution of devops and kind of what if we learned along the ways, my name is Mitch Ashley. I'm CTO with Textron group co-host along with Alan Shimmel who is busy on other activities.
I think he's away on assignment as they say In The Biz and happy to be hosting in his dad, and of course want to thank our great friends at tricentes tricentis is sponsored devops on that since it's beginning over two years ago. Been a fantastic partner helping us with topics and guests and creative input to along the way. I'm working with Lanier as well as with Jody on our production producer team.
So, thank you. Trade Centers for sponsoring this show great. Well, let's move on to our topic.
I first want to start by having our guests introduced themselves. Hope would you start? Sure.
I hope Lynch senior director of platform at cloudbees have been in technology for a long long time. So very interested in talking about these changes today. Fantastic Tim jump right in there.
Sure, Tim Banks lead developer Advocate with Dell Technologies. I've been in the the devops game for a hot minute also and having been both in the cloud hyperscaler side and the hardware manufacturer side and the private Cloud side. Just kind of looking forward to seeing what we do next.
A lot of stuff we use today and then going forward for sure. Thanks for being here Tim. And welcome Lee good to be talking with you again.
Nice to see you again match. My name is Lee Atchison. I've been in cloud computing and devops since really they became words I think and I'm software architect consultant author and my latest book overcoming it complexity was just released and is is been doing fine gradually.
Congratulations on the new book Thank you. Our problems are soft. We've got the answers.
Black City not to put too much pressure on you over. So no, it's a it's a fine book everybody. Check it out.
It's an O'Reilly book. I'm Prague do she VP of customer engineering here at tricentes really excited to be here and talk about our predictions for this year. It's already 2023 and let's see.
Let's see what happens and you can't refer to the you know, the first three weeks of January. I predict this because it's already happened already. Just alright, welcome Prague as always great to have you with us.
And again thanks to a tricentus for sponsoring devops and bound. We're talking about kind of where are we in the state of devops in this adoption? Some of us been doing it, maybe five six seven years other folks maybe earlier.
Maybe it's pretty new year or less maybe a year to a lot of things have happened. I know since I remember first learning about devops. Why don't you start us out kind of give give us a sort of your version where we where we are on this Continuum of whatever devops is and is gonna become.
Yeah, absolutely. Very interesting time one of the most interesting I've seen since I've been involved with devops and partly the impacts of AI ml low code no code all of these things that are sort of converging at the same time on developers and then people are also now thinking more about what is the experience for developers? How are they actually connected to the business?
It's not The you know developer in the back room anymore and it's and it's normalized. Now. This is part of how business is done having devops as part of your practice.
So I think we're at a very interesting time. I look forward to it playing out. Sure, we'll agree.
Nothing left to be said I think you covered it all no, no opinions here jumper here, right? Oh, yeah, certainly machine learning learning an AI. If if that isn't the the headline of any discussion of the the future when it comes to devops.
It really should be and I agree with you. I hope but I'm also interested in the operation side of AI and machine learning, you know, it's we've already seen the use of heavy machine learning when it comes to analytics and and examining analytics and finding Trends a large amounts of data and things like that. But I am also really excited to see some of the things that might be happening with AI and you know, The scanning code pre-deployment for a security violations are just code reviews in general and the ability of what sorts of things are even Bad actors that that can be discovered pre-release here.
We're we're now you devops is really enabled us to have you know thousands and thousands of thousands of releases a day, you know and Amazon still does what whatever you love and second something like that. And that's a lot of code that's getting deployed to our applications and more and more applications are sending a cross multiple companies with SAS services that fit into Etc. So having tools like that that can help us, you know scan to reliability of our system before it becomes an issue is going to be critical something machine learning and AI is going to be critical not only from the developers to that point and we're just seeing the beginning of what can happen there.
But also on the operation standpoint and the the pre-release as well as close really monitoring. That that we can do. I think it's interesting you talk about how how AI ml will will kind of drive devops.
But I do think that we also have to take account that devops like the deployment of AI and ml both, you know, whether it's the data stores whether it's analytics that go into creating these models right or the the actual Hardware itself that's gonna require a lot of wrenches turn on the devops pipelines and it's gonna be the same as always. I think the other big concern that I have as far as amml is that how do we keep these pools of data from generating malware themselves? Like, how do we keep it?
Pure, how do we how do we keep people from predicting what questions are gonna get asked over time and start injecting malicious answers to them. Right? And the more that we are reliant on and ml to do these kinds of basic programming things and they say, oh we can replace your engineers, which I don't believe but the more that'll become reliant on AI for answers the less screw the less scrutiny.
We're giving those answers and I think that's a big gap. Yeah, I completely agree. I think Chad AI has kind of proven that and brought that to the the Forefront when you know, they the opening AI team actively acknowledges that the reliability of the answers are sometimes suspect because of the learning that went into the data and and the process used for that learning process for that learning procedure.
Yeah, but I have I will say that I have seen you know, poking around and read it in some of the devops corners. There are developers who are saying they're using it as a coding partner now, right they are using it to come up with additional ideas find shortcuts. So it's not that.
It's replacing them and they are not you know, Blind Faith in it. Thank goodness. But but it is helping them have access to a wider a worry about ideas faster Bros.
The type of you've got a lot of oh, yeah thoughts on it. So jump in there. Yeah.
Yeah. I was just waiting there because you know agree with everybody and you know chat cheap PT everybody's like wow, this is so awesome. It's gonna change everything and then there's a segment of the population as has been for the last what six decades since the word robot was coined.
My Asic has more right that oh jobs are at stake. Okay. Well, let's look at what devops has done to all these companies to increase profitability and how much depth have we gotten into all these major Enterprises?
It's still not Prevalent like more they're more development teams that are not using these agile lean devops processes. So it takes a village to get devops, right? So as with any new technology as with AI has always been I see it as decisions support systems as I think hope is talking about how do we Empower?
Like there's too much put on the developers and the security comment of another scanner finding anomalies. I have enough scanners. I'm so tired of them.
The signal noise ratio is just terrible. So I need to know what are the things to care about? So if I have ai to be the decision support system for humans to do their job better.
Well, I I be happy if it takes only 80% of the village right now. It takes 1,000 people to do it in a hundred billion dollar market cap company today to do it right at scale for thousands of different agile teams, right? So we need At all the help we can get I think there's no shortage of jobs and I see this AI movement as actually empowering and you know, this might sound a little self-serving for a company like ours tristanis.
We make a tools that assure that whatever you're trying to do is done the way you expected testing, right? So you you're creating applications and software from your own imagination from customers requirements and you have to validate whether or not they did that right? So I think this is gonna be the year where testing will explode it will have a slow start.
You know, AI has always been a part of testing and it will augment it will enhance but we're always going to second guess. Okay. Did my chat GPT version 22 just made that up, right?
Is it still good enough? Because what did I actually learn from the testing right? The human still got to learn you got to get the or Out of that testing to be clear.
Yeah. Yeah. Did you say we might have oversold AI in the last now six or more decades?
No. No, I don't think we've oversold it. No, actually, I do believe we have I agree that started in it.
I think we'll always second guess it right like look at the number of false positives right the signal noise ratio. So if it can help us reduce false positives if it could take 10 different scanners. Yeah, you know that we use and you know different vendors of each of those same things that are semi overlapping and make it more intelligent and say look based on history your software has done poorly in production in these areas at this step in the users journey of using your application and therefore gives you a higher signal noise ratio.
Look here. This is not a false positive. Then we're just gonna become more efficient.
We're gonna become more confident in releasing. I think that's a lot. To be clear.
I think AI. Of all Stripes is a tool to help people. It's not a tool to replace people and I think that's you you bring up that point.
I think you're right that since these days if I'd say gas Mouse that's been the fear of Science Fiction, but that's not the point at all. And and the you know, nothing is more hyped nowadays than chatty chat gbt, right. I mean, it's probably the most hype technology available right now, but In the end.
It's not a tool to replace people. It is not but it can help perform some types of tasks and some of the things that you know, that machine learning is good for and some of the things that machine learning is good for is analyzing large quantities of data to look for an animal anomalies, you know, as anomalies can then be analyzed by humans to figure out what's going on or whatever. So I think the idea of scanning the that we talk about is about finding not anomalies my mouth isn't working at this morning.
I'm sorry about that. But you know as we as we move forward it's like with you with thousands of relations going on a day. There's no way that we can reliably predict that all of that is accurate.
So one good use for machine learning is to make sure to do the scanning to look for changes in analytic data to happen and correlate them to release some of those sorts of things are tools that help humans. Prevent them from having to spend all of that time that they're not good at it analyzing large quantities of data humans aren't good at spending large quantities of time looking at the same thing over and over again computers are very good machine learning is very good. Listen and for tools like that.
We can't a lot of time looking at YouTube We Came spent a lot of time. Okay YouTube. Yes, you know so question for the let's kind of shape this take a little bit different direction.
I appreciate the AI ML and chat GPT and the you know, that's sort of the shiny object at the moment in the world the AI and ml but the people part of it we talked about, you know, there was if I can bring up sort of a tangential example the whole South with their Airlines and baggage and scheduling and all that kind of thing not to to drag them into the topic. But one of the takeaways for me out of that was they kicked back to fully manual trying to do everything by hand when the systems didn't work and it was Far beyond the capacity not intellectually, but just quantity and the amount of data analyze and situations to handle was far beyond what a human could do and it seems like that's part of what we're doing in devops is increasing velocity by doing the things that we can do with software and then leveraging people skills and expertise like Prague. I'm sure we don't need the top tester examining the results of every test run right you want that person working on the next set of challenges or whatever.
It might be. Yeah. I think I think you know this whole notion of AI I'm gonna steal another one from Neil deGrasse Tyson.
It's it's the fact that you need to be adaptable. Right? So if you're really concerned about people and all it's really you're in technology your job is going to change actually then you're not in technology it changes if you're a farmer, you know and 1800s everybody new farmer right now.
You can't find one, right? In your cities and also so agriculture has completely changed because now we know exactly where to irrigate, you know, every single molecule of soil if you will, right? So I think having AI or having these capabilities come to Market to make people more efficient, that's really why you're hired is for your creativity.
Like you said, it's not for someone to examine, you know a billion test results on that application. We want to know what are those five things. That are going to lead to problems because this is the year of productivity right?
People are gonna be tightening their belts. Okay, we're going to be rationalizing our applications. We're gonna be rationalizing how much time you can spend building an application testing an application and how efficiently you can continuously deploy it.
So we're going to have to become smarter and to the extent AI is just one other tool. It will allow us to develop more time to those areas where you were originally hired right to know out of the thousand different ways. Things can go wrong.
What are those top five that could cause an outage or that could cause performance degradation. If you can home in on those things, then you can get in front of those kinds of things and I think that's what role humans will play and I think this also ties in so closely and I haven't seen anyone necessarily state it this way, but there's been a lot more conversation around developer experience. Like you said, you know, there are a lot Of jobs open, right and if developers are unhappy for too long or they're not getting the tools they need or you know, the conditions of the workplace or are not what you know, they hope work don't look for another opportunity.
But if you can find a way to make their experience of working and how they develop their software and how they test their software and they get other tools to help them and they feel more accomplished. They're able to be more creative. A lot of people forget that developers are Creative people then, you know, they're happier.
They're experiences better. Maybe they stay longer. Maybe they produce better product for the customers what's happening over the years developers have taken on more.
Okay now developers responsible for security. How many developers like to test even their own code? Right do code reviews, right?
They don't want to do these things. So I think this is going to be an explosion of more low code, right? That's what we're seeing in our Market that can we make tools reduce friction so much so that developer doesn't have to think about the mundane doesn't have to figure out okay, which scanning tool do I have it's actually left shifted into my pipeline.
They don't have to think about okay. I added a hundred lines of code and I'm gonna commit it actually cause a performance degradation. I can do a smoke performance test as part of the pipeline and I'm going to get a high signal to noise ratio of where things are.
That where I need to put my attention. Oh is those last hundred lines of code that I added that has something to do with? The change in performance, right?
So I think low code and putting more and more into the pipeline so we can get Less things piled on a developer. I think that's that's okay. Let's get him in here.
Okay. Yes, I would say to that end product. I think the the reason that more has been put on the developer has been maybe a result of I would feel what I feel is a misuse of a devops culture where the instead of empowering a developer to be able to do more.
They're saying we could use these tools of developers can be Ops and they can do deployment and now they can do security because now I have these tools for doing it instead of allowing those tools to enable people who specialize that to do those things. And you know back to Hope's Point earlier about about using at your point earlier. It's about utilizing Ai and ml to enable folks to be able to make better choices to use them at tools.
That's not what we've seen in the past. We know that historically engineering cultures engineering leadership will say well we can use it to save money by getting rid of security people by getting rid of operations Folks by getting rid of SRE and then putting it all on developers and then using managed services for the rest and what I really think we need to start saying the opposite of right is that over Reliance the tools and automation because of what you saw like with Southwest and things like that and and to the point where we're talking about where folks are with careers and jobs. We saw, you know, what 20 to 30,000 layoffs between three large companies not just do your folks, but it's very very senior talent.
That is a big Talent drain that is a big dream of folks who do how to do these things because they can't promote time. Before everything was pushed on a developers, right? And so what's going to be the effect of that on our pipelines what's gonna be the fact that these companies that they build and the companies that these people eventually go to and so I think what we're talking about how we use these tools to enable people to do things.
We need to talk about enabling people to still have Specialties and still have areas of concentration. So the developers can just develop these tools can make people in these Specialties with operations and security network or whatever. It is more effective at their jobs instead of taking their jobs and putting it off the developer.
Yeah. Yeah, I think we need enough for just getting it into the developers site to bring in that specialty right if you see hey there's a CV like this. I want to go to my security expert a common vulnerability or exposure right wanna go to my security expert and ask do I really need to care about this, right?
The scanner brought this up, but you know, I've got enough mitigating controls, right? So I think you're right Tim we need to I think the short shortsighted leaders get rid of the Specialists, but the companies that are doing well actually add more Specialists. It's hard to find security people, right?
You know, so let me bring this into the topic the subject of platform engineering and is that replacing devops? There's a complimentary or whatever it is and they're reading I've done about it. It's interesting that the rise of platform Engineering in some ways comes from getting back to developer friendly environments and developer productivity and kind of taking all the stuff that we've piled on to devops and devops tools and all the people involved and all of this.
It's kind of pulling it back to being and making them do security. You know, as you're saying Brock is like let's kind of get back to the basics or the fundamentals that are gonna help developers be more productive. But also that are more friendly to the developers to me.
It's kind of an interesting 180 counter-reaction maybe to where we are because of devops and anybody agree disagree have a different Viewpoint. I'm platform engineering you see how I can say this, you know the most Developers I talked to you know that. It aren't afraid of having more things put on them.
In fact, you know, they're they're not the one they're not sitting there saying. Oh no gonna do security. No, it's it's what they're more interested in is what tools do I have to help me do security because I know I need to worry about it the best developers in the world already know what the responsible for the responsible for everything.
They just want the tools to help with. One of the things I hear Developers. If they complain about anything the ones I talk to it's about things and I'm not saying I agree with this but it's about things like low code which come in and say, you know, the the types of low code that say I'll do all this for you.
You don't need to do this anymore. Just trust me and that's the sort of tooling that scary is developers because it's what it's a black box. I don't know what this does.
I don't know what's gonna do for me. I'm trying to take control of this and this is taking control away from me the best cooling the best platform engineering isn't isn't the the responsibilities are going up. It's here's the tools to help you with your growing responsibilities that you already care about.
and let me be controversial hopefully times. Yeah, sometimes I feel a little bit that platform engineering. Is the safe of devops for some organizations and here is why?
Sometimes management is like you know what let's just get one team that's gonna worry about all the tooling and standardize it across, you know, our Enterprise so our developers don't have to worry about what tools they're going to use right we're gonna turn this into you know, a sort of a factory experience but to Lee's Point developers, like what they like, they have found tools that work work the way their brains were and now you have a platform engineering team maybe in some organizations coming in saying, you know, that's not the approved tool anymore. You need to use this one because this is what everybody else is going to use get on board. Right?
So it's it's that standardization can go to far. I know in large Enterprises you have you know, 11,000 12,000 15,000 developers. You have to figure something out but you know it, you know, if it's done like a heavy Hammer.
I I think that's that's the wrong approach completely. You hit the mail and headed. There's actually a topic I talk about in the book is is the idea of standardization versus choice.
and it's a very very hard line to draw and Ultimately some you know the worst organizations if you will draw Hardline one way or the other ultimate developer Choice, whatever you want. The complexity is overwhelming our ultimate standardization. Sorry.
This is the tool you use no matter what developers are out the door. The reality is as you say, you have to give the developers the tools that they want to get their job done. Within the sandbox of guidance that is reasonable for their level of complexity that we that we want to allow in our organization.
So I like the the tools in the the term sandboxing right where you can say, here's the set of toys that we're playing. And this is a changing size you can bring toys in and we can talk about them. But this is the size of the sandbox within the sandbox do whatever you want.
And that's sort of model. I think helps a lot with this balance between Choice versus complexity. I think this gets to some fundamental psychology Parts here too.
But before I get in that let me just talk about like how is like platform engineering defined by analysts or or what do we think about platform? Right the word English word platform means to you know, use as a foundation to build on top of right? So the goal in removing or reducing some work from developers is all about reducing friction, right giving them more self-service giving them things that well.
Okay, the organization has already done tests on this stuff. So perhaps you can use this but then it gets to the psychological need developers. I agree with Lee hundred percent.
They come out of just just being a developer with the ethics of I've got full accountability. It's my application. It's almost like my baby and it's out there in production and I want it to be the best things in slight spread so they have that accountability from day one in terms of a that okay, but then when it goes as far as control or if the engineering manager or upper senior, you know senior layers above the developers are actually putting code into systems say well, okay.
I need to I need you to control and be fully accountable with the sales of your application and in the market, right and the developed that kind of accountability is put on to developers. Then the developers going to naturally gravitate more towards control. Well, how could I be responsible for the business?
If you told me that I must use this stuff that's been intentionally encapsulated. So I don't need to understand and and just use it. Right so I'm giving up accountability.
So I think when people use platform engineering as a mechanism to say I'm going to control what you do and remove Choice from developers, then it's gotten too far. But when it's when it's used to actually reduce work again back to the AI thing, right it is taking work off of the developer because that's where everything meets right and customer delight and and achieving the functionality the non-functional specs and everything. Right?
We're trying to spread out some of that workload and I think that's where platforms can play very well especially where developers don't want to worry about it and be accountable for things like security, you know Plumbing. Okay, how what service talks will another well what services allowed to talk to one another is this data accessible from this system do I need to have data privacy tags around that data things like that? Add that if we can push down into the platform then it does make us more productive.
I mean, let's look at the rise of kubernetes. Okay, it's a lot of people have complained that oh, that's too difficult. Well, I think that's a bunch of farts.
I can't think of a better word. It's just nonsense, right? It's it's developers or even operators that don't want to learn the fundamentals of distributed computing and systems engineering kubernetes and container platforms have just made it more simpler to solve that inherently complex problem, right?
So when people say oh, this is a tough technology, it's actually well. Look at That's The Power of platforms. Now, there's a lot of things you're not worrying about things that happen automatically in the platform that's taking care of for you so you can focus on your business applications.
So if you don't Rob yourself of the learning opportunity and you don't try to you know have a control sort of mindset then I think I think there's a there's a lot of benefit in the power of platforms here the program I'm gonna push back on you on this one about kubernetes having been really adopter kubernetes sure. It's not simple. It's extremely complex.
The cncf and the startup landscape will testify to that with all the people who are trying to make kubernetes more simple more approachable more accessible kubernetes is not simple. It's extremely complicated. It started off simple, but it's not how we use it.
Now what we have now is not simple and it gets more and more complicated as people try to use it for more and more and more. Right and that's fine. Right but there is a very very large gap between understanding the concepts of containers and schedules and orchestration and it's implementation and kubernetes does nothing to make that more simple that all said there is room for kubernetes the art of the possible which is why I think people really go there you can do a lot of stuff without having to write your own automation because there's a platform for it, but it's a lot like, you know, you can get from one place the other by flying a plane but flying a plane does not simply easy.
So I think I think within our within the devops community. I do think that the level of Tooling around trying to make kubernetes more approachable, you know kind of speaks to its to the complications thereof, but it doesn't mean that we're you know not rising to the challenge or whatever but we are recognizing that it is in fact not great. I think it also leaves room for something that something else that is maybe a little less not great.
But you know what that is next, you know, we'll see I think of it as in a constant Innovation. So as you innovate It's never perfect. Right?
So you keep improving you make things better. Like if you look at cncf there isn't a cloud native testing tool in the cncf landscape, but there are what a thousand different logos on the cncf landscape page, right? So so yes, there's those fundamental gaps there.
And so what companies do is they say? Okay, I'll go fill this Gap. Oh, I'll go fill that cap.
And I think what you have is you have inherent complexity. spreading an application on top of a lot of Compute storage and network infrastructure and being able to rewind and replay what happened in production to go back and improve your application. I think there's just a lot of inherent complexity if you look at devops as well how many different devops Technologies are out there today?
Right? There's there's hundreds of companies involved and they're going at it from different perspectives, right? You have gig there's multiple flavors again.
You have Bill tools. You have places your story or build right? You have image scanning tools, right continues deployment get off tools, right?
So I think if there's inherent complexity You're always going to need to keep evolving to make things simpler and simpler lower friction and it's a matter of the maturity of the platform. So I would say kubernetes is not done yet. And I think there are customer like if you were to say how would I take an application and right at the same way such that it runs in any environment and if everybody had to build their own mechanism do that.
You'd probably come out with very similar things that you know, we as an industry have developed well, but Necessarily. Okay. So, you know, we there are different tools other than kubernetes that accomplished the same thing.
There's for instance ECS which accomplishes a very similar set of problems but a much simpler way, but in AWS problem is the problem is that what kubernetes does is kubernetes gives Choice enhance complexity. And what ECS does is it says it gives opinions and and viewpoints are requirements and therefore it's a lot simpler if you meet those requirements, but if you don't it doesn't help you at all. So the comes back to the complexity argument.
I can you you create your sandbox and a sandbox gives you a level of complexity and that's the way it goes. I think the problem with kubernetes is they didn't put enough guardrails in place. And I think that's what some of these tools are doing.
Right some of these innovations that Tim is talking about he's absolutely right. Is there trying to Put some order on the chaos to reduce the complexity rain in the complexity and give some reasonable best practice guidelines for how to use it. And therefore at the same time make it simpler to use the kubernetes isn't is Isn't overly complex I think is false.
I think it is overly complex. But there's a reason why there's a reason why yes. Yeah, and it's basically that thing that everyone it's started become more and more lately where everyone is like, you know, what's the golden path right for the developer?
Right? Right. And if you can find that they don't necessarily have to stay there but they have some guidance.
Yeah. I was looking at the great philosopher of engineering a commander Montgomery Scott who said The more you overhaul the plumbing the easier it is to stop up the drain, right? So kubernetes doesn't doesn't eliminate complexity.
It just changes where it is, right? And I think that's the thing the things that what we do is complex things are trying to do a complex. There's no way to make that simple but there's a way to change where that complexity lies, right but it's so doing right now you change who's in charge of fixing it, which is a whole other.
That's right. It causes an organizational change potentially everybody. Okay, Scotty in the middle of a devops conversation has my ultimate respect.
Oh, he's you know what to two things can be true at the same time, right? There are some things that kubernetes environment does simplify for you. It is also complex because to your point earlier the about with great flexibility comes great complexity to misuse Peter Parker's Uncle Ben's quote.
So, you know, Have Spider-Man both at the same time in the same episode. Bad, right and we had somebody mentioned physicist earlier. I forget who you mentioned.
But yeah, but yeah, let's think about the developer and the standardization debate. They're sort of the goal that you like area where there's enough standardization that you don't get Rebellion from the developers. But at certain point if you tip it too far into these standardization mode, it kicks in Newtonian physics for every reaction standardization is an opposite and greater reaction, but the developers to say screw this I'm gonna do my own thing if you're getting ready those bigger guardrails.
Maybe I'll go look for it's the stretch rubber band as long as it's stretching. You're fine the moment. It stops stretching.
That's when you have a problem you rubber band right like gravitational physics comes along and you tell me wasn't that accurate it does. So let's do this. We have just a few minutes left.
So we have to have short lighting around short answers. What's the one thing you hope doesn't happen this year. Devops, like please don't mess this upper.
Please don't go down this Avenue. We've made that mistake before or whatever you can think of whoever wants to jump in first. I hope that in our our race to AI all the things and store all the data for AI that we don't forget that there is a a ecological cost to what we do the the computers that we use to do Ai and the amount of Cycles.
We use to store all the data do cost. You know, not just money but also energy and I feel like if we get so wrapped up and trying to predict all the things that we may be predicting our own demise. Sustainability great who's next?
I'll go next. Um, keep you on the AI theme I I hope we don't Focus too much on the word intelligence and Ai and depending on on this artificial a little bit more in other words. I think let's believe less hype and and more reality for what a I truly is Which is less than what the hype says it is.
Yeah, I guess I'll add. As Technologies evolve and you know the devops continues to grow I would say keep doing that, you know, keep keep the movement. You know, I know there's a lot of a myth that oh this is dying or even you know, this this will be replaced by some other new thing out there or you will be replaced don't give up what you've been doing.
If you look back over every decade, they're significant progress. And then in that process don't use technology to keep you to to stop you from continuously learning, right? So if we build platforms that become better that do have the guardrails that we want that make things easier have less friction.
Don't use it as a tool to say. Oh, I don't need to understand what that platform does use it to your you know to empower you but don't use it to keep you stupid. If you will if I can say that and never neglect operations and you know, I Since the dawn of applications running anywhere whether in cloud or on-premises or for small customer groups or for the entire world billion population, we still struggle to keep applications running and delighting customers.
So think about that up front security and operations and use the power of the platforms to help you get there and know the platforms are not going to be perfect at people said on the call and it takes a long time to evolve standards and get people to agree. Just don't give up hope oh speaking. Hope you get the last word.
Yeah. Well, I hope doesn't happen. And and that's that's pretty tricky.
I like it. Is I hope you know if we think about where we are in the economy the layoffs everything that is happening and you know the potential, you know Gloom that's on the horizon. I feel that.
Developers in some organizations are starting to see more like Commodities than than people. So I'm hoping that that concept where people think about the 10x developer. They continue to realize these These are actually people who are part of your organization.
They they do a good job, and they are critical but it just feels like there's a little bit of commoditization started to happen and some organizations and I I like for that to not become more widespread. I think it's a great note to end up on thank you all thanks to all of our panelists today where we heading in 2023 with that box. I think we had a lot of past that we explored and I'm sure some will come true and some won't we'll evolve.
So thank you to our panelists. It was great to have you Prague the Tim and hope and thank you to try scientist for being such an amazing sponsor and working with us and creating this great programming coming to you on Tech song TV on devops and bad. Hope you'll join us in another episode.
com, and I'm sorry devops on bound and we will have live around tables too. So sure and check out. Those are available on the website.
You'll see us under the webinar section. So take care everybody. Thank you all here.


