Techstrong Gang – July 15, 2024

Hello, everybody. I'm Mike Biard. Alan Shimmel is once again out on vacation.

We're gonna be talking today though, about a special report from an AWS conference that Paul Nacho at the FU group was at. Then we're gonna jump into, well, API anxiety and then the real state of software engineering. 'cause Well, there's just a lot of burnout out there.

You're watching Textron Gang. We'll be pack in a minute. All right, folks, we're back and we got a full house today.

We've got, as mentioned earlier, Paul Nati from Theum Group is joining us from, well, I think you're in Boston, outside of Massachusetts somewhere. Uh, today I'm back, um, back in North Carolina, but I was just recently in, uh, uh, New York at the Java Center for the AWS Summit Conference. All right.

Traveling everywhere. As usual, we have Mitch Ashley is in the mile high Denver, Colorado. How you doing, Mitch?

Good morning. Good morning. Happy week.

Have a great week, everybody. All right. And then we have John Schwartz joining us once again from the Bay Area.

How are you, John? It is sweltering here, but we Soldier on. There you go.

And speaking of sweltering Tracy, you were hiding out in the desert still. It's not sweltering here. It's beautiful here.

We're having lovely weather. All right. Awesome.

For you guys then. Yes. Well, let's just, Let's just jump right into this then, and we'll go to Paul.

But Paul, you spent a massive amount of time with AWS and, and they covered everything from developers to the business side, I assume. But walk us through a little bit about what you're hearing from these folks, because well, they play a huge role in so many IT strategies these days. No, absolutely, Mike.

It's, uh, it was a great event. Um, when I, uh, uh, arrived. It was, uh, kinda exciting to see the Java Center just like really exploding with a lot of people.

Just kind of, you know, interested in what's happening, uh, around AWS the announcements and such. But, you know, I think what was most interesting to me, uh, was the major themes that, uh, AWS were talking about this, this, at this event, aligned nicely to the research that we're doing. Right.

So, and I'll give you kind of an example. So there was three major themes. One was empowering developers and business users that, that aligned to the Democrat democratization of AI theme that we do for our research, right?

That was one second one that came up was driving business value with Amazon Q. That was really a, a big focus at the event. And in the theme that, um, I have, um, on the research side was AI to business transformation.

So that was, it was definitely a relationship there. And then finally, sustainability and leadership. Uh, that was, uh, part of our, uh, that was an announcement that they were talking about.

It was a theme that, uh, came up with, uh, in our research with sustainability and technology. But if we unpack those three things, uh, the, the real focus area that AWS was looking at was when we look at empowering developers and business users, there was, um, really that focus of democratization of AI around fine tuning the capabilities of anthropic ai, uh, as well as integration of Q with, uh, stage maker studio. Those were the two new announcements, major announcements that were kind of, uh, bru front center, front and center, uh, application development, creating applications faster.

That was a big focus for, uh, the keynote, Matt Wood was a, was was big on, uh, talking about that second theme that came up that was, uh, was right around driving business value around Amazon Q was, uh, really about that business transformation, right? There was over 40 data connectors, uh, around, uh, for options. Uh, you know, that really helped with Ty in the, I would call it bridging the gap between old and new.

You have the, uh, heritage systems of record, and then you have new systems of engagement, and you have these connectors that kind of tie it all together with, with the Amazon queue. Love that, love that model, because that really kind of ties again, into our analyst research around past, present, future, and then, and how I talk about that, uh, that stage. And then finally, uh, and we'll talk more about this later in this episode, but there was a focus on internal APIs, right?

Internal APIs was a, was a big area of focus, uh, in utilizing those APIs for the appropriate, uh, appropriate delivery around Amazon queue. And then, uh, the other announcement within Amazon queue was code generation and debugging. So, uh, a lot there that was interesting.

And then final theme, um, was around sustainability. And of course, uh, environmental, social and governance was top of mind. Um, you know, the way I view it and the way I think Amazon and most organizations are viewing it is this is really less of a focus go to market, so to speak.

But it's really an enabler for success. Uh, organizations that are looking at deploying new solutions are looking at ESG as ways to kind of deploy, but it's not like the primary go to market. It is, it is important, very important, especially in different geos in different regions.

But it's, it's, uh, it's definitely an area that is, um, an enabler for those. So for those products that were coming to market, um, the, you know, when, when I wanna talk, uh, from there, I, I, I guess I'll talk about the keynote and, and the keynote, um, really introduced a number of different things. And I kind of touched on some of it in themes, but I'll kind of double click down.

One was fine tuning, uh, take center stage. That was really a, a, a main, uh, focal point, uh, fine tuning for developers and, and, and creating these tools for the, to expand the business needs. Second bullet that kind of came up out of the keynote out of Matt Wood was really that I, I mentioned it, Amazon q embracing stage major studio.

That was a, uh, really a, a big focus. It's now ga uh, and, and, and adding, adding those two technologies in the stack allows for stage maker to kind of really allow, uh, amplify the Amazon queue focus. Uh, then, then there was a discussion around, uh, bedrock and the knowledge basis, how bedrock and knowledge basis allows you to connect the dots between that AI conversational agents, and allowing the, uh, streamlining data for, uh, for retrieval around those agents.

Um, big, big focus here that Matt was kind of talking through was grounding AI in reality, of course, when we're looking at these data sources, those 40 connectors I was mentioning, um, excuse me, tying back to these, uh, uh, different data sources within the LLMs, making sure you're grounding it not, and reducing the hallucinations, actually eliminating the hallucinations is ideal. So, and then finally, the, the big, uh, last bullet, I guess key out of the keynote was, uh, a new generation of builders for, uh, using AI and, uh, with, uh, developer customization using Q and and, and making Q Amazon Q apps an enabler for the area. So really, really powerful, really, uh, kind of messaging that was, uh, interesting to the audience.

