Today, we have a lot of monolithic system running. The future system landscape, however, will be micro services – a flexible and scalable architecture.
Why we move towards micro services is clear: First, because micro services are more flexible and scalable than old approaches such as monoliths. Second, due to the diversification on operational level, we get a robust system as a bunch of resilient services. The overall system does not stop, if only one services stops working, and it might heal itself. And last but not least, because we can!
Can we? How do we actually transform a monolith towards a micro service architecture?
Since monolithic are usually build out of modules, my answer is: We transform a monolithic into a micro service architecture based on its modules, which support the users business cases.
Monolithic software apply divide and conquer by dividing the software into modules. Modules encapsulates functions in the development steps design and implementation. Monolithic software operates as single process, which is scaled by running copies on multiple machine in parallel. The instances are synchronized on the database level.
In contrast, micro services apply the principle of divide and conquer to operations by combining separated running services on distributed machines to a cloud application. Due to the increased number of services, data synchronization is more complex, and will lead to redundancy.
But the design of services still encapsulates functions similar to modules in monoliths.
Quickly developing (design, implement and operate) a service that is usable, valuable and feasible is a basic principle, which now covers not only requirements engineering, design and implementation but also operation. You build it - you run it!
In order to provide a seamless user experience, the services must be integrated on the user interface level. This is the challenge: Orchestrating the services to a single point of contact towards the user.
A monolith architecture provides this by design.
Transforming a monolithic system towards a micro service architecture means transforming modules into services. Step by step, we cut out modules of the monolithic and run the separately as service.
Such systems functions must – in any case - be defined by stakeholder, i.e. customer and product management. And immediate feedback from quickly implemented function, that are valuable and usable to the user as well as feasible by the implementation, allows focused and effective product development. Approaches such as Minimum Viable Product and Agile Development (e.g. SCRUM) accelerate this goal.
With micro services architecture we can deliver services independently but operation gets an additional integral part of product development.
systems functionality focused, a clear and agreed product vision is required more than ever.
Why we move towards micro services is clear: First, because micro services are more flexible and scalable than old approaches such as monoliths. Second, due to the diversification on operational level, we get a robust system as a bunch of resilient services. The overall system does not stop, if only one services stops working, and it might heal itself. And last but not least, because we can!
Can we? How do we actually transform a monolith towards a micro service architecture?
Since monolithic are usually build out of modules, my answer is: We transform a monolithic into a micro service architecture based on its modules, which support the users business cases.
Background
In general, IT facilitates the principle of divide and conquer in order to handle complexity. A large problem is cut into smaller, manageable pieces.Monolithic software apply divide and conquer by dividing the software into modules. Modules encapsulates functions in the development steps design and implementation. Monolithic software operates as single process, which is scaled by running copies on multiple machine in parallel. The instances are synchronized on the database level.
In contrast, micro services apply the principle of divide and conquer to operations by combining separated running services on distributed machines to a cloud application. Due to the increased number of services, data synchronization is more complex, and will lead to redundancy.
But the design of services still encapsulates functions similar to modules in monoliths.
Quickly developing (design, implement and operate) a service that is usable, valuable and feasible is a basic principle, which now covers not only requirements engineering, design and implementation but also operation. You build it - you run it!
In order to provide a seamless user experience, the services must be integrated on the user interface level. This is the challenge: Orchestrating the services to a single point of contact towards the user.
A monolith architecture provides this by design.
Transformation
If your monolith is already divided into modules, the software is prepared to be developed towards a micro service architecture. If not, you are in deep trouble anyway.Transforming a monolithic system towards a micro service architecture means transforming modules into services. Step by step, we cut out modules of the monolithic and run the separately as service.
Modern product management
Independently of either running a monolith or micro services, dividing the system is based on the systems functions that support business processes. This business process was the glue between modules in monoliths and it will be the glue of micro services.Such systems functions must – in any case - be defined by stakeholder, i.e. customer and product management. And immediate feedback from quickly implemented function, that are valuable and usable to the user as well as feasible by the implementation, allows focused and effective product development. Approaches such as Minimum Viable Product and Agile Development (e.g. SCRUM) accelerate this goal.
With micro services architecture we can deliver services independently but operation gets an additional integral part of product development.
Conclusion
In order to run a flexible, scalable, robust system, a monolith can be transformed into micro services based on the monoliths modules. To successfully run a highly distributed system of micro services, the product development team needs to integrate the responsibility of operations. To keep the product team together and thesystems functionality focused, a clear and agreed product vision is required more than ever.
Kommentare
Kommentar veröffentlichen