Hi, this is Jonathan Smith, director of field engineering and education for cloud native applications. Today I wanted to provide a little bit of framing around cloud native in order to define what modern application development and cloud native application architectures is really all about. And so first, let's start with just defining cloud native itself.

So what is cloud native? If you ask 10 people the definition of cloud native, you're almost certain to get 10 different answers, and that's both reasonable and expected. There are lots of ways to approach the question depending on your perspective. And many definitions that I have heard focus on specific technologies. Microservices, containers, or perhaps infrastructure automation. Other times, definitions may focus on the ability for, uh, to move fast or to build applications that are more resilient and able to change quickly. And all of these definitions are correct. However, let's draw a few definitional boundaries, uh, around this, um, and we'll get to, uh, some, some pretty interesting conclusions about where cloud native is and where it's going.

So be forewarned, the cloud native space is both deep and complex. And as we start to explain some elements, we'll pull on a thread and that may begin to unravel many other things. But hang in there, we'll take a layered approach and put some of the important pieces together one at a time, uh, and hopefully it will make sense, uh, over time.

And as I mentioned, there are many definitions, but the definition I tend to lean towards the most is this one by our own Joe Beda, and that's that cloud native applications are applications that allow you to take advantage of the unique capabilities of the cloud. And I like this definition for cloud native, uh, itself because it isn't focused on specific technologies and it will evolve as the cloud itself evolves. And new capabilities that we haven't even thought of yet become available.

But to understand what unique capabilities are provided by the cloud, however we must understand what is the cloud itself. And in its simplest form, the cloud is simply running on other people's infrastructure. Uh, you're trading ownership to be a renter and one of the, the reasons that you may do that is that in scenarios where the cloud provider is better at managing infrastructure than you are, uh, you want to transfer that management responsibility and risk, uh, to them. An asset light technology business model, if you will. And while [inaudible 00:02:41] are, you know, have been around for quite some time, they manage infrastructure for a fee, uh, the cloud is different in that not only have you transferred the management responsibility to the cloud providers, uh, but the cloud providers are also providing some unique capabilities that [inaudible 00:02:57] did not, uh, provide. Or at least not, uh, in, an sort of a broad, successful manner.

So let's talk about what some of those unique capabilities of the cloud are. And first, let's talk about self-service. So just like no wants to, you know, call a restaurant to talk to an actual human to order food and wait in a queue for, for delivery, developers want to be able to provision their own infrastructure when they need it, uh, and get that instant satisfaction. Uh, prior to the cloud, most resources were provisioned through ticket-based systems where it could take weeks or even months to get a new server or even change a firewall rule. However, in the, you know, self-service model, changes are instantaneous and they can be made by the teams that actually have the problem.

Another benefit is that the cloud provided an API-driven model. So application programming interfaces allow for application developers to programmatically interact with the infrastructure environment and treat infrastructure as code. So not only can they make self-service changes, but can automate the control of that infrastructure. And of course, you know, this concept goes beyond just the API's for the infrastructure, the applications we're building are now designed in a similar manner. They're loosely coupled and dynamically composed of components that may run on different infrastructure and different languages and, and even be geographically dispersed. But we'll, we'll talk about that a lot more later.

Another good benefit, uh, uh, or unique capability is elasticity. By allowing infrastructure to be provisioned by developers and programmatically accessible by the applications or the underlying infrastructure management layer, applications can be scaled up and down to fit the need of the system or the user load. And that's a unique capability and a great benefit to, uh, this approach.

So again, what is cloud native? So, when we talk about cloud native, uh, from a, from a technology perspective there's a couple of streams that really come together. One is something that we refer to as DevOps. And DevOps, while it's often thought of as simply infrastructure automation, it's really a new way of thinking about infrastructure as code.

And continuous integration and continuous delivery, uh, is another really important topic and that's how do we start to repeat things that we do frequently in an automated way so that the mistakes that, you know, may have been made in the past manually are now, you know, no longer possible because everything, uh, is designed to be tested and deployed, uh, in an instantaneous fashion so that we can take advantage of some really, uh, new capabilities there.

And of course microservices, uh, is an important way of thinking about taking a large application, breaking it into smaller pieces and, and how that gets manifested is, is often referred to as microservices.

And finally containers themselves. So containers, of course, allow us to package our applications and their dependencies and this makes for some significant improvements, uh, in how we can do even DevOps and CI/CD and, and build microservices in a successful way. So this is a little bit of a deeper view. You know, DevOps is often viewed as the tooling. But the reality is is that DevOps attempts to align the goals of developers and operations teams.

Historically, developers were rated on pushing features and operations folks were rated on up-time. And these two things are clearly in conflict. Aligning both teams to customer-centric goals creates a new way of thinking about managing infrastructure. Of course, this was possible due to the self-service and API-centricity provided by the cloud. It's not required, but certainly makes it a lot easier and a lot better. And continuous integration and continuous delivery fits into the cloud native story because building, testing, packaging and ultimately releasing software is much simpler with cloud native architectures due to some of the next two, uh, things that we'll describe here.

And the first is microservices. So taking a complex application, breaking it down into smaller components requires communication between applications to take place between API's. By breaking apart your application into smaller components that can be deployed independently, uh, it allows for application updates and scaling to take place at the component level instead of the broader application level, Which makes it easier to develop features by limiting the potential impact to the overall system of change. And containers of course make microservices architecture easier because by breaking apart a large application into smaller components, you've now increased the complexity of managing that system.

Containers allow you to package your applications and their dependencies together, which makes the process of really delivering these microservices type applications much simpler and much easier. And so to be clear, cloud native doesn't necessarily mean running on the cloud or in the cloud. But again, it's, it's about taking advantage of the cloud capabilities or the unique capabilities of the cloud which includes bringing those capabilities to the on-premises data center. So cloud native is not something you buy, but something you do, uh, it's, it's not somewhere you deploy your application but, uh, again, uh, something that you operate on as an organization.

And by being able to build and deploy systems faster with higher quality, we can be more agile as a business. We can take more chances to satisfy our customers' needs and really win in markets where we weren't able to win before. Cloud native technologies also allow us to be less dependent on a single vendor. Cloud native application should be a lot easier to migrate, uh, because it leverages some pretty standard, uh, underlying technologies and patterns from a delivery perspective.

And we also must consider that we can exploit the ability to burst our application from on-premises to the cloud or run the application fully in a cloud model, which gives us a new way of thinking about managing costs so that we can align spending with the success of our application or our product, uh, which can reduce risk. And all of these advantages allow us to tackle new business opportunities with less cost and risk and perhaps even support customers where solutions, uh, you know, were not possible or cost-prohibitive before.

And so that concludes part one, uh, which hopefully provides a good bit of background around some of the motivations behind cloud native and at least one definition of cloud native. And in future, uh, sessions, we'll describe a lot more. Thank you for your time.