官术网_书友最值得收藏!

From the monolith to microservices

So, why did SoA evolve into microservices? Perhaps one of the reasons was due to the monolith. There was a point in time where applications were small, and the presentation logic was usually coupled with the business logic. Then, the domain model got complex and many software patterns arose. Most of them were focusing on one thing: Separation of Concerns.

Separation of Concerns (SoC) is a design principle for separating software into distinct sections so that each section addresses only one concern. But software is not the only thing that needs separation; the architecture needs it as well. Things like SoA are designed for that, as it allows us to hide our complexity behind black boxes to make our architecture more modular, and with the ability to handle the complexity that we require.

We may create a complex data store in the mainframe based on detailed business rules, or on a powerful database with a deep schema, complex stored procedures, views, and relationships. We can choose frameworks and tools to easily orchestrate all these parts. We probably also need a powerful Enterprise Software Bus (ESB).

An ESB is a software component that is in charge of the coordination, mapping, and routing of services. The overall idea is to have a very powerful component to easily orchestrate messages. In order to create complex applications, services were designed using most of these elements, creating complex relationships.

From services calling each other, to views querying several tables, pulling data from different business domains. And finally, merging in our ESB several of those elements with business rules to produce new services.

Complex SoA application

Changing one service, or a table in the schema, produces a knock-on effect in the whole application, resulting in those relationships and dependencies needing to be changed, whether they're services, mappings, or even screens as they are all bundled together. In many cases, this causes long release cycles as handling that level of complexity is not an easy task. And nor is the development, configuration, testing, nor deployment.

Even scaling the application could be affected, whether it's a bigger database, more servers for services, a bigger ESB for handling more messages. Since they depend on each other, it is not easy to scale them separately. All of this means that our architecture is coupled and we have created a monolithic application.

Monolithic applications existed before SoA and, in fact, this was one of the things that SoA helped to handle, decoupling the clients from the business domain. Unfortunately, trying to implement SoA drove many applications back to it.

Does this mean that doing SoA will produce a monolith? No. In fact, before the concept of microservices, many architects and developers started to adopt patterns and architectures to handle this problem. This evolved into what we call microservices today.

There were people doing microservices before that name existed; they just called it SoA.
主站蜘蛛池模板: 廊坊市| 兰考县| 寻乌县| 宝兴县| 庄浪县| 仲巴县| 麦盖提县| 德令哈市| 莫力| 来凤县| 遂平县| 遂昌县| 延寿县| 嘉义市| 那坡县| 巨野县| 库伦旗| 本溪| 金昌市| 驻马店市| 杨浦区| 石门县| 宝山区| 婺源县| 留坝县| 台南市| 株洲市| 灯塔市| 焦作市| 北碚区| 深州市| 嘉兴市| 秭归县| 通化市| 长岛县| 贡嘎县| 伽师县| 景谷| 松桃| 常德市| 襄樊市|