Techstrong Gang – June 26, 2024

Hey everyone. It's a tech strong gang, kinda Wednesday, we've got a lot going on for you here. We've got, uh, is cla is the blue off the Cloud computing, uh, with AI Rose, our AI organiz, our AI ready organizations really ready, and the day shift left, died.

All that and more on Textron Gang. Hey everyone, as I said, happy Wednesday to you. It's Alan Shimmel from Techstrong.

I am, uh, really thrilled to, I'm the only one in the studio today, so I'm really thrilled I got the cameras over myself. But we have a great gang on online and remote with, uh, with us to come at you today. Let me introduce him to you, first of all, usually sitting on my left, but he's back home up in New York today, our Chief Content Officer, Mike Baard.

Hey Mike. Good to have you on remotely. There you go.

Always happy to be here. Wherever I am in the world, I am sitting at the big table, uh, joining Mike also from New York, but they're not in the same location in New York. It is at Empire State.

After all, uh, he is the host of Infrastructure co-host of Infrastructure Matters podcast, and A-A-C-T-A Chief Technology Advisor at FU Group. It's our friend Steven Dickens. Hey, Steven.

Great to have you on here. Hey, Alan, thanks for having me on the show again. No, it's always a pleasure.

We're gonna have you on as a regular. And then speaking of CTAs, we have another ct, A who's, uh, high up in the map, Rocky Mountains today. It's our own CTA Mitchell, Ashley's, also CTO here at Techstrong.

Hey, Mitchell, welcome. It is a dueling CTA day, just the way it is. Absolutely.

I'm gonna concede straight away. Mitch, you get to win the award there, my friend. Oh, okay.

Well, hey, same back to you. You win next time. We all get a trophy participation.

Every, Everybody's a participant. And then she's more than a participant, though. She's from San Angelo, Texas, and she's the editor of Techstrong, AI Digital CXO and, and lots of other things here at Techstrong.

It's our own. Amanda Reni. Hi, Amanda.

How are you? Good. Glad to be here.

Absolutely. Um, so guys, let's jump right into what we've got cooking today. Mike.

You know, there's a story up on techstrong it SM around cloud computing in the age of ai. What do we got? All right.

Well, it turns out that folks are finding this a little bit hard. There's more data, the applications are a little bit more complex. There's things called GPUs in the mix, and I might argue that that which has been done in the cloud so far is relatively simple.

But I'd love to get some input from our friends over at futurum to follow this cloud infrastructure stuff closely. Are you guys seeing a change in the types of infrastructure that people are gonna try to try to manage, and what should they be thinking about? Yeah, it's really interesting, Mike, you bring it up.

We're starting to see, I think some maturity come through to people that, um, particularly enterprises, what have we been on this journey now, probably 18 months with regard to AI being a topic that, um, is in the public side, geist. And I think where we are now, the suddenly the way I see it, and I was out at HPE Discover, uh, got to spend some time with Antonio o Neri and the leadership team there as part of their analyst track, they launched a private cloud AI platform tightly integrated with nvidia. We're also getting briefings from the people like, uh, Lenovo and Dell.

We're starting to see a lot of this workload. I, I'd say find its way into production. And I think what I see there as a sort of key trend is whilst people are gonna try and pilot something on the cloud, as they look at more production workloads, I see an increasing trend where people are gonna move some of those workloads on premise.

That's gonna be security driven. It's gonna be data sovereignty driven. It's gonna be driven by some access to the data.

So if that data's on premise, moving the AI to the data, not the data to the ai. So I, I see a trend where almost a renaissance for the likes of the hps, the Lenovos, the Dells, the IBMs with running a lot of these AI workloads on premises in a combination with potentially some of this on the public cloud as well. I I would validate that too, Steven, when I was, uh, doing the same at SUSE last week, they came out with their suse ai, it wasn't an LLM, it was a, here as the kind of known good platform for running production AI applications, to your point, repatriating applications back into your own data center as well as up into the cloud because data's located there tighter stringency around location and security of data.

