Cloud-Native Requires DevOps—Or Does It? – DevOps Unbound Roundtable

Hey everyone, welcome to another live Roundtable edition of devops Unbound. Devops sunbound is a video series that we record a few times a month or every other week or so and we explore interesting topics devops from the mainstream Medi stuff to the nooks and grannies if it's about devops. We take a look at it here on devops Unbound.

Give up some bound is sponsored by our good friends at tricentes worldwide leaders leaders in automated testing and many thanks to chinatus for their sponsorship here. About once a month or so we do a live version. Of devops about much like this right now and we it's really a lot of fun.

And the reason it is is because we have a live audience to participate here. You are the stars of of this live Roundtable. Now, how do you interact?

How do you participate? Well for most of you if you in your browser and you look at the right hand side of your browser, you'll see the communications panel built into our big marker interface. And the first thing up there on the left.

It says chat. Oh and that's by default. I think that's on and if you go underneath chat, you have different flavors on it.

That's public chat, which means when you type it's coming from any, you know, and everyone can see it there's presenters, which you probably Not going to say and then private chat for one-on-one chat and Twitter. We have disabled so we don't pollute the Twitter sphere. If everyone would like to maybe log in to chat and just say hello from where you are.

I know I always get a kick out of seeing the full range. Of of where people are coming to from us today and including our panel members who are pretty spread out around the world speaking of our panel members. We have an amazing panel.

That I want to introduce you to today. But before we do I warranted it quickly talk about what we're going to talk about today. so the title of today's presentation of today's show is cloud native requires devops.

Or does it? And you know, this is a this was a question that came up in a live event. I was doing this morning as well.

You know, how is is cloud native grafted onto that devops tree can it exist without devops and you know, one of the questions I want to explore with it too. Is this Cloud native necessarily even need cloud. Um, we're going to explore all this some more with this fantastic panel.

Let me introduce you to them right now. First up. I want to introduce you to and I hope I pronounce it right Chad Bodine Chad.

Is that right? Close Chad Bowden Chad Bowden. All right.

I made it a little fancier, but Chad. Why did you introduce yourself? Sure, Chad Bowden chief engineer of devops at Boeing focused on making the life of developers better at Boeing.

Absolutely good work you do there as well Chad. Thanks for joining us next up. I want to introduce she's been on our show before April Edwards April.

Hi welcome, please introduce yourself. Thank you for having me back. So I am April Edwards.

I'm a senior Cloud developer Advocate and devops practice lead at Microsoft. I'm based in the UK, but I work across the world globally developing devops practices helping with devops content on a lot of our products. I as an Azure devops and just delivery to the cloud also using things like GitHub and pipelines and all that other good stuff.

Love it. Next up. He's also been with us on a few shows before Dr.

Parag Doshi parag. Welcome and maybe introduce yourself. Hello, everyone.

I am Prague. I am from tricentis building software testing tools. So my background has been both as a cloud provider spent 20 years at Gila Packard Cloud consumer working with Healthcare companies to consume Cloud even on premises as Alan said doesn't have to be in public cloud.

And now I'm building products where I think we can help with our digital transformation here at tricentis. I love to build engineering teams and make them successful make our customers successful. Love it.

Welcome Brock and then last but certainly not least joining us. Today is Michelle Ruiz? And shall welcome and thank you and tell us a little bit about your background.

Thank you for having me. Well, I'm actual race at the developer Advocate at jfrog but I my background is Chapa developers. So 20 years as a consultant solving problems.

And today I'm all about their books. How do we help developers to Embrace this new adventure actually welcome and thank you. so You know, let's start with a preliminary, right?

Do you need before we discuss devops and Cloud native? Let's just Define Cloud native. Do we need do we need Cloud for cloud native?

Do we need maybe we need private Cloud not public Cloud, you know we hear about kubernetes on bare metal. Um, is there do you have to have cloud and Cloud native? What do you think?

It actually I can't do that. I hold that thought for one second. We left out a very important person on my panel.

I always do it too. He's my co-hosted longtime friend. Mitch Ashley.

Hey Mitch a good be here. No just saying we have such great panel. I'm gonna be on chat most of the time so nice to be here with everybody.

So join in please join us on chat. Love to hear your thoughts there, too. Absolutely Mitchell's also CTO here at techstar group as well as principal analysts that take strong research.

And thanks for and always here with us. So thanks Mitchell. Um, all right, so back to the question.

cloud as a necessary component of cloud native. thoughts on that I'll be the first one to put my foot in it working for company. Um, we there is the cncf definition of cloud native.

So microservices containerized applications being able to run privately publicly Etc across clouds. I think as a cloud service provider, we we talk about it as leveraging platform as a service when and where possible. So breaking that down into microservices not maintaining a whole infrastructure on the backend and physical hardware and making that portable and I think for for customers that are Cloud native they have a microservice approach.