And it really kind of, uh, uh, I saw a lot of excitement in the room. Uh, so, but I'll be putting out, excuse me, I'll be putting out coverage, uh, on the future room groups, uh, site, uh, it should be live early next week. And, uh, that you can read all about it there as well.

Okay. Uh, thank you. That was a very comprehensive review.

Almost felt like I was sitting beside you there, Paul. Um, I'm curious, you know, a lot of things that are happening in market right now are about kind of platforms op, how to production operationalize applications that are using ai. And AWS has always been very, very developer friendly, maybe developer focused.

I'm curious, um, as you think about Amazon queue and platforms like Bedrock and the announcements around SageMaker, sometimes the story about how we move those things into production, uh, can be hard to tease out. Was it, was it really clear, uh, that Amazon's moving customers, like how do we get these apps into production as well as democratize and get people on the front end? What were your thoughts on that?

Yeah, Mitch, that's a great, great comment. Great question. Um, you know, I think when I, when I look at the out output, the key takeaways, right?

The key takeaways that I, that I kind of took away was really bifurcated for the business leaders as well as the developers. Um, when you talk about the applications and, and pushing them into production, it was really about, um, the big focus was using gen AI is no longer just for that tech giants, right? It's, it's really made for, uh, and to your point, Amazon enables businesses of all sizes to automate those workflows to basically enhance data utilization and unlock the, the, the different levels of, uh, innovation that organizations are trying to achieve.

And what I liked, what I was hearing at the event was for the business leaders, it was about, you know, taking those, uh, applications to market. What we see in our research is, uh, 24% of respondents to our research are looking to release code on an hourly basis, yet only 8% are able to do so. And with the output of the announcements from, uh, this keynote, or not just the keynote, but from the event itself, it was about enabling those businesses to release code faster.

So, to your point, the other key takeaway that, that I saw from the business leader's perspective was invest in the workload, the workforce. Now, this was not just internal, but also working with service delivery partners. There was a large afternoon session that focus on Deloitte and, um, uh, and, and AWS technologies and what they brought to the table.

It was really powerful to see that the two tech stacks come together, having the service delivery partner address those skill gap issues that we're seeing. And, you know, of course, the other keynote that I mentioned was sustainability. That was a big, that was a big focal point.

That was for the business side. And, and I'll be real quick on the developer side, um, it was really about, and, and Mitch, this is kind of probably where you were, where you were kind of driving towards, but it's the lower barrier of entry for those applications, getting those to market, getting them quickly to market, and, and, um, you know, those previously complex AI tools are now becoming more accessible for the larger audience. Um, the other focus was enhanced productivity and efficiency.

No developer wants to say here that, oh, we need to work faster, you know, whatever, whatever. But the reality of it is is developers don't wanna focus on maintenance. They want to focus on innovation.

And that's where I thought that this was a, was a big area. And then finally, from the developer perspective, it was introducing, excuse me, the new opportunity of having skillset, uh, addressing the skillset issues that we were seeing. So, Mitch, I know that was a long answer to your question, but I think it was, uh, relevant because it tied back to the, the two bifurcated, you know, business leaders as well as developer messaging.

Yeah. It shows, what it takes is a complex web of things to make it simple, right? To get there.

Sorry, go, go ahead. Trace. You know, I'm surprised at this point in our careers that we're still talking about struggling with doing high frequency releases.

Can you, was there any more insights into why only 8% of companies can claim that they could do that? Uh, certainly we've gotten better. Yeah, that's a great, well, I mean, I'll, I'll take it outside of the AWS conversation, just in general.

Um, the, the main com the main challenges organizations run into with, uh, with, with, uh, releasing code is their, when I talk to CIOs, their number one challenge is to modernize their existing heritage architectures or applications. The barriers that they run into are top of the list is complexity. Complexity is a, is an issue.

Second to the list is skill gap issues and skill gap issues. Uh, you know, it's when I did in my latest, uh, research report that just, that just came out in, in, in June, um, I, I was talking about the fact that 33% of developer time is spent on innovation, where 66% of the time is spent on maintenance. And when you're trying to release code on that, on an hourly basis, um, that CICD pipeline, that infinity loop that you run through, uh, becomes more and more complex when you're trying to add in all the different things that you run that that could happen.

So when you look at day zero, day one to two, build, release and operations, and you look at those actionable insights. So when something happens on day two, and you have to implement it in your, your, your, you know, agile processes, right? To release that code, that process becomes more and more bloated.

So, and I, I, I kind of equated to this, and I'm, I apologize if other people have heard this before, that I've said it before a thousand times, but think of stone Stonehenge, and, you know, if you put the, your hands underneath those rocks, and I don't know how they did it, but how they got those rocks up on top of the other rocks, the more hands you throw underneath, I find it really difficult to believe that people could lift that rock up. And it's the same with releasing code. You can't keep throwing more hands at it to release code faster.

You have to have automation in AI in the process. And that's what we're seeing is that pivot, uh, uh, uh, that kind of, uh, pivot in, in organizations in the CI ICD pipeline about moving code from, um, from manual processes to more automated and workflows. Well, I would've host by now, for goodness sakes, for our DevOps.

We've been talking about this for such a long time. Yeah. But I understand that there is a, we are in a, in, in a flux here because we're trying to modernize, we're trying to decouple these, these monolithic applications, or at least write new applications in a decoupled architecture.

And we don't have proper tooling. We don't have proper DevOps pipelines. We don't have proper procedures and processes to manage these decoupled architecture so that we can implement quicker.

So we've gotten our, we've gotten in the way of our own selves, to be quite honest. I bet we would've had a better answer to that five years ago. People would've said that they were releasing, uh, more frequently in a monolithic architecture because they have not yet adjusted to a, that digital transformation we've talked about.

And they are struggling with so many pipelines and so many pieces moving. Hey, I ask, oh, can I ask you a quick question about the significance of some of AWS app studio, of course, of just get a lot of attention, uh, uh, especially among users about building applications with the help of Gen ai. And they say Amazon claims within minutes was, was that significant at all?

Yeah, well, uh, Amazon Queue apps is, is, uh, kind of, uh, the main was, was really a main focus. It was really to drive that, uh, developer customization, uh, with, uh, basically shifting from the definition of the builder, so allowing more, I was calling it, and, and I know it's kind of a interesting term, but I was calling it the citizen developer. Think of it more like moving the developer to the line of business, allowing not a true coder developer to create those apps, but allowing for a low code, no code development cycle.

So developers can now leverage Q to create those, those, uh, you know, integrated AI applications directly into workflows. Um, and, and like such as, you know, like workflows, like utilizing Slack or other custom build applications, that's where I think it's, uh, uh, it's allowing for faster time to value and also allowing for releasing those applications on a much faster cadence. Um, I, I do wanna address what Tracy was talking about.

A lot of organizations are struggling with maturity within their organizations. They're struggling with keeping the wheels on the bus, nevermind introducing new methodologies to drive forward. I know for years we've been talking about optimizing CICD pipelines and DevOps methodologies and such.

And there's absolutely tools and techniques and methodologies in place in order to make the, the productivity and efficiencies many organizations are struggling to actually implement and deploy. And that's where I think there's a disconnect. Hey, Paul, I wanna ask you one quick question before we kind of close this one out.

Um, we had John Willis on this show, and I don't know if you know John, but he is on the gang, and he was talking about developer experience as it relates to LLMs. And, um, it was his opinion at least that, uh, much work needed to still be done, especially in the context of, uh, what AWS is up to. Did they talk about making a better developer experience for people who are actually trying to build AI applications?

Oh, absolutely, Mike, that was one of the key takeaways. I was, I, I glossed over it real quick, so I'll, I'll come back to it. The two things that come to mind out of the announcements was fine tuning, um, was for philanthropic, uh, uh, AI and, and also grounding AI in reality.

Those are the two things that, uh, enhanced the, uh, the, the developer experience for having accurate data. Uh, when I mentioned that there was 40 plus connectors for Amazon queue, that really expands out, again, bridging the old with the new. So you have the, the heritage applications, allowing those organizations to take those, uh, monolithic or heritage applications, but utilize a new front end to, to build those, uh, new, say new applications in the front end that are accessing, they can utilize the new fine tuning capabilities as well as grounding to eliminate hallucinations, eliminate redundancy, ellu, eliminate any challenges within that, the data flow.

Um, but it also makes it easier for developers because they don't have to, there's more confidence by, um, removing the human in the loop, so to speak, for every checkpoint, and having the confidence that the grounding and fine tuning can allow for. So I think that was really a, a powerful way of kind of, uh, amplifying that developer experience and allowing for focus on innovation, rest versus maintenance. All right, folks, that was a detailed report, and I think it was to Mitch's point, I almost feel like I was there.

Um, hey, but by all means, check out that report from Paul on the Futurum site next week. Paul, where is that exactly? com, um, website.

And it'll be under, uh, the, the insights and articles. All right, folks, we'll be back in a minute. All right, folks, we're back in as promised, our next topic is well APIs and a certain amount of anxiety that goes with that.

Um, just recently, an outfit called Boomi created a control plane for APIs that you can manage APIs regardless of where they are or what platform they were created on. io meanwhile has extended its API gateway to reach out to LLMs, and you can manage and orchestrate those as part of a workflow as well. And we've had some conversations going on, on Techstrong TV around APIs that Mitch has led.

So I'm gonna jump to Mitch, but Mitch put this in a little context for me, because I feel like we all agree that the APIs are kind of the glue that stitches everything together. And yet I feel like the management of APIs and governance is still relatively immature. So, uh, why is the cart before the proverbial horses at work?

I think we, we live in a world where it's, it can get away from us very easily in terms of APIs and the number that are being created, the management of them, you know, APIs are, are sort of like a, a version of code that you release and then you want to, you wanna manage over time. 'cause they have a life cycle that they actually go through all the way to being deprecated and replaced by something else. And we think about how much of our internet traffic is, is APIs.

It's just not the protocol. It's all the things that are happening within that protocol. Um, what's what the APIs are doing.

And we talked to, Tracy and I were on a, uh, episode of DevOps Unbound recently, talking about API first, which is where a different philosophy of designing your applications. So it only talks to itself through its own APIs. So you don't build a GUI into it.

You're, you have a user interface of whatever, mobile, web, et cetera, that's talking to APIs, that's an underlying background. And even products, the API is the product. That's how it's presented to the world.

So the point being is it's more than just discovery of what's happening in your organization. Yeah. Where are they, what are, you know, what are people using?

It's now, how do we, how do we think about it in a a PA lifecycle management? How do we think about, um, knowing that it's there, but also from a governance and a security standpoint, how do we apply policy to that? And making sure that if you think about accessing our LLMs or maybe citizen developers who are doing development, who don't realize that the code that they're, they're creating or the functionality they're creating underlying all that as APIs across all.

So it, it's kind of like the, it's really the plumbing of the applications. And we, we tend to gloss over that as such an important element of, I know Tracy, you live in the world of, of, uh, APIs sometime entangled APIs from our conversations. Yes.

I love hear your thoughts. So, you know, I don't, I don't wanna say that, uh, we're terrible developers. Let's just, let me just preface this with, with that everybody's doing the best job they can.

However, APIs traditionally, we have not done a good job of organizing them, let's just put it that way. So what happens is, is there's a lot of duplicate APIs because we don't really understand where to go find them. When we go to write something, can't find it, you're gonna write your own.

It's just the way we are as developers. I find it similar to, you know, I'm a pretty tidy person, but I have a junk drawer in my kitchen and I have a junk drawer in my office. Oftentimes I find that, um, APIs are all stashed in junk drawers.

