How do you avoid confusion when developing for a multicloud environment? Are there any tips you can share for keeping things relatively simple?
Sort by:
What kind of confusion are you referring to? If you are referring to what functionality should go where, how should it all integrate, who should own what pieces and things like that, the answer is pretty straight-forward if you are following best practices: ensure that you have a Solution Architect as a core member of the project team.
That is, the SA is brought on immediately upon project start-up to assist the PM with initial cost/complexity/risk assignments, determining required skill-sets, sizing work packages, etc. and is retained for the entirety of the project through the post-deployment warranty phase).
The SA role is inherently to bring a solution together by providing a coherent solution architecture, ensuring that architecture is understood, and to provide leadership to the various technical SMEs as they inevitably run into technical snags.
The SA should be regarded as a peer-partner of the PM in all technical matters but this does not diminish the role of the PM, but it allows the PM to concentrate on actually managing the project.
As a last note, in a well-run organization, there has already been engagement by the Architecture team in this initiative before it was struck as a project: Enterprise Architecture to provide the context for it's overall strategic value and Capability enhancement objectives, and Portfolio Architecture to provide the context regarding where and how the future solution will find its fit within the ecosystem of IT systems. These pieces of context are invaluable in providing the SA with the guard-rails within which they will create a solution architecture.
A good approach is to split the complexity, so that only some people are focused on some of the tricky technical issues and the rest can have a (relatively) simple experience. Assuming you're ultimately wanting to deliver software products on these clouds then focusing on good and widely-available abstractions and/or protocols is key e.g. focus your development teams on Kubernetes for compute, HTTPS for communication , AMQP for messaging, Postgres for RDBMS and coding in their language of choice. Then your engineering teams can map these standards onto the most relevant services in the clouds of your choice. The major trade-off is you lose access to some of the accelerative elements that cloud-specific PaaS offerings can bring.
I think you would mostly need to do this in one of the following cases:
1. Company / tech stack consolidation
2. Certain services that are better/cheaper on different providers
3. Hardcore business continuity management through Cloud redundancy
4. Customer shenanigans
In all cases, besides suggesting not to do it in the first place, consider the following advice:
1. Make one provider the primary provider and use others as auxiliary providers. Use the network in the primary provider as a primary network and connect anything else securely to it via VPN or other measures.
2. Make sure you use SSO for user authentication across all Cloud providers, so you have an easier time with access provisioning and deprovisioning.
3. Do not use the same service from multiple providers, e.g. manged Postgres on AWS and GCP at the same time unless absolutely necessary. Document for your teams which services they should use from which providers, otherwise it will become chaos. You don't want to manage identical services across multiple cloud providers.
4. Make sure you set API usage limits on everything that is in use. As the complexity grows, it's harder to keep an eye on all things and nobody wants a stupid bill for a mistake in code or configuration.