They've broken everything down and they can deploy to that pretty readily versus a monolithic app. So I think it comes a lot down to the design and the platform it's sitting on and that's a lot how we see it at Microsoft but from a personal point of view. Absolutely.

I talked to customers about breaking down monolithic apps all the time because there's so many things you can't do with it because you break the whole system. So that's that's my two cents. I'll let someone else chime in.

I'll chime in there next I I agree with April, you know the platforms. I see actually as an enabler platform as a service To Me Cloud is you know, some people think of it as a destination I go to public cloud or I build my own private cloud or I've got a hybrid associated with it, but I always go back to the nist definitions and the 12 Factor principles, which were always right? Okay, distributed computing distributed applications.

We try to achieve them we can never get all of them. Usually, especially when you have a lot of Legacy apps, but if we are able to make applications run across a distributed set of infrastructure, efficiently, we then get access to ubiquity ubiquitous Innovation ubiquitous connection. a huge amount of automation because the vendors that providers of cloud services whether it's a platform or full-blown SAS service are forced to Bundle in that Automation and then when you put that on premises you have the same principles.

So it's not a destination. It's the ability to have automation to have wrapped up innovation in such an easily consumed self-service manner back to the again the National Institute of Standards definition back in 2011. So Cloud can be anywhere if done right?

a great it's oh sorry, no good stuff. Well, it was really quickly for me. It's actually what they have already said it is about the size what we are shipping.

What how are we leverage either as a service of platform, but it is Distributing. Our offerings are worth services at the size. We can have a long discussion about what is the right size of a microservice?

And what is how how many how many ledgers are we going to take advantage of before saying Cloud native? so Yes. Yes, we can have Cloud native or without a cloud.

Because it all depends. I I agree. Agreed Chad.

You want to say something? Yeah, just I mean it it's already been it's already been said, I think the architecture is the big Focus right? Have you architectured your services availability and reliability all the abilities no matter where you're going to put it.

That's the key. a great You know, I before we move on I just want to remind because people come on late guys Beyond telling us where you're from in the chat. We'd love to hear your thoughts.

Whether it's a question a comment an add-on. Please feel free to use the chat or the Q&A section. To you know, raise your your point to the panel and we'll bring it up.

To the panel. So, you know, it's funny we're talking about pads. I've seen the cloud.

I I think you know, I've seen the cloud since we first started talking about cloud. And you know, the first iteration was infrastructure as a service and we talked about well one day that's going to give way to pass. Platform as a service and platform is a service will become dominant.

and You know I is that where we are now, right. And is that really what cloudnative is about more paths than than IA. Then infrastructure is a service.

I didn't think so, but from what I'm hearing. Some folks might be feeling that way April. What do you think?

I think I'm gonna think back to architecture because I like pictures. So I'm like literally drawing a picture in my head when I have worked with applications that are monolithic and problem. That if a lot of factors that go into them, they're always monolithic apps sitting on Virtual machines.

And sometimes something as simple as breaking that up into microservices helps break apart that that application and let you do or even just adds functions even like literally in Azure function that lets you. Tell your VM to do something and automates a task using Powershell that is even a micro service that your VM is not managing and that's using platform as a service. We we see so much of it because where Infrastructure of a service is stagnant is that the inability to scale unless you're using a VM scale set and and most people on Prem don't have that capability.

So I think There's a lot of limitations to infrastructure as a service which is why we don't tend to put it around Cloud native in terms of performance and capacity and capability from the architectural perspective. So as soon as you start hooking in microservices, you you start a consuming pass and there's just a lot of physical limitations around infrastructure service. So we tell yeah we tend to move away from it.

When and where possible we see it as a lift and shift. We absolutely don't see this Cloud native because they're also they're not always portable either. A great yeah, everybody in agreement with that disagreement comments and I'd say, you know looking at platforms as equal to Cloud native isn't necessarily what it is here.

Really? I see the platforms as a way of having a consistent accelerator. For achieving the architectural principles.

Like I said earlier, we're always right things like the 12 Factor keep the environment out of the code keep your multi-tenancy out of the code, you know separate things properly because what we want if you are lucky enough to build a service that runs anywhere on premises or in a cloud or in a private cloud. That has a lot of demand. It's got a scale like crazy.

So that's a good problem to have if you try to do it without resting on the shoulders of enablers like a platform as a service. It's just much harder. We can run a monolith.

On a cloud-native platform. In fact when you do a lift and shift not that it's always recommended but it's really hard for an application or a SAS service. Maybe that's been around for a decade or two decades even before Cloud was a term to actually break that down into microservices.

