Cloud native: approaches and benefits

Native cloud applications conform to a framework or “contract” designed to maximise resilience through predictable behaviour; highly automated infrastructure divided into containers, used in cloud platforms, guides the way the software is written and released. A good example of such a “contract” is illustrated by the 12 principles documented for the first time as a 12-factor app.

Cloud native structure: The Twelve-Factor

A widely accepted methodology for building cloud-based applications is the Twelve Factors application: this describes a set of principles and practices that developers follow to build applications optimised for modern cloud environments, with a particular focus on portability and automation.

While this methodology is applicable to any web-based application, many professionals see it as a solid basis for building native cloud apps, as systems based on these principles can implement, scale and add functionality quickly to react to dynamic market changes.

These factors are:

1. Code Base : a single basic code for each microservice, stored in its repository that traced with version control, can distribute to multiple environments (QA, staging, Production).
2. Dependacies : each micro-service isolates and bundles its own dependencies, including changes without affecting the entire system.
3. Configuration : the configuration information is removed from the micro-services and outsourced outside the code, through a configuration management tool; the same distribution can then spread through the environments with the correct configuration applied.
4. Backing Services : the auxiliary resoruces (data files, caches, message brokers) should be exposed via an addressable URL, in this way the resource is decoupled from the application, allowing its interchangeability.
5. Build, Release, Run : each release must enforce a strict separation between build, release and run stages; each should be marked with a unique identifier and support the ability to roll back. As we will see, modern CI/CD systems contribute to meeting this principle.
6. Processes : each micro-service should be performed in its own process, isolated from other running services. Any outsourcing requires the use of a backup service such as a distributed cache or data store.
7. Port Binding : each micro-services should be autonomous with its interfaces and functions exposed on its own door; in this way its isolation from other micro-services is guaranteed.
8. Concurrency : services extend out scales, on a large number of identical small processes (copies) as opposed to scaling-up a large single instance on the most powerful machine available.
9. Disposability : services instances (service instances) should be disposable, facilitating fast startups to increase scalability opportunities and shutdowns to leave the system in a proper state. Docker containers with orchestrator inherently meet this requirement.
10. Dev/Prod Parity : keep environments as similar as possible throughout the life cycle of the application, avoiding dangerous shortcuts. Here, the adoption of containers that therefore promote the same environment of execution, contribute greatly to this factor.
11. Logging : treat the logs generated by microservices as event streams (event streams); then process them with the use of an event aggregator and disseminate the related data in data-mining/ log management tools such as azure Monitor or splunk and, finally, in a long-term archive.
12. Admin Processes : perform administrative/ managerial tasks as one-off processes; these processes may include data clean up and analytics generation for any report. The tools that perform these tasks should be recalled from the production environment, but separately from the application

One thing to take into account is that in the near future, as native cloud technologies and practices evolve, their definition will also evolve.

Cloud-native systems, however, are designed to accommodate rapid and large-scale changes and the adoption of native cloud technologies and practices allows companies to create in-house softwarehouse and entrepreneurs to collaborate closely with the IT department, keeping pace with competitors and providing better services to their customers.

Therefore it is important for companies to have a platform for the development and management of native cloud applications and services that automatizzi and integri the concepts of microservices, containers, devops and continuous Integration / continuous Delivery.

Microservices

Microservices means the use of an architectural approach (small services) to the development of an application. Through the use of this architecture each service implements corporate capabilities, runs in its own process and communicates via HTTP API or messaging. Each micro-service can be implemented, updated, resized and restarted independently of other services, typically as part of an automated system, enabling frequent updates of applications in real time without impact on end customers.

• Each implements a specific commercial potential within a wider domain context.
• Each of them is developed autonomously and can be used independently.
• Each contains its own data storage technology (SQL, nosql) and programming platform.
• Each runs in its own process and communicates with others using standard communication protocols such as HTTP/HTTPS, websockets, or AMQP.
• Grouped together form an application.

