Cloud Native: principles and advantages

Cloud Native

Cover 1

Cloud native applications: definition and advantages

Cloud-native apps are a set of stand-alone, low-coupled micro-services, designed to offer tangible benefits such as the ability to quickly integrate user feedback and thus stimulating the continuous development of a solution. The Cloud-native is an approach to the development and execution of applications that take advantage of the benefits of the cloud computing delivery model to accelerate the creation of new applications and concerns the way applications are created and distributed, not where they are developed.

The Cloud Native Computing Foundation, primary promoter of cloud-native principles, provides an official definition:

‘’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’’

Native Cloud Goal: Distribute your desired apps at a pace set by the company

 

What does “cloud” mean in cloud-native applications?

A “cloud-native” app is designed specifically to provide a consistent automated development and management experience in private, public, and hybrid clouds.  The most critical aspect of the native cloud approach is the ability to offer almost unlimited computing power, on-demand, along with modern data services and applications available to developers. When companies build and manage applications native to the cloud, they bring new ideas to the market faster and respond to customers’ needs first, optimising their lifecycle.

In order to fully exploit this potential, it is necessary to transform the application development.

This is what cloud-native development is all about: an approach to making and updating apps quickly, which at the same time improves quality and reduces risk. It’s a way to create and run responsive, scalable, error-tolerant apps, wherever they are: in public, private or hybrid clouds.

Cicd Cover

 

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. Dependancies
    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 microservices 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 resources (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-service 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
    Service 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:

Cicd
CI/CD strategy for Node.js/Express app using AWS CodeBuild/CodeDeploy/CodePipeline

Surce: GitHub

Why are Native Cloud applications important?

Native cloud applications are built specifically for the cloud model. These applications, built and distributed in a rapid pace by small teams of features dedicated to a platform that offers easy scale-out and hardware decoupling, provide organizations with greater agility, resilience and portability in cloud environments.

Cloud as a competitive advantage.
Cloud-native means moving from cloud targets to IT cost savings to the engine of business growth. In the era of software, companies that can build and deliver applications quickly in response to customer needs will build a lasting success.
Enable teams to focus on resilience.
When the legacy infrastructure fails, services can suffer. In a native cloud world, teams focus specifically on architecture for resilience. A native cloud focus helps developers and architects design systems that stay online regardless of hiccups in any part of the environment; In addition, maintenance and updates are universal for all versions of the application: updates, patches and maintenance can be performed or applied automatically without interruption of service.

Gain greater flexibility.
Public cloud providers continue to offer impressive services at reasonable cost. But most companies are not ready to choose a single infrastructure. With a platform that supports a native cloud approach, businesses build apps that run on any cloud space (public or private) without modification. Teams retain the ability to run applications and services where it makes the most sense for the business, without having to crash into the cloud of a single provider.

Align operations with the overall business.
By automating IT operations, companies can become a lean and focused team, aligned with industry professionals. Eliminate the risk of human error failures, as staff focus on automated improvements to replace routine and routine administrative tasks. With patches and automatic real-time updates at all stack levels, they eliminate downtime and the need for “second-hand” operations experts.

The difference with traditional applications
Traditional applications cannot realise all the benefits of running on a native cloud platform because of the unique way in which each of them is being engineered or developed. This type of application often takes longer to build, is released in large lots, can scale only gradually and presupposes a high availability of dependent services. In addition, any updates, patches and maintenance must be customised for the specific work environment and often require an ad hoc configuration involving a temporary interruption of service.

Moving to the Cloud-native level is typically driven by the company’s need to modernise its applications as much as possible in order to dramatically improve the structure of large apps, as we have seen, creating autonomous subsystems (micro services) that can be implemented and scaled independently from the other areas of application, reducing long-term costs and increasing growth and development agility by providing significant low-cost competitive advantages.