This week The apache Ignite book becomes one of the top books of leanpub

This week The apache Ignite book becomes one of the top books of leanpub.


Microservices – under the hood

Last couple of months, most of the conferences and seminar discussing and debuting about the new architecture design named microservice. From the first glance micro service means, developing independent small service which will be high cohesive in functionality and could be changed rapidly. Some of the IT evangelist already starts debating, why micro service is a buzzword. From my point of view word microservice misleading itself. Design model under this concept is as follows:
1. Service should be loosely coupled.
2. High cohesion in functionality.
3. Service should be change with minimal effect on other services.
4. Automated in deployments.
5. Scaling out easily.
6. Can be use polyglot programming language and polyglot persistence store.
Most of these requirements are nothing new at all. Developers or IT Architect who already familiar with SOA already know all these above concept very well. From my point of view, we have to clear following three things to giving start coding on micro services:
1. Which benefits we can get from micro service and how it’s differ from the standard j2ee development and deployments
2. How micro service differ from SOA.
3. Industry where we can actually propose to use such a new concept.

Benefits of using microservices over monolith system are very obviously. Best explanation you can find from the Martin Fowler article.
A service in microservice should be fine grained, and can be responsible only for one functionality. A service in SOA can responsible for many responsibilities and may be hard to evolve as any monolith application. Most of the other design concept for either architecture almost similar. But we also should remember another 2 most import benefit of SOA architecture design, first it’s given one entry point (or integration point) for all the congregant applications and second we can orchestrate or coordinate service call from SOA based applications. One thing doesn’t clear from the micro service design is that, who will be coordinator for all the micro service calls?

Martin fowler specifies the microservice architecture as follows:

"In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies."

Context boundary of “minimum of centralized management of these services” is not so clear. May be only SPA (Single Page Application) can have minimum managements of services. However, if we can eliminate all the design patterns of ESB from SOA, both design approach of SOA and microservice will be the same. Definitely many vendor just miss guided the SOA movement in wrong direction with ESB to sell their product. We have never properly guided by any SOA governance, which causes the failure of the most SOA based project. Also SOA never help us to understand how to split monolith service into smaller pieces of service or how big is to big.
If we want to implement microservice we have to understand how to split service and how big is a big service.

Most of the time a lot of new ideas and technologies come from hi Tech Company such as Amazon and Google. NoSQL is one of them for example. Most of all times, these type of high technology related companies need to supply new possibilities to customer as soon as possible. Thus it is very important to find a way to change rapidly in their application and deploy as quickly. Also they are using polyglot programming language and persistence data store for various purposes. But if we taking a closer look to our customers, most of them are banks and telecommunication companies. This industry is very conservative with their own requirements and cultures. You can’t easily drag a new technologies or trend to such companies. From my experiences we cannot convince one bank to use Ansible to automate all the deployment process on more than 34 servers. Maintains department is very happy with manual deployment of all the artifacts in 34 servers. Either, I am sure, if you will propose that we want to provide docker with all our microservice for deployment, they will not very happy.

Then what is the best approach for such industries? Designing application with modules of services, which have very clear context boundary with high cohesion. It’s better to explain with example, suppose we have a few services such as sending SMS, e-mail or any push notification to clients. According to microservice design approach, you have to develop three different services, which will process independently and will maintain separately. It cloud be three different war file or can be spring boot application for examples. This approach giving granularity, but also complexity in the sight from maintaining. If we developing all the above three services in one module and will deploy as a one artifacts, nothing goes wrong. Off course if we will have to make a change only in e-mail service, we will have to redeploy whole module with other services. However one module with three different services is easy to maintain and they are very similar in operations. These types of modules we can deploy in single servlet container in tomcat or in elastic cat as isolated application for fault tolerance. Let me give a example of such application, in 2013-2014 we developed an application for Telecommunication to mobile number portability. From the business functionality we had the following context boundaries:
1. Business process execution in BPM server.
2. Exchanging message during business process execution with external system.
3. Exchanging messages with internal systems such as mobile switch control, delivery SMS, billing e.t.c.
4. One page web portal for operator.
5. Event processing.
Also we have polyglot persistency store, RDBMS and Cassandra Big Table.

Every module is highly cohesion in functionality and clearly separated by their responsibilities. Business processes was dramatically complex with more user interaction, for these reason we decided to use asynchronous interaction with external systems and thoroughly use short circuit pattern to got fault tolerant system. For internal interaction between different modules we uses binary protocol and for interaction with external modules we have http protocol. As a result we have got the following stack
• Spring
• Activiti BPM
• MyBatis
• Active MQ
• Oracle 11gR2
• Cassandra
• FlywayDB for incremental update of DB
• Ansible for automation of Deployment
• Nagios for monitoring
System is highly configurable and scaling horizontally. Changes or bug fixes in one modules gives very small effects on others modules. In conclusion I have to repeat what said martin fowler “don't even consider microservices unless you have a system that's too complex to manage as a monolith”.

No comments :