From Cloud Naive to Cloud Native at Cloud Native Now 2024

Hello everybody. Welcome to this talk about, uh, cloud naive to cloud native. This talk is a bit of a personal journey, uh, of mine, and it's also reflective of hundreds of conversations that I've had in the community with people who have made the same sort of transition from technology to technology between different technology waves, past present, not to mention new ones that are to be expected in future.

My name is Ram Iyengar. I currently serve as the chief evangelist for the Cloud Foundry Foundation. Now, cloud Foundry, as a lot of you might know, has been involved with several technology waves in the past.

And today we are navigating this rather uncertain space between staying true to our roots in the VMs world and being entrenched in sort of Cloud foundry on VMs and taking a foot and stepping into this world of cloud natives and looking at Kubernetes as the least common denominator for infrastructure out there. We can't help ourselves, but build community led versions of Cloud Foundry and bring that familiar Cloud Foundry experience for developers and operators on Kubernetes too. So my journey with the Cloud Foundry community influences a lot of what I'm going to say today.

But then, you know, c is huge and there's tons of people out there who've tried so many different things that I speak to. And like I mentioned, some of the conversation is also going to, you know, be inspired by that. I find that the community of, you know, human technologists are always butting heads against new technology waves.

We can't help that. A lot of hype gets created every time we listen to something new that's coming up. It's a lot of it is gen AI right now.

Gen AI right now. A lot of it was blockchain sometime ago, not in the very distant past, um, in the middle, you know, there was a lot of peppering of serverless and, uh, stuff like that. Now, I love how far computing has come.

Um, vacuum tubes, I've only read about them, never used them. Um, never seen computers, you know, that claim to be as big as, uh, you know, drawing rooms, maybe even bigger. Uh, transistors replaced vacuum tubes, but computers, you know, didn't get small complexity, certainly didn't get small.

Um, a lot of very fancy looking computers that I have seen in museums, uh, come from the sixties and early, late seventies even sometimes. And, and those were all about, you know, being networked and pushing computers to the era of not being just a standalone compute device, but a network device and raking the power of the entire network. And then the whole notion of client servers and having servers that are centralized and available for compute, for storage, for a lot of the heavy lifting, uh, was a paradigm that really dominated, uh, the time between the eighties and the nineties.

And the internet boom sort of really took off with, you know, consumer applications and, uh, office applications and applications for pretty much everyone starting to emerge. That was based on what was then defined as the internet. We were, we, we emerged in the data center era and virtualization started to take over, uh, stuff like infrastructure as a service is platforms as a service, and software as a service is started to emerge much after.

Now today, containers dominate the market. We, we all talk about containers, we all talk about container orchestration, and that's sort of the world that we currently find ourselves in, but we still don't have a very clear definition of what cloud native is, which I'll get into it just a bit, but I thought I'll clarify the definition for the cloud before we moved on to trying to define what cloud native is. Now, when we say cloud, most people think of a very fuzzy, uncertain space, somewhere in the deep dark woods of the internet that basically has either compute or some services or some API endpoints they can connect to or some storage, what have you.

So the cloud is really a very fuzzy entity for a lot of folks, which I generally believe that somewhere out there is some compute power that I can derive strength out of cloud native is very different from this notion of just the cloud. Why, because cloud native really set about to define a new paradigm of the way engineers, software engineers thought of applications and the way they thought about all of the things surrounding an application in order to make it complete and usable. Now, cloud native really starts off from the point of containers.

It relies heavily on open source, and it basically has to be running on immutable infrastructure designed as microservices and should be, you know, accessible to a lot of folks as containers. So that's my definition of what cloud native is. Now, you could have been on the cloud consuming some kind of services, but translating them into cloud native has been much more of a challenge than coming from servers onto the cloud and then moving on to cloud native.

So the first transition seems fairly easy in retrospect. Then the second transition from cloud to cloud native. Now let's examine what an application stack looks like in order to make this definition slightly more clear.

Now, what you see in front of you is a very rudimentary set of blocks that kind of define what an application used to look like or how far down the turtles went. So it's fairly self-explanatory. I'm not going to get into the details of this.

Now, what happened was, along came this notion of virtual machines that kind of defined a new abstraction for the way we thought about the operating system and everything that lay below it. Years later, the container ecosystem came up. Um, in retrospect, it, it was always LXD containers were always available, but the container ecosystem came along and kind of redefined the way we thought about how operating systems and the hardware beneath existed.

