Introduction to Microservices

Tram Ho

Partly, the project is in the process of maintenance, needs to improve performance and is also a bit interested in the microservice model, so I would like to share some knowledge about this area after reading the first chapter of Microservices: From Design to Deployment

In the book there are a total of 7 chapters that will go from how to design to deploying microservices like, of course, both the benefits and limitations of this model. Then start the first chapter!

1.Building Monolithic Applications

Often we will start the project with a monolithic architecture because of its simplicity when developing and deploying. With a reasonable module structure, packing it all and installing it into one block, it can be said to be both beneficial and harmful. The advantage is that the start is simple and fast, but the later the application gets more traffic and the database, the more control functions a module has.

Let’s take a look at some of the benefits and disadvantages as you keep your project in monolithic direction from start to finish:

Advantages:

  • As a traditional way of doing so it will not be difficult to start, there are many frameworks available to start without having to think as much as: Rails, Django, NodeJs, …
  • With the development of IDEs and tools focused on building applications on existing templates
  • This type of application is easy to scale by running multiple instances loaded with load balancers.
  • It can handle HTTP requests, perform business logic, access databases, and can exchange data with other systems.

Defect:

  • Over time, the project becomes more complex and bigger. New features will take more time to develop and refine existing features will be more difficult
  • Applying new technology is difficult because the whole application must change. Therefore many monolithic applications often depend on an outdated technology
  • It is not easy to understand the project because the modules are closely related. A small issue can kill an entire application
  • Important services cannot scale individually, resulting in a waste of resources because the entire application must scale
  • When the application is large, each new deployments will also be a torment

2. Microservice

With the above disadvantages of monolithic structure, the long-term development does not seem right: 3. But this is not a recommendation to structure towards microservice in the first place, NO. Do not start the application in the direction of microservice do anything, it sounds attractive but it is very dangerous and easy to fail.

It is recommended to build monolithic application into microservice gradually by gradually breaking down its features into small APIs (services). Over time, the number of features will decrease until they disappear completely or are just a small feature implemented by another service. This is also the main idea of ​​the microservice model.

With the idea of ​​such a subdivision, each microservice will be like a small, pretty, beautiful app. It may be a small piece of logic, for example, to charge.

For example, your application has the main function of giving money to all employees in a month, later it happens that in February, the employee will work 30 days. So you ask “wtf is that !!!” ? Is this guy OT or is it because February has 30 days? So difficult, separate service to handle this December case => 1 new microservice

Each function is now implemented by a microservice. Web applications can also be subdivided specifically for each user object. Designing the interface for each user object helps optimize the better experience, faster speed, easier compatibility while simpler functionality.

End user applications will not be connected directly to back-end services. Instead there is an API gateway in the middle. It acts as a common gateway for external applications to call into the internal microservice. The microservice call each other directly without API Gateway. The problem is how the microservice (and the API Gateway) knows the information of the other microservice to call. Then in the system there should be a component called Service Discovery – CHAPTER 2 (a common API Gateway like [Kong Gateway]) ( https://konghq.com/kong/ )).

Microservices architecture greatly affects database and application relations. Instead of sharing a database among services, each service will have its own database. This approach goes against traditional database centralization, so if you’re having trouble, it’s also possible to find a way to point to the main DB of the original application.

Especially in the microservice structure, each microservice will be able to choose a completely new technology or update the old framework to the latest version as long as it is appropriate and optimal.

Overall, the microservice architecture is similar to SOA (Service – Oriented Architecture). Both are a set of interconnected services. The difference is that microservices do not use standards set by large corporations such as IBM, Microsoft, Oracle such as web service specificcations (WS- *) or Enterprise Service Bus (ESB).

Analysis is quite confusing, so we will summarize the advantages and disadvantages of the microservice model.

Advantages:

  • Simplify the system, reorganize the large features (split) into many small services for easier management.
  • Freedom to choose technical for each small service to develop
  • Services can be independently developed, tested, deployed and scaled without affecting other services.
  • In addition, it is possible to optimize the cost of running the service by deploying each service onto an appropriate resource. For example, you can deploy iamges on EC2 server using Compute Optimized instances , but also need to search EC2 Memory-optimized intansces for RAM usage.

Defect:

  • Split will also lead to redundant services (not necessarily separated), petty + difficult to control
  • Distributed system (distributed system). Programmers need to choose how to develop each small service to communicate with other services or RPC. Moreover, they have to handle the problem when the connection is slow, the error is when the message is not sent or the message is sent to multiple destinations at different times.
  • Testing a service in microservices architecture sometimes requires running other small services on which it depends. Therefore, when decomposing an application into microservices, you should always check the level of binding between the services. If the small services depend on each other in sequence, A calls B, B calls C, C calls D. If so, the maintenance and testing will have the same complexity – all eyes. So good service design will minimize the impact on other services.
  • Deploying microservice-oriented applications is also complex. If the monolithic model only needs to add new identical servers behind the load balancer. Then the microservice service will reside on multiple virtual machines or different container Docker. As NetFlix currently has more than 700 services (2019). Therefore, it is necessary to have a device with a service detection mechanism to automatically update the IP address and port, description, and version of each service.

3. Summary

If your application is only small scale, do not think about what microservice does for headaches, keep the simple, lightweight, and effective monolithic model: 3. For applications with heavy traffic or complex logic processing functions, the microservice option is equally complex: v, but it is appropriate. ? ) for long-term development

After grabbing the skirt, after reading through the ebook and referring to the blogs I have a few notes when deploying a microservice model such as:

  1. Is this a long-term development product?
  2. Is the scale of the system large (scale of the number of users or data)?
  3. Hard work or not: 3

Thanks for reading!

Share the news now

Source : Viblo