11. Cloud Native is Just a Marketing Term – Tech Field Day Podcast

Software developers use the term cloud native to describe applications that are designed for the cloud, but today, it seems more of a term for containerized applications. This episode of the Tech Field, a podcast recorded ahead of Cloud Field, A 20 Includes Guy Coer, Jack Poller, Ziff Levy, and Stephen Foskett. That's me discussing the true meaning of Cloud Native.

Is it really just a marketing term? Welcome to the Tech Field Day podcast, the only show that dares to be both on topic or on premise, and sometimes even on premises or on location. That's right.

This week we're gonna be on premises at Cloud Field Day, and we're recording a special episode, kind of previewing what we're gonna be speaking about there. Each time we meet, we bring together a group of IT experts to discuss a single idea about a key concept in the industry. And this week we're talking Cloud native, because after all, cloud Field Day is coming up and cloud native sure seems to be a bit of a marketing term, so we're gonna tackle that.

But first, let's meet who's on the panel today. Hey everybody. My name is Eve Levy, uh, founder and CEO of Cloud Consulting.

I help companies that struggle with, um, getting out of legacy applications, legacy operating systems, everything around their cloud solutions, adopting the cloud, uh, that is still happening to this day, um, and everything around, uh, securing that solution on top of the cloud or on premise. Hi, I'm Jack Pauler. I am principal, uh, analyst with Paradigm Technica, a cyber security industry analyst firm.

I'm Guy Courier. I am a CTO and a tech market advisor at Visible Impact, which is part of the FU group. And I've been working on cloud and tech and app dev for about 20, 25 years.

And I'm Steven Foskett organizer of those tech Field day events series, uh, which is also part of the Futurum group. And I've been doing this for about 15 years, and I'm kind of getting tired of hearing how everything is cloud native because, you know, I don't know, some of it doesn't seem all that native. What do you think?

Guy? Wanna kick us off here? Yeah, sure.

I mean, cloud Native started out as really an AP dev term in my view. Uh, uh, cloud had come out as, uh, something that could be provided as a service, uh, infra infrastructure resource that could be provided as a service, uh, software that could be provided as a website and so forth. But when you're thinking about developing applications, uh, based on cloud, this would be going back 15 years or so, um, you had to take account of how cloud resources worked.

They were fragile. Uh, they were not necessarily persistent. They were not very well suited, uh, in a lot of cases to applications that just assumed resources were always available.

And so this cloud native term seemed to take account of that. It was a reaction that application developers, uh, should have, um, to using this terrific self-service style resource. Um, fast forward to today, and it seems to be a lot more about how the infrastructure is constructed, specifically containers.

Um, so when you hear cloud native, when I hear cloud native now, I just sort of substitute Kubernetes in my mind because I have a feeling that a Kubernetes pitch pitches coming. And, uh, that makes me wonder, um, whether cloud native has the same meaning it has anymore these days. I, I slash it when I write about it, I do cloud native slash and it's usually slash microservices slash 12 factor.

And once we start slashing, then we're starting to lose the original meaning. That's just my take on it. I'll, I'll come at it from a different angle in that I spent a lot of time talking to a lot of cybersecurity companies, and the term is bandied about quite a lot at a very high level.

And I would say it really seems in the cybersecurity world to be a way to distinguish, um, applications and smaller vendors who wrote their applications originally for the cloud rather than legacy vendors who started out with an application that may have been, uh, a legacy, um, monolithic infrastructure type application that was then either ported to the cloud or runs on premises and a hybrid cloud and in the cloud at the same time. And, uh, you know, you talk to 10 different vendors and you'll get 10 different, uh, definitions of what cloud native really means in sort of my experience, Experience. Well, I mean, it could be an ecosystem.

Uh, another word I usually try to avoid. I mean, there are meanings to it, um, that could extend, it should be part of every layer of the stack, right? But then I feel like the whole meaning gets flipped.

I mean, let's, let's go back to containers. Cloud native means containers now, right? At least within the infrastructure world.

Um, I was at Nutanix next a couple of weeks ago. Anywhere you saw Cloud native, you could just substitute in your mind Kubernetes, because Nutanix is a virtualization, uh, vendor, and they're looking to enter, uh, they are entering into container management. But then to me, okay, like containers right now are really more suited to stateless apps, but there's nothing inherent about containerization.

That means it's not good for stateful. And so now if with a container you are providing the environment for application X to run according to its own needs, then cloud native becomes meaningless. Well, it's not that cloud native is meaningless so much as it is that the things that people are describing as cloud native are not actually cloud native, right?

