In the last post in the cloud computing series for beginners, we talked about the advantages of serverless computing for the fast product release cycle. In this post, we will go a little deeper in the transition from the monolithic application model, a bit older, to modern applications, which use microservices for isolated and independent development, with functional division and focused on business results.
Motivation for the use of microservices
One of the main things we should know about microservices is the history and the motivation for their adoption. The term was first used in 2005, by Peter Rodgers.
About 15-20 years ago, the most common development model was Monolithic Applications. Large applications could even be made up of smaller modules according to some technical segmentation or resource, but there was an artifact packaging for deployment on application servers.
Due to the complexity of this packaging and the difficulty of isolation between the components, it was common for a particular module with problems to also impact other modules running on the same server.
In addition to the difficulties in runtime, the fact that several components were packaged and distributed together ended up creating challenges for the development process of the product teams. To be successful in large monolithic applications, it was necessary to do an excellent roadmap organization work among several development teams. This often impacted speed and efficiency of the teams – since it is much easier to develop products and update them without impact if the team is in complete control over the deployment and updating of applications it develops.
The idea of developing and packaging smaller applications has two main motivations:
- Fault tolerance in applications
- Autonomy for Product Teams
Microservices in a nutshell
It is in this context that microservices arise, a style of development architecture that divides an application into a set of smaller services with a more specific purpose. This division seeks to produce services that are:
- Easily maintainable and testable;
- Loosely coupled. Low dependence between them;
- Independently and separately deployable;
- Functionally divided in a consistent way with the business domain;
- The responsibility of a small team to maintain them.
Affinity with cloud computing
It is necessary to clarify that there is no practical restriction on adapting monolithic applications to development models practiced natively in the cloud. It is entirely possible that an application written 20 years ago can benefit from running in the cloud instead of on-premises data centers. However, although it is possible, it is very rare to find old applications that are already well prepared to succeed in the cloud.
There are some architectural features that we often find in traditional applications that make the transition to the cloud quite difficult. There are also many cases in which legacy applications in the cloud cost more than in traditional environments without companies having any additional benefits from being in the cloud.
Microservices have technical and functional characteristics that fit very well with the models offered by cloud platforms. Some of the main benefits that companies seek when planning to migrate to the cloud are:
- Elasticity: ability to increase and decrease the infrastructure size according to customer demand;
- Fault tolerance: ability to design more redundant and resilient architectures, often geographically distributed. This usually improves the availability of applications and services, which can tolerate failures in individual components;
- Self-service: Team capacity to hire and configure the necessary resources with autonomy, without human steps in the process;
- On-demand computing: The use of cloud computing generally allows for consumption and payment on demand without upfront payments. This model makes it much easier the experimentation and validation of products without significant investments at an early stage.
Application Modernization
The cloud adoption movement is not new, with early-adopters building cloud-based applications for more than 10 years. However, traditional companies that make up more than 80% of the world economy are still in the first steps of adoption and migration to the cloud.
As the applications of these companies have a mostly pre-cloud model, most of them are not prepared to run successfully in the cloud. In order to reach the excellent level of adaptation to the characteristics of the cloud, it is necessary to modernize applications in some aspects of architecture and development process.
We will have other more detailed articles covering this process in more depth, but we leave a great reference of what is normally needed: Twelve Factor-App.
Amazon 6 Rs for migrating applications to the cloud
In 2016, Amazon Web Services proposed an approach with 6 possible paths to the migration of any application or product to the cloud. Although the details of the migration process can be quite complex, analyzing the options we have is not difficult to understand. Which are:
Rehosting (also known as Lift and Shift): this is a migration process without modernization, basically reconfiguring servers and applications in the new cloud environment using virtual machines. It usually works, it is quick to migrate, but it does not bring relevant benefits. In most cases the costs in the cloud increase compared to the previous environment where the application was.
Replatforming: in this process, application settings are adjusted without requiring relevant code rewriting. Some specific adjustments allow applications and services to run on managed services from the cloud platform and already have good benefits. Simple examples of this process are:
- Adequacy of databases to run as Managed Databases;
- Save web applications session in managed cache services;
- Configure file uploads to use a managed service instead of saving to local disks on servers;
Repurchasing: in this case, instead of migrating an application to the cloud, a new service is contracted to replace the previous one. Common examples are the replacement of management systems such as ERPs and CRMs that run in data centers with new versions contracted in a SaaS model, software-as-a-service. This process is likely to involve a data migration between systems, but not a conventional environment migration.
Refactoring: this is the most advanced and perhaps most complex path, in which the application is improved with code rewriting to suit native cloud architectures. However, it is undoubtedly a path that can contribute a lot to the competitiveness of companies. The gains in efficiency and agility in the launching of products and also in the experimentation of businesses are expressive and the company is able to learn very quickly about its customers and market.
Retire: this case occurs when the company identifies that, in a migration scenario to the cloud, that application/service is no longer needed. An example would be an authentication/authorization application that meets specific company requirements and is replaced by an equivalent model available in a SaaS solution.
Retain: this case is very common in traditional data centers with a high volume of transactions or messages. The application may have an architecture and communication protocols not supported by the cloud, such as traditional applications that used Multicast communication as standard. This communication model until recently was not supported in public clouds and made migration without rewriting impossible. In this scenario, if the application is still necessary for the company, it needs to be maintained in the original environment. Scenarios like this often motivate the adoption of hybrid clouds to maintain communication between all necessary applications and services.
How to move forward and succeed with microservices
We talked a little about the characteristics and motivations for the use of microservices, but it is prudent to also clarify some points of attention in adopting this path.
That’s because microservice architectures can be quite complex and make the development process slower and more costly than it would be in a traditional application. There are challenges related to monitoring, integration between services and security that often do not justify this greater investment in developing the solution.
An important recommendation is to always seek clarity about what pain or problem you are trying to solve through microservices. Knowing what the pains are, it never hurts to question whether they have actually been felt or they may also appear in the future. A very common mistake among software engineers is to always believe that they will be able to reach a fabulous volume of accesses and criticality and design an architecture capable of handling all this.
What is often seen at technology events are talks by engineers from Netflix, Spotify and Amazon, among other world giants. The architectures described there solve problems that will never be faced by 99.9% of professionals; so, it does not make sense to deal daily with a higher complexity than our problems require, right?
We then leave the recommendation to have the architecture as simple as possible, the one that solves your problem, and only pursue a more sophisticated model when the needs become evident. The success of the product sometimes asks for the most ordinary and reliable technology possible. Wisdom always guides the best decisions 🙂