Exactly to what you're saying. So we're, we're kind of seeing the, the first wave of, you know, shiny object LLMs, chatbots, copilots are, are, you know, in full force. But now we're seeing the wave of how do I do this in a production environment?

Help me set that up so I I can succeed as opposed to everything being a new science experience. Yeah, I think, I mean, the way I would say is you, you're gonna have chap as and LLMs as part of cloud-based services. We've already seen that with Salesforce and SAP, you know, the use case for call centers and cloud-based call centers and also code assistance.

I see all of those public cloud orientated. I think if it's an LLM on top of a corpus of data that's already in the enterprise, I see those are gonna be on premise And also other data for the app that needs to be accessed that's on premise. So there's a lot of, there's a lot of gravity to data in its location to your point.

Yeah. So Steven, follow Steven, let's follow that to its end conclusion. That, so when is the definition and cloud computing gonna be going forward?

If everything is kind of running everywhere and we're bringing code to the data, the LLM is on premise. Is there a difference anymore? Is the cloud computing as a term kinda, uh, fading away in relevancy?

What's going on here? Well, cloud's a model, not a destination for me, always has been. So you can have a cloud model on your mainframe running on premise in your data center as well as you can have a cloud model running on AWS and running a serverless infrastructure cloud is, for me, a model of how you create services and sort of deliver those to the end user.

It's not a cloud is not a place for me. I know a lot of people say cloud and they think of AWS they think, think of as Azure, they think of GCP, they think of OCI, I don't think of it that way. I think you can run a monolithic application on bare metal on a, uh, public cloud instance and it not really be a cloud.

Yes, it's not in your data center, but that's not really a cloud-based service. So I think for me it's more an operating model than a destination. You Know, Mike, we're also seeing more partnerships with cloud-based data offerings like AI offerings that are running with Snowflake, right?

As a data store, that's, that's a data lake that's already in the cloud, right? So I think cloud, using, using, uh, Steven's model in whatever form that is, could elevate the data services that are offered either by the, uh, you know, the hyperscalers or worry or third party, uh, data offerings because they already have security built in. They've got data management built in, they've got data that they've already collected in the cloud.

So there's some applications that are, um, are ideal for the cloud because that's where the data is too. One we've not mentioned so far, that's perfect for this type of discussion is what Oracle's doing. If you look at where a vast majority of enterprise data lives today, it lives in a Oracle database.

That Oracle database is maybe on premise today. Then what with what Oracle's doing with doing cloud at customer exascale, exudate, connecting those as tethered devices to OCI being able to run Oracle databases on Azure and on Google. Those were just recent announcements.

I think as we have this whole, where is the data, where is the AI in bringing the data to the ai, Oracle's really well placed for this discussion. Look, guys, there was a time, I remember in 2006, 2007, people wouldn't say just cloud, there was private cloud, there was public cloud, and of course we've seen hybrid cloud and multi-cloud. I don't think cloud is going anywhere or disappearing as a term, but I do think probably the two strongest camps are your public cloud and your private cloud.

And, and to Steven's point running some big monolithic type of operation, well, you can't really run it on bare metal per se, I think on, on selling the public clouds because at the very least you're running on a hypervisor and then you build on top of that hypervisor. But what we've seen is we've moved from the age of infrastructure as a service to, uh, application as a service or platform as a service. But there's more to this whole thing in the age of AI too.

We haven't really touched on security, right? And I, I, I think at some level, more important with the data quality, whether I'm on Oracle or a private in my own data center or whatever, I think security concerns are gonna be a major factor in choosing what kind of cloud, where kind of cloud, where they're running it, what they're doing in, when it comes to, you know, cloud computing in the age of ai. Well, to back that up, we saw open ai, right?

We talked about this yesterday with, uh, rock set acquisition, right? One of the things we talked about performance and being a large reason for that acquisition security is another, uh, that's built into data platforms, data tools, data technologies like rock set. So spot on.

I mean, you can't have data without really strong security or else, you know, you're, you're messing with folly for failure. Um, so that is a given. And matter of fact, that may be another kind of gravity, if you will, in this whole picture that will attract AI to it, is I get the best security there with the data, with the platforms that are managing that.

