Resolving runtime dependencies to shared resources when migrating to the cloud
One of the aspects of migration to cloud is how technical architecture impacts organisational structure. Separating technical components as services (or microservices) in the cloud allows organisation to rethink its structure in order to better bridge both organisational and technical worlds.
Having separate teams, each of which having separate release cycles producing self-contained component images, creates a need to handle build but also in many scenarios runtime dependencies to shared resources which previously have been part of monolitic architecture.
While build dependencies are usually resolved with tools like maven handling runtime dependencies to shared resources like messaging platform or database layer is much bigger issue. Runtime dependencies cannot be resolved in the build phase but rather during deployment phase. Two approaches are discussed below considering as an example that shared resources are messaging provider and database:
Create one common release spanning over multiple components and also shared resources.
Pros:
a. Creates a single release view
b. Quicker to instantiate environment
Cons:
a. Creates additional maintenance effort to synchronise components between all development teams and infrastructure team for messaging provider and database.
- Since components will be deployed in separate release streams it needs to be orchestrated when messaging provider and database are deployed.
- Shared resources configuration (for example queues or/and database schema changes) cannot be stored in development repositories. Optimal place would be to store them in infra repository but that means development teams would work with infra repository for infrastructure related configuration.
b. Error prone due to complexity of maintenance both infrastructure configuration and components configuration coupled together.
c. Infrastructure configuration images need to be regenerated on changes of development components as both are tightly bound to the same release.
d. Dependency between development and infrastructure not only technical but also organisational.
Do not create a solution spanning release but keep development teams working only on their respective component releases. Shared components configurations for messaging provider and database will be configured dynamically based on component-specific configuration included in each development image during component deployment.
Pros:
a. Reduces significantly maintenance effort only to respective component release cycles handled by each development team. No spanning release including messaging platform and database.
b. Development teams independent in their release cycles and not bound to infrastructure.
c. Less error prone as eliminates synchronisation of infrastructure configuration which gets deployed dynamically based on actual content of image.
d. Last minute changes to release content do not require infrastructure image changes as not bound statically to components content.
Cons:
a. Instantiation of whole environment or single component potentially more time consuming. Risk when time is a priority.
b. Instantiation of whole environment or single component deployment creates a risk of delays when failing due to inconsistencies.