About microservice (Part 2) simplifies things complicated with microservices

In the previous lesson, the one-piece architecture hell we saw how a one-piece architecture has scary drawbacks.

Many corporations such as Amazon, eBay, Netflix have solved the problem of single-block application with Microservices architecture. The idea is to break up large applications into interconnected small services.

Each small service performs a number of specialized functions such as order management, customer management … Each service is a small application with a multifaceted architecture that is the business logic that connects to different adapters. Some small services expose an API for another small service or client call. When operating, each small service is run in a virtual machine or Docker container.

Each function is now implemented by a small service. Web applications can also be divided into smaller ones for each user object (one for taxi passengers, one for drivers). Design interface for each user object to help optimize the experience better, faster speed, easier to adapt while the function is more minimalist.

End-user applications will not be directly connected to back-end services. Instead, there is an API gateway in the middle.

There are three aspects to scaling a system using Microservices, the first is the Y axis with as little division of the service as possible, second with the X axis being the cloning of instances of each service and triggering by load balancer, third with Z axis is data partitioning, by partitioning similar services.

The chart below describes how the trip management service can be deployed with Docker running on Amazon EC2.

Microservices architecture greatly affects application and database relations. Instead of sharing a database between services, each service will have its own database. This way goes against the centralization of traditional databases. Consequently, there will be data redundancy, the foreign key mechanism binding data relationships cannot be applied to tables in two separate databases. This design will shock many programmers who are accustomed to the client-server model, where the database is always a center, gathering all tables. Storing data in each service is important if you want the microservice architecture to be really effective because it ensures loose coupling between services. But this is only a recommendation, in fact, some services can still use the same database to ensure the highest priority of data integrity.

The diagram below is an example of database architecture for services.

Each small service can choose the best data storage technology. For example, the vehicle service needs to use a database that supports querying in the best coordinates.

Overall, Microservices architecture is similar to SOA (service-oriented architecture). Both have a set of services. The difference is that Microservices are not standardized by big corporations like IBM, Microsoft, Oracle such as web service specifications (WS- *) or Enterprise Service Bus (ESB). Microservices direct more lightweight standards such as Protobuf, Thrift or open, easy to read like JSON. Microservice does not apply some parts of SOA such as canonical schema. It can be seen that Microservices are more compact, more diverse in the protocol as well as data standards.

And like everything else in this world, there are advantages and disadvantages. So what are the advantages and disadvantages of Microservices architecture, please see the next section, The pros and cons of Microservices .

Goodbye and see you again.

ITZone via codealohicguy