Cloud Native Theater | Cloud Native University: Cloud Native vs. Platform Native vs... Ruckus Voxi

This talk explores the evolution of cloud-native concepts, beginning with the inception of DevOps between 2007 and 2009 and the introduction of the 12-factor app methodology in 2011, which emphasizes decoupled and independently scalable application components. The speaker discusses the impact of Docker's introduction in 2013, which enhanced application portability, followed by Kubernetes in 2014, connecting DevOps practices with scalable container orchestration. The Cloud Native Computing Foundation (CNCF) was established in 2015 to promote open-source, vendor-neutral projects that support this ecosystem. The speaker highlights the need for true cloud-native applications to leverage open-source technologies and to be platform-agnostic, warning against the misuse of the term cloud-native in marketing. The emphasis is placed on building applications that are scalable and resilient without being overly dependent on specific cloud infrastructure, advocating for a more comprehensive understanding of what constitutes genuine cloud-native architecture.

All right. So, I have observed a growing drift between what people say is cloudnative or think is cloudnative. So, I thought a short history lesson might provide some clarity. It starts with DevOps being conceived between 2007 and 2009. And then we roll over to 2011 with the 12 factor app methodology. I'm getting some feedback on the mic. And if you're not familiar with that, that is a

collection of design practices to structure the application in a way where the components are decoupled and can scale more independently without having to make significant changes, which is the way we're still building apps today. And then in 2013, Docker entered the world and it brought portability to the table. There was containerization in the Linux kernel up to this point, but Docker's ability to extend beyond that has

greatly changed that and again brought portability front and center. And then a year later, you have Kubernetes released. I think a few people here know what that is. And despite the hard falls that we had learning to use it, the reason many of us embraced it was because it provided the connecting tissue to bring together DevOps practices, modular applications and containers at scale. And then finally in

2015 CNCF was formed to steer the direction of Kubernetes and this paradigm by fostering and sustaining this ecosystem of open-source vendor neutral projects. So this is how we got here. This is the biological makeup of what we consider cloud native. It's like DNA, a molecule containing the biological instructions that makes a species unique. Human DNA for example has these four nucleobases simplified as building blocks which would

be adanine, thamine, cytosine and guanamine. The cloudnative DNA is also made of four building blocks devops 12 factor app principles containers and orchestration. And if we examine the properties of these nucleiobases or building blocks, whatever they are to you, we can begin to identify the traits of something that has this DNA. Open source, while maybe not a hard requirement, is certainly a catalyst for DevOps. They share

overlapping principles in maximizing collaboration, transparency, velocity and flexibility. Which then leads us to our current reality where much of the de facto industry standard DevOps tooling is open source. The 12 factor app is platform agnostic with a core philosophy of offering maximum portability between execution environments. Docker and Kubernetes open source and portable by design can run anywhere with the compute network and storage resources to support them.

And then CNCF fills in as the backbone to complete the double helix giving structure to an emphasis on open source and vendor neutrality in the cloud. So this is the DNA of what we call cloud native. Open source, portability, and platform or vendor agnosticism are the hereditary traits. Now, fast forward some 11ish years. What is cloud native today? On one hand, it is perhaps the greatest paradigm

for application development. But on the other hand, it's also ballooned to this enormous bubble of hype. Just about anything or anyone doing anything in the cloud is cloud native. Every SAS is somehow cloud native. And if you purchase their SAS, you are now cloud native. But let's save that for my podcast that I don't have and let's just focus on the because the value has not gotten

watered down. It still solves some very specific problems that were present in the traditional model where applications were mostly monolithic and written for the resources that executed it. And that was messy for a number of reasons, but also very difficult to scale. When it did scale, they could only scale up. The 12 factor app comes along as a methodology to break this up and free the application's

concern of the environment so that it can run and scale as modular components on your own servers or someone else's servers. And then cloud native builds on this to remove your servers from the equation so that it is only someone else's servers completely abstract the infrastructure from you and from the application. And sure you can run these on your own servers but the emphasis is really to

