Microservices Architecture
It is approach to create loosely coupled services which can be developed, deployed, and maintained independently. Each of these services is responsible for discrete task and can communicate with other services through simple APIs to solve a larger complex business problem.
Key Benefits of a Microservices Architecture
-Small teams can work independently if required
-Can deployed independently
-improved fault isolation
– Service can be deployed only for the respective service instead of redeploying an entire application.
-technology stack can be different.
Some points to think about
1. How to Decompose
Create services based on business capabilities.
For example, the business capabilities for an online shopping application might include the following..
● Product Catalog Management
● Inventory Management
● Order Management
● Delivery Management
● User Management
● Product Reviews Management
2. Design the Individual Services Carefully
-When designing the services, carefully define them and think about what will be exposed, what protocols will be used to interact with the service, etc.
Example -We are taking a service (Service 1) and storing all of the information needed by the service to a database. When another service (Service 2) is created which needs that same data, we access that data directly from the database.
Now if schema needs to change, flexibility to make change is lost.
Alternate way – Service 2 should access Service 1 and avoid going directly to the database, therefore preserving utmost flexibility for various schema changes that may be required
3. Building and Deploying
-Creating services using best suited technology.
-Automated test cases
-Deploy services.
4. Deploy
It’s important to write Consumer Driven Contracts for any API that is being depended upon. This is to ensure that new changes in that API don’t break your API.
Two models for deployment
1. multiple microservices per operating system
2. One Microservice Per Operating System (using Hypervisors whereby multiple virtual machines are provisioned on the same host). Docker is one implementation of that model
Making Changes to Existing Microservice APIs While In Production
-version your API (Downside: maintain versions. Any new changes or bug fixes must be done in both the versions)
-Another way another end point is implemented in the same service when changes are needed.
5. Decentralize Things
– Have one team who develop, deploy, maintain and support it
-Another way is developer who needs changes in a service can check out the code, work on a feature, and get it reviewed instead of waiting for the service owner to pickup and work on needed changes.
6. Making Standards
-Best practices
-Error handling
Service Dependencies
In a microservices architecture, over time, each service starts depending on more and more services. This can introduce more problems as the services grow, for example, the number of service instances and their locations (host+port) might change dynamically. Also, the protocols and the format in which data is shared might vary from service to service.
7. Failure
What’s critical with a microservices architecture is to ensure that the whole system is not impacted or goes down when there are errors in an individual part of the system.
-patterns like Bulkhead (ship compartment) and Circuits Breaker(trip based on threshold)
