Common characteristics of this architecture: business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
Join the DZone community and get the full member experience.Join For Free
What is Microservices Architecture
The term “Microservice Architecture” has sprung up as a way to describe a specific way of designing software applications as independently deployable services in suites.
There are certain common characteristics of this architecture around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
It is often described as an approach of building a single application as a suite of many small services, whereby each service is running its own process, deployed independently, and communicating with other services with lightweight mechanisms such as HTTP API.
Each of these services can be developed in any technology stack such as Java, NodeJS, etc., and can use different data storage repositories such as MySQL, MongoDB, etc.
When an application is packaged and deployed as a single war or jar file, we call it a Monolithic application. Although it may have a modular code structure whereby different classes are grouped under different packages or modules.
But unless they can be deployed and run as separate or independent applications, we are gradually moving towards monolithic hell only.
Over time, a monolith application becomes so complex and large, that developers themselves find it difficult enough to develop, build and run such an application.
The code checkout time goes long, application build time goes twice long and finally, startup time also gets affected due to such a large code repository.
Another related problem that the technical team faces is deploying code frequently. In CI/CD era, continuous one or another code is sent to the staging or production environment. But if the application is so large and even a small change in one code results in building and deploying the whole application for longer hours, then the purpose and benefit of CI/CD cannot be drawn.
One more problem with the monolithic application is that we cannot scale modules individually because the whole application is deployed as a single unit on a server. And if there is a need to scale only 1 or 2 modules, then it is not possible to do so due to the reason that it is a single deployment artifact (war or jar).
In summary, such applications are difficult to scale and are unreliable. And as a result, following agile development and practices go haywire.
Journey from Monolithic to Microservices Architecture
This problem can be solved by splitting the application into a set of smaller interconnected services instead of a single monolithic application.
Each domain or functional or module of a monolithic application can be configured as a separate code repository or services which has its own build file and other required deployment configurations. Also, in this case, each service has the freedom to choose its own technology and database.
Each of these services has its own separate database and exposes REST API. Each microservice can invoke each other APIs to get the whole use case solved.
Advantages of Microservices
The first advantage that microservices architecture brings is flexibility. Each microservice is so modular that they are faster to develop, build and run. Deployment of these individual microservices is also faster.
Secondly, each of these services can get scaled individually. Unlike monolithic architecture, where the full application must be scaled up or down irrespective of individual modules/service.
Thirdly, developers are free to choose any technology for different services as they are not bound by one single monolithic application.
Lastly, it is easy to bring down or up a particular service for patch or maintenance purposes without affecting the whole application as such.
Disadvantages of Microservices
In my view the biggest disadvantage that microservices architecture is complexity. With the number of services floating around, much emphasis is needed to manage their lifecycle, their availability, etc.
A distributed transaction is another issue that developers face, as a two-phase commit is not possible between two or more independent services. Therefore, the focus is needed to design these services to handle partial failure and choose an eventual consistency approach.
Testing of services at the developer end is also difficult as one needs to either make dependent services available or create a mock services framework using tools like Mockito for unit testing.
Opinions expressed by DZone contributors are their own.