Micro services Fundamentals
Microservice
Microservices was a hot topic couple years back when it was first introduced. Sooner than later, it became something every software engineer or anyone in the IT industry must know. To be fair, it is something that has been globally adopted by companies around the world at an increasing rate.
Before talking about microservices, we should first take a look at how applications were developed before microservices were introduced. A traditional application used to be monolithic. All the services and functionality of an application such as the frontend, backend and multiple other components were baked into one giant application. The shear number of interconnected components made them a nightmare to manage.
Microservices on the other hands, is a type of architecture where the application is broken down into smaller services based on the domain.
Strengths of the Monolithic Architecture
- Less cross-cutting concerns : Cross-cutting concerns are the concerns that affect the whole application such as logging, handling, caching, and performance monitoring. In a monolithic application, this area of functionality concerns only one application so it is easier to handle it.
- Easier debugging and testing : In contrast to the microservices architecture, monolithic applications are much easier to debug and test. Since a monolithic app is a single indivisible unit, you can run end-to-end testing much faster.
- Simple to deploy : Another advantage associated with the simplicity of monolithic apps is easier deployment. When it comes to monolithic applications, you do not have to handle many deployments — just one file or directory.
- Simple to develop: As long as the monolithic approach is a standard way of building applications, any engineering team has the right knowledge and capabilities to develop a monolithic application.
Weaknesses of the Monolithic Architecture
- Understanding: When a monolithic application scales up, it becomes too complicated to understand. Also, a complex system of code within one application is hard to manage.
- Making changes: It is harder to implement changes in such a large and complex application with highly tight coupling. Any code change affects the whole system so it has to be thoroughly coordinated. This makes the overall development process much longer.
- Scalability: You cannot scale components independently, only the whole application.
- New technology barriers: It is extremely problematic to apply a new technology in a monolithic application because then the entire application has to be rewritten.
Strengths of the Microservice Architecture
- Independent components. Firstly, all the services can be deployed and updated independently, which gives more flexibility. Secondly, a bug in one microservice has an impact only on a particular service and does not influence the entire application. Also, it is much easier to add new features to a microservice application than a monolithic one.
- Easier understanding. Split up into smaller and simpler components, a microservice application is easier to understand and manage. You just concentrate on a specific service that is related to a business goal you have.
- Better scalability. Another advantage of the microservices approach is that each element can be scaled independently. So the entire process is more cost- and time-effective than with monoliths when the whole application has to be scaled even if there is no need in it. In addition, every monolith has limits in terms of scalability, so the more users you acquire, the more problems you have with your monolith. Therefore, many companies, end up rebuilding their monolithic architectures.
Weaknesses of the Microservice Architecture
- Development: Need to identify all the dependencies. Complete build of the system means all the services are built.
- Testing: All the Microservices needs to be tested in order to ensure that the output of one service is the desired input for another service. Contract driven testing needed for such assurance.
- Monitoring and Logging: All the Microservices need to be monitored continuously and logged with alerts if, the matrix is going wrong.
- Backward Compatibility: It’s super important to maintain versioning and backward compatibility as the system is so complex.
Why are Microservices better than Monolithic applications?
Most people think that microservice architecture is objectively better than monolithic approach. This is not necessarily true, they are both different ways of designing an application. This means there are use cases where a monolithic design is better for example a website for a small boutique business. However, for most of the other cases using microservices architecture is better.
Choosing a monolithic architecture
- Small team : If you are a startup and your team is small, you may not need to deal with the complexity of the microservices architecture. A monolith can meet all your business needs so there is no emergency to follow the hype and start with microservices.
- A simple application : Small applications which do not demand much business logic, superior scalability, and flexibility work better with monolithic architectures.
- No microservices expertise : Microservices require profound expertise to work well and bring business value. If you want to start a microservices application from scratch with no technical expertise in it, most probably, it will not pay off.
- Quick launch : If you want to develop your application and launch it as soon as possible, a monolithic model is the best choice. It works well when you aim to spend less initially and validate your business idea.
Choosing a microservices architecture
- Microservices expertise : Without proper skills and knowledge, building a microservice application is extremely risky. Still, just having the architecture knowledge is not enough. You need to have DevOps and Containers experts since the concepts are tightly coupled with microservices. Also, domain modelling expertise is a must. Dealing with microservices means splitting the system into separate functionalities and dividing responsibilities.
- A complex and scalable application : The microservices architecture will make scaling and adding new capabilities to your application much easier. So if you plan to develop a large application with multiple modules and user journeys, a microservice pattern would be the best way to handle it.
- Enough engineering skills: Since a microservice project comprises multiple teams responsible for multiple services, you need to have enough resources to handle all the processes.
Microservice Architectural Patterns
- Decomposition patterns
- Decompose by business capability
- Decompose by subdomain
2. The Database per Service pattern describes how each service has its own database in order to ensure loose coupling.
Get Kumuthini Ashokkumar’s stories in your inbox
Join Medium for free to get updates from this writer.
3. The API Gateway pattern defines how clients access the services in a microservice architecture.
4. The Service Discovery patterns are used to route requests for a client to an available service instance in a microservice architecture.
5. The Messaging and Remote Procedure Invocation patterns are two different ways that services can communicate.
6. Testing patterns:
- Service Component Test and Service Integration Contract Test
- Circuit Breaker
- Access Token
7. Observability patterns:
- Log aggregation
- Application metrics
- Audit logging
- Distributed tracing
- Exception tracking
- Health check API
- Log deployments and changes
8. UI patterns:
- Server-side page fragment composition
- Client-side UI composition
Key Characteristics of a Microservice
To get the full benefit of microservices architecture, there are some characteristic it must have.
- Bounded Context : This simply means that the domain of the application must be considered deeply before creating services.
- Independently Scalable : The microservices should be loosely couple allowing them to independently scale according to the needs of demand.
- Independently Deployable and Testable : As microservices are loosely couple, they should also be able to be tested independently and deployed independently without conflicting with the existing services.
- Small Team : As microservices requires knowledge of the entire lifecycle of the application, it should have a small team of full stack developers. The recommended size is 6–10 developers.
Scalability of microservices
The Scale Cube is a three-dimensional scalability paradigm described in the book The Art of Scalability.
X-axis Scaling (Horizontal Duplication)
Running numerous copies of an application behind a load balancer is known as X-axis scaling. Each copy handles 1/N of the load if there are N copies. This is a straightforward and widely used method of scaling a program.
An application should be able to scale up and down through x-axis. If one instance is insufficient, we should be able to spawn another instance and go on.
Z-axis Scaling (Data Partitioning)
When using Z-axis scaling each server runs an identical copy of the code. but at the database level, data is partitioned into different shards. Therefore each server is responsible for only a subset of the data. Some component of the system is responsible for routing each request to the appropriate server. for Ex: European customers are directed to European servers, Asian customers are directed to Asian servers etc.
Y-axis Scaling (Functional Decomposition)
This approach of scaling can be achieved by decomposing an application into smaller, independently deployable units. Microservices are well-suited to such a scaling paradigm because microservices are independent smaller services with their own database.
As a result, if our application has a high-demand service, we can only clone that particular service, rather than cloning the entire application.
Things to keep in mind when developing a microservice
- Each service should be able to use different programming languages, frameworks.
- Domain-driven design: services should be developed in such a way that a service can run independently without depending on other services.
- Service resilience and fault tolerance must be implemented: Because all services will communicate with one another, if one or some service fail to work or not responding, we need to have a proper mechanism in place to maintain this condition (Circuit breaker pattern, proxy etc).
- Use appropriate available frameworks for microservice development and deployment: we don’t have to invent everything; there are various frameworks that can do various task which we require.
- We need a full-stack team that can handle all aspects of the project.
— — — — — — — — — — — — — — — — — — — — — — —
Give your response and stay connected for more :-)
There are more to come :-)
I hope you liked the article.
Thanks for the reading!
— — — — — — — — — — — — — — — — — — — — — — — —