So I would even ask is microservice required or a fundamental requirement of what is called Cloud native. You know why that's a great point because I used to think cloud native was. Defined by using things like kubernetes and can Docker and containers and stuff like that.

But I I I've come to the other side of it now where I don't think it's necessarily that infrastructure kind of stuff. But how is is it microservices based? I think.

At some level. Here's how I see the progression of this a Mitchell captured it in the chat as well. If it has microservices if it's a microservices based application architecture.

By definition it it almost has to be cloud-native and if it is microservices based architecture and you didn't use devops as part of that development process. I don't know if you were successful because I don't know how you do without using a kind of devops mindset framework. In in that kind of thing now.

Look I'm not the developer. The shell is or April or even perago or Chad here. You guys are devops experts.

I'm just talking head, but what do you think? I'll be right. I'll be a little content to to Mitch here, right it is it a must I'd argue.

No, it's not a must but is it something you want to do? Absolutely, and should you do it absolutely are they required kind of jump into the heart of what the what the what the panel was about right? Do you have to have the two together?

No, but I think they go better together and they they complement each other a lot and you're gonna really struggle moving to Cloud native without devops and The converse of that of the vice versa that right Cloud native really helps what you're doing with your devops right bringing in that stability and high availability for your applications. And and one of the other things that I wanted to toss in there with the lift and shift I think often we get we get caught up when I think about a group or a company that's to taking this transition to devops and Cloud native and they see what everybody else is doing and you're like that's what I want to do. And and sometimes I get caught up in the perfect being the enemy of good enough because it's a spectrum right?

Sometimes people have to lift and shift when they when they go to the cloud and that's not advisable as Prague clearly pointed out but sometimes you have to do it and and it's this it's this Continuum or spectrum of where you are and where your team is in any of those efforts and you want to get to where where the big boys are doing it right and you kind of use that as your your goal post. But it takes time to get there. Right and it's a real struggle and it's it's very challenging to do and you're never done right?

Because you especially when you're doing a little piecemeal at a time when you do a lift and shift on there it sometimes takes a lot longer to get to that end state. But yeah, I'll get us I want to add to what Chad said don't you know, like don't. We if every cloud transformation.

I've held our customers with if you look at it that okay. That's a destination I go to and because the Jones is next door have the Ferrari and I need to do the same thing those fail. Okay.

Why do we want Cloud? Why do we transform you have to go back to the business objectives? If you don't have a true business objective then then what was your whole point?

So when we say is devops required for cloud native? Well, let's take a step back and say why do you want Cloud native this thing that was built for cloud or runs well in Cloud, well, there's some purpose at the large healthcare provider as that. They wanted to build a Whole Health Care company in Cloud day one why access to Innovation and automation Okay.

So now I've never seen people do a cloud migration a digital transformation a big data driving into artificial intelligence and Predictive Analytics. I've never seen all that successful without having Automation and without having access to Innovation and trying to solve yourself as one small company or even large company doing it all by yourself. So I think if you go back to what was your business objective the impending reason to change your it environment, then you'll come back and say hey wait, I really wanted it not to limit me.

I wanted to go to an environment where I have access to Innovation. I want an environment that I can move at the speed of my imagination. Okay, and to do that safely so that as I confidently go on this journey, I am releasing in a pattern that gets me to.

that business objective I agree. Sorry go ahead Excel. I have a slightly different opinion there for for example, one of the reasons what we went into microservices in this thing like that is to reduce as developers.

It was to reduce or focus on different business uses and some of the services that we provided who had the different kind of Youth usage. So for example, read could be more frequent that right for for some obligations. So there was a clear need of separating this kind of services into that.

Now what the idea of microservices came in also with with languages it was like, well you have several languages that are like fantastic for this kind of operations, but you have other for example programming languages or other tools that will solve this problem easily. So now even you have a very more compelling reason why to start separating the different yeah business This business usages into the different services and but that also brought some kind of problem different life cycles different versioning rolling out. So all that information started to create a lot of conflict and also by releasing quickly and releasing securely because you can do a release without following any devops.

I don't know methodologies, but it will be painful and what we want is to be certain. Safe our releases to be reproducible to be easy to be consistent and with a lot of things security what not. So that that is much much easier.

What you are adopting all this kind of methodologies. So for me, it was a matter of providing what was needed in the best kind of. Platform or even function as a service in in my world in Java World.

There are some functionality that can be broken into the bare bear minimum and it would this you can have like tons of instances running only providing that particular functionality. So it was we do think the deploying and well releasing and deploying in a in a automatic matter reproducible and painless. As possible and obviously leveraging the interest of developers and the entire organization into the business logic nothing to the infrastructure.

