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.