What Is Cloud Native and Why Should I Care?

Today’s cloud native technologies:

1. Help developers build, test, and deploy apps faster

2. Reduce IT operations workloads

3. Increase application and platform resiliency, reducing downtime

And much more.

Let’s see how cloud native technology and strategies can make your life faster, easier, and smoother.

What does cloud native mean?

While often discussed in relation to hyperscale public clouds like AWS, Azure, and GCP, the term cloud native actually refers to more basic ideas. A cloud is a software-defined and software-directed environment for hosting applications. Inside a cloud, real-world resources – compute, storage, network, etc. – are allocated with software, and made available on demand to applications. 

The big deal with clouds is resource abstraction and software control. 

At the deepest level, the term cloud native refers to platforms that are architected to provide cloudy, software-defined and managed environments and services, and applications that are built to function optimally within such environments. In cloud native environments, deploying, scaling, fixing, updating, and lifecycle-managing applications is done quickly and safely, with code – even automatically.

What are some benefits of cloud native platforms and applications?

Defining, deploying, configuring, and operating platforms and apps using software has enormous and diverse benefits, including:

• Speed - Software is fast. So resources, platforms, and apps can be delivered in seconds or minutes by clicking on a webUI or issuing a CLI command. Developers can get what they need on the fly, without the help of administrators and with little red tape. Operators can deploy and lifecycle manage platforms and applications quickly with web UIs, command-line interfaces, and code.

• Reduced errors and risks - Using code to compose apps and configure platforms is better than executing manual steps from a recipe. Once code works (and is tested at scale) it can eliminate a lot of boring toil. And it tends to keep working unless software dependencies break it. (We’ll have more to say about dependencies below.) Code-based operations can incorporate policies and best-practices that ensure its outputs (platforms and apps, in this case) are resilient and secure.

• Simplified resilience - Redundancy and distribution – duplicating apps and critical systems (and distributing their components across multiple failure domains) to ensure availability – is much easier and faster to set up and leverage in software-defined cloud environments.

• Resource utilization efficiency - ‘On-demand’ resource allocation in software-defined environments means that apps can be scaled to match real (and changing) requirements of usage and/or performance. In practical terms, this usually means you can run many more apps and components on a given collection of cloudified hardware than you can on hardware accessed conventionally.   

• Automation - Probably most important, having software-defined platforms and applications means that applications can talk to platforms, platforms can talk to apps, and Ops can be made more autonomous. For example, in cloud environments, apps experiencing heavier-than-normal usage can talk to their platform and ask to be scaled. Platforms that detect faults in certain resources can relocate applications onto correctly-functioning hosts, or restart failing parts of an app that’s misbehaving.

What is cloud native software?

Back when physical servers were the basic unit of computation, it was traditional to design applications to fit on them. A so-called ‘monolithic’ application might combine a webserver like Apache, the web pages and scripts it serves, a back-end command processor like PHP, and a database like MySQL, on a single machine.

This introduced several problems, among them:

• Numerous dependencies, great complexity - monolithic apps frequently depended on specific versions of support software, operating system versions, and other details, all of which needed to be installed and configured when an instance of the application was deployed, and needed continual reassessment as applications were evolved – most frequently as units. Normal operations tasks, like automated OS updates, frequently broke these highly-interdependent and complex software aggregations. Once broken, manual fixes could be difficult to figure out, error-prone to implement, and difficult to keep track of.

• Making such applications scalable and resilient was quite difficult - Creating resilience often meant adding even more software. Protecting a critical shared database, for example, might require adding ‘clustering’ software enabling the database to be mirrored across different fault domains, and failures detected and compensated-for.

Development of virtualized servers helped, but as long as single ‘server-like entities’ remained the basic unit of computation, architectures – at least architectures of software designed to reside on virtual hosts directly – tended to remain monolithic.

Container technology – that is, Docker – revolutionized all this. Containers let you package application software with all its dependencies, and let you run that software on any host that provides a compatible container ‘engine.’ Containers communicate with the engine and platform hosting them, and with other applications and components using narrowly-defined ports and methods. So it’s relatively easy to write apps as flocks of containers that use platform services to find each other and coordinate.

The growth of containers as the basic unit of computation has ushered in an era of new, so-called cloud native application architectures. Cloud native apps tend to have many small, simple moving parts, each a containerized application in itself – sometimes called a ‘microservice.’ Microservices are classically ‘stateless’ – performing a simple function in response to a request, and using no local storage to maintain state, so they are easy to load-balance.

Truly cloud native modern apps are mostly built from collections of small parts, and the benefits are again enormous, among them:

• Cloud native app components can be updated asynchronously and reused - As long as API and interoperability criteria are adhered-to, you can update the parts of a microservice-based application independently of one another without breaking the application. Containerized microservice functionality is easy to reuse in more than one application.

• Cloud native app components can be scaled quickly - Stateless microservices are easy to scale (just start more container instances of the function, make sure other parts of the app can communicate with them, adjust load-balancing, and start sending them traffic), and cloud native container-oriented platforms like Kubernetes come with built-in functions to help make this automatic.

• Cloud native app components can be made resilient automatically - Cloud native container-oriented platforms like Kubernetes are inherently resilient, can be configured to automatically distribute critical application functions/containers across failure domains in many different ways, can detect application-container failures and restart containers, and can detect node failures and relocate application containers to working hardware – all automatically.

While converting apps from monolithic to cloud native footprints isn’t always simple, adopting cloud native methodologies helps developers be much more productive, and makes apps that run better and are far easier to care for by operators.

Can you be cloud native without public clouds?

Amazon, Microsoft, Google, and others have developed software that turns large data centers filled with physical hardware into clouds, and they rent this capacity, along with various services, to customers on an as-needed basis (also called ‘on-demand’ and ‘as a service’).

That has advantages for some use-cases – for example, you can have the benefits of hardware without the capital expenditure or work of housing it. For other use-cases, it’s a less-perfect fit – for example, when sharing hardware with many other customers, it can be difficult to know for sure that things are perfectly secure, and working effectively with major public clouds typically requires a lot of knowledge about their proprietary software architectures.

But that’s not the only way to get to a cloud native platform. Given the right software – which these days is mostly open source – you can build your own private cloud on data center hardware. You can also rent ‘bare metal’ from hosts like Equinix and achieve the same result – effectively a private cloud – without the capital expenditure, facilities, and operating complexity.

The problem with all these methods, though, is that getting to a functioning cloud means learning a lot about cloud operations and staffing up to architect and manage cloud platforms – little of which is directly relevant to building and operating the applications that make your business stand out from competition.

Learning more about cloud native technologies

Many resources exist to help you learn more about cloud native best-practices and underlying technologies. A great place to start is our Cloud Native Cookbook, which collects definitions of important cloud native terminology and tutorials on the major components of the cloud native technology stack, like containers and Kubernetes.

• Learn more about cloud native technologies

• Learn more about Docker and containers

• Learn more about Kubernetes

• Learn more about accelerating cloud native operations

Or Download Mirantis Kubernetes Engine or K0S – zero friction Kubernetes.