Because that is like that's a machine job. Why put people to do a machine job if you have machines to do that? commodity April you're gonna say something I was gonna jump off what products that but I'm gonna shift gears.

Let me talk about what Excel said a microservices when we when we talk to customers about compelling reasons to go to the cloud and we talk about configuration mistakes failures and breaches 90% of outages in the cloud or due to human error every time 96% because we're human we make mistake and Excel you said it you're like well if we have a machine to do it, why do we have a human doing it? And and that's exactly it and the other the other, you know, when we talk to customers they have single points of failure all over the place teams are inefficient and we want to increase their efficiency make it repeatable and scalable. And and when we talk about the human error element, it's a big compelling reason of what they want to achieve because they've probably experienced those pain points and it's stopping them from doing something that organization that hurts them a lot and that's usually where when I was on the engineering side at Microsoft and we engage with customers.

We were always presented with this is our human problem that we have. How do we then make it something automated without using the d word of devops? How do we then automate it?

How do we make it scalable? How do we get rid of our human problem and every single time that's what we did. We there were still humans involved, but we got rid of human element of single points of failure and the limitations by automating pretty much everything beginning to end that we could and nothing that go ahead.

I wanted to I guess jump on to that a little bit Michelle brought up a good point and not that I want to steal Mitchell Allen's job of asking questions of the panel. But what what are your guys' thoughts on the panel for you know compliance and security how how Cloud native and devops helps that right? It's hard to get away no matter where you are.

As in what company you're doing and problem set you're solving right compliances almost always an issue and certainly security is specially recently with all the stuff. We've been seeing there. So kind of curious what people's thoughts are there.

I'll take that question because I think it is something we're seeing and I get a question a lot. I've been asked. Hey, let's let's run this stuff on premises or I'm a regulated company and I can't just move to say a cloud environment and introduce all this automation.

But then we go back to what April said. It's it's, you know, a lot of times I see our cios say how much productivity can I get with automation? Right, but that's not where it's at to me.

It's preventing the human mistakes. Okay, having a consistent manner to operate and automate your environment prevents those mistakes. So the cloud or any form of great automation package nicely to consume it easily and nicely as a self-service pay for use is very convenient actually to achieve higher degrees of compliance higher degrees of security better resilience better operations better availability in you know hundreds of data centers around the world.

That you don't have to bring to the table. You don't have to be a data center expert you don't have to know how to build infrastructure services and know how to virtualize storage across all the different types of storage and stripe discs and all that fun commodity stuff you focus more on the business application and you focus more on automating your operations. So you can go two ways at this you could think of cloud as this Big Easy Button.

That the security folks will fire you for or the operations folks will not let you get to right or you can look at it as an enabler. To access that Innovation and automation environment built on on the shoulders of many other people as a set of reusable services and actually be more secure be more resilient have better business continuity. But but you have to configure it that way it doesn't come without any investment.

I agree with your para. I mean one of the critiques or I for both sides from developers saying oh my goodness. We are not Security Experts.

Now everybody's telling me that I have to become a security expert because it's going to be part of my entire life cycle to support development life cycle and the developers are running. Scared on one side on the other side. They tell me Well, actually though.

I was over developmental cycle. That weakest link is a developer. I'm like, okay, let's let's stop a little bit here.

So developers have one concern and is usually transforming the business logic into Things that actually execute that business logic we are not Security Experts. We are actually spent a lot of time trying to be experts in our domains in our languages in our tools. So on top of that add security as an expert, it's really way too much.

So that's why we rely on the Security Experts and the people that are running the infrastructure. So if you ask me as a developer, do you prefer it to have it in Hell on Prem or you prefer to have it outside? My answer will be like the guys that are outside the people that are outside probably because we are one of thousands have more experience like you go with the Hard battle especially people that are doing that all day long and they have the infrastructure they know how and they already have faced this problems repeatedly alongside the different Industries with similar business.

Well similar use cases probably not business logics. so Security. Yes, of course even developers we will.

Follow the entire process in our devops in our devops workflow. We will have tight Loops to recheck it. Are we Security Experts?

No, we're not. We rely on our security or Security Experts that create policies and configure the tools that we are going to execute as part of our workflow. I've got to say something on what the hell just said.

Developers are not Security Experts, but the cve's were already in your code. So when you're running on a cloud native environment and let's say you're going to do containerization or or you know, serverless you have usually have to rewrite functions as a service. I'm speaking of specifically.

But if you're going to containerize something. The original source code or the libraries that were in that source code that you have dependencies to already had the cdes what these Cloud native platforms have done is they put a better magnifying lens to scan them now, we're in scanning hell okay, to be honest. There's a bunch of false positives and overlapping things there.