There are different repos, there's, it's hard to understand what they do. They're not, well, they're oftentimes not well documented. So some of these new tools, these control planes are there to, to help us clean up our mess so that we can make APIs more efficient and get to them easier.

Or even know who to call if something breaks. If you're using an API in your application and something breaks in your application, you may not understand that a, that API was just released and it's now new. So how do you even find that out?

How do you know who to call if you're an SRE? You know, where do you go? So it's time, um, for these tools to start thinking about making APIs, uh, more organized.

Uh, I always talk about domain driven design. It's important, it's important today, it was important when we were doing c plus plus and object oriented programming. And it's important to be able to organize these APIs in a way that developers can have clear access to, to, to them when they're writing, as opposed to trying to hunt them down and say, it's easier for me to rewrite this than to go look for it.

The API first conversation, that, that's an architectural approach, but it also goes to treating APIs as your product, whether it's product externally or internal to your own development and applications. And if you took that, the importance of APIs to that level, whether you're doing it architecturally that way or not, that would elevate the importance of managing it, cataloging it, understand where it is, where it's being used, where to go to find out. And that's where some of these control planes and platforms are a big help.

Mike. All Right. Yeah.

You don't wanna have jump drawers for everything that you're working on, right? You wouldn't wanna sit there and dig through all of the, all of the stuff, you know, okay, here's a a letter opener. Here's some broken pins.

Christmas of 2021 APIs. So, so, so we have terms for the things in the junk draw. There are, uh, things like, we call 'em rogue APIs and we call 'em, um, unsanctioned, unmanaged APIs.

And there's all kinds of, this conversation's been ongoing. Paul, who is supposed to be in charge of managing the APIs? 'cause I sometimes feel like the developers create the APIs, but then they forget about 'em.

Yeah. API I management is, is, uh, is definitely tricky. It, it, it comes across the, there's, there's a number of, of approaches that organizations take, which is, uh, it a lot of organizations will take, and developers will take an API first approach, which is understanding the traffic between the applications and how the applications connect.

Uh, but usually the API first approach is, is in place to basically map into, uh, new, new applications that have to access the, the, the different, um, data sources in the backend. So the, what SOLO and Boomi and, and others are doing right now is really enabling those developers to, uh, have access to, uh, the, the, the different data sources in the backend. But utilizing APIs first in order to have those applications have more of a broader span so they can take advantage of, uh, of those different, uh, uh, LLMs that Mitch was talking about.

But also it, I think it ties back to what we were discussing in the AWS conversation, which is, it, it, it does amplify the need to make sure that there's harmonization for, um, uh, reducing the hallucinations and reducing the, or I should say increasing the fine tuning. So I think those are the types of things that need to be taken into consideration, regardless which platform you're on. And I think that Solo and Boomi, uh, I'll have a, uh, provided a good step in order to get in that direction.

Mitch, is API management the job of a DevOps team or a platform engineering team, or, um, has that kind of just been outside the scope A matter of opinion in, in my opinion, I think it's, it's, it's in the realm of the developer. It's in the realm of the p creators and users of those APIs, right? So if you're creating an API, it's your job to provide whatever information, here's what the API does.

And whether that's comments in, in the code or it's in some repository where that API is checked in. Um, the more you could help others know about it and others understand what it does, more likely it's gonna get reused. Um, because you might also say it's part of the, an architect's role, maybe a lead developer kind of person.

Um, but those are the people that are cranium, those are people who are writing duplicates of it if they don't know how to go find it or don't want to take the time, 'cause they're, you know, under pressure to deliver whatever that might, that might be. Now, it also affects other parts of the organizations, of course, because now you're talking about integration not just within, but across applications to Paul's point, getting to data sources, et cetera. Um, but also security people care a lot about this as well.

So, you know, we think, see things in the security world of more than just having a gateway that applications go through. It's kind of a control point. Like we would an application firewall or web, web application firewall is to be able to apply some governance to that.

So that's what this, this is how this API is intended to be used, and are we using it that way? And how do we know? And that's where that can be assessed and then controlled if you're a controls applied to it as well.

So there's a lot of parts to this, onion layers to it. I think it all starts with the developers. I'm not entirely sure.

'cause I feel like, you know, we've been talking about shift left and that's been a mixed success. And frankly, you know, Tracy, let me ask you this, but, you know, are APIs just too important to leave the developers to manage? Um, I think developers do their best to manage them, but they have a lot of other things to do.

And if they don't have proper tooling to manage them, what are they supposed to do? Right? They're checking 'em into a, a repo.

And that's kind of the process we've always done. Um, so yeah, it is a little bit too much work for a developer. There should be some procedure or some way of properly managing them.

Now that can be hard to do. I've seen, I have seen repos set up in a really clean way where you can see precisely where to go find, um, some of these, uh, APIs and reuse them. But for the most part, I don't see that.

And when, instead I see a lot of names that are kind of strange, you can't really understand what was checked in. A new developer doesn't know that a good naming standard, they're not following it. So they, it just gets, they just create a repo and they have some stuff in there.

They may have documented it in the repo and the readme, but you really, you really can't see what these APIs are doing unless you have the information federated in a way that, that everybody can follow. So, you know, we are talk, we, we talk about shift left all the time, but you can't expect the developers and shift left to developers who have no, they have no budget. They do their best to bring on open source tooling, and they do their best to pull these parts together.

But if somebody is not looking at the problem from a, a higher level, from, from farther right? Or somewhere in the organization to address these issues, maybe in the DevOps space or, um, you know, at a somebody who's managing application development overall to look at the problem and understand why developers need these tools and how they can be implemented, then developers are always gonna struggle with it. You can't, they can't solve everything.

We can't always shift left to the developers, um, because they're not being asked to do way, way too much today. They really are. So the, the Federation of data is so critical in APIs.

