Microservices
The term “Microservice Architecture” has sprung up over the last few years to describe a pattern of splitting an application into smaller components for scalability and maintenance benefits and have seen widespread adoption.
Idea:
The main idea behind this architecture is to break down applications into very small pieces and each piece can be developed, test and deployed independently.
Each module/piece bears single responsibility and it becomes easy to track which piece is malfunctioning and to gets its replacement and
also to scale one piece only if only one piece requires more traffic.
Is it new?
It is not a “new” style of building large enterprise applications.
Many leading IT companies were using it to scale their applications, but no formal name was given. Also, there are other programming paradigms that address this same concept, such as Service Oriented Architecture (SOA).
Is it different than SOA?
Microservices are SOA done correctly. The core difference between SOA and microservices lies in the size and scope.
As the word “micro” suggests, it has to be significantly smaller than what SOA tends to be.
Also, SOA is an architectural pattern in which application components provide services to other components.
On the other hand, in microservices, these components are suites of independently deployable services.
Reasons for migrating to microservices:
More availability: All components can be deployed to various servers. So, if any component dies, then we can have a similar component responding from other machines. Even if a single component dies in all servers, only a few functionalities will be impacted.
More scalability options: All micro-components have their own servers and if we know that one component needs more traffic, then it will be easy to increase memory for that server and it will be more effective as compared to increasing memory for a single full application.
Independent development: Developers can work independently on their microservice and independent of the technology used for each microservice.
Emerging technologies: Easy to try and take advantage of emerging technologies and frameworks.
Productivity: New team members quickly become productive and can start on their work easily.
Benefits :
Scalable
Easier and Flexible to develop complex applications in a shorter time.
Flexible with multiple technologies.
Fault tolerance
Isolated components and applications
Multi-technology stack with cross platforms and operating systems
Challenges:
It is hard to deploy and address troubles to keep a huge number of modules together.
Microservices always rely on each other. Therefore, they need to communicate with each other.
As it is a distributed system, it is a heavily involved model.
Every service is difficult to find for a mistake. Centralized logging and workflows are crucial for debugging issues.
Automate the Components: Hard to optimize as a variety of small modules are available.
We will have to adapt the building, deployment and monitoring phases for each module.
Perceptibility: It is hard to deploy, preserve, supervise and address troubles to keep a huge number of modules together. All modules need to be highly perceptible.
Configuration Management: It is often difficult to maintain the configurations for modules in different environments.
Debugging: Every service is difficult to find for a mistake. Centralized logging and workflows are crucial for debugging issues.
Using Microservices with Docker
All the containers will be run or administered by a single OS kernel which results in lightweight than the existing virtual machine level operating system processes.
Docker contains a daemon that manages all the containers in the Docker.
Docker has high-level APIs (Application Programming Interfaces) to expose lightweight APIs to be used in order to run the isolated processes.
Frequently Asked Questions
Why microservices are preferred?
Failure of a single process or application doesn’t impact the entire system.
Developers can work on their independent service and can be deployed faster than previous web services.
Why people do not prefer microservices?
It requires heavy investment and infrastructure.
Increases delay due to remote calls
Need more collaboration as many individuals are working on their own services and need to make sure everyone collaborated and sticks with the design and standards.
Can Pact help in Microservices?
PACT is a popular open-source tool to help in testing the interactions between clients and services. The service developer writes test cases and which defines the interaction with the service.
PACT is used to implement Consumer Driven Contract in Microservices.
Swagger is also getting popularity which defines all the use cases/ interactions with the service.
What is Domain-Driven Design (DDD)?
Domain-Driven Design is an architectural style based on Object-Oriented Analysis Design concepts and principles. Here, we create complex applications by connecting the related pieces of the software into an ever-evolving model.
We consider the sphere of knowledge as a Domain and focus on that. Now we put out designs based on the domain model.
What are the testing types in microservices?
Unit tests and performance tests mainly tested by developers.
Stress, load and SVT testing by the test team
Acceptance testing by stakeholders.
What is DRY in Microservices architecture?
Don’t Repeat Yourself. It means that developers need to reuse the code/functionality or using shared libraries.
What is Reactive Extension in Microservices?
Reactive Extension, Rx, is an approach wherein we call multiple microservices and collects data from all and returns back to the client. It is getting popularity in distributed systems.
What are Coupling and Cohesion in Microservices?
Cohesion here refers to related functionality between microservices.
Coupling here refers to dependencies between microservice. Developers can deploy their services without impacting other services. In microservices, we have loose coupling and high cohesion and that’s why the design is getting popular.