But but as a developer, I think we're empowered because the CVS we're already there and now we just know about them. So it's the observation that actually provides better intelligence here and we'll make a more secure product that actually gets delivered to customers. And I might go ahead Excel.

Sorry CVS is just one approval. We have problems with configurations we have with publishing sometimes. Keys or databases and passwords so best practices.

So yes, I totally agree with you like security and CVS are already part of the source code. We sometimes generate them by uploading things that we shouldn't or not configuring correctly the tools that we're using. I mean even one library that it's very very secure.

We may not be using it securely enough because of configuration parts. So but there there is tools that we can adapt into into our software development cycle and you all know that I work for you so I can give a long list here. And I'm gonna be a little bit of a devil's advocate Excel you you spoke about having security teams.

There's there's a couple fall like pitfalls that people get into one is yes, you have security team, but they have to be involved from day one from day one. And also a lot of times our security teams are our blockers because they don't understand what developers do and they just they block them, but we need to enable our developers to do more and and the security starts when our developers are cloning their code without question, so What the reason why I talk about Security in every single one of my talks or customer presentations is because it's responsibility of every person to be conscious of it, but not necessarily be Security Experts. So we there are so many amazing tools out there that we encourage our customers to utilize in the cloud when they go Cloud native and I'm gonna just talk about one specifically.

So you talked about pushing codes secrets up secrets and keys. Absolutely. We look at the recent breach by our little friends at Uber who always provide me with security breach stories.

I literally can rely on Uber to tell it to tell a security breach story and Someone put a password into Powershell file. That's not the follow the provider. It's the fault of the developer.

And I think the problem is once we commit that code we've committed that code that history is there that can be found out whereas if we look at things that can prevent the pushing of code. So what we're seeing in the industry is a lot of tools getting closer to the developer experience in their IDE. So I'm going to talk about GitHub push protection because I'm a big fan of it.

It stops that key from getting into your repository. So using those Cloud native tools are critical to helping that because you're right as a developer. I'm going I'm in a rush.

I'm under time pressure or we just make a mistake because we're humans helping get close to the developer experiences crucial because we can't always rely on peer reviews to catch everything and it's a leveraging. These tools is huge. It helps helps our team.

Yes present. I totally agree with you. I mean, there are so so many problems.

For example, we have Integrations with the ideas because for example Dependable or our frog board, which actually does Morris of more stuff it's too late already. It's part of the pr. It's already you already push the code the developer already used some some time to create a feature and it's ready to so it's too late.

For example, we also are moving closer to the ID. So when the developer is typing code, we're trying to provide as much feedback as possible the problem when I'm saying here, we're not security expert it's because we're using for example and right now I scan one particular pet clinic from from some of other provider microservice provider and you will see that they have like thousands of security advisories probably 10 critical so but that's that's my point when we say when I say, we're no security expert because as a developer, I have that feedback at the fingertips. Oh like in front of me, but how do I prioritize because if everything is a priority nothing is a priority and my bud It is not mine.

I mean it has to come from our team leader from our product owner. He has to say, you know what this are really important to you. This is our critical but not exploitable.

This are even if our medium critical but they are we are in serious risk because of our particularly way of deploying the application. So this is when I say that we require I cannot as a developer. Honestly.

I cannot take that decision by myself. Not in the in the terms of the technical background that I possess to assess the threat nor on the management part to actually invest our time our developer time into fixing something. So I need I need policies seamless integration between the the tools and also some kind of trusted knowledge about those said risks.

You know, I was out in Las Vegas last week at the Quality QSC conference. And this topic right here was was top of mind. You know the the good Folks at minor in this came up with the cve.

A guidelines Mitchell you and I were doing them. It's still secure. What is it?

Maybe 15 years ago. 16 years ago something like that 2004 2005 seems like 10 minutes ago. But yeah.

And you know and critical criticality of vulnerabilities. It was a good it was a good idea and a good start compared to what we had before but it didn't take into account a lot of context. and context matters Right.

And so to run your your your shift left security vulnerability program based purely on cve's is not I would say it's now practice right? It's negligent. and and you know we need To understand I think I'll show you hit some of these things.

What's the availability the exploitability? What is the the cost? To fixing that cve or that vulnerability, right?

And this gets into manage risk. We raise her in the audience put out something in there and risk at the end of the day. We can't lose sight that we don't do security for security sake.

Security is supposed to be about managing risk. Right and we for the life of the developer, we need to kind of simplify that security right. We we need the developer is probably not the person to decide.

What's the risk of leaving this vulnerability in there? We could try to automate that risk measurement. With with applications right with technology.

Process but you need people in those people aren't developers Chad. I know, you know you guys have thoughts on this at Boeing. What do you think?

