Introduction to Microservices (part 1) hell architecture one block

Microservices hiện đang nhận được rất nhiều sự chú ý: các bài viết, các blog, các cuộc thảo luận trên phương tiện truyền thông, trên mạng xã hội, và các bài thuyết trình hội nghị. Đâu đâu ta cũng có thể bắt gặp những chủ đề liên quan đến Microservices.

Cùng với đó cũng có những hoài nghi trong cộng đồng phần mềm, những người cho rằng microservices không hề có gì mới mẻ. These gười này cho rằng các ý tưởng về Microservices chỉ là một hình thức làm khác của SOA (Service-Oriented Architecture) hay còn được hiểu là kiến trúc hướng dịch vụ.

Tuy nhiên, bất chấp cả sự cường điệu hóa lẫn những hoài nghi, thì mô hình Microservice mang lại những lợi ích đáng kể trong việc xây dựng những giải pháp phức tạp, đặc biệt là nó tạo điều kiện cho việc áp dụng agile lên project một cách hiệu quả.

feature02-figure02

One-block architecture.

In the past, people built a monolithic applications.

Imagine you are building a mobile taxi service to compete with Uber and Hailo. After a number of meeting gathering requirements and design analysis, you will choose technology stack and then create projects with frameworks like Rails, Spring Boot, Play, or Maven. This project will have a hexagonal division architecture (hexagol architecture) or, more generally, a polyhedron. Multifaceted architecture helps specialized data model applications.

Graph-01-e1431978090737

Looking at the core of the application, we see that business logic is represented by service blocks (services), objects for each domain objects and events (events). Around the core are adapters to connect to the database, send messages, web services or front-end web applications.

Although there is a reasonable modular structure, this type of application will encapsulate and install into a block (monolithic). The way to deploy the application package depends on the programming language or the framework library. The application example uses Spring framework, which is embedded in a WAR file, deployed on application servers like Tomcat or Jetty. Using another framework, for example Spring Boot, Java application is a self-packaged file to run as JAR. Applying Rails or Node.js packaged according to hierarchical directory structure.

Writing applications of this type are extremely popular. They are completely easy to develop, especially with the development of IDE and other tools focused on building single applications based on existing templates. Why? Simply, because they need to convince the programmer to follow the technology / framework, the manufacturer must do how to program just need New Project, press the Build & Run button is the right application to run and always. You can easily perform testing by running the application and performing a UI test with Selenium. This one-block application is quite easy to deploy. Simply copy the package to be built on the server. In addition, these applications can also be easily scaled by running multiple instances loaded with load balancer. In the first phase after deployment, they work extremely well.

Step down to hell.

Unfortunately, the approach to architecture in a single block is easy but reveals many defects.

Your application succeeds, leading to an increase in the number of users, new feature requirements, increased data, more complex logic, increased communication with other systems, and hundreds of other things leading to a result. is a horribly bulging application. After each sprint, a series of new features are added, adding code, adding tables, adding logic … Only after a while, the simple application will become as bulky as a monster. And the amount of effort spent developing and maintaining this monster is not small either.

When the application swells too big, every effort is made, applying the agile method is no longer effective. Only a small edit will have to refer to where it is used to consider its impact on the entire system. It's too hard for a programmer to grasp and understand the whole system code. And as a consequence, fixing bugs, or adding new features becomes more difficult and time-consuming.

In a monolithic application, rigidity is a natural advantage derived from architecture, but it has the potential to constrain rigid (tight coupling). Cost, time, development effort, error correction, a function test will increase the number of exponentials according to the size of the application.

As the application gets bigger, every new version deploying will be a formidable one, even worse if the down time for restarting is too large. This also affects when the programmer is debugging the application, imagining a redeploy application takes 10 minutes, in which 10 minutes the programmer will do, clearly it greatly affects productivity.

Recently, you heard more about the concept of continous deployment. Advanced SaaS (Software application as Service) applications need to be updated several times a day. It is too difficult to re-deploy an extremely large application because of some minor upgrades. Operation is stalled, retesting after deployment will be longer. As a result, this will be difficult to apply to a single-block application. If not, it is impossible.

In addition, it is difficult to scale when the modules are different, with different resource needs in common. For example, deploying the application on AWS (Amazon Web Services), you have an image processing module, this module takes up quite a large amount of CPU resources, so you can use EC2 Compute Optimized instances , besides, you have a The module using in-memory caching with RAM resource needs is extremely large, preferable if you use EC2 Memory-optimized instances . However, because it is a block application, we have to calculate how to best fit, this also affects not less than the cost.

Một vấn đề khác với các ứng dụng nguyên khối đó là độ tin cậy. Bởi vì tất cả các module đang chạy trong cùng một quá trình, một lỗi trong bất kỳ module nào, chẳng hạn như một lỗi memory leak, cũng có thể có khả năng làm down toàn bộ quá trình cũng như cả hệ thống.

Finally, the application of a single-language block, a single framework so the developer working on the project will be familiar with the convenience and ease of just grasping a language, a tool can solve most problems. They gradually depend on that language and become biased, afraid of being open, integrating with other technologies of other languages. Even when the framework or language has inherent disadvantages, because the application of a block of applications will force test programmers to introduce changes in foreign breakthroughs.

Simply put, if you use a block with more than 2 million lines of code on the XYZ framework, whether your team has the courage or resources to rewrite the whole new, better ABC framework. Even if you have a good, creative programming team, they don't want to do this deadlock project. Or if you really want to do it, the cost to rebuild and rebuild the entire system is enormous. The situation of keeping is hard, it is difficult to build, making your service and products more and more difficult to develop.

In short, clinging to a monolithic architecture, a ticket to hell is higher up to heaven.

So we have to do?

See you in the next section, Simplifying all the complexities with Microservices.

keep-calm-and-implement-microservices

ITZone via Codealohicguy

Share the news now