Yeah, I think if you think of an LLM and this whole sort of stack is yet another opening up, it's an API if you think of it simply providing yet another application interface into my data. This is gonna be mission critical data in a lot of cases. So being really thoughtful about that is where I think a lot of the enterprises are gonna be as they move to production.

You know, some small chat bots as part of a chat interface on a website is one thing. Putting access to PII data off an Oracle database to be able to provide sort of business intelligence and more analytical type workloads, that's a whole different ballgame. You know, I was having a chat with some folks from Dell and they were telling me they were trying to sell, you know, when it amounts to a managed service as a cloud operating model, they have their Apex service and they were telling me that they went to an oil and gas company and the oil and gas company was just not having it.

And the point of their executives were, we're swimming in cash. It's easier just for them to do a CapEx budget. And you already have the IT staff, it's a sunk cost.

So they weren't really jumping up and down about let's go to a cloud operating model. And I think there's a lot of companies out there that still have their own internal IT squads and their own infrastructure and prefer CapEx. So how many people are really gonna move to this cloud operating model writ large versus just occasionally using a cloud service from AWS or whatever.

Well, it's interesting you say that. I think if you think of cloud as a model, not a destination, let's take the banks. The big banks are sub 10% adoption of the public cloud, but are they looking at providing microservices?

Are they looking at comp, uh, complicated chargeback models? I was just out at finops X in San Diego last week, you know, a lot of the banks were there. Are they thinking about how do they, um, containerized applications?

They're doing all of those things. Just where is the computer that runs all those services? It's gonna be in their data center.

Does that mean it's not a cloud? Absolutely doesn't for me. You can have a cloud operating model running in your data center, maybe even air gapped from the public internet, but it's still a cloud operating model.

So as I think if you break the distinction between cloud being a destination and turn it into cloud, being an operating model, it, it helps with the thinking is has been my experience. Let's almost think of cloud as a spectrum, not as a binary, right? Mm-Hmm.

What is the mix and multiple things. Some apps look differently than other apps of where they are, what they're doing, how they're leveraging either public or private, and how they're interfacing. So I think it's, it's not cloud going away.

It's new uses, new models because of ai, um, in addition to what we're doing. Yeah. What, what is a bunch of servers you own running Kubernetes in an equity data center with a really good chargeback model?

Is that a cloud? I don't know, is, I mean, the operating model would say yes, maybe the destination not being in your data center says yes, but you own the kit. I think as you say, Mitch, it's a more nuanced discussion than AWS Google, Microsoft, IBM and Oracle equal cloud, everything else equals private.

It's not as black and white and it never has been for me. Let me ask you a follow up question to that, that, do we need to rethink what we're calling cloud? Because there's a model that's starting to emerge where maybe I'm running the compute in the cloud, but the data stays on premise and, um, and I'm using a high performance network in between, and I'm, it's distributed, but I'm not necessarily moving data.

And some folks I know think that, you know, moving data is the source of all original sin 'cause nothing good happens. So can we rethink the way we build the apps and kind of leave the data where it is, but take advantage of the compute up in the cloud? I think for, I mean, it'd be interesting if I ran a weekly podcast called Infrastructure Matters.

And, um, because, because that might, that might give you a hint to my thinking. I, I think if we look where are we, we're 18 years into the journey with AWS you, you know, you look at where I think the enterprise architect is now, where they were maybe six or seven years ago. I was having a lot of conversations six, seven years ago, public cloud's the answer, what's the question I want to get out of the infrastructure business?

I just want everything there. Serverless gets coined as a term, the magic spark of fairies come and run the workload and you'd have to worry about infrastructure. Don't think we are there anymore.

Um, my biggest sort of pushback to serverless is which server does it run on? And I think the enterprise architect is now thinking that through, is it a TPU? Is it a CPU?

Is it A DPU? Is it a GPU silicon's back in fashion? People are thinking thoughtfully about what does this workload look like?

What are its non-functional requirements? What is the best place to run it on? What it's type of infrastructure that thought processes back in fashion?