Yeah, I I what he shall said really resonates with me and I I also agree with with April's throwing in about the tools there because you're right the the developers saying we're not Security Experts is very common and then you go and get a security expert and then you get into the Trap of developers going. Well, that's not my problem. That's their problem.

They they need to fix the security stuff and they're slowing me down. They're slowing down. They're slowing me down.

Yeah, they're The Gatekeepers as was brought up, right and so and there's never enough and and usually they're not software developers. And so they don't understand the domain or the technicalities of what you're what you're implementing what your developers are implementing. So I think what I've seen I'm like the tools really help make developers more Security Experts, right?

They they illuminate issues and codes and and sometimes you know, um and fixes for that and that helps educate developers on becoming more security conscious as they move. Forward so they don't Implement that stuff as Mitch was talking about, you know, the shift left mentality. And so I I think it's it's both it's you know developers realizing they do have a responsibility for security and compliance for what they're developing.

But you also have to have those tools in there that are finding stuff because as April point out, right it is a people problem almost all the time. And so you got to have those tools identifying where you made a mistake or where you took shortcuts and and helping you fix those and adjudicate those and then yes the overall risk of does every cve need to be fixed. No, you'll spend all of your day.

And and usually the first time you get a cve tool and you throw it in to your ci/cd pipeline, you can sometimes get security people weaponizing security and say no we're gonna fix everything We're not gonna have any CVS, right which is a pipe dream and you go you go you go up and down, right? It looks like a sign away on there of what you're gonna do and they you kind of normalize on Evaluating things and and this is where developers do have to have some sort of security awareness so that they can can use the context of okay. I'm in this environment.

I have these Protections in place already. Maybe I'm on a network that's not even connected to the Internet. So I need to take that into account when I'm adjudicating some of these CVS.

You know, I'd like to comment on what's happening in the chat. There's an explosion of ideas around risk management and and are as a panel. We picked one aspect.

I think Reza said it security right but what we're trying to do here and I'm gonna bring it back to the main topic Alan if you don't mind here of today, you know, go ahead. Yeah is um, we're all trying to do trade-off. We're trying to evaluate business trade-offs as a developer.

You understand that my code has to be functionally tested has to function and deliver the business use cases to features have pretty colors on the screen work with people with disabilities as well as have a great backend at Scales to the moon or Mars or further, right? So as developers, we understand these aspects but then they're security there's resilience, you know, we want our system to be constantly running and at huge amounts of scale. So then we're gonna say we now need quality engineering as well.

What we're doing as an industry is we're shifting all these things left. I know that's a buzzword. But today's topic is is devops and Cloud native do they go together is one of prerec of the other are they the same cousins or whatever right?

So if we're thinking about shifting left that is really what we're thinking in our CI, maybe CT CD continuous testing continuous miring continuous. Improvement continuous learning continuous everything process we're talking about shifting things left, right? So how would you move into an environment which we call Cloud native?

Without having that shifted into your pipelines. So I think it is actually we don't want to say it's a prerequisite meaning. Hey, don't stop your Cloud native program because you you're not mature enough and devops you need to do this simultaneously.

They simbate symbiotically help each other. Why because we're all trying to make the business trade offs is my code ready for release. I think it shall mention that for us to make that assessment.

It's a risk management assessment that needs to be automated in our code. I need to scan whether I can maintain the code. How many duplicates are there.

I need to scan for CVS. I need to know how my keys are managed today customers are not they're getting more savvy than some of the providers. They're saying I don't want bring your own key.

I want customer and provided key. I don't even want the provider the cloud provider or the SAS provider to have that key. They're getting more and more sophisticated.

There's man in the middle attacks. There's supply chain attacks. Look at what happened with solar wind.

right We have to be Savvy enough. And automate that into our Pipelines. Or our customers will force us to do that.

So as the provider of SAS guys, I got a jump in here because I see what's going on in chat and I gotta look. com but I've got 20 plus years in security. And for those people who are saying compliance is part of risk.

I say nonsense we have wasted way too much time in security trying to be compliance cops. And what we forgot was that compliance is no more than a byproduct of good security and good risk management. You do your security right?

You do your risk management, right? You don't got to worry about compliance. So for those who are saying deaf-secops and Dev compliance Ops nonsense nonsense, I don't care whether it's the Lord or anyone else.

Compliance comes from doing good security. I'm from having good policies and trying to be consistent managing risk. It's not right.

It's not part of that risk. Now you want to say there are things other than security and risk there is Right have we picked the right platform? Is it scalable?

Right. What am I risk to using Azure versus AWS. So Google for a particular thing.

That's part of risk management. But I I don't think compliance is in there. Chad I I hope you sounded like your partially agreed, but that No, I I was laughing.

I was gonna say like love seeing the passion and certainly spoken like a like a man who's been in the trenches for this for a while and and learn some hard lessons. So yeah, I I agree. Yeah defect Ops, you know devops.

