Recently there is an increase in the popularity of MicroServices but it has been prevalent for a long time. A number of factors can be attributed to the popularity that has led to this trend with scalability being probably the most important one. Utilization of Microservices by “big guys” like Amazon, Netflix, eBay, and others, provides enough confidence that this architectural style is here to stay.
Microservices also frequently called “Microservices Architecture” have started gaining traction in the last few years. It explains a way of designing software application as stacks of independently established services. There is no certain definition of this architectural style, but certainly, there are common characteristics which revolve around organizations especially in reference to business capability, intelligence in the endpoints, decentralized control of languages and data along with automated deployment. Microservices enables organizations to develop uninterrupted delivery/ deployment of large, complex applications.
Microservices Architecture breaks large software stacks into small, independent and loosely coupled services. Each of the services, it has a separate codebase, which further can be managed by a relatively small development team. Thus, the services can be independently deployed to smaller groups who can efficiently work on the project. At the same time, these small groups/ teams can update an existing service without rebuilding or redeploy the whole application.
Although the separation of the application into smaller parts is comparatively not a new concept. There are other programming models which also caters the same notion, such as the Service Oriented Architecture (SOA). But in Micro Services Architecture, there are new tools and techniques which have made it a success.
When it comes to Microservice architecture, it has its clear benefits for enterprises
Compact and uncomplicated code base:
Since the microservice architecture has the responsibility for only one thing, it tends to require less code. Thus, it is easy to understand, to reason about and has a tremendously low risk of changes.
The effortless process of scaling:
When there is a large, monolithic application, then one has to scale everything together. For example, an application has 2 parts – registration and login subcomponents. One realizes that the problem lies with the registration process, but then in a traditional architecture it alone cannot be scaled. Instead, we will have to scale the whole application which would be a complex and resource intensive process. With the recent evolution in technology infrastructure, for example, AWS; elastic scalability is quite a simple task to build microservices in-case the demand for a particular service is temporarily increased.
Easy to discard:
Solutions constantly keep evolving at a fast pace. What may have been cutting edge yesterday, might be considered outdated and slow today. Or maybe a vendor product that one earlier relied on, does not fit the bill anymore or one wants to move to the open source alternative. Majority of the time, it is easy to start from the beginning using new and modern tools and languages rather than to reuse old and outdated technology. This is where the microservices comes to rescue. It helps in facilitating the whole process.
Easy to Deploy:
In case of monolithic applications, for changing even one line of code requires redeployment of the whole application, at least on a platform like JVM. This could lead to complications for many organizations which can lead risk and disruption. Thus, using microservices makes the whole process easier as the scope of deployment is much smaller. Also, in case any problem arises, one would know how to scale the single issue.
Usage of different technology stack:
The approach used with micro service is to utilize the best available tool and language for the job instead of one size fits all. The same is applicable for databases too. It is also much easier and convenient to work with small teams. Each team can look into one micro service and also access other services through high level API.
In case a monolithic application stops working, then a lot of functionality will stop working. On the other hand, if a microservice stops to work, other functionalities will continue working. Thus, it is easy and simple to build some resilience around smaller service.
Challenges around Micro services for organisations:
One of the biggest challenge that an organisation may face in micro service architecture is to provide a means to troubleshoot a user workflow which will cut across multiple services. It is an issue because there is a lack of stack traces through services
Microservices have to closely communicate and rely on each other. Thus, a common communication channel has to be framed using HTTP/ESB etc.
Within Microservice every module relies on its own code, platform, and APIs, and they will require designing of multiple teams sometimes working concurrently on various modules of microservices. This requires strong monitoring to effectively track and operate the entire infrastructure, if a service disruption is not identified immediately it becomes difficult to track down issues when they arise
There may be many services that need to be monitored which might be using different programming language.so more microservices have to be created.
Logging mechanism for different services will be different which will result in GBs of distributed unstructured data.
Spanning of Transactions
There is a high chance that microservices may result in transaction spanning over multiple database and services. This further might lead to an issue caused at one place to cause a problem somewhere else.
Determining Root Cause
Microservices will lead to extra effort to find the root cause due to distributed logic and data. Although performance related root cause can still be worked out and managed by using tools like New Relic and Dynatrace.
Overlapping dependency between service
It is very difficult to reproduce a problem when it will be removed from one version and coming back with a newer version.
Testing can be complex
Testing in a microservices architecture is not simple. Each service has its own dependencies, as features are built, additional dependencies will emerge. Monitoring these changes becomes difficult, also as a number of services grow, so does complexity. It can be an error in a database, latency within the network or unavailability of service. Microservices architecture should be resilient enough to be able to handle faults. As a result, resiliency testing is a must.
The way Ahead
For Enterprise applications, one worth serious consideration is MicroServices architectural style. A Monolithic architecture is considered to be useful for simple and lightweight applications. Complex applications maintenance will cause a nightmare for any organizations. Despite the drawbacks and implementation challenges of microservices pattern, it is anytime a better choice for complex and evolving application.