1. Defining logical domain boundaries clearly

This includes –

• Domain data management (separate or shared Databases between one or more Microservices)

• Well defined interfaces for communication means that each Microservice does exactly what it is supposed to do and nothing else, so there is no overlapping of purpose or functionality across Microservices.
• Each Bounded Context of the domain maps to exactly one business Microservice, which in other words means the Microservice is cohesive within itself but not across other Microservices.
• Events propagation and communication methods within application and from outside application (HTTP/HTTPS or AMQP).
• API Gateway for single point of interfacing for the clients. (API Gateway or Backend for Frontend pattern)

2. Security Architecture:

Security design and implementation at multiple levels: authentication, authorization, secrets management, secure communication.

3. Orchestration:

Achieving scalability sounds simple but is by no means a simple task. Given the complex set of activities going on in parallel, orchestrating them at scale needs to be a well thought out plan. Using the Microservices tools is also important. Our experience at Parkar shows that Kubernetes and Helm are common technologies that have performed well for achieving scalability. It may look complex, but here are key aspects one should look into:

• Service registry and service discovery
• IP whitelisting
• Authentication and authorization
• Response caching
• Retry policies, circuit breaker
• Quality of service management
• Rate limiting and throttling
• Load balancing
• Logging and tracing
• Managed orchestration

4. Monitoring and health checks

Each service needs to be healthy to process requests. And hence monitoring service health is a key consideration. In one of the instances at Parkar, we have seen that sometimes a service instance is incapable of handling requests, yet it was running. And when we debugged further, we found that the specific service had run out of database connections. The key learning for Parkar from this, is that when this occurs, the monitoring system should generate an alert. The load balancer or service registry should also be designed intelligently so as to not route requests to the failed service instance. And ideally, the request should be routed to working service instances after checking the necessary pre-conditions.

5. Deployment (DevOps and CI/CD practices and infrastructure)

Faster release cycles are one of the major advantages of Microservices architectures. But without a good CI/CD process, you won’t achieve the agility that Microservices promise.

For example, assume, in an organization, there are sub-teams working on different features of an application. In case of monolithic application, something goes wrong for, say sub-team B, the release candidate of the application gets broken and there is no production rollout.

On the current application modernization project, Parkar team was tasked with reducing the application deployment time while improving the quality and ability to add new features rapidly. With Microservices, we were able to develop and deploy services rapidly and decouple the business functionalities to enable rapid deployment.

The key for us, at Parkar, has been following the Microservices philosophy, where there is not a long release train where every team has to get in line. The team that builds service “A” can release an update at any time, without waiting for changes in service “B” to be merged, tested, and deployed.

Now that we have looked at the key things to consider before you zero down on the Microservices architecture, there are certain things you must ask your team or your IT service implementation partner before you invest your money and time.