Principles of cloud-native application development

The fundamentals of cloud-native applications are based on the four pillars as shown in the figure below.

A popular way to define Cloud-native applications is to consider the four fundamental pillars of DevOps, microservices, containers, and continuous delivery. Each of these pillars refers to a specific aspect that is relevant when building modern Cloud applications, ranging from development mindset, to technologies that act as key enablers for developing cloud applications with certain desired qualities. In this unit, we explore each of these pillars in detail to understand how we can build cloud-native applications in a better way.

Containers are the third pillar of building Cloud-native applications. Containers offer are a lightweight approach to running multiple processes in an isolated and specifically restricted way on a single hosting operating system or virtual machine. They are realized with Linux control groups and namespaces, where control groups define what processes can do and namespaces define what processes can see.

Given their lightweight isolation, containers enable an easy, reliable, and flexible way of moving software between different computing environments, from our local laptop up to the data centers in the Cloud. Therefore, containers are a key enabling technology for continuously delivering software in a reproducible and highly automated way.

With the digital transformation comes greater customer responsiveness, whereby the software requires more frequent updates according to business needs. While traditional software development is based on the waterfall model, which tends to follow rigid, long-term plans with release cycles of several months or years, agile development principles embrace a culture of change and delivering value to customers in short release cycles of only a few days, ideally allowing for changes to be delivered up to several times per day. Here, agile methodologies offer a wide variety of benefits over the traditional waterfall approach.

They provide an increased level of transparency and awareness of the work that is ongoing and still pending, which strengthens effective collaboration among cross-functional teams. Given short iterations of work in well-prioritized iterations of usually only one to two weeks, defects can be removed quickly, eventually allowing features to be delivered in a more predictable, business- and value-oriented way. In particular, with agile methodologies, the definition of value is strongly driven and continuously evaluated by the direct feedback of real users early on in the development process. The short iterations between deliveries are enabled by fostering a high degree of automation and codified knowledge of the delivery process.

Overall, continuous delivery enables us to deliver software quickly with higher quality, increasing its value for customers while allowing for experimentation with less risk. Continuous delivery is the ability to get changes of all types - including new features, configuration changes, bug fixes, and experiments - into production, or into the hands of users, safely and quickly in a sustainable way. We will learn about continuous delivery in the next units.

A term that is often mentioned in the context of Cloud-native applications is the twelve-factor application. The twelve-factor application is a set of recommendations and best practices for building software-as-a-service application in the Cloud, following Cloud-native development principles. Let us examine each of these factors.

The twelve-factor application defines twelve best practices for building Cloud-native services and applications, such as, the recommendation to manage the codebase with source version control, or to make dependencies of an application explicit by using, for example, dependency management like Maven or Node Package Manager (NPM). A number of the most fundamental guidelines behind the twelve-factor application are as follows:

• Stateless and self-contained application processes

  The recommendation is to build applications as stateless and self-contained application processes. This allows us to easily develop and dispose of processes without much effort, for example, to be able to provide scalability and resilience.

• Separation of application code and run-time configuration

  The factors suggest separating application code and run-time configuration. In this way, the consumption of external backing services like persistence services or external APIs can be decoupled from the application code by only binding to these backing services at run-time to retrieve the configuration of the application.

• Traceability and reproducibility of all changes

  The factors recommend fostering traceability and reproducibility of all changes, in particular, using source version control, making dependencies explicit, and aiming for parity between development and production environments.

The underlying guiding principles outlined above play an important role in building Cloud-native applications. In the next units, we will see how we can use these guiding principles and apply them to build a full side-by-side extension to SAP S/4HANA from scratch.