I mean, as you say, many people are containerizing applications that, but, but not actually making them into any kind of scalable microservices type, you know, modern application framework. All they're doing is they're running a, a monolithic application in a container using co Kubernetes to schedule that and calling it cloud native. And that's just really not the right term for that.

I, I mean, that's, that's good. Uh, I will be the first to say that running applications and containers is fricking brilliant, but it doesn't make them cloud native, right? Yeah, I agree.

I I think that, um, you know, there's a major difference between, you know, trying to run your solution, uh, just as you described, and then try to actually, you know, build it from, you know, different components, different services, you know, use all across the board, uh, on the different platforms and leverage, you know, those different services. Uh, that would be, you know, cloud native to me, um, that's, that's how I see it. So I agree with you.

I think one of the other challenges is the perspective of the audience. If you are a developer or working in app dev or working in the guts and the technology, then knowing something is cloud native and what that means in terms of that it's running in Kubernetes and microservices is, or can be very important to you. Uh, on the other hand, if you are looking at, uh, acquiring software as a service, um, as long as the service provider, uh, provides you scalable, uh, services, do you really care what's underneath and that it's running cloud native or Kubernetes or their own technology underneath?

Does it really matter? Actually, I think the service provider example is a perfect example, Jack, because maybe you do care. Why would you care?

Because if the, if the provider is not one you already know intimately and assume, well, let's assume you don't because you're evaluating them, um, they're gonna tell you theirs is a resilient, scalable, globally available service or whatever, maybe they'll be more limited, say, you know, available in North America and Europe, whatever it might be. Great. And one of their proof points is going to be it's cloud native.

And if you don't know what they mean by that, then it's not a proof point anymore. So, you know, I feel like discussions like this are as much about, um, clarity in the market as they are about like, you know, features and products and technologies that are available. And that's my whole problem with it is, um, you say cloud native to, uh, uh, platform engineers, they're thinking one thing.

You say it to application managers, they're thinking another thing. At least that's how it seems to me right now. Well, I think, you know, uh, some of the things that guy said resonated with me that it is, um, Kubernetes microservices based, um, scalable.

Uh, and I think probably most importantly is that it, the term native to me means that it's actually built for and running in and taking advantage of all of the technological features of Kubernetes microservices environments, right? So it's not, as you said, Steven, it's not just we've taken a monolithic architecture application and dropped it inside a virtual virtualization environment that just happens to be Kubernetes versus VMware or any other virtualization environment. It's actually built to use the features of the technology and the technology that's involved.

So an application that has, um, for example, that can spawn multiple, uh, different processes, um, as demand increases, um, you know, each of those being scheduled by Kubernetes and run, uh, as a container containerized service on, you know, whatever, uh, platform Kubernetes decides, uh, something that can, uh, grow and shrink as demand changes. Um, what about things like the, um, APIs and so on? Um, are there essential elements of, of the interface, uh, between applications or application components that need to be considered in order for it to be con considered cloud native?

I don't think so, Steven. Um, I think that, uh, I'm a huge proponent of, you know, the so-called API economy, right? Um, API, uh, management and, and development management and use is, is essential to these kind of distributed, disconnected, actually mix of stateless and stateful, et cetera, types of applications, services oriented, continuously delivered and so on there.

And it's, they're just an essential tool now, but I don't think conceptually there's anything about the API that's, uh, that's needed, um, uh, to make something, uh, cloud native. I think, um, or maybe I'm just really being old school and just thinking like, you know, there, you just do not know if it's cloud really what the behavior of the hosting environment is going to be, and you develop accordingly. And containerization and container management and orchestration is a beautiful tool for allowing, uh, for the kinds of infrastructure support that the application needs.

But once the application starts counting on certain service levels from the infrastructure, it, it may be cloud native, but it's irrelevant whether it is or not. And the connection points that different microservices have between each other, they don't have to be API based, in fact, I can't think of any, but I, there there could be really important performance or security reasons not to use APIs, and I wouldn't want to exclude those from a, a cloud native paradigm. Yeah, I'm in agreement.

I think that, um, it makes perfect sense. Um, I don't really see a difference between, you know, why will you, why would you call something cloud native or not, you know, based on, based on API availability. I mean, obviously it should be there, um, in a proper form of course, um, and allow developers to interact, you know, with the different services while they're building or sending out the commands.