I'm just kind of keep it at devops just because everything gets wrapped around there and it's still it's all about devops. It's all about your architecture and your ci/cd right whether or not it's devops today or something else tomorrow. It's about that the tight feedback loops security minded when you're doing things doing what's right and doing what makes what makes sense given the context of the situation.

The one correction I'd make is is compliance in there what is compliance compliance with what with security with resilience with performance with delighting customers with ADA compliance with this and that and the other right? I think compliance is baked in. This is what we're doing.

We're slowly left shifting. We left shifted testing. We don't call it Dev test Ops why because untested code is is crap.

Let's face. Okay, what's the value of untested code? So we just called it devops.

Okay continuous testing it. We don't need a c i c t c d because what uses it without testing, right? So but it's not just testing in every way you can think of it is a security.

It's the resilience it is all these little factors that make up compliance and I think of compliance as an oversight to make sure you don't move so fast trying to win the Indy 500 without any breaks. I think you know, I'm sorry go down. No.

No, you just taking your job away from you, you know, we talk about compliance all the time. And that's usually the initial decision makers discussion. You know, what are we trying to achieve?

And then Industries Financial, I do a lot of work in the financial industry Services FIS and that's entertaining because they have compliance requirements that aren't compliance requirements. They have some Legacy rule that someone's kind of made up and they're like, but we must do this because it's been around for 30 years. I'm like, but that doesn't work this way anymore and it's not a black and white written rule.

It's some interpretation. So ideal that a lot. That's that's a hoot and I really want someone to write the white paper to like all the banks and say you're compliance is wrong.

These things are not actual compliance requirements. Someone has just interpreted that way and then you all have felt that you need to believe it that way. So that's fun.

But I was gonna shift gears because we do have a question from the audience which is amazing. Zach has acknowledged it. Yes security is huge.

How do you control devops containers security IE preventing elevation and Privileges and and with from within the application as well, so Is access a pretty good question that I think we should throw down who wants to answer that Chad looks like he wants to answer that one. Putting him on he got me right when I was taking a drink. I know that's exactly like you.

Yeah, I think it goes back to what I was talking about earlier right with the the education of developers right tools tools help a lot in this regards, right? You can get tools that will scan for some of those issues within your container and what base container you're using and and and and what capabilities are there. So tools certainly help there and that education of your developers right making sure you're using a secure-based container that doesn't allow elevation of those privileges and and hopefully again going back to the tools to help discover those and mitigate those and fail builds if you're if you're using those so you can't deploy those into production it so you look like you want to say something.

No, no, I agree with you. First of all is having like for example in that record. It's I can give some tips like having your registry of a scan and approve already images because we again we're trying to reduce and help our developers to make the right choices at the beginning.

So making the right choice of the beginning. We already know a little bit about what they need so we can provide already secure from secure sources images for their to start like developing or even some other images with more more the third configurations for different stages or staging environments. So yes, I agree with you chat.

We are creating more and we are integrating more and more of this kind of tools to exactly reduce the options for the developers we already okay, but but not like Like tighten them like being in the way. No, there has to be a process that is fast and in a way intelligent, like if you require this particular image and we already pre-approve it. There you go.

If you have this requiring this dependency and we don't have it. Let's see if it's compliance with what matters to our organization if it matters with our organization and it's there go ahead use it if it not with trigger something either we're going to analyze it or we provide you with an alternative doesn't work that alternative. Let's come back to this process.

So we already doing that because we're not this that problem and again Let's do let's leave the machines to the machine work like this kind of decisions. It shouldn't for part of the process. It shouldn't be involved human until you have this this very quarter cases where it's not well defined and we shouldn't even be on the way.

of the developer You know, there's two aspects to me of containers security. one One is you know involves the developer and one doesn't. Right.

I think when we look at container security first, you have to look at you know, what's the payload of that container does the code contained within that container have vulnerabilities is equality code we could spin there are plenty of tools out there. That'll scan that code and tell you and that's the kind of thing that a developer should be looking at even before deployment so forth, but then there's a second aspect and that's what April I think is talking about and that is this the configuration of these containers, right? What?

What can they do? What can you do with them? How can you do it, you know and and there again, we have some good tools that have been developed around that right and I think it does lend itself to a good devops methodology, but certainly We're still learning.

I think what or the let's put it this way. There's not best practices yet. There's emerging practices.

Well, I think that's why we're in Tech because we're constantly learning. I always tell people if I wanted a boring job ago being accountant because numbers don't change the factual the black and white, you know tax laws might change but numbers don't change. We're in Tech because we're always learning and that's what keeps it fun and interesting and devops is a continual process and always learning always changing and you're right.