Well, you know, we all, there's also, we think of cloud as the services and the virtualization of all that. Um, and Mike, I'm sorry, Alan and I have a good friend, Mike Greer, who was with AWS working on the telecommunications side, the infrastructure side of it. And we, we've had VPCs for a long time, for good 10 years if not more.

And there's a whole infrastructure of interconnecting a customer's locations, data centers, things like that through high speed data connections. So they can do applications either moving data or accessing data across those big pipes. So underlying the cloud is a lot of interconnected pipes, if you will.

Kind of like you used to think about, let's put our stuff in Equinix, right? And, uh, what are the, you know, what are the providers and uh, can you have, uh, three home providers that I can use for failover? It's the same thing in the cloud.

It's just, uh, we don't talk about those pipes very much, but they're all there to do what you're talking about, Mike. So Mitchell, let's follow up on that for a second. Do developers need to rethink how they construct their applications because of those things?

Or is there gonna be some magic compiler that shields all that stuff from them? My, my bias would be to think that's an architecture decision. Don't, don't have the developers building their app, assuming something is in one location will always be there.

Um, there may be a set of performance requirements that have, they have to meet or are asking the infrastructure to meet the architecture to meet. Um, but that data could be in one place. It could be in five distributed places tomorrow.

'cause we acquired a company and now we've gotta figure out how to adapt that to our architecture. So I'm not saying we can completely abstract it away and developers will, you know, just do a, a magical GPT query and that'll get 'em the data from whatever it's in. I don't mean that kind of, you know, la la land scenario, but I think you need to architect it not with a lot of assumptions about where that data is, uh, unless there's some really, really tight performance guidelines.

Yeah, I mean, Mike, I carry a rubric crown in my head of each workload is on a scale of one to 10 on the following criteria, performance, availability, security, scalability, TCO and increasingly ESG environmental, if you can as an enterprise architect, think through those six criteria. Give a workload a score of one to 10, 10 being the most demanding, zero being kind of, I don't really care. Then you end up with a thought process of, okay, which infrastructure do I put this on?

Now, maybe you don't encumber the devs with that thought process in that rubric, but somebody needs to, in the organization needs to be thinking about it because if you want run it on serverless on AWS or Google or, or a or Microsoft, you're getting three nos availability. You get an outage, you're gonna get a 10% service credit on that month's bill. Well, if you want to run a mission critical banking application where after 45 minutes you get a call from the head of the, um, bank of England saying, are you still in business?

That's not really the right platform for that workload. So there's, there's a continuum of all those six criteria, and you should be thoughtful about where you're running your infrastructure and where you're running that application and that workload. Hey Guys, I, I gotta jump in here because we're gonna have no time to discuss anything else.

I think we, we've more than discussed this one. Let's take a break here on the gang. We're gonna be back and we're gonna ask how, how AI ready are organizations really?

You are watching Text on gang. All right guys, we're back and we're talking about how AI ready organizations really are. GitLab has a report out this week that says 78% of organizations, uh, wanna be AI ready in the next two years, but only, only maybe half of those 39% or so are actually using AI to write software applications today.

And then SNY had a similar report talking about, uh, there's a disconnect between the C-level folks who think the organization is more AI ready than the rank and file do. And as you kinda look at all this, and based on the previous, uh, conversation we just had today, I'm gonna start with Amanda, what is your sense of how AI ready are organizations out there as you kind of manage text drawing ai, you see a lot more of this. Yes.

So as you mentioned, business leaders, the C-suite, are very enthusiastic about implementing AI as quickly as possible, but they're kind of, they're so enthusiastic, they're skipping over important steps. They're not running proof of concepts like the article said, and they're not giving proper, um, training to the developers on how to use the AI technology. Um, so they're missing critical steps, which is leading to problems down the line.

Alan, are your C-level compatriots a little outta touch with the rank and file, or what do you think is going on here? I, I think like always c the c-level folks are, we're always looking for the next shiny trinket and what's going to radically give us an edge in the business. And, um, I I think if we, if we did a survey based and, and we divided it based on C level management and practitioner, et cetera, C levels would probably be the most optimistic about how much AI is going or any new technology for that matter.

