In technical terms, a microservice system allows development of single function modules. This trend of developing single function modules has increased agility, performance and cost efficiency for organizations both large and small while enabling continuous testing and early delivery. But, before we delve deeper into the fundamentals of microservice design let us have a look at its advantages.
Advantages Of Microservice Architecture
Technological Flexibility
While monolithic architecture always left the developers looking for the “right tool for the job,” a microservice architecture offers coexistence of multiple technologies under one cover.
Different decoupled services can be written in multiple programming languages. Not only does this enable developers to experiment but also scale their product by adding additional features and functionalities.
Increased EfficiencyMicroservice architecture speeds up the entire process of creation. Unlike a single unit, teams can work simultaneously on multiple components of a software system. This, in addition to increasing productivity, makes it easier to locate specific components and focus on them.
Malfunctioning of a single component will not affect the entire system. Instead, this also eases error location and maintenance.
Products Not Projects
According to Martin Fowler, microservice architecture helps businesses create “products instead of projects.” In simpler terms, the use of microservice architecture allows teams to come together and create functionality for business rather than simple code. The entire team comes together to contribute to different functionalities. These can further be used for different lines of business if applicable. In addition, it also creates an autonomous, cross-functional team.
Fundamentals to A Successful Microservice Design
1. The Scope Of Functionality
guidelines or steps to define the scope of microservice are:
a) identify the code or peice of coe replicated under various modules
b) identify module is loosely coupled with rest of services
c) check if the features would be used with heavy load, allows the microservice that would have to be scaled up in the near future.
2. High Cohesion Combined With Loose Coupling
When breaking down a monolithic architecture into smaller services or components, it is important to combine similar functionalities. This combination of related logic into a single unit is known as cohesion. The higher the cohesion, the better is the microservice architecture. A low cohesion would indicate too much communication between different services leading to poor system performance.
3. Unique Source Of Identification important for any service to be the unique source of identification for the rest of the system. e.g. for order mgmt service order id is of the source of truth for other services (rather than other attributes of order record)
4. API Integration
The fundamental of microservice design is using the correct API. This is crucial to maintaining communication between the service and the client calls. Easy transition and execution are important for proper functioning.
Another important thing to note while creating an API is the domain of the business.
This definition of the domain will ease out the process of differentiating the functionality.
There are several clients which are external to the system. These clients could be other applications or users. Whenever a business logic is called, it is handled by an adapter (a message gateway or web controller) which returns the request and makes changes to the database
5. Data Storage Segregation
Any data stored for a specific service should be made private to that specific service.
This means any access to the data should be owned by the service. This data can be shared with any other service only through an API. This is very important to maintain limited access to data and avoid “service coupling.” Classification of data based on the users is important and can be achieved through the Command and Query Responsibility Segregation (CQRS).
Command and Query Responsibility Segregation (CQRS): Every CQRS object is divided in two objects: one for the query and one for the command.
A command is defined as a method that changes state.
On the contrary, a query only returns a value two data stores 1 for read and another for writes
queries are read from the read store
commands updates messages to write store and also updates events to read store (which serve queries).
6. Traffic Management
Once the APIs have been set and the system is up and running, traffic to different services will vary. The traffic is the calls sent to specific services by the client. In the real world scenario, a service may run slowly, thus, causing calls to take more time. Or a service may be flooded with calls. In both the cases, the performance will be affected even causing a software or hardware crash.
This high traffic demand needs management. A specific way of calling and being called is the answer to a smooth flow of traffic. The services should be able to terminate any such instances which cause delay and affect the performance.
This can also be achieved using a process known as ‘auto-scaling’ which includes constant tracking of services with prompt action whenever required. In some cases, a ‘circuit breaker pattern‘ is important to supply whatever incomplete information is available in case of a broken call or an unresponsive service.
Circuit Breaker Pattern (CB): circuit breaker pattern protect against cascading failures and to provide fallback behavior for potentially failing calls.
7. Automating The Process
CI & CD of microservice
8. Minimal Database Tables (Preferably Isolated Tables)
Accessing database tables to fetch data can be a lengthy process. It can take up time and energy. While designing a microservice, the main motive should revolve around the business function rather than the database and its working. To ensure this, even with data entries running into millions, a microservice design should have only a couple of tables. In addition to minimum numbers, focus around the business is key.
9. Constant Monitoring
prometheus, caching etc.,