And Mitch said something important too, this, there's security aspects, uh, to that as well. Think about it, every API has its own SBO m So when you go to, when you go to run an application or you go to deliver an application, say to the government, um, you have to have an application level. SOM, they don't want an SOM for a few, a few hundred APIs.

So we have some federation work to do. And, uh, I think these are good steps. You know, Tracy, to to your point, um, you were talking about developers can't do everything.

So I, I guess my thinking really applies to, it happens in the realm of the world of development because it has to be owned by an architect. Someone has to take responsibility, somebody has to take ownership. That's the real issue.

So who's gonna own naming Sanders? Who's gonna own, do we need a repository or a different platform to manage APIs? Who's gonna own that?

We follow the standards for what we set out for how we're, when we define an API, how we manage its lifecycle, the naming of it all, uh, we check those things in code reviews, et cetera. I don't think that shifts left to security or some other organization. I think it shifts to some owner within that development realm.

Because ultimately that is the application that is the software that you're creating, because that's, it's more than the kind of hard outer shell that you're going in and out of. It's how the whole complex web of microservices and integrations to, to third party sources or other applications internally happen. So I think it has to fall in the realm of an architect or maybe an engineering leader or someone in the organization that's taking responsibility to say, this is how we're gonna do it.

And I think developers will think, say, thank you, appreciate it. Now just make it easy for me to do it that way. You know, Mitch, I I, I kind of, I agree with what you and Tracy are talking about here, uh, anecdotally, it, it makes a lot of sense.

The, the one thing I I try to do as an analyst is back everything up with data, right? That's just my, my job and what I do, right? So when I look at our research and I look at, we've asked these questions about why things are slowing down, why, who owns what process, and the whole shift left kind of method methodology of moving from the day two to day one to day zero.

Um, especially when it comes to API management, it, it, you know, there's, there's this desire for organizations to shift from, you know, DevOps to platform engineering to kind of move towards more clo mo clo move closer to engineering. So engineering can make those decisions that they don't have to incorporate changes later in a cycle. Uh, now with that said, I have to just default back to from the, again, this is based on research.

It really hyper depends on the maturity of the organization. Uh, if the organization doesn't have everything that you, Mitch and Tracy were talking about, uh, like if doesn't have the compliance and governance and regulations and, and rules and, and map that methodology, uh, as part of their culture, uh, it, it all kind of falls apart, right? I mean, if it's, if it's, if it's kind of the wild West and, and people are doing what they want to do, uh, to get the job done, that's one approach.

But you typically don't want rogue developers just doing whatever they wanna do, uh, only because it's not really a good exam. A a good for that developer. And it's also not good for the business because it's not repeatable.

So, um, again, the, I guess the guidance I would give the audience here is, uh, in basically instill and ensure that you have, um, compliance and guidelines for your organization to help mature your processes and your methodologies. Hey, I wanna bring John in here for one second at a higher level, because I know, you know, John's not the geekiest guy, but he is been on, It's above my pay grade, to be honest with you. Yes.

Uh, but you've been on a number of these shows now, and I just want to get your impression are, are you surprised how disorganized we are in it sometimes? You know, Actually that, that's, I'm, I'm glad. No, I, I wouldn't say that, but it, it just seems to me, it, it, there's a common theme that runs through a lot of these discussions is the lack of, and, and you and Alan have had this, these discussions or debates about the, the value of, of, of security apps, uh, a lack of governance, the, uh, the increasing pressure.

We're gonna talk about this in the next segment, increasing pressure on engineers to become business strategists. And it's, it seems like just a wild, wild west. And I think a lot of it has to do with all the hype that surrounds AI and the pressure that is being put from the top down on a bunch of folks, um, with more regulation overseas.

I just think there's so many factors at work here that make it nearly impossible to have a tidy, organized approach to things. There's so many factors work working against you, and this is complicated stuff, right? And the only small group of people, including you all really understand it.

So the chaos seems to me quite reasonable. I almost expected I would agree, I would agree with that. I would 100% agree with that.

Make Sure you support John. I, I channeling Tracy because I, because I get this, I get these, um, talking points from you that you're very clear about your talking points, Tracy. And it's a, there's like a sense, I sometimes think of frustration, and this, this doesn't apply to what you do, but to a lot of different jobs.

There's some complex jobs are only suitable for a small group of people. And you have all these outsiders trying to try to second guess you or look over your shoulder or tell you what you're doing wrong. And it must be so, uh, agonizing, right?

Daunting, frustrating to, to, to kind of go through this process. 'cause you're doing the best you can to try to help these folks, and yet they think they know better. I mean, it kind of applies to just in, in general, the, the way the government looks at tech.

They think they know better. They don't. All right, thank, I wanna add one more thing.

I have to get this in. And that is something, um, that Paul said about maturity. Um, I would agree the more mature the organization is in terms of their DevOps process, say for example, the better off they are.

However, we have disrupted that. So because software, because we change software changes, architecture changes, we have to also change our, our models, our processes internally. And to be quite honest, the DevOps pipeline has not been, um, disrupted.

It is time for the, the, the, that DevOps pipeline to be disrupted, for example, to include a control plane. So when you publish an API, there's something that happens. It gets published up to that control pan so people know where it's at and what it does.

Um, but we have a lot of that has not been done. And the complexity around APIs requires more, more work in terms of organization. And the DevOps pipeline is where some of that needs to be done.

And we have not done a good job of, of doing that. So I guess what I'm saying is that maybe you were mature five years ago, but maybe you're not so mature today as we change the technology and we change the way we write software. I hear a revolution brewing here, Mike.

I, I, But I would just, you know, I would love to end this conversation or we could keep going forever, but, um, when you think about it, it's just amazing that anything works at all. Hey guys, we'll be back In a minute. Cloud native now is The web's leading resource for the growing cloud native ecosystem.

