Skip to main content

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
• IBM 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”.

Comments

Popular posts from this blog

Send e-mail with attachment through OSB

Oracle Service Bus (OSB) contains a good collection of adapter to integrate with any legacy application, including ftp, email, MQ, tuxedo. However e-mail still recognize as a stable protocol to integrate with any application asynchronously. Send e-mail with attachment is a common task of any business process. Inbound e-mail adapter which, integrated with OSB support attachment but outbound adapter doesn't. This post is all about sending attachment though JavaCallout action. There are two ways to handle attachment in OSB: 1) Use JavaCallout action to pass the binary data for further manipulation. It means write down a small java library which will get the attachment and send the e-mail. 2) Use integrated outbound e-mail adapter to send attachment, here you have to add a custom variable named attachment and assign the binary data to the body of the attachment variable. First option is very common and easy to implement through javax.mail api, however a much more developer manage t

Tip: SQL client for Apache Ignite cache

A new SQL client configuration described in  The Apache Ignite book . If it got you interested, check out the rest of the book for more helpful information. Apache Ignite provides SQL queries execution on the caches, SQL syntax is an ANSI-99 compliant. Therefore, you can execute SQL queries against any caches from any SQL client which supports JDBC thin client. This section is for those, who feels comfortable with SQL rather than execute a bunch of code to retrieve data from the cache. Apache Ignite out of the box shipped with JDBC driver that allows you to connect to Ignite caches and retrieve distributed data from the cache using standard SQL queries. Rest of the section of this chapter will describe how to connect SQL IDE (Integrated Development Environment) to Ignite cache and executes some SQL queries to play with the data. SQL IDE or SQL editor can simplify the development process and allow you to get productive much quicker. Most database vendors have their own front-en

Load balancing and fail over with scheduler

Every programmer at least develop one Scheduler or Job in their life time of programming. Nowadays writing or developing scheduler to get you job done is very simple, but when you are thinking about high availability or load balancing your scheduler or job it getting some tricky. Even more when you have a few instance of your scheduler but only one can be run at a time also need some tricks to done. A long time ago i used some data base table lock to achieved such a functionality as leader election. Around 2010 when Zookeeper comes into play, i always preferred to use Zookeeper to bring high availability and scalability. For using Zookeeper you have to need Zookeeper cluster with minimum 3 nodes and maintain the cluster. Our new customer denied to use such a open source product in their environment and i was definitely need to find something alternative. Definitely Quartz was the next choose. Quartz makes developing scheduler easy and simple. Quartz clustering feature brings the HA and