Don’t Put Cloud Native in a Box: The Philosophy and Technology of Building Cloud Native Applications

Don’t Put Cloud Native in a Box: the Philosophy and Technology of Building Cloud Native Applications

Cloud computing has rapidly evolved from a niche solution to become the de-facto technology used by businesses large and small. However, many workloads that currently run in the cloud aren’t written to be “cloud native”. These workloads may utilize various public cloud services available to be consumed by the hour or megabyte, but true cloud native applications are still relatively few and far between.

In fact, there are still a lot of misconceptions when it comes to cloud native applications. It’s often assumed the term refers to “containers” and “containerization” and even the media sometimes makes one analogous to the other.

Cloud native is a philosophy for building applications designed for continuous change and improvement. It’s about creating loosely coupled systems for public cloud and systems that are architected to run in an elastic and distributed nature.

My colleague, Tim Shackleton, Sr. Product Manager – Public Cloud, and I, would like to present three philosophies and three technologies that together encompass “cloud native” today.

1. The Philosophy of Agile Development

Agile redefines the concept that developers need to know all the requirements of a development project before they start coding. It removes process barriers and enables key stakeholders – developers and customers/end-users – to collaborate more quickly to accelerate delivery and meet evolving requirements as the project progresses.

Agile encourages constant, iterative change to deliver code faster, and encourages large monolithic applications to be broken down into small interlinking components.

2. The Philosophy of DevOps

DevOps, as the name implies, takes the best of development and the best of operations and combines the philosophies, practices, and tools from both to shorten and de-risk the development life cycle.

A DevOps model brings together development and operations teams so when new code needs to be deployed, it isn’t simply “thrown over the fence” from development to operations. Rather than using two discrete teams, one combined team is responsible for software development, deployment, and operations.

3. The Philosophy of CI/CD

Continuous Integration / Continuous Delivery (CI/CD) focuses on software-defined lifecycles and automation.

CI/CD streamlines development and deployment phases and, for example, can be used to test microservices and create containers more rapidly.

CD, in and of itself, can help businesses become closer to customers, which in turn, can create more reliable, robust, and scalable applications. Common CI/CD technologies include Jenkins and GitHub. 

4. Serverless technology

IT is gradually becoming more developer-driven, and in doing so, is moving away from an infrastructure-led approach. Increasingly, developers can deploy what they’re building without the input of infrastructure engineers.

An increasingly popular approach is to use serverless architectures such as AWS Lambda and Azure Functions. With serverless, organizations benefit from the same level of monitoring and source control as they would have with a containerized application, but without the high administration and maintenance burden that often comes with containers.

Serverless functions only execute when needed and run on a pay-per-execution model. In this sense, serverless is often suitable for event-driven applications with intermittent usage patterns. Scalability is also outstanding in serverless architecture and auto-scaling means that the environment can handle spikes more easily.

5. Microservices technology

Microservices, which structures applications as loosely coupled services, can be a huge asset to the cloud native approach, making apps easier to build, and perhaps more importantly, easier to expand and scale. The architecture possesses similar functional properties to serverless computing – that is, they can curb operational costs as well as the application deployment cycle.

Microservices are often best suited for longstanding, complicated applications that have high resource and management requirements. Existing applications can be migrated to a microservices architecture, which facilitates modular development and simplifies deployment to the cloud.

 6. Containerization technology

Containers give developers the ability to create predictable environments that are isolated from other applications and this offers flexibility through the ability to run on any infrastructure. Because it’s decoupled from the environment in which it runs, it is far less likely to suffer from bugs or configuration problems when it moves between devices.

The concept has been around for a long time, but only recently have open-source standards encouraged wider adoption. Plus, because containers essentially share the operating system with other containers, they are more lightweight and require less start-up time than Virtual Machines. Reduced resources mean lower costs in the cloud, and reduced start-up times means they scale more quickly.

Conclusion

As organizations increasingly adopt cloud, most are probably using some of the philosophies and technologies of cloud native applications described above. Fully embracing a cloud native approach has benefits and drawbacks. For many organizations, it probably involves re-architecting applications.

Unequivocally, there are huge rewards to be reaped when you choose the right approach and so it’s important to find a partner to act as a guide through these decisions to find the perfect solution.