The most common trend for organizations in the past has been to move their on-premise workloads to the cloud. This provided the organizations with a lot more agility in terms of scaling, as needed, without worrying about complex procurement processes mandated by their data centers.
A lot has changed since CapEx vs OpEx was the topic of discussions regarding cloud adoption. Organizations have found their cloud of choice, and migrated legacy workloads to the cloud. While many applications are newly developed or redesigned in a fully cloud native fashion, some companies have chosen the strategy to “lift and shift” onto the cloud.
An architect has a number of options and attributes to consider in making their choice among what the market offers in public cloud computing:
Serverless or app services would appear to be the most effective choice for computing (from a developer point of view) when the need is to build a number of functionalities contained within a simple application. With minimal knowledge required for DevOps or hosting, a programmer can quickly set up an application, just by referencing the provided documentation regarding the components.
However, as the organization and the application begin to grow in scope, scale, and transaction volume, the hosting costs will also rise notably. At this point, the organization can find itself with limited options for optimization, whether it would be migrating to another cloud or distributing across multiple clouds, due to the tight dependencies and reliance on their current cloud provider.
IVirtual machines, on the other hand, provide a wide range of flexibility for system engineers to explore and configure anything that is needed. However, the overhead costs of administration and operations to manage those instances would increase significantly with scaling.
Hence, for an organization with hundreds of microservice apps and high transaction volumes, or for companies looking to grow quickly in this scale, Container based architectures would provide the most practical structure, allowing for a balance of flexibility, portability and affordability. This would also provide the efficiency needed for further growth and expansion to a multi-cloud solution, which ultimately can bring about the following benefits:
Competitive pricing
High degree of resilience
Higher availability
Flexibility during security events
Closer proximity to users and better performance
Easier risk management options
Deploying a service in multiple clouds requires the data layer to be kept in sync so that the consumers see the same response, no matter which cloud is servicing them. Such design can be made possible by choosing storage services outside of the typical public cloud subscriptions.
Microservice applications can greatly benefit using NoSQL datastore such as MongoDB Atlas which orchestrates its services across the cloud.
Redis cloud provides cloud agnostic in-memory caching options.
Platforms such as ArangoDB provides great GraphQL interfaces, freeing applications from the worries of being tied to a specific cloud.
When it comes to data lakes, Snowflake, Databricks, etc., have great offerings.
While all these data storage options have some flavor of public cloud, Blockchain based systems, such as Etherium, Hyperledger, r3, etc., can provide even better storage options. IPFS, Storj, etc., are also options to review while building decentralized apps, purely agnostic to the cloud service provider.
While all these data storage options have some flavor of public cloud, Blockchain based systems, such as Etherium, Hyperledger, r3, etc., can provide even better storage options. IPFS, Storj, etc., are also options to review while building decentralized apps, purely agnostic to the cloud service provider.
While such gateways may be considered a lock-in, it is still much easier to switch over to other alternate options, as and when appropriate. The only effort required would be to port over the configurations, and not the entire servicing apps.
An alternative option for the gateway is to use specific ones on each cloud (or even at region level) and set up a service discovery such as a DNS lookup, pointing to the specified backends, based on a routing policy. The routing policy should also include a health check and failover routing records. DNS based routing will not work if all services are located under one domain. This would end up routing all services under the domain to alternate clouds in case of a failure, even in one. Therefore, such an option would also require assigning a DNS subdomain to each group of microservices for better routing flexibility.
Metrics from each cloud can be harvested with observability platforms which, in turn, can be aggregated for reporting, decisions, and actions. These actions, executed with near real-time effect, can be used to apply necessary controls, similar to that of a centralized API management solution.
Based on the various considerations, a high level solution for multi-cloud deployment would look as follows.
With the considerations provided, organizations can now plan to move onto active-active multi-cloud deployments. This, not only avoids a lock-in to a cloud provider, but also provides better availability, resiliency, and a great level of flexibility with cloud cost management.