What does it mean to be Cloud Native?

In my role at IBM as a hands-on architect, I have been working on client projects involving Cloud since around 2013. Cloud-Native is no longer a buzzword, or at least it shouldn’t be. In speaking with my clients and fellow practitioners, I find that everyone seems to have a little bit of their own definition of Cloud Native.

“Stop what you’re doing and text ten of your colleagues. Ask them to define the term “Cloud Native”. Good chance you’ll get eight different answers.”

- Defining Cloud Native, Microsoft Docs

There is no shortage of material on this topic. Just google, “what is cloud-native.”

There is some excellent material out there. I’ve included a few that I found to be particularly good reads in the references section below.

My goal with this article is to share in some detail my point of view on what Cloud Native means, how to build net new greenfield applications as Cloud Native, and how to modernize existing legacy brownfield applications towards Cloud Native. My point of view has been shaped by my many client projects, my fellow practitioner colleagues, and the many experts in this space whose works I have read.

The Official Definition

The Cloud Native Computing Foundation (CNCF) is a Linux Foundation project that was founded in 2015 to help advance container technology and align the tech industry around its evolution (Wikipedia). The CNCF has defined Cloud Native as follows:

“Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.”

In his book “Migrating to Cloud-Native Application Architectures”, Matt Stine spends a fair amount of time discussing the Cultural Change and Organizational Change necessary to be successful with a. Cloud-Native journey. When asked about the exact takeaway of cloud-native from an architect or developer viewpoint during an InfoQ interview at an O’Reilly Architecture conference, Matt had the following response:

“So the thing that I’m calling “cloud-native” is the convergence of a lot of different ideas that also happen to coincide with a lot of companies trying to move to the Cloud. The ideas include DevOps, continuous delivery, microservices, agile infrastructure, Conway’s Law, and reorganizing companies around business capabilities. There are a lot of things going on, and cloud-native happens to be a common name that I and some others are applying to it. If there’s one takeaway from the book, it is that the vast majority of what I talk about is around people, organizational structure, and culture change. And there’s a little bit of technology sort of mashed in there with it.

It’s kind of strange to be talking about cloud-native architecture and spending all of your time talking about people, but it really is a fact that this type of architecture really only works if you change your company to facilitate it working. And when you do so, then the architecture is going to give you a lot of benefits to go along with sort of that reorganization. So I think the main takeaway is that this trend is not solely or even principally a technology trend. It’s primarily a cultural and organizational change trend.”

So, Cloud Native is more than just the technology view. The technologies and architectures necessary for Cloud-Native require a change in traditional ways of working. Here is how I’ve described the key elements of Cloud-Native to my clients:

1. Cloud-Native applications take full advantage of the on-demand self-service characteristic of the Cloud for speed. Cloud-Native applications leverage the fact that the Cloud provides on-demand self-service provisioning of compute, network, and storage to achieve speed; speed to market and speed to experiment with new ideas. They can spin resources up quickly and tear them down just as quickly. They can wipe out their entire application setup in the Cloud and recreate it identically in a matter of seconds and minutes. Everything in Cloud is disposable and should be treated as such. When dealing with traditional non-cloud infrastructure, this was not the case. You didn’t want to get rid of anything because of the time and effort it would take to get it all back.
2. Cloud-Native applications take advantage of the elasticity of cloud resources for scalability. Cloud-Native application take advantage of this elasticity to be auto-scalable, i.e. to horizontally scale-out when under load and to scale-in when the load diminishes.
3. Cloud-Native applications choose to leverage Cloud services as opposed to building their own or hosting their own. Applications require services such as caches, databases, messaging, etc. All leading cloud providers offer these as a service such a Redis as a service, MySQL as a service, RabbitMQ as a service, etc. Cloud-Native applications prefer to use these fully managed services provided by the cloud service provider as opposed to deploying and managing their own service.
4. Cloud-Native applications are architected in such a way to tolerate failures in the underlying Cloud infrastructure to ensure resiliency. Public clouds rely on commodity hardware. Lots of commodity hardware. Failure is inevitable. Cloud-Native applications are architected to tolerate failure in underlying cloud infrastructure components. Several resiliency design patterns are employed to ensure fault tolerance, and that failure is isolated, i.e. the blast radius is contained. Modern architectural styles that are inherently better resiliency characteristics are used. Techniques such as Synthetic Monitoring connected to Automated Runbooks resolve potential incidents.
5. Cloud-Native applications leverage modern architectural styles, modern SW engineering practices, and new ways of working that enable agility in delivery and ability to scale the development teams while maintaining the quality of the SW delivered. Leveraging small full-stack autonomous teams that have end-to-end ownership and accountability of a business capability/product, i.e. a vertical slice. Being able to add many such full-stack autonomous teams, each responsible for their own vertical slice, is necessary to accelerate delivery. A culture of automation, CI/CD, and DevOps enable a level of automation needed to achieve a high deployment frequency. Practices such as Test-Driven. Development (TDD), automated testing, and Pair Programming ensure quality that helps keep failure rate down.

