One nice thing about working at Futurice is that every now and then we get asked fascinating questions. Recently we were asked how a global corporation should construct their cross-cloud infrastructure. Their diverse teams implement independent in-house business applications all over the world, and they would like to allow these applications to utilize each others' business logic. Futupeeps interested in this challenge collaborated for a while to produce this draft.
Each discrete service system (VPC in the center of the diagram above) can be a responsibility of one Service team. Such a team deserves to have all skills and privileges needed to keep smoothly defining, developing, managing (bottom left), and operating their systems. The organisation helps them with their initial and occasional needs (eg. the red notes in the diagram).
Purpose-built APIs and general messaging gateways provide specific ways to use these services for other systems (right) and users (top).
Kubernetes has succeeded in garnering hosting support from each of the major cloud providers. In many production systems, it already serves us well for:
In our experience, utilities built on top of Kubernetes make it even more efficient to use:
While we often use Kubernetes for managing configurations inside Virtual Private Clouds (VPC), managing access to them from outside requires sorting out some more details (eg. the front services in our diagram). Terraform provides a beautiful language for that, as well as plugins to manage each provider's cloud services separately. We have been delighted with its feasibility in cases varying from trivial to intriguing scale.
Development teams worldwide should be provided with simple, automated ways to get their own development pipelines up and running. These should come complete with deployment configurations where one can uncomment or otherwise trivially instantiate all necessary aspects of application runtime environments. Emphasis on publishing versioned business functionality through REST APIs and message queues should make it possible for development teams to provide services to each other in addition to relying on existing services.
Companies' preferred practices and guidelines for systems can be published for development teams as Terraform modules and Helm templates. Both can be parameterized for routinely changing details or customized for more complicated cases.
Some of this should seem familiar to you, if you lived through the heyday of Enterprise Java Architecture, or SOA. We hope our emphasis on team ownership of their systems, together with the relative simplicity of REST as well as automated infrastructure control will help avoid some of the worst bottlenecks of large systems following that approach. Numerous challenges of course remain to be faced over the course of first establishing and then improving such a framework.
Would you like to challenge our thinking? Want to correct something in the above? Would you love to contribute? Join our cloud automation team.