This blog is a one-stop knowledge point for Microservices architecture, in general, and introduces Ninjacart’s microservices platform in particular.
In a system where services are developed in a monolithic architecture, they are interdependent and hence seek the need to be designed, developed, tested and deployed, together, at the same time. Also, the tech stack for such services has to be the same. Thus, when the number of services increases over a period of time, it becomes complex to manage and maintain.
To solve these basic issues, a system of services can be converted to a Microservices architecture, where each service is developed separately by a dedicated team and deployed with its own release cycle. There are many benefits of this approach of separating the back-end logic into multiple microservices, but there are challenges as well that this approach needs to be wary of. The next section discusses the same.
Benefits & Challenges of a Microservices Architecture
- Promise of agility and faster time-to-market achievement. For example, because microservices are easier to understand, and enhance in smaller pieces, therefore they are easier to deploy. Data management is decentralized and thus brings in more agility to the system.
- More innovation can be accomplished by using the best technology for each problem, and by thus making the switch between technological bases easier. No long-term commitment to some specific technology is necessary.
- More resiliency. For example, better fault isolation, less impact on other services when an error happens. It is achieved through resiliency patterns like bulkheads, circuit breakers. All in all, better availability through graceful degradation.
- Better scalability is achieved through the separate deployment of services, and auto-scaling features of the infrastructure, paired with resiliency patterns to avoid any overload.
- Better reusability, which can be achieved through an organization around business capabilities (instead of product or platform features), and interface patterns like “Tolerant reader” or Consumer-Driven Contracts.
- Promise of Improved Return on Investment (ROI), and better Total Cost of Ownership (TCO), achieved through faster (thus cheaper development), and the use of cheaper commodity hardware.
- Designing decoupled, non-transaction systems as opposed to old-style monoliths is difficult.
- Keeping data consistent and available while scaling above and beyond traditional databases.
- Many more “moving parts” with many more potential error cases force using graceful degradation approaches.
- The increased number of deployment units and their dependencies in the infrastructure leads to complex configurations that need to be maintained.
- Duplication of efforts across implementation teams and an increased cost through multiple different technologies.
- Integrated testing is difficult when there are only separate microservice teams.
- Greater operation complexity through more moving parts and more operational skills are required from your development team.
A Typical Microservices System
The following diagram shows a typical microservices architecture with basic infrastructure:
The following services form an integral part of a microservices system:
Ninjacart’s microservices platform
The following diagram depicts the architecture for the Traders App implementation:
The API Gateway
The entry point for all actors (users, support, services) is the API Gateway. API Gateway has the intelligence to route a certain API call to the right instance of the service that implements it; a.k.a. the right microservice, the right API and the right server with authentication.
The following diagram shows, how the call to ledger API gets routed:
So, a Microservice is a small unit of work, that is independently tested, deployed and maintained. Each Microservice can be developed in the specific tech stack that suits its requirement, and is typically solely owned by an independent team. Finally, the business perceives the whole as a collection of microservices and this drastically reduces the time to market as each service is a small unit of work and is independently deployable.
Director of Engineering