The Benefits of Cloud Native

Given the above five essential elements of Cloud Native, the benefits of Cloud Native should be clear. They are:

1. Speed
2. Scalability
3. Resiliency
4. Agility

These are the benefits realized by the specific application. What I have found is that organizations to move towards Cloud Native have better-engaged developers and can attract and retain some of the best talents.

What does this mean Architecturally?

The CNCF definition kind of eluded to an architectural view of Cloud Native. Most opinions out there, including mine, agree that at the highest-level Cloud Native applications follow a Microservices Architectural style, run in Containers (typically Docker) orchestrated by Kubernetes, and leverage a Service Mesh like Istio. Yes, there will be aspects of Event-Driven Architecture, and yes, there may be some Serverless, etc. But at the highest level, it is Microservices, Containers, Service Mesh, and Kubernetes. That is a good starting recipe for Cloud Native.

Microservices fit the Cloud Native bill really well. Microservices do one thing and only one thing. They do it really well. They have well-defined interfaces. They manage their own data. They can be scaled independently. They have their own CI/CD pipeline. All of these tenants allow teams that build a vertical slice of the business capability to work independently and work fast, hitting the mark om speed and agility. Resiliency design patterns such as Circuit Breakers stop calls to services that might be experiencing problems, thus preventing cascading failures.

Tenants of the Microservices Architectural Style

I won’t go into any detail on Microservices, Containers, Service Meshes, or Kubernetes, as that was not the purpose of my article. James Lewis and Martin Fowler introduced the idea of Microservices in March 2014. Since that time, we collectively as an industry have gained a lot of experience with Microservices, and much has been published. Sam Newman has a couple of great books on the topic; Building Microservices and Monolith to Microservices.

The Twelve-Factor App

We cannot talk about Cloud Native and not bring up The Twelve-Factor App. The 12-factors are a great starting point for characteristics of Cloud Native applications that take advantage of the Cloud platform and behave nicely in the platform. The Twelve-Factors can be found here: https://12factor.net. I am listing the 12-factors below for easy reference.

1. Codebase — One codebase tracked in revision control, many deploys
2. Dependencies — Explicitly declare and isolate dependencies
3. Config — Store config in the environment
4. Backing services — Treat backing services as attached resources
5. Build, release, run — Strictly separate build and run stages
6. Processes — Execute the app as one or more stateless processes
7. Port binding — Export services via port binding
8. Concurrency — Scale out via the process model
9. Disposability — Maximize robustness with fast startup and graceful shutdown
10. Dev/prod parity — Keep development, staging, and production as similar as possible
11. Logs — Treat logs as event streams
12. Admin processes — Run admin/management tasks as one-off processes

Building new Cloud Native applications (greenfield)

Building a net-new application as Cloud Native is relatively straightforward. Just enough Architecture and Design, 12-factors, Domain-Driven Design (DDD), Event Storming, Microservices, Containers, Service Mesh, Kubernetes, small autonomous full-stack squads responsible for vertical slices, i.e. end to end business capability, Test Driven Development (TDD), Pair Programming, DevOps, CI/CD, automated testing, resiliency patterns, health checks, synthetic monitoring, runbook automation, etc. etc. etc. I am in no way suggesting that building good well-architected Cloud-Native greenfield applications is easy. I am only pointing out that it is easier when you have a clean slate to work with.

Over the last little while, I have been primarily focused on the Financial Services Sector and Retail Banks in particular. I find it a luxury to get to work on a net new application development project. What I encounter way more is the modernization of existing legacy applications that are a decade or two old that have gathered a lot of technical debt over the years as a result of adaptive maintenance. These applications are critical to the operation of the Bank, and there needs to be a plan of what to do with them.

Modernizing existing legacy applications to Cloud Native (brownfield)