It should be noted that micro-services promote the principle “One codebase” of application to twelve factors, seen above.

Also having an independent independent life cycle, it is not necessary to wait for a quarterly release to distribute a new feature or update but you can upgrade a small area of a complex application, less risk of damaging the entire system.

In addition, instead of resizing the entire application as a single unit, only those services that require, for example, more processing power or network bandwidth are resized; This fine-grained scale approach provides greater control of the system and helps reduce overall costs as only portions of the entire system are scaled.

Container

Containers are technologies that allow you to create packages and isolate applications with their entire runtime environment and all the files needed for execution. They offer both efficiency and speed compared to standard virtual machines (VMs), in fact using virtualisation at operating system level (OS)a single instance of the system is dynamically subdivided between one or more isolated containers, each with a single writable file system and a share of resources. The low container creation and destruction overhead, combined with the high packaging density in a single VM, makes containers an ideal computing vehicle for the implementation of individual microservices.

The CNCF places the containerization of microservices as a first step in their Cloud-native Trail map, a guide for businesses starting their cloud-native journey.

Creating a container for a micro-service is simple: the code, its dependencies, and runtime are joined in a binary called container image. These images are stored in a container registry, which serves as an archive (repository) or library (library) for images; a registry can be located on the development computer, in the data center, or in a public cloud. For example, the cloud azure, which we at EDALAB use every day, has a container registry to store container images near the cloud applications that run them. When needed, it turns the image into a container in running instance. This instance can be executed on any computer that has installed a container runtime engine and you can have all the instances of the service enclosed in the necessary containers.

Therefore, since the development of an application is based on configuration in its environment and depends on libraries, dependancies and specific files, with containers, these become easy to emulate locally without all the overhead of recreating complicated server environments; all without affecting the entire system as indicated in the principle “Dipendancies” from application to twelve factors.

Containers support workloads for both Linux and Windows and the cloud azure, mentioned above, openly embraces both and is Linux, not Windows Server, the most popular operating system used.

DevOps

One of the best definitions of DevOps comes from one of its most fervent supporters, Donovan Brown:

"DevOps is the union of people, process, and products to enable continuous delivery of value to our end users."

This is a wide range of ideas that span the entire software development lifecycle, from the specification of an application to the delivery and operation of that application. This term, derived from the contraction of the words Development (development) and Operations (processes) describes, therefore, those approaches aimed at accelerating the processes with which an idea (for example: new software functionality, an improvement request, or bug fix) goes from development to deployment, all in an environment where it continues to provide value to the user.

We therefore need an integrated collaboration between developers and IT with the aim of constantly providing high-quality software that meets customer requirements. This has the potential to create a culture and an environment in which the development, testing and release of software takes place quickly, frequently and in a more coherent way; Cloud-native applications, based on these principles, have clear advantages in terms of development speed, stability and scalability, entrusting their management to these DevOps models.

Of course, this means more frequent code changes and more dynamic use of the infrastructure, where traditional management strategies fail to keep pace with this type of demand, that’s why adoption of native cloud technologies is a journey of gradual but fundamental changes, representing a cycle of change that can be difficult to embrace.

Continuous Integration / Continuous Delivery

Continuous Integration (CI) continuous Delivery (CD) is a process, often viewed as a pipeline, involving the addition of a high degree of automation and continuous monitoring for the development of native cloud apps, so that changes to the source code are automatically translated into a new container during construction, tested and distributed during development and possibly in production.

Case by case, what the terms refer to depends on the amount of automation incorporated in the pipeline. Many businesses start with the addition of CI, and only then move on to automating delivery and distribution, for example, during cloud-native apps development.

We at EDALAB provide support and consulting services for software development through CI-CD practices, helping the team of developers to optimise the process of code creation and release.

This process, enabled by Agile development practices, allows you to constantly release small portions of software to the production, through automation: continuous delivery makes the release more reliable, so that companies can frequently deliver, with less risk, and get faster feedback from end users, as shown in the following graph: