ERP Resources: What are Microservices?

This is the tenth of a series of articles on 'technologies for the coming decade that I am writing in my blog. I intend to cover 21 technologies / ideas. Here is my publishing history.

Introduction

About 50 years ago we used to predominantly have General Physicians. She was the Go To Doctor for all the illnesses ranging from headache to cuts on your ankles.

If the GP is down due to illness, say diarrhea, all the medical support systems in the town came to a standstill. Whether you had a head ache or a throat infection or a knee pain, you had to wait till the GP was available.

In technical terminology, that single GP was a 'Monolithic Architecture', akin to a single application that is installed as a package or an executable. In case of a bug in one part of the application, the entire application went down and all the inter-dependencies had to be retested before the application was available again.

In the world of medicine, then came specialization. You had specialists handling different illnesses. If a 'Hand Surgeon' was not available, treatment of other illnesses did not have to wait. In case of a complex case which needed expertise of multiple experts, a clear communication protocol was established between different specializations.

If you look at a modern hospital as a software application, each of the specialist is a 'Microservice' and these services communicate through a standard communication protocol.

The application (hospital) do not stop due to issues with a single specialist. In other words, the issues are 'localized'.

Multiple small services, talking to each other through a standard communication protocol and where the problems are localized...

This is Microservices.

What are Microservices?

Microservices is an 'Architecture'. It is not a group of services lying around for the application developer to pick and choose as the name seem to suggest. In microservices architecture, different parts of the application are developed as separate services. Each of the services talk to each other through APIs.

Each of the services will have its own code, logic, APIs and configuration settings. They will be grouped together as a single block called 'Container'. This process is called 'Containerization'. Each container can be installed separately.

Since each container is a separate entity, any issues in one part of the application can be localized to that container and can be addressed quickly without impacting the other parts of the application.

Consider an e-Commerce application. It may have features like Product Catalog, Order Placement, Shipping, Tracking, Payments and Returns. Each of these are developed as a separate service. A problem in the catalog application will not impact the payment application. This is the benefit of Microservices.

Explain the evolution of Microservices

First driver is the introduction of Web Applications. You could install your application on a remote server and users could access the application through browsers installed on their desktops. Suddenly the user base exploded. Anyone sitting in any part of the world could access the application.

This led to the demand of 'high level of application availability' and increased the pressure on traditional tightly integrated applications. Any bug in any part of the application impacted the application availability and customer response. E-Commerce vendors started looking for 'Loosely Coupled' applications where each component was delinked from the other and could talk to each other through a common language.

Scalability was another driver. The nature of E-Commerce is inconsistent demand. You could have peak demand in some areas for a couple of weeks followed by regular or even subdued demand on other days. In a 'Tightly Coupled Application', this meant that the entire application had to be made scalable to respond to such demand fluctuation. This was an inefficient approach. Why should you add resources to an item catalog application when the demand spike was in the Order Entry application?

Microservices was the logical answer to scalability. You could have a separate Order Entry application which could be scaled up during the peak demand period while the other applications could maintain at the base level of resources.

Finally, traditional application had to be written in only one language. Technology was evolving radically with new languages evolving to meet the requirements of modern business. Traditional applications, developed in a single language, were losing out on the best features of modern languages like Python. In addition, developers were also moving to new languages. Microservices allows different applications to be written in different languages. This overcomes a key challenges of traditional applications.

In summary, evolution of web applications, need for limited scalability, and evolving technology were the key drivers of Microservices.

Monolithic Architecture: The opposite of Microservices

Traditional applications were designed as 'Monolithic Architecture'. The applications may be modular, but application was developed as a single, big executable. Any changes, issues or bugs in any part of the application meant two things. One, the System Integration testing became critical. Even when the changes are made in a small part of the application, the entire application had to be tested for impact on other areas.

Two, every time changes were made to one part of the code, the entire application had to be reinstalled. This meant significant disruption

Microservices resolved both the issues of traditional applications. By keeping each service as a 'localized entity', it ensured that any issues in that application can be separately handled and installed separately.

Advantages of Microservices

We have already discussed this. The advantages include localized bug fix, localized install and maintenance, multiple languages, localized scalability and standard APIs that communicate between services.

Challenges of Microservices

Given the advantages, it is easier to assume Microservices as a panacea, which it is not. For one, the monolithic applications are also evolving with technology. The main advantage of monolithic architecture is control. It is easy to plan deployment and shut down. A large application made up of microservices could be difficult to maintain and manage. When you add additional complexity like different languages, the number of resources required to maintain the application increases.

Also microservices could compromise quality standards. Since each services is coded as per its own standard, the project manager may find it difficult to enforce a single quality standard for the entire application. However, this is also applicable in a modularized monolithic application where different modules are developed by different teams with their own quality standards and time line pressures.

For microservices to be successful, a tight control on its original and continuing scope is very important. It is very easy for the application to be divided thinly with too many individual services or tightly to have too few services.

Related Terminology

Cloud Computing: Read my post HERE
Containers: As discussed earlier, these are blocks of services with their own code, configuration and APIs. These are the basic building blocks of Microservices
OAuth: Open Authorization (OAuth in short), is the access protocol between different services. OAuth is an 'agreement' between two services whereby one service provides customer information to the other without the use of passwords. OAuth is used by Facebook to share customer information with Instagram, for example.
Docker: This is a platform that enables developers deliver packages in Containers. In other words Docker enables 'Containerization'
Spring Cloud: In simple terms, a spring cloud is a library of tools and resources that help developers develop standard patterns. Some examples are Service Registration and Recovery, Routing, Load Balancing and Distributed Messaging.
REST API: This is also known as 'RESTful API'. This is the communication protocol using which different services 'talk' to each other. REST stands for 'REpresentational State Transfer' and API stands for 'Application Programming Interface'

References

ERP Resources

GDPR Declaration !!

Saturday, March 13, 2021

What are Microservices?

No comments:

About Me

Meet me in LinkedIn