Microservices: Know why & Know how

As per Moore’s law, the number of transistors on a computer chip was doubling every 18 to 24 months — what would be Moore’s law for the future of Cloud?

We are in a time where code writes itself (eg. Github Copilot AI programming using the world’s advanced AI GPT-3). Mostly we are leading to a phase where repetitive tasks are not worth coding and technologists will have to innovate to create value. Yet, we are in a very interesting time where we are sandwiched between Legacy applications and platforms/products built using ultra-modern technology.

As technology continuously evolves, Software Architecture has been evolving big time.

• Monolithic to
• Service-Oriented Architecture (SOA) to
• Microservices

are a few Software design patterns/architectures we keep discussing.

There have been so many Software Architectural patterns that are ruling over several decades. By implementing Microservices or SOA, we do not stop using any of the below Microservices — we use them in the same way as we have used before.

Few of the core Design patterns

• Multi-tenant architecture (Software-As-A-Service SAAS based)
• Stateless / Stateful architecture design
• N-tier layered architecture
• Circuit breaker architecture
• Serverless Architecture
• Queue based architecture
• Event-Driven architecture
• Cache based architecture
• Bulkheads pattern
• Floating IP pattern
• Container-based application
• Database based application

we shall discuss more in a separate Architecture series. We shall touch base on a few of these patterns as part of the Microservices series where required.

What is Microservices

What if India is one big city-state country without its 28 states and 8 union territories? and what if Singapore has 20 states and is not a city-state country? This statement according to my puts up the uniqueness of Microservices and Monolithic and when to possibly use Microservices and Monolithic.

Coming back to India, given its size and massive population, instead of governing the country as one big entity having all the essentials such as military, housing, education, electricity, etc. and allied services “divide and rule” is the simplest and essence to manage such a huge country. Each of these States can be independently managed, services could be altered according to geography, people, climate, etc. but yet will constitute an entire country when viewed from outside. This is Microservices to you — it comprises independently deliverable programming units with its own required libraries and technology infrastructure and has interaction capabilities between one another to function as a unit as a whole so that it becomes one giant social media site or an e-commerce store when used by the general users.

At the same time, Singapore for its size and number of people works at its best and optimal if functions as a single entity with several districts for management yet have common governance and infrastructure.

From the above, we understand that the core of Microservices is its ability to design and implement independently as small functional units yet with the ability to function as one with inter-service communication either via Queues or REST API protocols. Each microservice is an independent box and knows only what it has and what it does, it does not know or care about what the other microservice is doing — all it does is it calls the next block in the chain and that block is treated as a black-box.

There are four main parts to Microservices

1. Business Logic: It is important to define the service boundaries or functional decomposition for each of the business functionality as Microservices which is done in liaison with the business users. This is the logic tier.
2. Data Access Layer: Here is where the data access happens and the extent of functional decomposition and how logically data is segregated and accessed to get a meaningful unit of data is the key. Business logic functional decomposition and Data access layer segmentation should be dealt hand-in-hand. The Data Access layer by the external consumers shall happen either via (1) Queues or via (2) REST API. There is no single method for the entire flow. The core strength of Microservices is its being technology agnostic.
3. Databases: Not a single database. The Database design for Microservices can either be (1) individual Databases (2) individual schemas (3) same schema and separation at row level. The same level of importance at the Data Layer we give to multi-tenant architecture must be given to the Microservices design pattern. How the transactions are committed and use of Saga pattern and how the final reports & analytics are performed from these distributed data sets must be catered for in the start itself.
4. Monitoring and Messaging Layer: Having a clear logging structure, enabling log aggregation and monitoring distributed systems from (1) system-level — CPU, Memory & Storage (2) Architecture level — Interprocess communication failures, time-out issues, etc. (3) Microservices level failures (4) Functional failures (5) Data related failures, etc. There are several sophisticated tools available to handle these complex tasks that shall be discussed in future sections.

Monolithic to Microservices. Image created by the author.

