Traditional applications VS Cloud Native applications
We have already emphasised the importance of having flexible and high-performance applications, a goal that is difficult to achieve today with traditional applications designed according to a monolithic approach. They do not allow for rapid evolution, they cannot keep up with new technologies and, as a result, the company using them will probably struggle to remain competitive.
In the case of using one or more legacy applications with monolithic architecture, it is therefore advisable to start migrating to a Cloud Native architecture. This process is based on breaking down monoliths and highly coupled applications into simpler components.
Why take this path? Adopting Cloud Native principles, whether in the context of ex-novo development or modernisation, enables significant results to be achieved:
- From a strategic perspective, Cloud Native realises benefits such as speed of delivery and optimised user experience that enable the business to work better and increase profits;
- from an operational perspective, it enables developers to support collaboration with Operations and the organisation of work in agile mode.
To develop and design modern applications and/or to modernise existing ones, the best practice is to follow the methodology called 12Factor, which includes a set of principles and best practices to make the application Cloud Native (more on this later).
The 4 pillars of Cloud Native applications: Microservices, Containers/Orchestrators, APIs, DevOps
The application architectures, technologies and methodological frameworks underlying Cloud Native development jointly support the needs of enterprises that demand flexibility, speed of response, performance and efficiency from IT.
To summarise, there are four pillars underpinning Cloud Native solutions:
- ARCHITECTURE: Microservices
- INFRASTRUCTURE: Containers / Orchestrators
- COMMUNICATION: APIs / Service Mesh
- PROCESSES: DevOps, CI/CD
Below we briefly look at them, if you want to go deeper you can read this article: why Cloud Native is the answer to a modern, changing market.
ARCHITECTURE: Microservices
The microservice architecture suggests a new model for building applications, based on individual, independent functional units. Each function can thus be compiled, implemented or modified without affecting the functioning of the entire application. A small, dedicated and specialised team works on each microservice.
The advantages? Definitely worth mentioning is the reduction of architectural complexity and the possibility of scaling and distributing single functionality across different environments. It also increases the overall resilience of the application, since a disruption on one microservice will not affect the functioning of the other services.
Another benefit stems from the reduction of development time and time-to-market, as one can act on individual components without stopping or slowing down operations related to other microservices. Also to be considered is the improvement of the developers' responsiveness and software quality (due to focused skills and know-how).
INFRASTRUCTURE: Containers / Orchestrators
Containers are virtual instances of a complete runtime environment that host the entire application (built in Cloud Native mode or according to a monolithic architecture) or microservices (individually or in clusters), allowing them to run independently of the underlying infrastructure.
Containerisation, which can be realised with specific tools such as Docker, therefore proves to be an extremely effective technique in hybrid and multi-cloud environments: the decoupling of hardware and software components guarantees the full portability of applications on different systems, without distinction between on-premise data centres and cloud infrastructures.
Containerising applications means eliminating the inefficiencies in functionality and performance that may arise when moving between heterogeneous environments. The flip side of the coin is the increased complexity of container management, especially when the number of applications to be deployed, distributed and maintained is particularly high. The use of container orchestration platforms, such as Kubernetes, proves to be the ideal solution.
COMMUNICATION: APIs / gRPC, Service mesh
When designing and building a Cloud Native application, communication becomes a significant design decision.
There are many questions to be answered: how does a front-end client application communicate with a back-end microservice? How do microservices communicate with each other? What are the principles, patterns and best practices to consider when implementing communication in Cloud Native applications?
The strategies to be implemented are manifold and must be carefully considered at the design stage. We can rely on established patterns such as: API Gateway / Management, gRPC, Service mesh.
The use of a modular microservice architecture allows all communication between the various application components to be based on lightweight, technology agnostic protocols. This constitutes a further step towards reducing the complexity of deployment, allows architectural complexity to be governed and increases the level of independence of developers who can concentrate their efforts on business value rather than on infrastructural aspects.
PROCESSES: DevOps, CI/CD, GitOps
DevOps is a methodological framework that facilitates collaboration between Developers and Operations, enabling efficient and effective processes for managing the software lifecycle. DevOps follows the same principles as Agile development methodologies (e.g. Scrum), emphasising the creation of synergies between teams.
The purpose of DevOps practices is simple: to eliminate the traditional lack of communication between those who develop the application and those who manage it once it is released, by encouraging a sharing of responsibilities.
How? For instance through CI/CD practices and GitOps, methods for frequent app distribution to users in which automation plays a central role.
- CI - Continuous Integration:
- changes to the code made by different teams are constantly channelled to a central repository, allowing the alignment of parallel activities within a single project.
- CD - Continuous Delivery: releases are made with a very high level of frequency.
- GitOps is a way of implementing Continuous Deployment / Continuous Delivery for Cloud Native applications. It focuses on a developer-centred experience also with regard to infrastructure activities, using tools with which developers are already familiar, such as Git and Continuous Deployment tools. To learn more, have a look at our talk and slides.
But what are the concrete benefits of the framework? These include the possibility of streamlining and agile processes, with a consequent increase in release speed; the increased quality of the application, due to automation that reduces human errors and continuous feedback between the two teams; and the increased reliability and scalability of the application.
Moving to Cloud Native: how to modernise a legacy application
Having stated the basic principles of Cloud Native development, however, it must be borne in mind that companies have built up a wealth of legacy applications over the years that today must also be able to function in modern Cloud environments. To completely rewrite the entire application park in a Cloud Native key would be a titanic and foolhardy undertaking. There are in fact several ways to modernise an application by bringing it to the Cloud, and the correct approach must be weighed up on a case-by-case basis.
Here is a brief overview of the viable options:
- rehosting (also called Lift&Shift) consists of simply migrating the application to the Cloud, without making any changes. To be used if the loss of functionality and performance is zero or minimal;
- refactoring involves small changes to the source code to eliminate inefficiencies or malfunctions in the application, ensuring optimal or otherwise adequate performance even on the Cloud;
- rearchitecting introduces a number of properties and techniques typical of Cloud Native design, from containers to APIs, deeply intervening in the structure of the application;
- rebuilding a more drastic operation, which involves rewriting the application from scratch, according to Cloud Native practices and with the aim of rebuilding all functionality. Since it is a complex and costly procedure, it is only recommended for business-critical applications and in the presence of serious malfunctions;
- replacing finally corresponds to the replacement of the software with a ready-to-use SaaS solution, equivalent in functionality and use.
LEGGI ANCHE: Application modernization: cos'è e quali sono i vantaggi
Development of a Cloud Native Application
In order to correctly develop a Cloud Native application, we recommend proceeding according to the Twelve-Factor methodology, which defines twelve general principles for building next-generation software or modernising legacy software, guaranteeing performance, portability and scalability in Cloud environments. The Twelve-Factor model aims to optimise development time and speed up software deployment, adding quality, flexibility and code portability.
We see three good practices to follow: replicability of dependencies, separation of code and configurations, stateless approach.
Replicability of dependencies
The proper execution of an application is strictly dependent on a number of associated technological components, e.g. vendor-supplied libraries or the functionality of the underlying operating system. Containerisation makes it possible to package all application dependencies within a complete runtime system, which can be easily transported to different environments, on premise or in the cloud, for design, testing or production.
Separation of code and configurations
Each environment may require different configurations, e.g. access credentials to a service or database connections may vary. While traditional applications contain the configurations internally in the code and repeat them as constants, Twelve-Factor principles suggest decoupling through specific techniques. For instance, by using environment variables, configurations are made available to the application but are retrieved by the runtime system at runtime, without residing directly in the codebase.
Stateless approach
Another fundamental characteristic of modern applications is the stateless behaviour of processes, i.e. it does not assume that its behaviour can depend on previous executions nor that components, such as memory and file-system, are shared and persistent between consecutive executions.
Any traditional workload can be modernised and brought to the Cloud without undergoing a complete refactoring. With the right modifications, it is possible to make an application easier to scale horizontally, more resilient to errors and more performant by being able to natively exploit every service provided by the Cloud vendor.
The benefits for the company in choosing a Cloud Native application
Enterprises that opt for Cloud Native applications achieve significant results in terms of business and competitiveness. First of all, they can have applications optimised for hybrid and multi-cloud environments, providing users with more effective services and a better user experience.
DevOps practices accelerate time-to-market and returns on development activities. Frequent releases allow users to benefit immediately from the improvements made to the application, without having to wait months for the final release. Very often, in fact, designing an application or finalising a required change can take months, with the risk that business needs have changed in the meantime.
Finally, the Cloud Native design is future-proof: the scalability and portability of modern applications allows optimal utilisation over time, regardless of the evolution of the underlying infrastructure. progettare un applicativo o fi
The advantages of the Cloud Native approach for the development team
Convenient for the entire organisation, Cloud Native applications also add specific benefits for development teams.
For example, the use of APIs makes it possible to reuse functionality already developed without having to rewrite the code from scratch, saving hours of work. Containers ensure the migration of applications to different environments without the need to make changes, thanks to decoupling with the underlying hardware, thus reducing developers' effort. Automation tools (for container orchestration or CI/CD process management) minimise the repetitive and time-consuming activities of developers, who can then focus on indispensable tasks.
Collaboration between highly specialised multidisciplinary teams, as well as the adoption of DevOps practices, ultimately leads to an increase in software quality. This contributes to raising the company's perception of the IT function, which is increasingly seen as a business enabler and not just a cost centre.
Cloud Native Applications: where to start?
Implementing a Cloud Native application or modernising the application pool using the Cloud Native approach is not trivial: these operations require in-depth knowledge of the necessary processes and technologies. Otherwise, there is a risk of losing efficiency and money.
Our experience with our customers has led us to realise that the path to Cloud Native is marked by 4 precise stages:
- Preparatory phase of data collection and initial definition of the Cloud Native strategy.
- Strategy definition phase, including timelines, methodologies, tools and KPIs to be monitored.
- Implementation phase of the Cloud Native strategy at both methodological and technological levels.
- Delivery and implementation phase of the solutions and periodic check-up to validate the implemented strategy and defined KPIs.