com is your destination for news, thought leadership, features and webinars on cloud native architecture, Kubernetes, serverless, cloud native application development, microservices, service mesh, cloud native security, and more. Stay on the cutting edge of modern application development at cloud native now. All right, folks, we're back to our final segment.

And we're talking about a, a survey that Jellyfish did. They are a provider of a platform that helps software engineers manage various processes. And the thing that leaps out to me is that the burnout rate for both managers and software engineers is still relatively high, even in the age of ai.

And we still can't find enough software engineers according to the report, but it's never quite clear to me what is the root cause of all this burnout. So, Tracy, what is it that's kind of like creating so much friction that everybody's just kind of tired all the time? I don't think today's any different, um, than 30 years ago in terms of, of burnout.

Uh, for developers in particular, they're asked to do quite a bit of work. We talk about ship left all the time. They're coding, they're managing their, their, their test, their, their, their DevOps pipelines.

They're called for production issues, even though we're, you know, we, we don't really talk about that. But oftentimes developers that got have access to production, uh, areas so they can try to fix things, they're doing a, they're doing a a lot on top of that. We have created pretty, a pretty complex new architecture.

Uh, Kubernetes got us all excited. We all started, you know, blowing apart our monolithic applications into decoupled applications. So now we have this massive transformer that we're trying to manage out in production.

So there's just a whole lot to be done. I mean, I, one night, um, when I was doing software development, I was working at a bank and there was a concert I really had been looking forward to, and I got so distracted, I forgot to go to the concert. I was so irritated with myself.

But, you know, you get, you get, and that causes burnout. So if you're that focused on trying to deliver software, then you know you're going to have a, a, a burnout problem. And it, I don't believe it's any different today than it was before, but I do believe what's different is this idea of constantly saying, let's fix things earlier in the life cycle.

True. Let's do that. But we have to be, uh, cognizant of what developers are experiencing on a regular basis.

Um, I have a, a niece who has just gotten into the business and she told me something, I was astonished. She said, you know, I have, I, I, we're, we're being pushed off a lot to deliver software to deliver code. And she said, I, I literally can generate 6,000 lines of code a day, but that doesn't mean it's a good code or something I wanna push out.

So they're being squeezed, they're being squeezed on on many different sides. They're being asked to learn machine learning and now how to deliver LLMs. They're, they're being asked to write more secure code and make sure they're doing das and SaaS.

They're doing a lot, they're doing way too much. And I feel like that this conversation about shifting left, shifting left, shifting left has worked, but we haven't really added a whole lot of staff for that shift left experience. So it's, it's the same thing, but it's, it's different.

Let's just put it that way. Tracy. Hey, Tracy, I had two questions.

Number one, what was the concert? Number two, what is this situation ever gonna get better? I mean, it seems like there are fewer resource, fewer people doing more work and more complicated work.

It wasn't, it was a nerdy concert. It was somebody who plays, um, classical piano. It would've been a beautiful night.

I'm so sorry that I missed it. Um, and I'm still irritated that I do. And what was your second question?

Oh, Sorry. That was more important. I guess the, uh, the second question was the, there is this quandary that engineers are, are facing, right?

They're, they're giving more responsibility, but there're maybe they're, are fewer of them doing more ambitious projects. I don't think this burnout issue is gonna go away. That's just my accelerates, right?

I, like I said, you know, I, I started coding in the mainframe and we, we had burnout then. Um, even though we had things like endeavor that took care of us so much, and we've never been able to achieve that kind of streamlined process on, on the distributed platforms. So the developers, they're the, they're, you know, they're the, they're the grunts and they're the ones who are, they're the factory workers.

They're the ones that are working and trying to deliver this code. And you know what I used to say? I used to say, don't let our, our manager, I was like, don't let the manager see the latest version of Dr.

Dobbs, because they'll come up with this great idea that we should be implementing. And we can't. We don't, we don't have the time.

And I, I find that still is the case. I find that, you know, upper managers, directors, they go to conference, they hear about these great ideas, and then they bring it to the developers and ask the developers to implement it without any, uh, any budget. They have no budget authority whatsoever.

And, and they do their best to do so, but it just doesn't, it just doesn't work all the time. And so then you get these immature processes. Yeah.

So Mitchell, Mitchell, wait a minute, Mitchell is, are the five scariest words in it? I have a great idea then. Um, yeah.

Or, or i, it used to be, I read an article on the plane. That's the five Scariest words. You know, what comes to mind is you think about all the work.

We've, we've gone into fighter pilots, so I'm gonna like akin developers to fighter pilots. Like they've got all this complex data all around them, all these things around 'em going off and, you know, LA lights flashing, et cetera. That too, so many things could distract them from being able to accomplish their mission.

So what they do is they get tunnel vision into a hu heads up display that tells 'em, here's what only the things you need to see. They're gonna be all right there. You don't have to look around, you know, look down, look, take your hands off your eyes, off the horizon or whatever that you're doing.

It. It's very much like that in development because, and by the way, development's a lot of fun people who do it really, really enjoy this, and that's why they work so hard at it. Um, but it's like solving a complex math problem.

You don't, most things you can kind of do in a minute, but when you're working on building something, creating, solving a problem, doing triage, whatever it might be, you gotta invest your head. You have to get tunnel vision. Uh, we talked about cognitive load.

You really have to focus. And when we ask developers to manage APIs, developers to, Hey, we have, I have this question about this piece of code, or we have an issue in production, or Can you go to these five meetings today and still work eight hours today? That's the problem, is that you need focus time to be able to work on developing software and doing it well.

Otherwise, you get a patchwork of, now I need to, now I need to take 30 minutes to get back into my game of where I was to pick up with the next steps that I need to take care of. So I think my point being, and I actually got hired as a CIO one time by explaining to the COO who is mystified, why developers aren't more productive. I said, just 'cause you don't understand how developers work, that's why you're asking them to do things they can't accomplish.

Here's how developers work. Change your leadership to what they, the job they need to perform. That's what I advocate for All.