exploit someone else's servers offered as ondemand resources. The argument being that then you can just focus on code and let maintenance and scalability and resilience be someone else's problem. That said, simply throwing your application on someone else's servers doesn't mean it's scalable and resilient. For one, someone else's servers can and do run into their own problems with this. two, their servers may be running beautifully, but it's

actually your application that's the bottleneck. A cloud provider paves a roadway, but your application is a vehicle that has to drive on it. It has to be built in a way that is scalable and resilient. And that brings us back to these two buckets of hype and paradigm because this is where the hype can get us into trouble and be a little misleading at times about what

you are actually getting because it's the paradigm that needs to be put into practice to get that benefit. And then we also end up seeing these very opinionated prescriptive guidance on cloudnative architectures that look something like And this is not a knock on AWS to be clear. This is just to point out a blurry line between what people think about or talk about cloud native versus the

problems that the paradigm intends to solve. At a glance, I'm having a hard time seeing what makes this in particular versus just a cloud-based architecture. Considering that three of the four managed services actually predate the entire concept of cloud native and since infrastructure as a service has been around since 2003 when Lenode started then what benefit are we suddenly getting with this all these years later with

cloud native? Can we call this cloud native or does an application written to run this way qualify as cloudnative? When we look at the CNCF glossery for cloudnative apps and cloudnative technology, it basically says that the responsibility for this part really falls on the application side of the fence and not so much how it is implemented to run on someone else's It also rightfully points out that

there is no onesizefits-all approach to this, which then means there can be a fair bit of room for interpretation. I can look through this and pull out points to be like, yeah, that architecture is cloud native. And I can just as easily pull out points to say, no, it isn't. So instead of chasing our tails here and embarking on this endless debate, let's go back to the

DNA of cloud native. Recall that containers and the 12 factor app principles seek to give an application portability by loosening its tight coupling to an environment. This is a tight coupling to an These are proprietary managed services specific to this one platform. And sure, you can loosen this coupling some by mixing in some open- source tooling and different techniques and so But regardless if an application depends

on platform specific proprietary services, regardless if you've chopped up and containerized it, it is not portable. It is written to run on just this platform. Therefore, I think this would be more appropriately called, in my opinion, platform native. And this is perfectly okay if this works for you. There's nothing inherently wrong with this. It does come with some of the benefits. It does give you ondemand resources

that you can scale out at least within its boundaries. And yes, cloudnative technologies such as Kubernetes can easily integrate with But when your use case or needs for scale or cost of ownership or any other number of factors push you to move beyond this boundary. Most of the time to unwrap from this requires refactoring which then lends itself to scenarios where you cannot make high impact changes

frequently and predictably with minimal toil. And furthermore, when I read this definition, if I read this out of context, if I didn't know what this was, I would think this is just coffee room DevOps talk. This is a DevOps conversation. It's got some elements of culture and operational strategy and technical implementation. So then is this to say the cloud native is nothing more special than we brought

our DevOps to someone else's service? No. Because of this DNA, it is DevOps practices alongside the 12 along with the right once run anywhere nature of containers in tandem with orchestration systems to scale and manage it. It is the adoption of open-source software, declarative coding patterns and execution environment portability. It's the whole paradigm. All of it. And I think we can all agree that abstraction is a

big part of this. So then that begs the question, what level of abstraction? Because to carry these genetic traits, if you will, and squeeze the full potential out of this paradigm, that abstraction has got to be more than just someone else's service. The abstraction needs to be the cloud as a whole. The application should need no knowledge or concern of whose servers or what platform it's running

on. And since that responsibility evidently falls on the application, the application needs to be built that way. It needs to be built to be cloud agnostic. And that is my opinionated stance on what it means to be truly cloudnative. And if you've got other opinions or debates or hot takes, I'm also very open to being educated from any of y'all. That's it.