Most VLEs (very large enterprises) already use 2 or more cloud platforms. The concept is to shift applications between cloud platforms using Flexera or a similar CMP based on workload compatibility and cost. Often this may prove problematic if the application design is not built for portability.
Multi-cloud can be sensible to avoid vendor lock-in or fulfil data residency requirements. Multi-platforms are of course complicated, requiring IT groups or their partners to supply the requisite operational and service expertise and support. They must also engage in the abstraction of workloads to allow portability. Many platform-specific tools may not be allowed to reduce proprietary risks. This may increase overall platform costs.
For starters, make sure all your hosting environments support the language you plan to use for your application. Most of the time, the language it is written in won’t matter in terms of application portability. For example, if your app is deployed using self-provisioned, cloud-based VMs, you have the freedom to configure the VMs to support any language you want.
However, other deployment strategies may limit your choice of programming languages. For instance, serverless platforms like AWS Lambda or Microsoft Azure Functions do not let users make significant changes to the host environment. These services only support apps that are written in certain languages, and not all clouds support the same ones.
Choose a language that is supported on all major serverless platforms; Python, C# or Java.
There is nothing – absolutely nothing – wrong with a VM infrastructure. If you need to control the OS, and you want complete portability than a VM infra is a good choice. It is often easier to manage, upgrade, move and migrate, than containers. VMs are great for legacy-stateful applications that may need some refactoring or version upgrades. Limitations would include scalability and tight coupling (though this is often not true, since many near-legacy apps are 3-tiered and loosely coupled).
Containerisation on the other hand, though much in vogue, is in reality quite difficult since it assumes de-coupling, rework or build-new, complicated management (K8s), and also a largely stateless architecture. Your team will need the Docker-K8s skills or be willing to learn them, along with deep coding skills, network management and security.
An issue with containers is that many apps are stateful. They are also OS dependent. You can create a containerised application architecture with stateful sessions. Docker for example does not totally abstract apps away from host environments. The major limitation, in this respect, is that a Linux container can only run on a Linux host and a Windows container only runs on Windows.
Containers don’t bother with variables like where data is stored, as long as they have a way to access it. If you have the skills it should be reasonably straight-forward to lift and move a Container to a new platform – assuming that the OS is the same.
There are a variety of API platforms including iPaaS. Mulesoft, Red Hat’s Fusion, and many other platforms exist as independent API PaaS’. You build the APIs in these platforms and connect your applications. The API platform is independent of the underlying infrastructure and applications which can be moved and re-platformed without breaking the API call connection. You will need to be trained and certified in these platforms and they are licensed and not cheap to operate.
There are also ‘unified’ API platforms such as Apache Libcloud, or Kloudless which offer less costly options and the promise of ‘multi-cloud unity’. These platforms provide tools which serve as abstraction layers. The applications issue requests and the unified API forwards the requests to whichever cloud you’re using. This way, you only write API calls once but you will need to have the skills and operational capacity to effectively manage their life cycle. As well, unified APIs have limited functionality. They only support certain languages and if a cloud provider changes its native API without warning, a unified API may no longer be able to support it.
Cloud platforms of course offer their own API PaaS. The cloud-platform native APIs will be easier to build and consume, however, they do lead to vendor dependency. If you wish to move the APIs to a different cloud, you will have to rewrite much of the logic. API design can be reused but the underlying code will need to consider the native service and API integration (constraints) on that platform.
Personally, I would use either Mulesoft for platform independence, or the native Cloud API platform and make a design decision that certain apps and their dependencies are clustered on that particular platform.
IAC is the practice of using JSON, YAML or similar templated scripts to define how a software environment or application should be deployed or configured. Those tools are then used to automatically create the specified configurations. Tools such as Chef, Puppet and Terraform are cloud agnostic.
Using agnostic tools will allow you to automate application deployment and simplify the process of moving the app from one cloud to another. Infrastructure as code will not make your application more portable by itself, but it will make the deployment process more portable, which adds up to greater portability overall.
Migrating an application from one cloud to another will almost always require some reconfiguration and faffing around. There is no such thing as a completely cloud-agnostic, 100% portable app. That is not the reality of IT where platform constraints ranging from APIs to networking do exist.
However, an Enterprise Architect should be ensuring that some extra work around design-portability is done upfront to guarantee application portability. A proper design, based on key architecture and general application features, is easier to enforce at the beginning, than it is to rewrite large portions of the app down the line.