But AI specifically, how much AI is going to change their business practices. I think originally a lot of CC level folks were, you know, rubbing their hands in glee, thinking about reduced people cost as a result of ai. They never call in sick, they're never disgruntled, they don't ask for a raise.

And if I can replace some humans with ai, wow, what a, what a beautiful world it would be. I, I don't think that's the reality of it. And I, I don't think we're gonna be in a position to be changing or to be cutting people back because their jobs are being taken over by AI anytime soon.

In fact, I think with AI we're gonna hire more people 'cause it's gonna enable us to do more things, but you're gonna need more people as well. So, you know, I, I think, as I said earlier, I don't know if the bloom is off the ruse quite yet, but I, I think we're finding out that there's a lot more to this AI thing than just, you know, installing, installing chat GPT or something like that. And then it's really interesting, you may read that as that point.

I look at it that we've unlocked a Q code, you know, to use a gaming analogy in certain spaces, if you are a developer and you are not using your code assistant right now, then what are you doing? You know, that is for me is being able to unlocked a QI code that gets you a 30 to 50% productivity gain. If you are in a call center and you are not using chat GPTT or an AI or an LLM model to curate and give better answers to that assistant on the phone, what are you doing?

So I think there's some really interesting use cases that for me, have moved beyond the line of these aren't just, should we pilot it? Should we evaluate it? That absolutely you should be doing this.

You know, I write a lot, I'm not writing on PA with a Quil pen anymore, and I'm not sort of sending my research notes in via carrier pigeon. You know, I'm using a tool like Grammarly, for instance, to check, and there's AI features for that. So I think there's a continuum of usage.

Most of us should be using those assist to type tools if a developer's not using ai. But I think the po other point you mentioned for me is I don't see that replacing developers. We've got a shortage of developers.

Those guys need all the help. They can get security professionals, you know, if they're looking and using AI to look across, um, security instance, we're not got a shortage of security professionals. Those guys were overwhelmed before.

So I don't see it as a, um, getting rid of jobs. I see it as unlocking the 30 to 50% cheat code to make the job faster. But you still need people in this loop.

You still gotta be, somebody's gotta be writing something for Grammarly to check your grammar. It would be the analogy, yes, you're gonna use those, you know, features in Grammarly to do the AI check and maybe to phrase a sentence better, that doesn't replace the original thought. It doesn't replace the person at the end of the call center doesn't replace the developer.

Yeah, and I agree with Alan for right now, we're gonna see more people hired in mm-hmm. To supervise and, um, make sure the AI tools are working properly. But down the road we might see the job shift to something else, but I don't think we're gonna just, um, see a decline in jobs.

They're just gonna be new jobs. And we've done this a hundred times before. We used to have more stable hands than we invented the car, and now we've got mechanics jobs get replaced and the economies pick up and move.

Now that's tough if you are the stable hand and you've got retrain to be the mechanic when the car was invented, but over, if you look at the economy as a whole, it's not gonna be a challenge. I, I think that's a great point. You know, think about, and I'm, I'm not the only one who on this panel who would remember it, but think about Yellow Page salesman, right?

If you worked back when you, there were the Yellow Pages, how often would they knock on your door and your business or call on you, you know, to get an ad in the Yellow Pages and the Yellow Pages was the way to reach people locally, right? That's, I was the first place people would go to, to, you know, before there was Google, um, where are all those yellow page sales right now? I think they're working in my sales department here, but, um, That, that was the original SEO, right?

It was four as IT services, right? So you could be the top of the list You want, well you had to, you had to have a name that started with aaa, right? Well, how Many, I mean, just look at it.

How many people does NVIDIA employ? Off the top of my head, I don't even know, but 70,000 people maybe. Yeah, that company probably didn't exist 40 years ago.

No, and I'm assuming NVIDIA's got a, I haven't looked at their website, but if I looked at their careers page, I'm assuming they're hiring a few people right now. I I just think that the expectations are a little unreasonable in this regard. Many years ago, I asked an IT person, I said, you know, what's the difference between your organization and Google?