Are we going to fast? Do we need to slow down? Is that part of the problem?

You know, I I think that this conversation's a great conversation because I think a, a a lot of, uh, organizations need to recognize the, the, you know, the, the, uh, discussions and the challenges and the hearsay and everything that's going on within organizations and, and we're reflecting a lot of the anecdotal information that we hear, right? And, and experienced ourselves throughout our careers. But I, I'll, I'll back this up with data.

Uh, I've done trending studies, and one of the things that, uh, I, I found in, in 2022, uh, continuous testing only registered at 29% of respondents were doing continuous testing on the CI ICD pipeline. In 2023, that bumped up to 66%. And the reason why, uh, that bump was, was because, uh, organizations were realizing that the developers were getting burnt out their, pushing their, the business.

KPI was to push code out the door fast. The dev, the DevOps teams pushing big green button, even though they're getting alerted saying, Hey, there's challenges, there's, there's bugs, there's code, there's security issues, whatever their KPI was to push the code out the door. So they're hitting the big green button, pushing the code out the door, leaving it to the, uh, customer or prospect that's using the application to quote, debug the problem.

And the response back from a lot of these organizations was, well, you know, we do sprint releases every two weeks, so if there's a problem that comes back in, we'll just, we'll just push out a new version. The the problem with that is, you know, of course, as we all know, you use an application and if it fails once or twice, you're probably gonna move on to a competing application and you'll never go back to that application. So it's a very risky thing.

So to see that jump up from a 29 to 66% in two years or in years, uh, that's a big, big, um, uh, indicator that, uh, organizations are putting more emphasis on testing and doing the, the right quote, right thing. All the things that Mitch and Tracy had talked about, uh, in this discussion. Uh, you know, there, you're right.

Uh, the thing is, is there's only so many hours in a day. So what a lot of organizations are starting to implement and starting to look for is that true North Star. And that true North Star is really al aligning the business KPIs to SLO service level objectives and development organizations are starting to align to those SLOs so they can, can carve off the things that are less important to them and more focused on those, the, the, the delivery for the business.

And that also means that, uh, you know, Mike, to your question, uh, do we have to slow down to go faster? Yeah. As, as a matter of fact, we have to carve off the things that are not necessary and not important, uh, and, and focus on only the things that are important in order to, to move faster.

I would also advocate that there is a tremendous push right now to leverage and integrate automation and AP and, and, and AI into this workflow to get, to build the confidence that you can eventually remove the human in the loop to develop these applications. That's the, pretty much the only way we're going to accelerate, uh, the delivery of applications, uh, at the rate that we're looking to go in the business. I feel like this is a vicious cycle, right?

Because what Paul just described was, um, you know, I kicked the can down the road to the next release to fix something, but then the technical debt starts to increase, and I get pressure to build new code, but I gotta go fix the old code, and then I'm in this vicious cycle and I'm more stressed out than ever. Yeah. And now in today's world, we have all these APIs we're trying to manage on top of that.

So we're not just trying to manage our code, but we're managing code that we're, we're consuming. Um, it's this, we've created a lot of complexity. The complexity We used correctly is a good thing.

You know, we would be doing better, I believe if we go back to our API discussion if the APIs were better managed, because then we can do low code, and the lower the, the less amount of code, the more time the developers can do to do maintenance and to respond to users' request and to, uh, be more, uh, business agile when somebody wants a new feature. But what we find ourselves doing is a lot of work trying to manage the chaos, and there is a lot of chaos, uh, right now in coding. And when we add to that, we need now security, we need, you know, we need to add AI to this.

And you keep pushing that, oh, back to the developers. You find your, your, your developers are at their limit. And ultimately we have to revisit what we do in terms of what is a mature software development life cycle for a, you know, a, a life cycle that is addressing cybersecurity, that's addressing how do we manage LLMs.

We have so much to do in this area. It's kind of ridiculous that we're still just sitting here struggling with managing APIs, because that's going to be the foundation of all code moving forward. We're not going to see a lot of, I don't know how many people are writing monolithic applications from the beg from the beginning.

There are definitely consuming other packages. So API first will get us out of this. And then, and the acknowledgement that developers cannot do everything shifting left is not always the best idea for every single problem that we face in software development.

Hey, Mike, there's some other really good things in this study that I wanna, hi, like, just briefly to what Paul was talking about, 81% said AI increases the quality of code 84 said 84% said AI frees up time to focus on high value activity. So the use of AI definitely is already, uh, making an impact. I think at a macro level, what I was impressed by was overall, 90% of respondents said that their engineering teams help inform the business strategy.

They're not back office. It, you know, technical people, 94% said engineering helps to grow the business. Uh, so there's a number of stats in here that said that eng that software, software developers, engineering, et cetera, are thinking not just in their own closed loop, but why they're doing what they're doing and what's the impact on the business, Right?

Mitch, follow that through for a minute though, because the people who are in a rock and a hard place in this conversation are the folks managing the developers, right? Because they're the ones talking about back to the business and having that conversation you just described. And yet the burnout rate is high.

So how do you navigate that as the manager? Because it seems like, you know, there's a, maybe you're over promise to the business, but you know how stressed the developers are. How do you work that?

Well, you can't make every decision for every developer about what's the most important thing to work on. Uh, and everyone, no matter their job, whether developer or tester or a, you know, service rep, they wanna know the why. Why are we doing this?

Why is this important? Why should, why are we working on this? Why are we implementing, uh, cloud native?

Why are we moving to Kubernetes? Why are we changing this direction? So the more you can inform your job as a leader is to, is to surface and answer the why questions.

It's not a, it's not just take the flag, charge up the hill, follow me. We will, we'll all die together on, on this hill. Um, but people wanna know why.

And if you're informed on why this is important, guess what that developer can say? Well, when we talked about this at the team meeting or at the company, the, the group meeting, a company meeting, that's what my manager was talking about. That's what the architecture was referring to.