Large enterprises like the big Banks have thousands of applications. Sometimes as many as 3 or 4 thousand. As part of a journey to Cloud, in most cases, an application portfolio analysis is necessary to determine what to do with the applications in the portfolio. This portfolio analysis is a time-consuming exercise, requires subject matter experts of the applications, and can be improved/accelerated by leveraging tools. At the end of the analysis, there will be some applications that we:

• do nothing to and just leave alone,
• retire as they are not needed anymore,
• consider replacing with a SaaS offering,
• lift and shift as-is to the Cloud,
• modernize to cloud-native

The do-nothing, retire, and replace with a SaaS are easy to understand. The Lift and Shift, a.k.a. Rehost approach is one that I’m not a big fan of. This is when we make little or no changes to the application and lift and shift it to the Cloud. It is typically a VM to VM type of a move. There isn’t much business value to be gained. The application remains the same. Any issues the application may have had, move with it. The business gets no new features/capabilities. It is a like-for-like move. This is not Cloud Native. Having said that, I have been involved in a couple of lift and shifts. These had compelling reasons for doing that. Avoiding the cost of a significant data center hardware refresh, for example, can be a pretty compelling reason.

Containerization is also typically an approach. Keep in mind that just because you managed to force your legacy monolithic application into a container and run it in a cloud platform doesn’t make it cloud-native.

The modernize to cloud-native is the pattern that I find yielding significant benefits. The benefits are not just from an application perspective but also from an organizational and culture change standpoint. My experience has been that the technology part usually turns out to be the easy part. The culture and people part is the problematic parts.

Clients want to see value from their modernization efforts quickly. They don’t want to modernize the entire app and do a cut over from legacy to modernized. They want to see incremental value as the modernization effort progresses. Kyle Brown has published a great article on applying the Strangler Fig pattern to strangle the monolith to Microservices incrementally.

In Summary

The mind map below summarizes what it means to be Cloud Native.

Cloud-Native Mind Map

I am always happy to receive comments and feedback. If you feel there are other essential elements of Cloud Native that I have missed, I’d be glad to learn about them.

References

1. “Defining Cloud Native”, Docs.microsoft.com, 2020. [Online]. Available: https://docs.microsoft.com/en-us/dotnet/architecture/cloud-native/definition. [Accessed: 17- May- 2020]
2. “Cloud Native Applications”, Ibm.com, 2020. [Online]. Available: https://www.ibm.com/cloud/learn/cloud-native. [Accessed: 17- May- 2020]
3. “What is cloud native?”, Cloud.ibm.com, 2020. [Online]. Available: https://cloud.ibm.com/docs/cloud-native?topic=cloud-native-overview. [Accessed: 17- May- 2020]
4. A. Wiggins, “The Twelve-Factor App”, 12factor.net, 2020. [Online]. Available: https://12factor.net. [Accessed: 17- May- 2020]
5. “CNCF Cloud Native Definition v1.0”, GitHub, 2020. [Online]. Available: https://github.com/cncf/toc/blob/master/DEFINITION.md. [Accessed: 17- May- 2020]
6. “Cloud Native Architectures — a Conversation with Matt Stine”, InfoQ, 2020. [Online]. Available: https://www.infoq.com/articles/cloud-native-architectures-matt-stine/. [Accessed: 17- May- 2020]
7. M. Stine, “Migrating to Cloud-Native Application Architectures”, O’Reilly Online Learning, 2020. [Online]. Available: https://www.oreilly.com/library/view/migrating-to-cloud-native/9781492047605/. [Accessed: 17- May- 2020]
8. M. Fowler and J. Lewis, “Microservices”, martinfowler.com, 2020. [Online]. Available: https://martinfowler.com/articles/microservices.html. [Accessed: 18- May- 2020]
9. S. Newman, “Building Microservices”, O’Reilly Online Learning, 2020. [Online]. Available: https://www.oreilly.com/library/view/building-microservices/9781491950340/. [Accessed: 18- May- 2020]
10. S. Newman, “Monolith to Microservices”, O’Reilly Online Learning, 2020. [Online]. Available: https://www.oreilly.com/library/view/monolith-to-microservices/9781492047834/. [Accessed: 18- May- 2020]
11. K. Brown, “Applying The Strangler Fig Application Pattern to Microservices Architectures”, Medium, 2020. [Online]. Available: https://medium.com/ibm-garage/applying-the-strangler-fig-application-pattern-to-microservices-architectures-e9a03321a1b9. [Accessed: 19- May- 2020]