And he said, well, you know, the difference is they have a lot of engineers and I have administrators and the folks that we have run in these enterprise IT organizations, you know, they're not well schooled in ai and yet their c-suite comes around and says, we gotta do all this stuff tomorrow. And I think, you know, they all nod their heads and go, yeah, that's gonna be awesome. But I think they, they're more aware of the gap between where they are and where they the organization needs to be than the c-suite is.

So are we, you know, asking too much of IT folks in the short term? Well, I think for me, this is a generational inflection point. If you look at where the internet was in 99, 2000, nobody knew how to set it up.

We were all learning, we all figured it out pretty quick. You look at mobile and mobile apps, 2006, 7 0 8, we didn't know how to do that. We figured it out pretty quick.

I see this as one of those 10 year, 15 year cycle type inflection points. But the thing is, we're learning faster. It probably took us, I don't know, five years to figure out the internet, three years to figure out, um, mobile.

It's gonna take us 18 months to figure out, uh, ai. I see it at that type of, it's one of those big 10, 15 year trends, and we're gonna figure it out quicker than we have the previous inflection. I, I think what's different about this one, Steven, is we're not the only one figuring out, I think ai, the AI is itself for figuring it out as their evolution, right?

Becomes it gains traction and speed, they get better. Yeah. And I, I think one of the things we're gonna have to learn to do is just what we think we gotta figure out.

The next iteration comes in and gives us even more, uh, possibilities and choices. So staying ahead of all that is, is gonna be a, a thing, right? I think, I think the thing is you've got to embrace this technology.

Oh, Absolutely. Well, you, you don't have to, you could just stick your head in the sand and, you know, wake, you know, If you wanna write on a typewriter and with a quill pen, you Should, God bless you. Absolutely.

But it's happening. I'm sorry, go ahead Amanda. Oh, well I just think we're gonna see more internal, um, education programs within companies, um, to get everybody up to speed with the AI technology.

And it's funny because I was watching a commercial this morning and I can't remember what eyeglass company it was, um, because I was more focused on the AI part of it. But, um, it's funny, they were embracing some of the, the learning curve issues with AI and trying to use AI to make their commercial. But it was kind of a, a joke or a scoop.

The AI messed it up and they were like, AI still has a long way to go, but you know, basically by our eyeglasses. And I just thought that was so funny. But I do think we're gonna see a lot more education and training for using the ai.

Mm-Hmm. I'm too busy working to be trained. Alright.

Hey, we're too busy here today, but we need to take you another break. We're gonna be back driving our Chevy to the levee on the day the shift left, died. com is the leading resource for news analysis and education on challenges facing the cybersecurity industry.

com covers all aspects of cybersecurity, including data security, DevSecOps, cloud security, application security, network security, security threats and more. com has the largest selection of security content featuring breaking news, blog posts, podcasts and more. com to learn more.

com. Home of security Bloggers network. com and our other sites and one of those articles is titled, uh, ship Left is Dead.

It's by a fellow named Jason Baum who works over at Sauce Labs and it basically pauses the idea that we may have attempted to ship too much of the load for our responsibilities over to the developers. There might not be as many full stack developers as people think. And the question is, is where does all this kind of backend workflow processes from security to testing to everything else actually belong?

Alan, let's start with you. I know you've been kind of following this space, but you know, is Shift left dead then or is it just kinda maybe uh, needs a little resuscitation and redirection? So first of all, I know Jason Baum, I worked with Jason Baum, you know, the next part is, you know, Jason Baum.

But that being said, I, you know, Jason was trying to make a point here and, and you know, you always get a look at where the points are coming from. Jason used to work with us at DevOps Institute, he's now over in uh, sauce Lab and they're a testing company and you know, testing companies have a specific viewpoint on Shift lab. So you gotta take it where it comes from with a grain of salt.

Um, shift left is far from dead. The problem with Shift left is, and, and I've had this discussion with my friends in the platform engineering world as well. Shift left cannot mean throw it onto the shoulders of the developer.

It it's not, that's not what shift left is. Shift left should mean and did mean we are looking at things or we're gonna do things further left in the development cycle, earlier in the development cycle. So things like security testing and, and making sure our code is of good quality and that other kinds of testing, you know, setting up the infrastructure or the platform if you will.