So I don't think it's really relevant to that particular term. But when, when, when you say that it doesn't necessarily have to have an API, you know, or there might be use cases where we don't use an API, I think that's correct, but I think one of the hallmarks of the environments and being cloud native is that APIs are the, the standard way you interact with the system, right? So rather than having a command line interface and a separate web interface and a separate this interface and, you know, everything is done through an API, so you have the, the application builds its own APIs, and then the interface to that can be, uh, uh, accessed programmatically through the APIs, and then if a user needs to access it, you have a front end written that will eventually call those APIs.

And it's a different way of interacting with the system so that you can include automation and scalability in it without having to write custom things for every time you change the environment. Yeah, good. True.

But I'm just saying it's not definitional. I mean, I'll give you an example of something I think probably is definitional, which is telemetry and observability. I can't see a way to build a proper cloud native application without telemetry and an observe an observation platform.

I just can't see a way to do it because, um, that would, that would, um, remove, uh, insight from the operators into how, as well as within the code as to how the application is behaving. And that's fundamental to, uh, running something cloud natively, whereas the, I I realize it's only theory, not practice, at least not at this point, but theoretically, you could create a cloud native app that doesn't use APIs at all. I guess it depends on how you're gonna define it.

I mean, I would say that, um, to me, I would think that any kind of cloud native app ought to have an API interface, um, and specifically ought to have, you know, a rest interface because it just seems to me that that is one of the, it's one of the standard things that people expect, but I will concede to guy that I could, I could imagine an application that doesn't use that. For example, you know, backend databases probably don't use REST as the interface. Is that an API, not particularly, but I would say that SQL is still acceptable in a cloud native application.

So I will concede that I can see a situation where an app might not have API might not be completely API driven, but at the same time, um, I'm not sure if I agree with you about having telemetry and observability. What if the microservices are just that small and ephemeral that you just don't care? Do you need telemetry from everything or is that just another nice to have like an API?

Yeah, I think it's a, it's a must. Um, I've a lot of experience with, you know, flying blind, and I can tell you that once you are able to make that shift, you really don't wanna go back the amount of, um, you know, the information insights, uh, just be able to, you know, be able to see that everything is running smoothly, how it works at scale, um, things you need to improve and just make sure that, you know, overall you're healthy, um, is definitely something that you must have when you're building an app if it ties into, you know, cloud native. Sure.

All right, I'll check that box, but I think it's essential either way. So what other elements do you think are essential, uh, for cloud native applications, or maybe not essential, but uh, are, uh, likely to be found in them? We talked about, um, microservices based and containerization.

We talked about APIs, uh, we talked about observability and telemetry. What else? Well, key components that you can definitely leverage in, um, you know, for cloud native solutions would be, uh, everything around security.

Um, so, uh, the different aspects of what happens, you know, above, above the code, uh, the different services that you can leverage, uh, different components that can interact, interact with each other, that would help you, uh, get a much more secure stack and proper controls in place, both for incoming traffic, outcoming traffic, uh, would be something that would also be essential in my eyes. Um, that, that's, that's absolutely right. I think, um, in, in implied in that Leadin stated is, uh, a certain amount of network networking, um, uh, networking, service management, um, not, I mean, any of these things.

One of the, one of the neat things about one native is you can use southbound integration to, um, to affect, uh, like you say, Steven, to, uh, to influence, um, the infrastructure and how it behaves, um, you know, in production. And a key element to that, that I think is often overlooked is, is, is networking, throttling up, throttling down, controlling ingress and egress to the different other services. I'd include that as well.

Storage management is frequently coded for. Um, but I think networking is, tends to be the, the Cinderella of the whole architecture, uh, looked aside, uh, looked to scan, set by the, by, by, uh, most elements of it, and yet critical to the user experience. See, I'm not, I'm not sure I, i, I get that as from looking at it from the outside in, everything that you're talking about in terms of the networking is not, to me a feature of being cloud native.

It's a feature of network controls and security controls in that sense. And when you say cloud, when you say I'm cloud native, or I'm not cloud native, I don't feel that if you say I'm not cloud native, that I'm losing anything on the networking side or on the security side. Yeah, Jack inherent to the user experience is responsiveness and availability.

And if you have ever been in a tunnel trying to use an app on your phone, you can see that very frequently, um, a poor or no con connectivity, sorry, is not really built into the, the, you know, the, um, the, the portion of the app on the phone, the client portion, and if it were, if it were network aware, I wouldn't say network aware, I would just say more network tolerant, then you'd have a better user experience. I, I don't argue that. I'm just trying to feel out if that is a fundamental characteristic of cloud native versus versus good app development and good user experience development.

