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

Integrating monolithic

Whenever a choice is made to move away from the monolithic architecture in favor of the microservice-styled architecture, the time and cost axis of the initiative will pose some resistance. A business evaluation might rule against moving some parts of the monolithic application that do not make a business case for the transition.

It would have been a different scenario if we were developing the application from the beginning. However, this is also the power of microservices, in my opinion. A correct evaluation of the entire monolithic architecture can safely identify the monolithic parts to be ported later.

However, to ensure that these isolated parts do not cause a problem to other microservices in future, we must take one safeguard against the risk.

The goal for these parts of the monolithic application is to make them communicate in the same way as that of other microservices. Doing this involves various patterns and you utilize the technology stack in which the monolithic application was developed.

If you use the event-driven pattern, make sure that the monolithic application can publish and consume events, including a detailed modification of the source code to make these actions possible. This process can also be performed by creating an event proxy that publishes and consumes events. The event proxy can then translate these events to the monolithic application in order to keep the changes in the source code to a minimum. Ultimately, the database would remain the same.

If you plan to use the API gateway pattern, be sure that your gateway is able to communicate with the monolithic application. To achieve this, one option is to modify the source code of the application to expose RESTful services that can be consumed easily by the gateway. This can also be achieved by the creation of a separate microservice to expose the monolithic application procedures as REST services. The creation of a separate microservice avoids big changes in the source code. However, it demands the maintenance and deployment of a new component.

主站蜘蛛池模板: 垫江县| 尚志市| 栾城县| 清涧县| 洪洞县| 赣州市| 达孜县| 乡城县| 双柏县| 东兰县| 保靖县| 涟源市| 新乡县| 昭苏县| 晋城| 大厂| 陵川县| 商南县| 汤阴县| 依安县| 榆中县| 南康市| 定结县| 安化县| 灵寿县| 项城市| 布尔津县| 布拖县| 安平县| 郴州市| 海淀区| 青冈县| 广安市| 敦化市| 略阳县| 泊头市| 紫金县| 景泰县| 白城市| 瓦房店市| 郁南县|