We wanna do that as far left as we can because A, it's more efficient when we do it further left. And b, once that stuff is set, you want your developers to be able to go as fast as they can. Now, unfortunately, what it became to some folks is let's throw this on the developer's test 'cause they're the ones sitting there at the left.

And so let's make the developer do testing, let's make the developer do security, let's make the developer set up the platform that should die, right? When you see surveys that developers are only spending somewhere between 11 and 23% of their time developing, you know, coding that's wrong. Developers want to code, we gotta let 'em code.

Um, but that doesn't mean we should go back to our old ways and not shift these tasks left into the timeline of your software pipelines. It just means who should be responsible. That means security people have to shift left, testers have to shift left.

And I think that's a better way of looking at it than trying to say shift left is debt. I'd a hundred percent agree that it goes back to the conversation we were having about infrastructure ops and the enterprise architect personas gotta be part of this. They've gotta be collaborating with the dev team and being able to say, for this application, we need you to be developing over here because we've done the analysis that that's gonna be the best place for this application to sit.

Those are infrastructure questions that devs shouldn't really have to worry about. So for me it's about dev and ops working together as if there was a term in the industry for that. And then layer in there the security team.

You know, maybe I'll try and coin, coin a new phrase here, but DevSecOps, maybe it's something, it's The first time I've heard that. I Know, I mean maybe it's new and revolutionary, but I mean I think these disciplines, as you say Alan, have gotta move left, Right? They don't only mean that developer's gotta be responsible For it.

Yeah, I mean the same thing as the platform engineering folks a few years ago to get attention, we're saying DevOps is dead now Shift left is dead. Who's dying next? Uh, it, it's just not the truth.

So I Wa I watched a video somewhere and um, shift left is definitely not dead, but it was interesting in saying that it's about, um, there are different methodologies and sometimes perhaps Waterfall is gonna be the best one. Um, so you have to analyze the project and um, the company, um, organization first. Well, you look at Netflix system, Netflix went microservices with their big streaming service and then took it back to monolithic because it was a dog as a, from a performance point of view, it goes back to your point Amanda, you need to be thoughtful about what this application is, where you want it to sit, how you need it to be secured, how you want it to be tuned for performance, availability, security, scalability.

The answer is no, I'll just throw it into a container, make it a microservice and put it on the public cloud. You've gotta be more thoughtful than that. And that Netflix story about them going, um, microservice and then going back to monolithic is just speaks to that.

Steve, are you hearing the term platform engineering among the cloud teams and 'cause some folks, um, argue that platform engineering is just the revenge of centralized IT and we embrace DevOps to revolt against that in the first place. And there's, there's a lot of tension in this conversation. Yeah, I think, I mean, I was at a cube.

I've been at the last four cube con. I've seen the rise of platform engineering there. I think it's just an acknowledgement that just throwing it up onto a serverless infrastructure on the public cloud is not gonna be the right thing for probably 95% of your applications.

It's got a place and absolutely, you know, the team, I, I've been briefed by the team at AWS as an example and they're doing a great job at serverless. Keith Townsend just recorded a podcast with that team. Great team.

It's the right thing to do for some of these workloads. I think platform engineering for me is just an acknowledgement that you do need to engineer a platform and you do need to be thoughtful about workload placement. To me it's the new ops, right?

For a long time, OPS has been phishing. We heard of no ops, new ops this, ops that, ops I think platform engineering and along with SRE except a lot of the ops guys, you know what we've run really over, we had a long first segment, I apologize, but I I think we've gotten the, the gist of the, uh, the day shift left, died. We got a, we got a, uh, a special, uh, section today on Textron gang.

I wanna mention my good friend Ira Waker. And if you've never heard or met Ira, you really are missing out. IRA's a, a personality in the security space space like no other.

He's a force of nature. Ira has a long history coming outta the NSA and he was responsible for one of the most famous hacks in the world or discovering one of the most famous hacks in the world from time to time. IRA's gonna do sort of much like we have robot, what Bob Reman do here on the gang, uh, a solo sort of, uh, Andy Rooney kind of event and Ira calls it Bite Me.