We have a way that works now and that's hard for a lot of organizations to say. Well, what's my five ten-year plan and I'm like I can't tell you this application is gonna be around in 10 years because in 10 years, but you know think about the last 10 years. What what has come out in 10 years, right?

I don't have a five-year personal plan because I work in them. You are the tech could change the cloud could fall in on itself or I don't know some new groundbreaking thing comes out and that's my new favorite thing to work with. I don't know.

Yeah, I think it's you have to be adaptable at agile to an extent, but you have to love learning as well. Sure, guys, I got to take a quick break. We you know on these shows we give out four Amazon gift cards every every show and I have to announce the winners.

I hope I can read them from it's up on a monitor far away from me. So we've got the winners are like Muriel Deez Act V razor a and Kimberly S I hope I got the names right our folks will reach out to you and get you your Amazon gift cards. Thank you very much.

Guys, we have less than 10 minutes left here. I'd like to focus in make sure we answer the question that we started with. Do we need devops to do Cloud native?

We we circled around and round and rounded we've talked about some amazing great topics. I want to make sure that people leave here with it an answer from us. So I'm going to go to each of you and give you your closing arguments.

If you will be last week was election day. April of you. Don't mind.

I'm going to start with you doing these devops for cloud native. Yep. I'm gonna say yes flatly pretty simply because if you're not life is going to be painful and you won't adopt it.

You won't want to continue so I'm gonna say yes to be successful. Yes. Great Chad.

Yeah to be successful. Yes, they're like chocolate and peanut butter. They work.

Okay separately, but they're much better together and definitely you should be doing both. Michelle, how about you? Yes, everything it's way better like not doing it.

It's still possible, but it's going to be so painful. It's like you can eat every Mushroom in the world at least once but you're probably want to eat it twice. Okay Prague.

How about you? Okay, I will say this if you're a company that doesn't need to change and I would even argue even accounting is changing how you capitalize R&D expenditures changes every year, right? So if you're a company that believes in stagnation believes that changes not the normal modus operandi don't want to learn.

Yeah, maybe forget about that boss, but they're not ask. Why did you go after a cloud native in the first place? Right.

It is the ability to adapt the ability to change to take on to Unown the biggest risk that we have in all called out is the unknown risks and how you react that matters. Okay. So if we are true Risk Managers and we believe that this is a changing world.

Then devops is such an absolute requirement that it's a prerequisite to success. you the only thing I'd say is it's a Journey Don't Stop innovating in building out your microservices building up private Cloud on premises or going to a public cloud and refactoring your applications to take advantage of all this because you believe your devops maturity is too low no solve these problems simultaneously in parallel and when you see the other side I will argue devops is one of the greatest money makers of businesses around the globe today because it gets all of our imagination out to production faster with risk in mind so it hey Mitchell, I'm going to give you the last word man. Okay.

Well first I had to laugh at his show because we just voted on mushrooms in Colorado. So it passed by the way. Okay, it's surprise.

Yes the baby this is just fantastic panel. And one of the things I've always wished is that wish other people could really experience what it's like to create software because it's not just sitting in front of that idea and writing code into it. There's so much more to it.

It's really a putting so many things together and that's very representative by this conversation of why we talked about so many dimensions of this. And maybe this is a good way to get get a better feel for what it's really like to be architect or software developer. So my record that take this recording and play it for folks.

My answer is yes, and as part of how we created this question because if you're gonna do microservices and that's kind of what I think is the heart of cloud native is doing micros you do that at scale and deliver code. Quickly that velocity. Yes, you could try doing it without but to do it at very, you know, velocity speeds you've got to do something like devops and that's what our kind of current generation of how to create software.

So, you know, really I wish everybody a great great progress on their Journey because we're all on different points in that path and Playing this to our worlds and back to April, you know The Five-Year Plan with was different yesterday if we have one so back to you Alan. Thanks, Mitchell. Folks on our panel.

What a great panel. This is we'd love to run it back. Um sounds like we could talk security devops Cloud native, whatever whatever.

We'd like. I'd love to have you all back in here. We'll ask our producers to try to make that happen even to my friend razor out in the audience.

We'd love to have you on let's talk about compliance equal see not equal security at some point, too. I'd love to have that conversation most of all to all of you who joined in live today and even to those who are watching this on demand. We get a lot of people watch these on demand.

Thank you for joining us. We hope you enjoyed it and then finally big big thank you to our friends and try centers who make this whole series possible. We couldn't do it without them.

Thank you. Thank you this Alan shamol, we're gonna call it a rap on this episode of devops on down. We'll be back on with one of our regular recorded shows in the next week or so, and we'll be doing one of these in the next month.

So we'll hopefully catch you. Take care of everyone and good luck.