Microservices without Changing the Organization?

Microservices are more than just an approach for software architecture. They have pronounced effects on organization. Changes to the organization are often very difficult. Therefore, the question arises whether microservices can be implemented without changing the organization.

Microservices without Changing the Organization

Microservices make independent teams possible. The domain-focused teams are responsible for one or multiple microservices—this ideally includes their development as well as operations. Theoretically it is possible to implement microservices without dividing developers into domain-focused teams. In that case the developers could modify each microservice—an extension of the ideas presented in section 12.2. It would even be possible that technically focused teams work on microservices that are split according to domain-based criteria. In this scenario there would be a UI, a middle tier, and a database team that work on domain microservices such as order process or registration. However, a number of advantages usually associated with microservices cannot be exploited anymore in that case. First, it is not possible anymore to scale the agile processes via microservices. Second, it will be necessary to restrict the technology freedom since the teams will not be able to handle the different microservices if they all employ different technologies. Besides, each team can modify each microservice. This entails the danger that though a distributed system is created, there are dependencies that prevent the independent development of individual microservices. The necessity for independent microservices is obliterated because a team can change multiple microservices together and therefore also can handle microservices having numerous dependencies. However, even under these conditions sustainable development, an easier start with continuous delivery, independent scaling of individual microservices, or a simple handling of legacy systems can still be implemented because the deployment units are smaller.

< Prev   CONTENTS   Source   Next >