Cloud-native is a methodology and a mindset that’s been gaining traction in the DevOps and application development space as more organizations look to leverage the benefits of cloud infrastructure, including scalability. As with many other topics in the DevOps space, however, cloud-native isn’t easily definable; rather, it is loosely described by the technologies it utilizes, including containers and Kubernetes.
In our second episode of Ambassador Insights, featuring DevOps Institute ambassadors Leonardo Murillo, CTO of Qwinix Technologies; Tracy Bannon, senior principal and DevOps strategic advisor and software architect at MITRE; and Pawel Piwosz, lead system engineer at EPAM Systems, we delve into what it means to be cloud-native, look at some of the c
The video is below, followed by a transcript of our conversation. Enjoy!
Transcript
Charlene OโHanlon: Welcome back to TechStrong TV. Iโm Charlene OโHanlon, and I am here with another episode of the DevOps Institute Ambassador Insights Panel Discussion. Iโm so excited to have these on a monthly basis with some very, very smart people who also happen to be ambassadors with the DevOps Institute. And each month, we have a different topic of discussion to align with our monthly spotlight topics on DevOps.com.
This month, we are going to be talking about cloud-native and cloud-native technologies, and so, I have some experts in the field right now. First up, we have Leonardo Murillo, who is the CTO of Qwinix Technologies. Hey, Leonardo, thank you so much for joining me today.
Leonardo Murillo: Thank you for having me, Charlene. I really appreciate it. This is great.
OโHanlon: Alright, alright. Next up, we have Tracy Bannon, who is the Senior Principal and DevOps Strategic Advisor and Software Architect at MITRE. Tracy, thanks so much for joining me, we really appreciate it.
Tracy Bannon: Thanks for the invite.
OโHanlon: Great. And finally, last but not least, we have Pawel Piwosz, who is the Lead System Engineer at EPAM Systems. Pawel, thank you, also, for joining me today, we really appreciate it.
Pawel Piwosz:ย Itโs a pleasure to be here with you.
OโHanlon: Great, great, great. So, letโs dive right into the discussion. I know weโve been talking on DevOps.com and Container Journal a lot about cloud-native, but Iโm not sure, actually, that a lot of people understand exactly what we mean when we say cloud-native, so maybe we should set the stage, if you will.
Leonardo, maybe you can start us out since you are really focused heavily on cloud-native. Can you kinda tell us what we mean when we say cloud-native? What are we talking about?
Murillo: Sure. So, I think when we talk about cloud-native, weโre talking about a specific mindset and patterns to apply when weโre building both systems as well as organizations, which is kinda one of the things that I wanted to discuss today, right? Because cloud-native is not just how you build technology, and you donโt really need the cloud to build cloud-natively, right? Usually, when you think in terms of cloud-nativeness, youโre thinking about loosely coupled architecture, youโre thinking about containerization, immutability, statelessness, right? All of these are components that are incorporated in a cloud-native solution, and I think the organization has also to become cloud-native, and thatโs where DevOps becomes really important, right? To be able to leverage and really take advantage of all the different qualities, right, that the cloud has basically surfaced and made available, right? What do you think, Tracy?
Bannon: To extend on that and sort of foot stomp for what youโve said already and love that you want to talk about the organization, we can talk about, I call it a reverse Conway maneuver.
Murillo: Right. [Laughter]
Bannon: [Laughter] So, thereโs a lot to be saidโIโm actually finding that thereโs not agreement on what cloud-native is. Thereโs an argumentโit means containers. Well, yes, and letโs talk about serverless and the impact of serverless. So, itโs not a specific architecture pattern, but it does mean that we are building to take the best advantage of the infinite scalability, right, and the self-healing nature and other aspects of cloud. Love your point as well, Leonardoโwhile we say it needs to be on cloud proper, building for cloud, right, doesnโt mean that Iโm necessarily hosting in an AWS GCP, et cetera and so on. It means that I have applied those principles, and I can do that within my data center, my private cloud, or whether Iโm paying somebody else to be the host for me.
Murillo: Yeah, great point.
Piwosz:ย Thatโs true, and itโs not only about the application, itโs about everything what is around. For example, CI/CD, how we store our code, how we approach to the code, how we approach the security networking. Because this is something that we very often forget when we are going to the cloud, right?
OโHanlon: Mm-hmm.
Piwosz:ย So, platform as a service, we have everything, we donโt need experts.
Bannon: [Laughter] Donโt get me started at all!
OโHanlon: [Laughter]
Bannon: But thatโs an interesting point is that there are so many fantastic capabilities that are being provided as a service that I don’t think the folks actually know where to begin. Iโve had some awesome infrastructure folks who go out and they do some Googling and they do some research and they come up with a reference architecture. And heaven forbid, but God love them, they go out and spin it up and push the button, andโwow, this is a good solution for my firm or for my client or for my needsโand it isnโt, necessarily.
So, thereโs a lot of trade space that weโre unintentionally losing with the rapidity that weโre moving, trying to move towards cloud. Architecture should be more important, not less important. It shouldnโt be a stalling factor up front, but I jokingly say that, in order to push some value, provide value out into industry or to my clients, I have to be doing that from vision forward, right? I canโt take a steel girder and put it through a wood chipper, right? Itโs not going to work because it wasnโt constructed and thought of that way.
But Leonardo, to your point earlier, as much as the technology to me is the fun and sexy part, the human aspect really needs to be dealt with as well. We talk about it a lot in the DevOps piece of it, the DevOps portion or support effort on it, but you really bring up that cloud-native requires us to think about the organizational structure and building a separate culture than what weโve had before. Iโd be interested in what you think about some of the emerging software factories, or should I say continued proliferation of software factories as the way to move forward on software?
Murillo: I think that actually talks about kind of a different subject, and Iโd like to kinda step back a little and thinkโbecause you mentioned something that is very much aligned to this, and it is the whole strategy as to how you approach the cloud, right? Itโs not just about click a button and going in, right?
Bannon: Mm-hmm.
Murillo: And, to me, that has a lot of resonance to what DevOps is all about, right? If you think into kinda the cada mindset, right, define your North Star first, right, assess your current state, think about it consciously and mindfully, right?
I think if organizations that are looking to go into the cloud or mature into the cloud do take that step, do take time, they will be able to maneuver this gigantic ecosystem of tools that are out there and technologies that are out there. Because I think thereโs also an interesting component that we should discuss. You mentioned, Tracy, how itโs not just about the technology, itโs also about the humans, right, the people that are implementing.
Bannon: Mm-hmm.
Murillo: But I think that also resonates with the fact that technology is not there just for the sake of picking the latest and greatest tool, right? I read this great post by somebody that I canโt recall, that basically talked about how boring is good. You know, how boring technology is good because people are used to it and they’re kinda like aware of how it works.
And I think the closer you are in your evolution path to what is comfortable, the better. And I think thatโs one of the problems that I sometimes see in cloud adoptionโpeople try to bite too big of a chunk of change at a given time, right?
Bannon: Yep. Mm-hmm.
Murillo: And thereโs so much to choose from to make that huge bite. An actually targeted approach that is mindfully defined that is well strategized will solve a lot of these problems, right? Because it will give you a signal amongst all this ecosystem noise that teams are gonna be exposed to, right? So, Pawel, you are kinda like engineering these solutions, right? How do you work around this ultra-diversity of available technologies, right, when youโre building something?
Piwosz:ย Mm-hmm. This is … a very big problem. Because right now, together with cloud, we gained much, much more speed with everything, really. So, imagine 20 years ago you had a server room with racks and servers there, so youโd change only the server, but the logical side was still the same.
Today, we are jumping. Letโs stay with AWS. We are jumping from instituting analysis to microservices, then to serverless microservices, then to serverless itself. Who knows what we will find next year, for example, right? You need to switch your mindset here. This is something that especially all kinds of CisOpsโwell, I am all kinds of CisOpsโpeople have in mind, right? The same for networking, for security. There is a huge difference in speed here.
So, you need to incorporate into your mind things like do fast, fail fast, learn fastโespecially learn fast, because we are forgetting about this very often; too often, I would say. And also, we are forgetting very often in the trenches about the security of the cloud.
Bannon: Oh, gosh, yes.
Piwosz:ย Becauseโyes, because weโre saying, okay, we have a shared responsibility model, so they are responsible for everything. Weโre just running our application and not caring about anything else, what is really, really wrong, I believe.
Murillo: And I think that points to a fundamental misunderstanding, right, of what security in the context of cloud native architecture is all about, right? And I also think about, Tracy mentioned this infinite capacity, right? And you mentioned, Pawel, going fast.
Iโve been thinking a lot recently as to how those two components need also to be very effectively managed.
Bannon: Yes.
Murillo: By leadership, by those that are sponsoring these initiatives, right? Because after allโand this is something that Iโve been talking about lately, right? We have optimized for speed alone already without having, really, awareness of the impact that that would have on the environment and many things, right? And I think we really need to establish a mindset where engineering teams are aware that infinite capacity doesnโt mean just free for all, grab whatever amount of resources you have, that shared response security is not infinite, overwhelming security, right?
And I think this is also relevant in the context of the tooling that we were talking about, right? Everything now is available kinda point and click. You download a package, you have an appointment. You download another package, you have authentication and connectivity, right? And we donโt go into details necessary to understand kinda the supply chain of all these solutions.
So, I think thatโs whereโthe mindset of DevOps, right, reduce waste also becomes very relevant, right? Just because you have infinite capacity doesnโt mean you canโt be wasteful or you donโt have to be constantly evaluating the outcome of your ongoing efforts, right? Yeah, so, I think thatโs very important.
Bannon: Thereโs a treasure trove of topics that you just landed on, so it sounds like it could be a longer collaborative.
OโHanlon: Yeah, right. [Laughter]
Bannon: So, in terms of reducing waste, one of the things that Iโll put out there is that I believe, in what Iโve observed with teams that I run or teams that Iโm reviewing the content is that some of the cloud capabilities have made us, I think, lesser programmers, lesser developers, because weโre not concerned about the same things that we were before. Weโve delegated authority or weโve delegated that concern.
Iโve seen some pretty hideous, performance-wise, if I were to run it anywhere other than being able to up my compute, it used to be that we had to be concerned because it cost a lot to add additional resources, right? If it wasnโt as performant as we needed it to be, you just threw more hardware at it. That went away for a long time because it was cost-prohibitive.
Weโve almost gone back and revisited that in some ways. From a security perspective, itโs always been my perspective that it needs to be baked in. It has to be part of the ecosystem. So, when folks started talking about DevSecOps, I was actually against that, because DevOps means that thereโs a security part of it, but I do understand that it was, at times, not thought about. Our developers need to be educated, but they need to be held accountable because it becomesโthere is a group effort. Now, when I say developers, I mean the athletes who are hands-on, they’re engineering with us, they’re moving the software forward.
But there are two pieces that come to mind with this. Thereโs a limit to how much they can consume. Mentally, thereโs a limit to how much they consume. Iโm looking at Pawelโs background and Iโm thinking to myself, โI love all the stickersโ and yet, those are all the technologies that heโs considering that heโs looking at. So, as leaders in technology, one of the things that we need to do is to provide guidance to the folks who are on our teams to help them reduce the noise. It doesnโt mean to ignore the new things, but it does mean go ahead and get to finish, get to done on one thing, get it working, learn from it, and then improve it. And if improving it means that thereโs a certain amount of acceptable refactoring or pulling in another toolโabsolutely, right? Thatโs technology insertion, thatโs a good, smart thing.
But it does also mean that we donโt instantly glom onto everything thatโs coming along. I have one organization in particular where every team is allowed to have the autonomy and latitude and Iโm just there as an observer, and itโs a little bit of melee. There are lots of good pockets of interesting things, but because thereโs such technical diversity even in a small space, they’re having a hard time, because they’re not able to get crisp and good and deliberate with the first set of tools. To your point earlier, Pawel, they’re not getting good enough with what they’re doing before they’re switching on to something else.
So, cloud native mindset is pretty important, but helping to folks understand cloud native from a, what is it from a patterns perspective, what are the architectural tradeoffs for it, and then helping them to make selections and stick with it long enough to get a success, I think, are really keys to helping organizations.
OโHanlon: So, do you guys think that cloud-native is kind of an all-or-nothing proposition? Are organizationsโhave you seen organizations kind of going all-in on cloud-native and then maybe pull back?
Murillo: Iโve seen them going all in and Iโve seen them crash and burn. [Laughter]
Bannon: Yes! [Laughter] Alright, then!
Murillo: Yeah, I thinkโI was talking the other day as to, everybody knows juggling is really good for the brain, but if you try to learn to juggle with your most precious items, you’ll never learn because youโre gonna be very afraid.
I think itโs the same about cloud and DevOps, right? Everybody knows itโs great, everybody knows thereโs gonna be a lot of value out of it, but if you try to learn it with your most precious thingsโfor instance, your entire organizationโyouโre gonna have a lot of resistance to getting it right.
So, I think the same applies for DevOps and cloud-native. I think you need to iterate. You need to start small with projects that youโre capable of experimenting with, right? Kinda like the whole concept of a culture of experimentation and iteration is important, right? But thereโs gotta be awareness to the fact that you cannot just experiment with everything, right, or with everything at the same time.
So, what I mentioned, right, bite small pieces at a time, iterate, do concepts, and use those concepts to build kinda your operating model, right? What does a cloud mean to you for your organization, right? And then expand up until you have a very solid framework that is well establish, well understood, and then you can kinda start juggling with fire, but not until then.
Bannon: That also helps us think through greenfield versus brownfield. I deal a lot with governments and a lot with federal governments and different agencies in defense. And thereโs a tremendous amount of brownfield. It doesnโt mean that thereโs old brownfield, but it means that thereโs something pre-existing, so there have to be decisions made about where do I add on the cloud-native? Do I do it around the edges, is it incremental, am I doing strangler fig tree patterns, et cetera and so on? Thatโs one piece of it. Net new sometimes is a good place to try cloud-native, right, because you do have perhaps less confines around it, so take something smaller thatโs greenfield and make your first foray that way.
I think itโs an interesting conversation about the starting and stopping points for cloud-native? I noticedโand Iโd like to hear, Pawel, if youโve seen the same thingโI saw everybody lift and shift as quickly as they could. โI wanna get rid of my data center, so Iโm just gonna move my workloads, right? IAS, Iโm gonna move my workloads.โ
So, they moved their workloads, and I naturally thought the progression would be to pass or would be to cloud-native and to the refactoring. What I actually observed was a pendulum swing to the analytics side. And so, there was a tremendous, I have all of this compute available to me, I have less expensive storage, Iโll move over to the analytics side, and weโre just starting to see, a real increase in the cloud-native application space. Unless youโre truly talking about upstarts and greenfielding, there has been much less of it with the brownfield and the incremental improvements.
Piwosz:ย Yeah, I agree with you. So, first of all, if you just do lift and shift to cloud, whatever we call the cloud, you will cry very soon. So, this is the first thing.
The secondโyes, we have a lot of possibilities regarding analytics, we have beautiful words right now, buzzwords like observability, telemetry, et cetera, et cetera. So, weโre just expanding our monitoring, letโs say old-fashioned monitoring to the new areas and collect more and more and more, and more structured things.
So, this is something what is very, very easily achievable, but alsoโand this is in relation to the previous topic here, if you start with cloud, well, you are already in the cloud. There should be still a logic behind everything. Because, today is so tempting, because you do not have to do the initial investment, right? You just click a button and start using serverless or just create a big, big cluster of something, right?
And then, in my work, I observe this multiple times, then you create a crazy, really crazy solution for a very simple thing. Well, what can go wrong in this, right? So you are using like 10 or more technologies which are completely different, you are trying to wire them together and then you are sayingโokay, I know 20 technologies, it looks perfectly well in my CV. But when you talk with people, you just realize that it doesnโt work as it should work, really. Thatโs why, very often, organizations which are going to cloud and do not take logic in this, how it is organized, how it is architected, how this even developed, they are paying much, much more, not just because they did lift and shift, but they started to create very, very crazy solutions, right? And this is the kind of waste that you mentioned as well.
Bannon: Iโm gonna throw out just a couple quick words thatโll make people cringe, but when I think aboutโso, agility 20 years ago, right, the agile manifesto, thereโs a woman named Linda Northrop from the Software Engineering Institute at Carnegie Mellon who said it was one of the worst things that ever happened to software architecture, because unintentionally, there was this emergent architecture, my architectures will just emerge, I donโt have to worry about them in advance. I want to push forward that enterprise architecture needs to still exist, but in a different form, in a different format. There still needs to be, itโs okay for there to be somebody more senior, somebody who is helping to drive the architecture and helping to pick which cloud technologies and where cloud native is the most appropriate.
Because thereโs different trade space, right? Even if I talk containers, thereโs different trade spaces between how Iโm using the containers and how Iโm moving forward with that. Does that resonate with you, Pawel and Leonardo?
Piwosz:ย Yes, yes. I would even add here that if you want to be cloud-native, your developers need to be cloud-native. So, there is no more, โIt works on my machineโโthis is obvious, right? But also, I will be bold here, so even development should go into cloud. And this is another layer here, which we didnโt touch, but it is very important, I believe.
OโHanlon: Well, I feel like we could have this conversation for at least another hour, but unfortunately, we gotta wrap things up, guys. But I do appreciate Tracy and Pawel and Leonardo for your insights. You guys are great. Iโm gonna have all three of you back on and weโll talk about other things in the future. We have lots of topics to get through this year.
The level of intelligence and insight you guys bring to these conversations is just so, so value added, so I do appreciate your time in joining me today for another one of our DevOps Institute Ambassadors Panel Discussions. So, thank you, guys, again. We really do appreciate it, and please do stay in touch with me. Iโd really absolutely love to get your expertise back on the show, so.
Bannon: Alright, fantastic. Be well. Stay safe, everybody.
Murillo: Thank you very much.
Piwosz:ย Thanks, everybody. Thank you.