It's when we say business agility, that's what they mean. Okay, now I know why I need to be able to, uh, deliver this code in this part of my app on a more frequent basis, not just 'cause it's a, some great stat in the Dora metric. You know, the other thing is, uh, that in that they, it talked about, I think that it was like 60%, I didn't, I, I don't have it up, but they, I think they said around 60% of managers reported, um, that they couldn't find qualified engineers.

Mm-Hmm. Which is high. That's a high, that's a high number.

60%. Yeah. Well, Tracy, the other thing that we're seeing in our own fu on research is organizations, 67% of organizations are hiring, I, uh, generalists over specialists because they can't find, they can't find the specialists.

So 67% of organizations saying that, look, they're gonna hire generalists to do the job, which means that they're put in the, the problem of the complexity and the challenges back on the vendor selection that they're making for the tools, the tech stack that they're using for this generalist to do the deployment. And you go back only 60% that Tracy mentioned that does, that's even with widespread layoffs in tech. I mean, so that's really significant number.

You're right. Yeah. But I think we do this to ourselves.

There's only so many purple unicorns put that are polka dotted that have been doing Kubernetes for 20 years. Yeah, Exactly, Mitch, that's exactly, People are on. You have to grow your people and grow those skills, and you want to, as best as you can, couple 'em with folks that either outside or inside have some of those experiences.

And, you know, it isn't just go hire another widget off the shelf that's got a different feature set of a person. Well, it's, you have to invest in people and help 'em grow. Well, Mitch, the other part of that is organizations absolutely do not have patience, and they don't have time to wait for an individual to become up to speed.

So they'll make moves in three months where it takes six to nine to 12 months for, uh, uh, you know, an individual to become, you know, uh, to understand the tech and, and deliver what they're asking. So if they're not making the moves in three months, they're, they're removing, they're making changes. And that that frequency is way too rapid.

Uh, so you, and to your point, the unicorns that are out there, if you can find them, which you won't, but if you can find them, you better pay them whatever they want because you're never gonna get them again. Well, and you want the unicorns, well, you want those skills, but you want them to be working with your people, so they learn from them. It's, there are situations where we're up against the wall three months, we gotta do it.

I don't care what it takes to just get the right person to help us. But I mean, for example, the first, uh, the first Kubernetes and microservices implementation that I did, I went and hired somebody. I knew how to do this, and I brought 'em in to help us architect it, teach the team how to do it.

We were under high pressure to get this done, but I knew we wouldn't do it on our own. But I also couldn't afford to just do it in some third party and never have the ability to do it again. So that's my point about this is, yes, go find the best talent you can and institutionalize it as best you can in your team if it's that vital of a skill.

Tracy, I wanna point out, hold onto these people because, well, I, Sorry, go ahead. I guess I, well, I guess what I wanna know is, so if I do find this unicorn, um, everybody and his brother's calling him up and saying, Hey, come work for me. And so what's your best advice to maybe hold it onto these people?

Seems as big as challenge as finding them. Yeah, pay 'em. Well, don't expect 'em to work so late that they're gonna miss a great concert.

Right. I mean, you know, you've gotta take some, you gotta take some of the weight off their backs. There is, because these unicorns will end up being the, the, the, the one person everybody goes to.

They're like the lab manager, right? They do everything and it's just, it, it could be too much. And the other thing that we, we really should be talking about here is if that 60% is true, um, we potentially have some more, more pressing problems in our university systems.

Maybe our university systems are, are, are not, um, moving as quickly as the industry. And in fact, I have spoken to some deans of some CI programs and they talk about the fact that it can take two, two years to get a new course offering. So, you know, Kubernetes gets released and people start using Kubernetes.

They're looking for Kubernetes, Kubernetes developers, or at least people who understand the architecture. But the university system hasn't caught up with that. So I feel like we have a lag between the Yeah, you're saying like A two year lag.

Yeah. Yeah. So, so maybe we need, we need to have, um, a discussion about that.

The universities need to have a discussion about getting these new programs into their, any, these courses into their programs sooner than later. Uh, because two years we have changed, it kind of reminds me of the government, you know, they go, they'll put out a request for, uh, for, uh, RFP for writing a certain system, and then two years or three years later, they finally decide on it. But that time, the architecture's also, they start all over again.

Uh, and the university system is somewhat like that. And also the university system, they, these programs can be a little bit superficial because they are understaffed themselves because some of those unicorns who could be teaching in the university system, they're going out and making money in industry and finding good instructors. And those instructors who are in the university systems working with these students are doing a, an amazing job.

And they're, and they're, they're selfless in their approach because they could be off doing something, probably making more money. So there, there's some things that we have broken in the supply chain of our, of new developers coming into organizations. I think that they're behind.

I believe that the, uh, education that they're getting is a bit superficial. They don't really understand how applications are constructed and they, they lack a, uh, an understanding of DevOps. They lack an understanding of basic, basic security practices.

Um, and they probably are way behind the curve in ai, even though I'm sure many of 'em are putting AI programs together. You know, how comprehensive those programs are is yet to be seen. All right, folks, I don't think we're gonna solve this problem, but the good news is AI tools are reducing some of the toils.

So there should be less stress. Bad news is we're probably gonna ask you to write 10 more applications than we did previously. 'cause we think the AI tools are gonna help you be faster.

So it's gonna get complex. Hey guys, I wanna thank you all for sharing your knowledge and insights, Paul. Yeah, no, thanks Mike for having me today.

It's been great. I love, uh, kind of do doing the recap of AWS summit and, uh, and the conversation about APIs as well as the, the burnout that for developers, it's a real thing. com.

All right, Tracy. Thank you John, as always, Mitch, as always. We'll see you guys next time and stay tuned.

We have an awesome show, as usual, a great lineup coming up right behind us and there's more tech on TV ahead.