Architecting Microservices

Architecting Microservices

What to expect from this post?

You have heard the buzzword .. Yes, go the 'microservices' way!
We heard this term too and started to go down this route..

I intend this post to walk you through what follows there-after.. the path of evaluating, discussing the fundamental aspects, pros and cons of microservices, deciding if we are ready to take 'microservices' on !

Starting 'Microservices'

What's such a big deal with microservices? Microservices is a whole new ball game, in terms of  operations, DevOps(CI/CD), development and architecting.

Below are few interesting discussions we had when we went out exploring Microservices:
- Microservices is a good thing but nobody has done Microservices here. You will not get any help if you get stuck.
- We will need massive investment in terms of infrastructure, monitoring, deployment pipeline. Do we want to go this route, especially if it is only our team and not the organizational guideline?
- We must avoid distributed transactions. Let's not over-complicate the system.
- We should go the Microservices route. You should justify microservices so that management decides on Microservices.
- We are not convinced either ways - To Microservice or not to microservice.

Conclusion : With all the background discussions, we took the first step and decided we will not go the mcroservices way big bang but will keep our architecture in line with Microservices.

Continuing with 'Microservices'

We went understanding the microservices more.. jotting down few more interesting discussions around microservices aspects:

Granularity : 

- I don't think we should have so many micro-services. This should not be a micro-service...

- Breaking into microservice makes sense if we need scalability for this module. Why break application unnecessarily into microservice?

Conclusion: We decided to divide the system in independent logical/functional stand-alone units and let these units serve the purpose of micro-services.

Indepenence :

- Why do we need separate database for each microservice?

- Why cannot 'Module-1' just invoke 'Module-2 database'?

Conclusion: Each microservice has its own database which makes the service completely independent and a replaceable unit.

Inter-service communication :

- Inter-service communication is a big overhead .. system becomes slow. It's a concern with microservice architecture. Do we need to have microservices?

- Why shouldn't we have synchronous inter-servicecommunication.

Conclusion: Inter-service communcation is an overhead but probably an affordable one with the advantages of microservices. The communication can be synchronous or asynchronous. However, with network partitioning coming into picture for distributed computing, asynchronous communication takes care of distributed transaction via eventual consistency.

Service Discovery :

- Why can't we just invoke the REST end-point of Module-2 from Module-1?

- Why do we need any service registry?

Conclusion: Service discovery helps with dynamically allocated resources and more so with dynamically changing resources (like with auto-scaling, failures, etc). NGinx, Eureka are few examples for service discovery.

API Gateway :

- What is an API Gateway?

- Why do we need an API Gateway?

Conclusion: We have decided to do away with an API Gateway, as becoming part of an already existing (chosen/decided) architecture.. By the way, an API Gateway is a server that is the single entry point into the system. It is similar to the Facade pattern from object-oriented design. The API Gateway encapsulates the internal system architecture and provides an API that is tailored to each client.

To be continued...

Implementing 'Microservices'

Handling Distributed Transactions

Dockerizing Microservices

... and will add as things become clearer..