I see that if somebody tells me their app is cloud native or their development environment and their stack is cloud native, I don't immediately go to, okay, I'm gonna have a great network in, you know, experience, right? I'm never gonna have dropouts because we all know that's not the case. We had plenty of dropouts and plenty of network issues with apps regardless of whether cloud native or not.

I do on the other hand, think that when I say an app or an environment is cloud native, that I will have a much better experience from a user perspective on things like scalability because of the inherent nature of Kubernetes and cloud native tools and the environment to scale up and scale down automatically without the administrators having to get involved, right? And so I have a better user experience in terms of a load, but I don't necessarily see that on the networking side. So I'm just trying to dig in and say, is that really a fundamental characteristic of cloud native?

Yeah, I think you're yining my yang Jack because, uh, when we're talking cloud, one of the many cloud resources that you can't rely on is, um, connectivity between the microservices. And the key part of that connectivity is networking and security. Yeah, if I wanted to be cynical, which I do, I would say, um, you cannot say that networking or security or storage, um, a advanced, uh, configuration of, of any of these services defines cloud native or are required for cloud native because most developers do a horrible job and don't know a darn thing about networking or security or storage.

And, uh, so many cloud native apps do a poor job there. You just can't have that. It can't be definitional, because if it is, then we would have to disqualify so many applications.

Um, and other, you know, other elements of the stack too, I mean performance, um, I I would say that those are all really critical for a successful cloud native application, but I just can't see that that has to be definitional because if so, then you know, people are just doing a poor job of it. Um, in fact, I would say that most cloud native applications probably have big holes in their networking and security and storage, um, infrastructure. So I would like to challenge that just a bit.

I think that what I'm seeing, you know, over the years is that, you know, different platforms are trying to get, you know, the different customers into, I would say a good default setting or a good place to start, um, when they're building their apps. So yes, far from perfect, but let's say if you have no idea what you're doing and you're, you're just writing your code and expect it to run, I think you are off to a better start. Um, you know, when it's being delivered on top of those platforms versus not going with something that would be, you know, qualified for that cloud native app being served from someplace else.

Uh, there's just far more things that can go wrong, um, versus what you can get out of the box on top of those different platforms. Well, I'm gonna sort of think about it and go back to sort of the original high level question is, is, is cloud native really a marketing term? And I think it's a little bit dependent on usage.

And, um, audience, again, and I'll go back to what I said about audience is that, um, a lot of marketers love to use adjectives in wherever they go to, um, and you know, in all the marketing content and the discussions they have in person. And one of the big adjectives I always hear is cloud native, and I'll, I'll get back to again what I said earlier, guy, which is sort of, why do I care from a technology perspective and a technologist? I love it and I think it's great and it's modern, it's what we should be doing because it's solving a whole bunch of problems that monolithic architectures and other architectures have.

Um, from a, a consumer purchasing or, or an enterprise level person looking at choosing between three or four different solutions to a problem, whether it's cybersecurity or storage or an, uh, you know, uh, A-A-C-R-M application or mark marketing application. When I think about those as a consumer of the application and a purchaser of the application, I hear the cloud native word and it just sort of disappears. It's in the noise along with fastest and greatest and best and First and Pat and, you know, pat Award-winning and all the other adjectives that we as marketers like to throw in there because it doesn't have a consistent definition as you know, this conversation here, we've been in the world, this world for 15 plus years, all of us, we've been using this stuff for 15 plus years and we still spent 10 minutes trying to figure out and come up with a definition for it, right?

And so it really, sometimes it really does bother me that the marketing people throw it in because it's not, I can't put my thumb on it and say, this is exactly what it's, Yeah, but I feel like we're back to the beginning, except I feel better about it. It is a marketing term. It's mostly a marketing term, but I actually kind of feel like that's a good thing.

A story is not in a word. So my product story is not, this is a cloud native product. There's more to it than that.

Let's just make sure we're ta we're explaining that, I guess To channel my inner Justin Warren, I have to say words have meanings, and if we're using them wrong, that's a problem. And so I would say that if people are describing their application as cloud native, we should be ready at least to ask is it true that this meets the definitions that, you know, I have, that you have that other people would have for that term? And more importantly, does it meet the goals that that term has?

I mean, so often what we've been talking about here during this discussion are the, the, the, the physical consistency of an application. But what we're really asking is does it achieve what we need it to achieve in terms of scalability and performance and stability and, and predictability and all these, all these actually useful outcomes. You know, the, the, the benefit of cloud native is building applications that are bigger and better than anything we could build that would be monolithic.