Now, after the container ecosystem came along, the challenge was that a lot of things that were written specifically for using operating systems and what was beneath it had to be re-architected to work with a container. Now, you had, you never had this notion of treat your servers like catalysts and not pets. So that's the statement that merely redefines what it means to be container native or cloud native.

And it was about re-architecting all of the applications in a way that took advantage of the container ecosystem beneath it. Now, even applications were constantly evolving, or what we call an application is actually business logic. And around it, there's tons and tons of different tools and, uh, different technologies that really need to come together in order to make an application function and be accessible and available to developers or users, what have you.

So this in entirety, what you see right now are all of the different blocks, in my opinion, that are required to make a single application layer function, or it goes through the topmost to sort of the pseudo bot most layer. Uh, now as we started to do this, there was a parallel set of movements, uh, called Agile. And Agile became sort of the DevOps movement, and it, it, there was a lot of rediscovery in the, in the way we looked at software and the process that it took for software to turn from an idea into an application that was, uh, actually running and helping people accomplish things.

And in that transition, what we discovered was there were so many of these little stacks that we had to define for so many different pieces of software. There had to be a stack that was functioning, that made version in control happen. There had to be a stack that was functioning, that has to make CI happen.

Like you want to integrate your software continuously, and then for CD you had a separate and independent stack. And so as we started to write more software and rely on more software, what happened was there had to be more and more stuff that was running, and life did not become simplest, but only more complex and enter this very interesting current, um, rather hyped up technology called Kubernetes. And, you know, Kubernetes was supposed to solve everything, right?

I mean, Kubernetes by design is intended to solve this one small particular piece of the stack, which involves bin packing, which is placing the containers in the right formation, uh, so as to utilize compute in the most optimal way, scheduling a lot of containers for using the compute and the infrastructure beneath it. And in the event that a container went down, spinning up a new one in its place and making sure that applications are reliable, this is all that Kubernetes was designed to do. But Kubernetes has had a disproportionate impact on the way we think about applications, and it has really spawned this movement known as cloud native.

Now, you not, again, the definition according to me for what it take takes to be cloud native, is you have to be open source, run on immutable infrastructure and use declarative paradigms. You have to be microservices defined, and you have to take a container first approach. And so all of this together, according to me again, um, is, is what really means to be cloud native.

Now, I want to go to my next section of the talk where I illustrate this transformation of moving to cloud native. So there's ways in which you can accomplish all the stuff that we are going to talk about in a manner that's not quite cloud natives, but there's also a way there's an alternate to doing this within the cloud native ecosystem. And we are going to pick each one and sort of contrast the different approaches and see, you know, what might suit a team of engineers better than the other.

The first thing I want to talk about is a cloud native, um, computing foundation project. Oh, in fact, all of the technologies that I'll be talking about right now are, you know, obviously open source and in the public domain, but will largely belong to the CNCF ecosystem. Um, 'cause that's, that's, uh, that's really what we are here to, uh, talk about, right?

So the first project that I'll sort of, um, touch upon is what is known as Build Path. Uh, the Brave Packs have a history. They were envisioned as a way to create an artifact that can be deployed in Heroku.

Now, if folks don't know Heroku, you're probably 22 years old, you just finished college. But Heroku back when I saw it in 2012 for the first time completely transformed my life. It, it changed the way I thought about applications.

It changed the way I thought about deploying an application, and it changed everything, um, that I had written in the form of make files and other things I use, uh, for deploying applications that I wrote. Heroku was able to package any app that you sent. Its way by detecting the language in the family itself, creating that immutable artifact depending on what the family of languages was and deploying it and adding ingress and helping load balance it and do all of this, uh, heavy lifting around an application that developers had to do by hand and cobble together and write separately, not right in fact, you know, sculpt it for production and maintain it and things like that.

And so in its checkered history, um, build like every good technology diverged and was split in the community in the way they were thought about, and two communities worked on it independent of each other. So the second version of Build Packs was about supporting two distinct communities, the community at Heroku who continue to do the amazing stuff that they do and the community of people who were known by different names. Uh, but it was pivotal back in the day, cloud Foundry was their main product that consumed Buildpacks and then, um, they had a whole ecosystem around it, uh, for different, uh, languages in families, much like the Heroku Buildpacks were.

But they were designed specifically for being consumed within the Cloud Foundry environment years later. Um, fortunately for us, uh, the Kubernetes community was instrumental in bringing the Pivotal folks and the Heroku folks together in order to create water, now known as the Cloud native bill packs. Now, cloud native bill packs are a way to create OCI containers, um, OCI being Open Container Initiative, which defines a set of standards for what containers are supposed to look like when you deploy them, um, to Kubernetes or to other container run times, I guess.

