State of play
We see 2019 as the year of scaling public cloud adoption. While this resonates with all industry sectors, this is a reality across a number of financial services institutions. This comes from a place of greater understanding of the opportunities that public cloud offers. Coupled with scaled public cloud adoption, multi-cloud strategies are also being embraced. Many organisations are exploiting this approach to get the best of security, autonomy, disaster recovery and solution superiority for specific workloads. While each of the leading platform cloud solutions are broadly comparable, they are not directly portable.
In addition to the multi-cloud reality, hybrid (cloud) architectures will also be a reality for the foreseeable future. The biggest constraint or blocker in preparing for this reality is legacy applications and technologies. Based on our experience, irrespective of whether you have an already stated intent multi-cloud strategy, or a single cloud strategy, or a hybrid interim state, there are a few no regret architecture decisions you could undertake to plan for this eventuality.
Starting the cloud migration or adoption journey in a cloud agnostic fashion would involve integrating the following essential elements into your approach from the onset. This will also help maintain the right pace to transition to the cloud journey and integrate with the hybrid environment with minimal friction.
Containerise your application
Containerisation technologies such as Docker have massively improved the way we build and deploy software. One of the key advantages of containerisation is its ability to be portable, a key element when migrating from one cloud service provider to another. You specify everything that your application needs to run in terms of runtime, environment variables and any setup scripts and you are able to start and run the container almost everywhere. This essentially means that any application, bundled with all its dependencies, can be dropped into any managed container service such as Amazon ECS. The underlying container platform will then manage the container lifecycle and provide additional benefits such as logging and monitoring.
If the intention is to avoid vendor lock-in, containerisation is a quick win. In a hybrid environment, refactoring/ engineering existing applications to adopt a containerised architecture if often the most effort intensive aspect. Investing in enabling this across business critical legacy application is well worth the effort to eventually enable migration to public cloud.
Infrastructure as code (IaC)
Prominent cloud providers have their own mechanism of running infrastructure templates on their relevant platforms, be it CloudFormation in AWS, Resource Manager in Azure or Cloud Deployment Manager in GCP. However this will still mean you are locked to a particular vendor as the syntax will be vendor specific. In the last few years we have seen the emergence of 3rd party tools such as Terraform that provide a mechanism to script infrastructure on leading cloud providers, providing the much needed abstraction layer to the underlying api calls. You specify the provider you wish to use as well as the access keys and secret keys and when you run terraform apply, the CLI will spin up the appropriate infrastructure for you to then deploy your application. However, you will still be writing code specific to a cloud provider. To be truly cloud agnostic one would need to write a terraform abstraction layer that will do the job of interfacing with whichever cloud platform you need to spin up the infrastructure. While this is the ideal solution, the reality is that the effort vs. benefits of this abstraction layer doesn’t justify its prioritisation. We would recommend sticking with the APIs that are available for the chosen cloud provider and spend the effort automating your processes instead.
Orchestration - Kubernetes
Building on containerisation and IaC, is the orchestration engine i.e. a system for running and coordinating and managing the lifecycle of containerised applications across a cluster of machines. For a cloud agnostic deployment, a key requirement is that there should not be any binding between workloads and the underlying cloud. The easiest way to achieve this is by not using managed services from a cloud provider, e.g. AWS RDS, Google CloudSQL, in your applications. Your best bet is to stick to using containerised versions of platform elements that you need such as containerised version of your choice of database, containerised version of load balancer, etc. Essentially, by creating a microservice architecture for your entire application platform stack. Adoption of an orchestration engine such as Kubernetes allows for this.
Cloud agnostic architecture is not a new topic. The biggest challenge ahead of a number of organisations however is moving legacy systems to the cloud, which will still require refactoring. Choosing to be cloud provider agnostic can divert your focus to designing for all platforms, rather than focusing on maximising the business value you are delivering through cloud. Instead, focus containerising, automating and integrating with your hybrid environment – a reality for the foreseeable future. Some of cloud providers have already latched on to this reality which is reflected in some of their recent product launches.
Invoking the mythical tech promise of “write once, run anywhere,” Google Cloud announced a new product Tuesday that customers running its managed container services can use to manage multiple cloud or hybrid cloud deployments.