If an application is, is is meeting that is delivering that, then I guess who cares whether it was built in a cloud native structure or not. Um, you know, we were hearing guy at, uh, click connect last week, uh, that, um, many applications were built, many early applications, um, were built not on a cloud-native, a recognizably cloud-native structure, but were built in a very monolithic way with a monolithic database behind them. But it was a really big strong monolithic database that was able to scale.

I think, uh, Denny was telling us about MySpace, for example, that used a Microsoft SQL server backend. That's certainly not a cloud native app, but it certainly did scale. So I guess ultimately, if, if somebody's gonna make a promise about Cloud Native, then they better be ready to back that up in practice, right?

Yeah, absolutely. And I'm looking forward starting tomorrow to see, I mean, I feel like we've almost established a template or a reference point. 'cause I expect us to hear that word cloud native a few times, uh, maybe starting tomorrow from, uh, uh, uh, Juniper or, or from Google, um, this week at, uh, at, uh, cloud Field Day.

And now I feel a bit bit better oriented because what I'm trying to do, like you say, with Cloud Native is create this resilient, globally available, scalable et cetera application. And so now if you as a vendor are saying to me, this is for cloud native, that's a reference point against which I can judge what you're doing. I'd say the, the big caveat that I have to all of that and, and what I will be listening for is, um, vendors throwing the term out there and labeling their product as cloud native to give people the impression that cloud native is a silver bullet that's gonna solve all their problems, right?

And I don't believe that I, I believe in doing Kubernetes and cloud native stuff, but it is not a silver bullet. And just the, the fact that you're doing Cloud native doesn't mean you're going to solve somebody's problem. I'll suggest a different approach.

I think that what should be the angle would be possibilities. You have the flexibility to do a lot. It's really up to you to figure out whether you wanna leverage that or not.

Let's try to settle for that. Ziv, you're so nice. Like Jack and I we're like the marketers here.

We're the ones who are supposed to be like all optimistic and stuff. And, uh, uh, it turns out that we're the cynics. Well, I guess, uh, I guess all of us are a little bit, um, anytime we start a conversation on the premise that something is just a marketing term, I think there's a little bit of cynicism or pre maybe a lot of cynicism built into that.

Um, but ultimately, I, I think you guys are, are, are onto something here that in order for something to be truly cloud native, um, it really depends on what you're getting out of it and not what you put into it. And, um, I can imagine someone building a microservices API driven app with telemetry and networking integration that stinks. And I could imagine someone building a monolithic app that is wonderfully scalable and, and doesn't.

And so ultimately I think that we need to make sure that we're getting what we want. So thank you so much. This has been a really cool conversation.

Um, we'll have more of this at Cloud Field Day this week. I'm really glad to have you all joining us. Uh, along with the other, uh, nine delegates that are gonna be out there with us, uh, we're gonna hear from some incredible companies.

Uh, we've got Google Cloud for an entire day, I'm sure they have a thing or two to say on this subject. Uh, we've got Juniper Networks, which goes directly to some of the conversation we've had here about networking insecurity. Uh, we've got Morph Morpheus data and Oxide computer who absolutely know a lot about building scalable platforms.

And, um, I think it's incredible to, uh, to think that we'll be able to continue this conversation this week. Uh, before we go, uh, let's go through and, uh, tell us a little bit more. Where can we continue this conversation?

Where can we connect with you and where will you be covering Cloud Field Day Guy? Uh, you'll see me mostly in LinkedIn. I do publish at fu Room's, uh, website, um, and you might see a piece or two there in the coming weeks.

But, uh, check me and follow me in LinkedIn. Like, guy, I do most of my work on LinkedIn, so please follow me and, uh, find out more about all the companies we'll be talking to next week. Same here.

You can find me on LinkedIn, uh, with all my relevant content. And as for me, you'll find me here, uh, on the, uh, tech field, a podcast along with our, um, weekly news rundown every Wednesday and our utilizing tech, uh, podcast season, which is back now with a season focused on AI data infrastructure. Uh, we just kicked that off.

So that's our Monday podcast. Thanks so much for listening. Um, this is the, uh, tech Field Day podcast.

Uh, we really do enjoy bringing these discussions to you. Uh, we enjoy throwing, uh, our fantastic Tech Field Day events and, and spending time with these incredible people, uh, in person at those events and sharing that with the world. Um, if you enjoyed this discussion, please do subscribe to the YouTube channel.

Uh, also maybe subscribe in your favorite podcast application for an audio version of the podcast, and, uh, give us a rating and a review that really helps. This podcast is brought to you by Tech Field Day, home of IT experts from across the enterprise, part of the Futurum Group. com/podcast.

Thanks for listening and we will catch you next week.