So that's the history of, you know, where build Packs began and what they're capable of. And the alternate to cloud native build packs in a cloud naive world is to make use of Docker. Docker is fantastic.

I have got nothing against them, but there's one or two limitations about Docker that are really resolved nicely by the Buildpack specification, and that's the reason I kind of love this technology known as Buildpacks. And I, and I love to speak about it and evangelizing now much like Docker containers, uh, build packs based OCI containers, so also come in layers. Um, but these layers are more individually addressable.

The build packs themselves are more composable and modular, which make them a slightly better alternatives to using Docker web builds. There are other alternatives to Docker build that I've seen. I've seen Build Kit, I've seen apco, I've seen a bunch of other tools that are capable of architecting container images, but what I like about Build Packs is the way they're more modular.

They're very focused on what, uh, different frameworks and different, uh, language families care to optimize. And, uh, there's a bunch of different, uh, bill packs families that are available for use in production. Now this is just an illustration of, uh, one kind of, uh, bill packs that are available known as Pato and pato are production ready implementations of the Bill Pack specification.

The PAC CLI is one way to consume, uh, bill packs. So if you wish to try this technology out, I highly recommend using it in place of any docker bill steps that you're doing right now. And so I guess in summary, the cloud naive way doing containers is to continue to use docker build and the cloud native way would be to explore what build packs are now build packs, work without metadata or met files known as such as Docker files.

Um, they have, um, they have no requirement for these additional Docker files that you need to write and maintain and, you know, maintain for a different environment. So things like that. So if you're keen to try, try the project out, I would recommend going to buildpack io and, um, seeing how you can get started.

PTO was among the first family of Buildpacks to be open source and production ready. Uh, and very recently, I think in CubeCon in Paris, uh, a few months ago, Heroku also opened up their ecosystem of AKs for everybody to use. So for build necessities, um, the cloud native way to go is to use ak.

The next project I'm going to be touching upon is known as Dapper. Now dapper is from the DIA grade stable. Um, if I remember the, the company correctly and dapper, there's a, there's a full form for dapper, um, application programming, runtime, what have you.

You can definitely check the docs, but why I chanced upon dapper and why I like it is because it provides a number of very key building blocks that you can use in order to alleviate a lot of trouble that developers typically have to go through. Now, in my opinion and in my experience, developers are constantly trying to create a bunch of different, I wouldn't say boilerplate, but they work in certain patterns. They, they tend to create, um, I mean, applications tend to have secrets, and so you need to have secret stores.

Um, they tend to require monitoring and observability. So you sit there and build out observability infrastructure, um, for every single application. So they can be instrumented.

There's, uh, there's different applications that do different kinds of messaging in different ways. And, um, you know, you need a pop sub broker for that. And a lot of applications are stateful and you need to create different parts of the application that take care of each of these different aspects as the application is built and is moved to production.

Dapper plays a very important role here where it provides a lot of these key components in a consumable and very easy way to integrate within an application. And so what Dapper does is gets your developers started at a level that's slightly higher than a zero. So they can already start writing applications that consume a pub sub broker, let's say.

And that messaging queue can very easily work with any messaging queue infrastructure that you have. And it gets connected through dapper. Now, dapper lives as a bunch of different sidecar on Kubernetes infrastructure, and it can create this sort of quick start, so to say, for developers who are looking for a way in order to get started with building applications and deploying them and so on.

Now, dapper has a really reasonably complicated infrastructure, thanks largely to the very complex problem that it solves. And these little dapper operators that I said will live on a Kubernetes cluster and they will deploy, they live as sidecars on the Kubernetes cluster, and they, they'll make use of these components and they'll make the components available for developers through a bunch of different SDKs for any language and, you know, uh, uh, a language family that they want to use. And that way Dapper helps speed up application development in a manner that's very consistent with, uh, you know, what the kind of speed with which cloud native technologies aim to allow developers to, you know, build and deploy, build and deploy.

And, and so a lot of velocity and potentially gain is available when using dapper in order to create these components as opposed to creating the drum scratch. Again, the cloud naive approach is to write every single component that your application needs from scratch and create deployments for them and manage these deployments just like you would manage the core application itself. Now with the, the cloud native way is to make use of dapper make use of a lot of the built in service discovery and component framework that's available and speed up application development and make your applications available much faster by using this cloud native tool that's available.

