Left side is monolith whereas right side is SOA(where every one is doing there own job and together making beautiful rythm) .
In this article we are going to learn about micro services architecture, why micro services, micro services pros and cons, when to opt or not micro services, SOA, micro services pitfall and things to consider before implementing
SOA (Service Oriented Architecture)
As per Wikipedia :
A service-oriented architecture (SOA) is a style of software design where services are provided to the other components by application components, through a communication protocol over a network. The basic principles of service-oriented architecture are independent of vendors, products and technologies. A service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online.
A service has four properties according to one of many definitions of SOA:
- It logically represents a business activity with a specified outcome.
- It is a black box for its consumers.
- It may consist of other underlying services
We can Define a service as a business function which performs set of task, For example consider a normal e-commerce application which has multiple features like cart, online payment, delivery, category listing etc.
Here we can divide application into multiple services like payment , cart, delivery, product and category services etc. where each service will perform set of task and each service will call api’s of other ‘s for data, operation.
In this design one service becomes the owner of set of task and other services just use it instead of developing it.
Services must have their own data store and other dependencies listed. Divide Service Dependencies into critical, optional and non-critical.
Critical dependencies must be satisfied for a service to initialize successfully.
Sample Image of how Micro Services could look like.
- Its a more refined version of SOA.
- Split Service into smaller components.
- Size of service depends on use case basis, We can go upto one api one service paradigm(Single Responsibility), I don’t like breaking services to this granular level as complexity of systems increases with more components.
- Service registry and Inter service communication framework forms the core of this architecture. Spring cloud provides it by default.
- Services must be able to scale and deploy independently.
- Services generally communicate over http/tcp/rpc.
- Every Service is an independent process, In SOA multiple services can be clubbed and deployed as a single process.
- Services are self contained and deployed independently.
- Service wise versioning is easy which actually avoids need of API versioning, however based on size of service one could consider API versioning alongside service versioning.
- One service release doesn’t affects others, which means each service development cycle can be different.
- No code repetition, as only one service owns a set of operation and others use it.
- Bug fixing and patch release is easy.
- Scaling is easy.
- Ensures and focuses on re-usability which is write once.
- Beneficial for Software service providers as they have to build component/service only once and use the same for others.
- Services are small hence re write is easy.
- Library upgrade, different technology or moving from one tech stack to others is fairly easy in this architecture.
- Collaboration is easy and rapid development is possible.
- Readability and maintainability of each is service and eventually whole system is good.
- Test Automation is fairly easy.
- Well Every system has some or other pitfalls, this architecture also has few.
- Initial development is slow.
- Strong DevOps and Automation is must, more services means more cluttering, more servers need and many more middle-ware integration.
- Database consistency is little difficult to guarantee, however there are many design patterns are available which will ensure eventual consistency in near real time.
- Larger development team size.
- Network calls increases.
- System design needs to specially take into consideration for fault tolerance and retrial.
- Services are free to use different tech stack which means request and response format (xml/json/html) could vary. Integration will be difficult without good library to transform data between different formats .
- Tracing an exception/ error could be really difficult without having proper logging/tracing module.
- Databases are different so across tables join is not possible.
Why Micro Services:
After meeting with many developers the most common question which I had to answer is why we should go for this architecture when our current system is working fine.
My answer is :
We must at least go for SOA.
Micro services provides rapid development and once architecture is setup prototyping of new features becomes fairly easy. Different technologies and developers location is not a bottleneck in this case. Parallel and fast development is what it offers, Some or most of the time we have to re write existing code, as we know reading someone else code and writing it again is more time consuming task then writing fresh and here this architecture helps us as components are already small we can just throw it and write fresh. Bug identifications and fixing is fairly easy here. Incorporating fast business requirement changes are super simple in this case whereas in monolith its always like scratching your head.
Organizations which are multilingual and multinational can benefit from this architecture.
If there is a monolith system and developers are comfortable then it becomes a challenge, Why? coz in monolith environment everything is available right there however in micro services case its cluttered.
First thing first, We cannot build a big application and scale it massively in monolith that’s the super limitation and if we can’t scale or build new things then monolith pros becomes its cons.
Monolith systems will be deadlock for organizations which are planning to expand in near future.
When to choose microservices/SOA:
Are you building something similar like Netflix, AWS.?
Are you planning to go i18n and l10n soon?
You have multi city/country Development center, .
Do You want rapid development cycle with one time extra efforts?
You don’t like whole application is down due to small mistake .?
You are ready to move towards automation.?
You have big team or planning to expand.?
Do You want rapid development of new features?.
Do You want rapid incorporation of changing business requirements?.
If Answer to any of the above question is yes the you need at least SOA.
Major Problems in SOA/micro services:
- When more services then how to do orchestration, most of the design problems come at this stage also.
- Client side there is few domains to call but server side there are 100s of services what to do and how to do.
- What will happen if Service/layer which is doing orchestration is down, Will it start behaving like monolith, well this is architectural design problem .
- In monolith all database and tables are at one place however in this case its on different places.
- There are cases when we need to join multiple tables to get data and similar needs will arrive in this case also but now its really really difficult to join tables actually we can’t join tables, However there are design guidelines to overcome this problem.
- Logging of exceptions,errors and tracing is cumbersome. What failed where is difficult to identify, However there are design patterns to solve this case.
- Forget about Database transactions across multiple services, its really difficult to implement it but we actually don’t need always consistent database, really do we?.
- Without proper DevOps and Automation It will bite us back.
- Easy Development and system monitoring different typed of libraries integration. However this is generally one time effort and nowadays most of the libraries are freely available.
- Deployment is cumbersome.
- Service discovery, communication protocols decision.
- Lots of network calls avoidance.
Things to Consider for doing SOA/ microservices:
- Break services logically and put more often needed api’s together in one service.
- Separate Database and DB credentials for each service, Never club databases of services.
- Build Data Pipeline / Analytical service which will collect data from various services and aggregates it for various analytical operation.
- Consider Caching solution, I preferred central cache like redis but distributed is also good.
- Carefully design your orchestration layer.
- Logging/ tracing solution.
- Eventual Consistency for data stores.
- Try to use homogeneous technologies initially and when things are up you could consider mixing tech stacks.
- Not every Service needs incoming http/tcp api’s.
- Consider building Services like library which provides normal function call.
- Sometimes we unnecessarily creates http service.
- Not every service needs to be at micro level, We can have mixture of small and big services.
- Consider creating utility layer and implementing shared model concept which powers every service.
- Consider Dockerized/Containerized deployment using automated tools like Kubernetes.
- Prepare good system design document listing all components with answer of basic questions for each component like what, why , how and when.
When not to go for SOA:
Until unless you are bootstrap/prototyping, You must consider SOA, Number of services/components can be less or more depending on case studies.
When not to go for micro services:
With this We want to know when we should not move from SOA to micro services.
- Service is fairly stable and no scaling issues.
- Less conflicts when multiple developers contribution, or We have fixed set of people who are contributing and there is no issue.
- Readability , maintainability is good.
- Bug fixing does not take time(here time might vary based on kind of bug), However what I mean to say is Identifying nature of bug and how to fix should be fairly easy.
- New Developers are productive in fairly less time.
- Some other service has not started doing what this used to do.
- Adding new features is not like scratching head.
We should not move from SOA to micro services if all of the above conditions are met.