Microservices and Cloud Native
Microservices are often associated with another term, Cloud Native, but a distinction must be made. Microservices are a software engineering architecture, while Cloud Native is a true paradigm for creating modern applications. Cloud Native methods and tools enable the enterprise to react quickly to changing market demands by proactively adapting its IT services.
Operationally, Cloud Native applications are applications that can run on a private, public, or hybrid cloud. The microservices approach is one of the paradigms for building Cloud Native applications. Alongside them we find containers, container orchestrators (such as Kubernetes) and the use of declarative APIs, as well as Agile development methodology and DevOps practices based on Continuous Integration and Continuous Delivery (CI/CD).
A microservice architecture finds containers the perfect technology to express its full potential. Containers allow a microservice to run independently of the underlying infrastructure.
FOR MORE:
Why did microservices arise?
Microservices are simultaneously the evolution and logical development in the history of software engineering. The path has been long and took its first steps from monolithic applications.
Monolithic architecture
The monolith architecture provides, simplifying the concept, that the user interface (the frontend) and the interfaces for accessing and manipulating data (the backend) are contained in a single, independent, indivisible, modularity-free piece of software.
A monolithic application must contain everything needed to complete a particular task. Today this perspective is potentially outdated: thanks to the modular approach of software, it becomes possible to use, update or modify a series of small components independently without the need to deploy or deploy the entire application.
Monolithic applications are functional in a circumscribed environment, as the early mainframes were and as personal computers have long been as well, and provide integration of functions in nonstandard environments.
Over time, however, the complexity of the problems to be solved and the increasing power of computers led to the creation of increasingly large and heavy monolithic applications. Such structures have become very expensive to update quickly and o maintain properly: they can be said to have outgrown the ability of programmers to exploit them effectively.
“As long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem.”
— Edsger Dijkstra, computer scientist
Here the IT world had to identify new development methodologies and processes to improve the quality of software and its management. First came procedural and object-oriented programming to manage large, complex projects with undefined specifications in detail. Later, with the development and growing importance of the Internet, various architectures emerged among which the most widely used is SOA, Service-Oriented Architecture.
SOA: Service-Oriented Architecture
Rather than a revolution, SOA is considered an evolution of existing development practices that allows the enterprise to build its applications with a holistic and nonrigid approach. SOA is an architecture in which some components of an application provide services to components of other applications through a communication protocol that operates independently and nonproprietarily over a network.
Multiple SOAs, joined by a dedicated hardware or software infrastructure, can become the functional equivalent of a larger, more complex monolithic application, without many of the associated disadvantages. SOA encourages the sharing of individual software components and their reuse.
In the service orientation that underlies SOA, we can already glimpse what will be the future development of the architecture. We are clearly talking about microservices, which make the modular approach their strong point.
From SOA to microservices
The differences between the two approaches are numerous. Architecturally, SOA is designed to share resources through services; microservices, on the other hand, are services that run independently.
SOA is organized on larger and more modular services than microservices that are centered on a single function. In addition, the Service-Oriented Architecture shares data storage space while each microservice has its own independent data storage.
As a communication system, SOA uses ESBs (enterprise service buses) and microservices use APIs; for remote services, SOA uses protocols such as SOAP and AMQP, while microservices rely on REST and JMS.
Finally, while SOA is more efficient for projects involving large-scale integration, microservices are designed for Cloud Native web applications that are easier and faster to design and put into production.
Finally, while SOA is more efficient for projects involving large-scale integration, microservices are designed for Cloud Native web applications that are easier and faster to design and put into production.
What are the advantages of microservices?
Implementing a project based on microservices brings a number of advantages:
- Microservices make it possible to reduce the architectural complexity of an application by deconstructing it into a series of point services that are faster to develop and maintain.
- Each feature can be scaled up quickly and deployed across multiple environments independently of the rest.
- The time to develop and then to put the application into production is greatly reduced, which positively impacts time to market.
- The application is more resilient because individual services do not impact the operation of the entire application, and maintenance operations are faster.
- Development teams are smaller and very specialized in a single part of the application that has a smaller code base.
- Agile methodology and DevOps development practices can be used more easily, enabling collaboration between Developers and Operations with a Continuous Integration and Continuous Delivery approach.
When (not) to choose microservices?
There is no "one size fits all" approach to application development that solves all problems. As much as microservices are the new market standard, the monolithic approach may actually be the most cost-effective solution for some companies.
For example, it is advisable to opt for traditional architecture if:
- you have little time and budget to make an MVP (Minimum Viable Product);
- one needs a very simple application that does not require special scalability and flexibility;
- you do not have the necessary skills to develop in microservices (and you do not intend to rely on a specialized partner, which is still a recommended choice if you are dealing with new and inherently complex technologies).
In most cases, however, the choice of microservices turns out to be better suited to meet business demands because it provides more flexibility, speed and scalability.
Evidence of the growing popularity of this approach also comes from data. For example, Statista's 2021 surveys show that 71% of companies use microservices at least partially. O'Reilly's 2020 survey found that 28 percent of respondents have been using microservices for at least 3 years, while 61 percent have been using them for a year or more. At the level of liking, 92% expressed that they have benefited from the introduction of microservices.
Challenges and complexities of microservices
Beyond specific cases, it is important to consciously assess the challenges that microservices bring to the enterprise.
A microservices-based architecture requires a different hosting infrastructure than traditional monolithic applications, which must be tailored to the needs of the business, made secure and maintained. And it works best for companies that need to innovate quickly to a very diverse user base.
Microservices have a different complexity than monolithic applications, but one that should not be underestimated. The focus is on communication between individual services in the application, which can include several dozen to several hundred different services for larger projects.
In addition, debugging a microservice-based application is more complex because one has to trace the source of each individual problem through the logs of tens or hundreds of small components. Still, the testing phase of microservices integration presents some difficulties because they are distributed in different environments and it becomes complex to replicate them in a local testing environment.
Finally, since the operation of a microservices-based application is achieved through the use of APIs, constant attention must be paid to the evolution of APIs. Indeed, if new versions of APIs are defined, it can be very complex to understand how they will impact the microservices that use them.
Net of these considerations, microservices architecture proves to be the most innovative and advantageous choice for those companies that are able to cope with the added complexity because of the many benefits that can be achieved
From monolith to microservices: the stages of modernization
A microservices-based project can be developed from scratch or, more likely, will be the result of a transformation starting with a legacy application.
There are two popular refactoring strategies for managing the transformation from a monolithic to a microservice-based application: implementing all new functionality as services and extracting individual services from the monolithic application.
The first case is the easiest to deal with as it does not require fragmenting the entire legacy application. And it also has the advantage of showing a greater speed in getting new software into production than the traditional monolithic model.
However, the only way to completely modernize the monolithic application is to extract one module after another from the application and convert it into a service. This is done with a preliminary analysis and mapping phase: the individual services that will replace the different modules in the monolithic application must be defined. This is followed by the development, testing and deployment phases to redirect traffic to the new services. At this point, the functionality transformed into microservices can be removed from the monolithic application.
In conclusion, migrating a monolithic application to a microservices-based architecture requires a preliminary activity of analyzing and then converting the individual mapped components iteratively.