In this episode, IRA talks about kind of some of the, uh, hypocrisy around people getting into cybersecurity jobs and what their re the requirements are. And it's a kind of catch 22. You can't get a job without an ex, without experience.

You can't get experience without a job. What is someone to do? Here's our good friend Ira Winkler and we're gonna end Textron Gang on that.

Stay tuned for the rest of Textron TV today as well. Hi there, this is Ira Winkler on the first edition of Bite Me. Now, the name we came up with, yes, it's a good name and I hate to say it, but we used AI to come up with this name.

So anyway, that aside, I have about five minutes in my first segment to go ahead and for lack of a better term, rant about something. There's so many things to rant about, but I think the first thing I want to rant about is the fact that frankly, cybersecurity is not an entry level position. No matter what all these people are trying to sell you, no matter what degrees, no matter what bootcamps and things like that at the moment, especially, there are few, if any quote unquote entry level positions, and I use Dr.

Evil quotes on that. 'cause frankly, the biggest problem we see is that everybody's like, oh, we need to bring new people into the market. We need to go ahead and have this, and you need to have experience before they'll give you a job.

Well, frankly, yes, you do need experience. You're not gonna go ahead and save the world without experience. People somehow assume that entry level means zero qualifications.

That's not the case. I say, you know, on an extreme analogy, to be a doctor, you need 12 years of, you know, grade school, another four years of college, another eight years of residency, med school and all that sort of stuff. And then you can become an entry level doctor.

The reality though is in cybersecurity, most of the roles we need in cybersecurity are people who already have skills. So for example, yes there are a few entry level positions, for example, like SOC analysts, you know, where you can take somebody, but even them, you know, I tend to hire people who were not analysts first who have the background ability to work a 24 7 rotating shift and be able to go ahead, go in, understand those cases and understand basic networking principles. The more people know before they start a SOC position, which is one of the traditional entry level positions, the better they are.

That's number one. Number two though is people say, well gee, you know, I want to get outta college and go right in. Everybody I know that has been in the profession for any period of time has started with a different IT position.

Entry level positions in cybersecurity people seem to forget, include programming, include system administration, include installations, include networking, include a variety of other entry level IT positions that they then can go out and develop background experience for this whole myth that you can just go ahead and graduate or the certification theory comes around and goes, Bing, you're now certified and therefore you can have an entry level position is a bunch of garbage. What people need to understand is cybersecurity is a subdiscipline of information systems, of computer systems and everything else. And without having a fundamental understanding of the underlying disciplines, you're not gonna be good at cybersecurity.

You need to have the understanding of the business background. Having years in programming a few years, having years of administration, working with people on a help desk or something like that, gives you experience in understanding what you're securing. Because frankly, the last thing you want to do as a cybersecurity professional is ruin the reputation of the cybersecurity profession by going ahead and telling the system admin who's been doing their job for a decade possibly, that you're gonna then walk over and tell them how to do their job.

As an entry-level person, that just doesn't happen. Where's the pipeline gonna come from? That's another thing I hear about this whole lack of entry level positions.

Frankly, the pipeline is gonna be from places like network administration, like system administration, like programming, like designing systems and maintaining systems. And the problem is, in cybersecurity we think we're this little snowflake. Nobody goes ahead and all of a sudden starts out entry level in just about any other profession that is completely isolated from the rest of the underlying disciplines.

And we need to understand that, again, get it out of your head that cybersecurity can be an entry level position and start to understand that to be in cybersecurity, you need to have a broad, fundamental understanding of the disciplines that you can get by going in other places that frankly have many more job openings right now. 'cause I know of people with decades of experience who are out of a job. So anyway, that's bite me and I will go ahead and say thanks until the next time.

com is the number one online destination for DevOps education and community building. com covers all aspects of DevOps, including DevOps, best practices and tools, DevOps culture, DevSecOps, business impact, continuous testing, continuous delivery and more. com has the largest collection of original DevOps content featuring breaking news, blog posts, podcasts, and more.

com to learn more. com where the world meets DevOps.