Nand Kishor is the Product Manager of House of Bots. After finishing his studies in computer science, he ideated & re-launched Real Estate Business Intelligence Tool, where he created one of the leading Business Intelligence Tool for property price analysis in 2012. He also writes, research and sharing knowledge about Artificial Intelligence (AI), Machine Learning (ML), Data Science, Big Data, Python Language etc... ...Full Bio
Nand Kishor is the Product Manager of House of Bots. After finishing his studies in computer science, he ideated & re-launched Real Estate Business Intelligence Tool, where he created one of the leading Business Intelligence Tool for property price analysis in 2012. He also writes, research and sharing knowledge about Artificial Intelligence (AI), Machine Learning (ML), Data Science, Big Data, Python Language etc...
Data science is the big draw in business schools
491 days ago
7 Effective Methods for Fitting a Liner
501 days ago
3 Thoughts on Why Deep Learning Works So Well
501 days ago
3 million at risk from the rise of robots
501 days ago
Top 10 Hot Artificial Intelligence (AI) Technologies
Monolithic to Microservices Architecture - Scalable Approach
Scalability, Performance, Rapid & flexible development are some of the key considerations while designing the architecture of any product at ValueFirst Engineering. Traditionally, we were following the monolithic architecture (obviously layered architecture). As volume, load and expectation of rapid and complex customizations/development has grown multi-fold, we have shifted to microservices architecture or hybrid microservices architecture to cater technical considerations, and volume growth expectations.
Let's relate the monolithic application with Big Ball of Mud, kind of system without any pattern. Applications built on unplanned structure or architecture, over period becomes complex. With every release, more line of code gets added to the application.
-Code becomes duplicate,
-Difficult to understand by developer on such huge code,
-More time required for bug fixing,
-More time required for new enhancement,
-High Chances of error to be occurred on unknown areas.
Though application works fine and successful, means generating decent revenue. But keep on adding risks and threat, and delay time to market. Ultimately heap of code due to non-existence of base structure start releasing foul smell.
Here is the reference logical architecture
Every component in product is independent and runs in different process. User Interface layer and other modules access each other through services or API.
Before we take you on benefits realized, let's quickly explain Microservices architecture, and overlapping difference between Microservice and SOA, this would help beginners to understand better.
Microservices architecture involves splitting complex application into independent applications/ processes, and exposed as service.
You must be wondering and relating this with SOA, yes looks like same but if you see in detail, there is basic difference between two - SOA is primarily at enterprise level, for e.g. exposing applications functionality as services to other applications.
Microservices are subset of SOA, where Microservices focussed to serve within application, whereas SOA to other applications.
Having said that, doesn't mean every single functionality/feature you will start writing as service. It should be a core product feature/component, which actually add value, makes architecture manageable, and further lead to SOA , more like a bottom-up approach (As we use multiple technology stack for different product e.g. Java, .Net and PHP. Separating out the code base, help to easily use independent component in other products irrespective of thinking on technology, elements of SOA will be achieved).
Though each service has its own database to ensure loosely coupled, at the same time it is important to ensure data integrity. Data traverse from one service to another where each service holds a particular set of data. This can be covered a) by proper planning whether each service require separate DB b) maintain integrity through event driven approach across services to update dataset as per flow.
In microservice architecture, each service is an independent piece of code (i.e. packaged either in jar/war/ or any other format as per programming language) and hence each service has its own instance, which in turn a process. Interaction between services is called inter-service communication or typically Inter-process communication.
There are different communication mechanism (i.e. synchronously/asynchronously/event based) and formats (i.e. JSON/XML). You can decide inter-process communication mechanism depending on the requirement and use case e.g. HTTP or messaging with JSON/XML Format. In our case we have implemented both HTTP/HTTPS with JSON, and RabbitMQ for interaction between services for asynchronous processing. In order to add security layer, we have used OAuth2.0 in order to implement Authentication and Authorisation.
Though micro service architecture is typically designed for internal interactions, but at times it also help to meet requirement to expose similar service to external application, which can be done through URL configurations, and additional token based (or any other) security options e.g. like SAML, OpenIDConnect, HTTP(S) Basic Authentication, SSL Certificates etc.
Let's see some of the benefits of using microservice architecture:
>Develop and deploy each service independently, easy to manage and build
>Easy to Scale -Microservices architecture support scaling application component wise. For e.g. in our case, one of feature required to upload, clean and process heavy size file (say approx. 1 cr. records). Multiple users can upload heavy files concurrently. Similarly execution of multi-channel campaigns requires memory and CPU to perform complex logics. As per microservice architecture, we have created these as separate application with DB. Easy to deploy separately and fulfilling the required compute and memory requirements.
>Allow to use different technology and avoid technology limitations. As each service is independent, and hence can be developed in different stack to meet the business requirements.
>Limit impact and easy to debug. In case of any error, particular service is easy to debug and trace error. This would also avoid impact on other par, and continue to work properly.
Here are best practices to follow:
>By definition each micro service should be independent of any other service, can have its own release & dev cycles.
>Deploy API health monitoring and alters to identify the concerning point where multiple micro service within same product.
>Configure less timeout for micro services to avoid failing multiple services, and identify the point of failure.
>Maintain versioning for each micro service / API.
>Rightly decide on deployment architecture to manage requests from each service. Multiple micro services eventually creates traffic even no significant user traffic, as services interacting each other puts requests to server. This has been observed that internal services create more load than the actual user request.
>Prefer to have Single source of truth to every data. Generally it is suggested to have separate DB but this may increase chances of data inconsistencies. Hence take right decision after proper analysis in given situation.
>Implement auto retires wherever possible to mitigate failures, primarily in case of background jobs/queues.