Replacing a monolith via the implementation of microservices is a very common scenario for the introduction of microservices. It requires a lot of effort to keep developing a monolith and to add new features to it. The complexity of the monolith and the associated problems caused by it progressively increase over time. It is often very difficult and risky to completely replace an existing system with a newly written one.

Rapid and Independent Development of New Features

In the case of companies like Big Money Online Commerce Inc., the rapid development of new features and the ability to do parallel work on several features are vital for the success of the business. Only by providing state-of-the-art features can new customers be won and existing customers be kept from switching to other companies. The promise of being able to develop more features faster makes microservices compelling in many use cases.

Influence on the Organization

The presented example illustrates the influence of microservices on the organization. The teams work on their own microservices. As the microservices can be developed and deployed independently of each other, the work of the different teams is no longer linked. In order to keep it that way, a microservice should not be changed by more than one team at any time. The microservices architecture requires a team organization corresponding to the different microservices. Each team is responsible for one or several microservices, each of which implements an isolated piece of functionality. This relationship between organization and architecture is especially important in the case of microservices-based architectures. Each team takes care of all issues concerning “its” microservices from requirements engineering up to operation monitoring. Of course, for operation, the teams can use common infrastructure services for logging and monitoring.

And finally, if the goal is to achieve a simple and fast deployment in production, just including microservices in the architecture will not be sufficient. The entire continuous delivery pipeline has to be checked for potential obstacles, and these have to be removed. This is illustrated by the tests in the presented example; the testing of all microservices together should be reduced to the essential minimum. Each change has to run through an integration test with the other microservices, but this test must run quickly to avoid a bottleneck in integration tests.

< Prev   CONTENTS   Source   Next >