The next project that I'm going to touch upon is a cloud native, uh, favorite. Um, it, it, it's called cross plane. The company that really puts its weight behind cross plane, it's called Upbound.

I love the cross plane community for what they've achieved. Uh, so far. The, the entire vision of the cross plane project is amazing and it really, you know, amazes me how they've been able to step up and build something that's so loved by the community.

And, um, in order to understand what cross plane actually does, every sort of application out there is is a massive spread of so many other tiny little applications that, you know, live somewhere. And, um, all of these are composed as services and they all connect with each other. And then you have some applications or services that are specific for internal testing and some applications and versions that are specific for, uh, pre-production environments.

And then you have all of these different microservices that we love to get that all connect with each other and work in a very MI reputation and, and they're all not, you know, uniformly maintained and built and things like that. And this is the, I guess, cloud naive way to do things. And, you know, companies build themselves into this position.

It's definitely not that an engineer designed a mess by themselves, but oftentimes they just, you know, build themselves into positions that, uh, where they find themselves confused about, you know, what are the different technologies we are using and how we're we using them and what is it that we do so on and so forth. And cross plane aims to eliminate all of this sprawl and make managing all the services that are used by putting them in a control plane that can be triggered on Kubernetes using cross plane. What that means is cross plane defines what is known as a composite resource definition or an XRD.

Kubernetes has a concept known as CRD or a customer resource definition and cross plane sort of takes that and builds an abstraction over and above it. A basic idea is if the entity that you're interacting with has an API, which most certainly does because, you know, it's all services and distributed computing at the end of the day. So cross plane can connect with any API and execute sort of everything that an API endpoint can.

And you can create this execution using Kubernetes that has the same kind of declarative syntax that we all lost about Kubernetes. So you can define declaratively saying this is what you want a certain API endpoint connection or service to look like. And cross plane can make it happen because it runs on Kubernetes and because it functions deteriorated, we, and because it's a composite resource definition that lives on a Kubernetes cluster, it then becomes the responsibility of cross plane plus Kubernetes in order to maintain the state of that API and the data and the connection and the data flow in between just the way it would maintain, let's say, a pod on Kubernetes with the same kind of reliability and the same kind of, uh, declarative syn types that tax it.

So again, cross plan is a, the, the, the cloud naive way of doing this is to write different API consumers and maintain all of them as independent applications and things like that. And the cloud native way is to pursue a path using cross plane and writing composite resource definitions for everything that you'd like to manage. The next sort of project that I thought I'll touch upon very briefly is abstractions that can help navigate the cloud native space.

Now, as we all know, the cloud native landscape is massive and contains so many different projects and it's very hard to sort of find your way and choosing which projects are good for you, which projects are not. And there's a couple of tools out there that help make sense of this landscape. Now, two of my favorites are Radius, a tool by the Microsoft Open Source team, and the other one is from the Cloud Foundry community known as qfi.

Now qfi takes this notion of an abstract platform available to consume cloud native projects and it puts a whole bunch of different cloud native projects together there. So a developer has a very clear route from their code to it being a container and run on production. So this makes use of, um, contour for ingress, for example.

It makes use of kpac in order to build containers and it uses some Kubernetes stateful sets and a whole bunch of different CRDs which are designed in order to provide these ingress and other things. And, um, it can be integrated with any container registry like Harbor for example. And so I find Query Fi a very useful tool that can help me consume a lot of the cloud native technologies.

Instead of going the cloud naive route of putting all of these different tools together by myself by hand and getting them all running together, it's much simpler to go the cloud native route of picking a good platform that can help you consume your cloud resources. So this is a bit of a summary of my talk. So if you want to go the route of cobbling together, your own sort of, um, tool chain for exploring the cloud native technology, explore coup vanilla Kubernetes, try using buildpacks, put them in your current CICD flows.

Something slightly higher up the plane are tools like cross plane and dapper, which help your developers manage some parts very easily by themselves and also leave some others to abstracted or just make use of best practices by operators. But then if you want your developers to just focus on the programming and the application at hand, while you want a lot of the other cloud native technologies to be managed through an abstraction, then all of the CNCF projects come together very well when using Radius or query feed. So that's my talk today.

Um, it's really about two paths, something for the cloud naive and something for the cloud native ecosystem. Thank you so much, uh, tech Strong and cloud native now for having me for all your questions, comments, feedback. I'm available as on a lot of the different social media platforms.

Find me, connect with me, don't be shy, drop a word. I'm happy to get all this feedback. Thank you so much.

Bye.