What problem Microservices try to solve

As we saw at the beginning of the article, there are so many design patterns and software architecture principles, why Microservices and why increasingly huge organizations are moving towards refactoring their applications, especially when moving to the cloud? Is it such a performance efficient or cost saver?

We have to note that, if you are looking for performance efficient or a cost-efficient solution, then Microservices is not your preferred architecture pattern. In fact, you may see a big lag in the latency and your cost might go up rather. Microservices is to have a lego bricks approach. Rather than developing and changing a giant code and keep on testing and fixing bugs, which is laborious and not a smart way of doing things, microservices a more commonsensical approach of “divide and rule” is easier to manage. Smaller is better to develop, test and deploy without disturbing the system as a whole and one failure does not bring down the entire system as a whole.

Key concepts/foundation of Microservices

While most of these concepts will be discussed in the future sections of this series, I am just putting a laundry list/cloud of concepts associated with Microservices grouped as categories.

1. Architecture / Patterns: Hexagonal Architecture pattern | Saga Pattern | Circuit breaker | Event-Driven vs. Orchestrator based | Side-car pattern | Security pattern | Logging and monitoring architecture | Scaling architecture | Failover architecture | Kubernetes architecture | Serverless architecture | DevOps architecture | Microservices development lifecycle
2. Functionality: Functional decomposition | Service boundary
3. Messaging in Microservices: Inter-service Communication | Kafka and Microservices | Graphql, and Microservices | Synchronous messages | Asynchronous messages | Service contracts | Message formats | Rest API | Service Mesh
4. Data: Decentralized data management | Database per service | Private schema per service | Private table per service | Distinguishing based on rows
5. Scale: Load balancing | Horizontal scalability | API Gateway | Service Registry | Service Discovery | HTTPS | Ingress controller | Kubernetes
6. Deployment patterns: Single service per host | Multiple services per host

We will cover the above under 4sections as part of this Microservices series.

1. Architecture Layer (Main and Supporting)
2. Modeling for Microservices and Microservices Patterns
3. Core concepts/building blocks
4. Microservices Development Lifecycle and the DevOps

Image by the author

Advantages & Disadvantages of Microservices

Any software architecture is heightened common sense that is templated with all the required critical factors so that we do not have to reinvent the wheel every time. But, while we use it, we should remember that we should not use these design patterns like a black box or just a vending machine, rather understand it and use the best features of it, understand the disadvantages and corner scenarios and continuously see if there is a room for improvement and or innovation. Well in this fast pace development cycle with Business pushing results there is very little time, but in a true engineering sense, this is required. Even though microservices is one of the finest design patterns, if you implement without addressing the specific concerns you will end up building a less robust and convoluted system. A quick SWOT Analysis will help to see the clear advantages and disadvantages of Microservices.

Advantages of Microservices:

Strengths:

1. Right fit of heterogeneous technologies
2. Robust
3. Loosely coupled
4. Technology agnostic
5. Lego-bricks approach and ease of development to deployment

Opportunities:

1. DevOps is not an optional function
2. Scale
3. Working as teams and align towards business
4. Effective Agile
5. Reusability
6. Moving from project to a product

Disadvantages of Microservices:

Weaknesses:

1. Major operational & technology overhead
2. Web of information flows and security concerns
3. The complexity of distributed systems
4. Monitoring and troubleshooting distributed systems
5. Developer’s pain points
6. Reporting & Analytics not so easy
7. Latency and performance issues

Threats:

1. Change of interface and disrupting the equation
2. Redundancy or code duplication
3. Testing
4. People understanding the overall flow
5. Application support and monitoring
6. Monolithic vs. Microservices running cost
7. Microservices is not for everyone
8. Breaching service boundaries due to urgent focus on business deliverables

Summary:

The beauty of Microservices is that there are so many independent services that keep chain linking and you can introduce or remove any service based on the need and one service does not know what the other microservice does, it is simply a black box. We shall explore more as part of this series “Microservices — Know why & Know how”.