The Multi-cloud Blueprint

Ten years ago there were but a brave few who dared untether from the safe confines of Mother Earth and venture to the clouds. These pioneers reaped the benefits of near infinite scalability, unprecedented infrastructure agility and consumption based modelling, and quickly gained the competitive edge. But fast forward to today, and most businesses either have a presence in a public cloud, or are doing that first generation of "cloud-like stuff" on-prem. Simply being in the cloud is no longer the advantage it once was. Moreover, the realities of living in the cloud (functional, financial and operational) are starting to hit home, and the once-perceived simplicity of hitching your wagon to a single cloud provider is becoming both a hinderance to evolution and potential concentration risk to your business. It's no surprise then, when you open any article on the top IT trends of 2022, multi-cloud features prominently.

But in so much as there is a plethora of commentary around multi-cloud being the future, there isn't a great deal of rhetoric on how the majority of enterprises could or would leverage this to their advantage - i.e. if I'm moving to a multi-cloud model to experience the "best of both" worlds and give my business the edge... which cloud would I choose for a particular function? So I decided to put together what I believe to be the first (and only) Multi-Cloud Blueprint.

Now, something like this doesn't come without a bunch of assertions and provisos, so here goes:

• My major premise is that no one cloud offers the complete Enterprise package, but between OCI and Azure (formal cloud buddies), you get everything you need without crossing into the realm of diminishing returns
• This is a set of guidelines, not a set of rules
• The advice here is based on my experience working in and for enterprises large and small. What I've noticed is a consistent set of core technologies and whilst the scale may vary, the functional requirements and need for these services don't differ all that much. To this end, anything suggested here is conversational and general in nature and doesn't necessarily reflect the right platform for your particular situation (this is where a partner like Kelima can help you navigate specific requirements)
• I generally follow the KISS principle and believe that just because something can be done a particular way, doesn't mean it should. In fact, I'd go as far as saying this is the secret to a successful cloud transformation
• Nothing is binary. The beauty of multi-cloud is that you have access to services in either cloud. Perhaps consider these recommendations as "primary" targets, or where your deployment gravity sits rather than exclusive options
• To that last point, this list generally covers off the "best-of-breed" aspect of the multi-cloud discussion. If you're looking at multi-cloud to address your BCP or vendor concentration risks, you may need to look at moving down the stack to a lowest common denominator in a couple of these areas, or accept that what may be delivered as a service in one cloud (your primary target) is delivered on IaaS in the other.

I'm sure some may find these recommendations provocative or challenging, but I'm happy for it to stir a discussion that leads to a more learned and evolved viewpoint of multi-cloud beyond just a concept. So here goes:

Orchestration: Terraform

Let's start with a cross-platform fundamental - one of the long-established benefits of moving to the cloud has been the ability to define infrastructure and environments as code. Hashicorp's Terraform has emerged as the popular leader in this space due to its cloud agnosticism (there are "providers" for just about every platform that is, has been and likely ever will be), open source nature and easy human readability. If you're already using Ansible, you're probably good to stick with that but if you're using anything else (Puppet, Chef etc.) the move to cloud might present an opportunity to revisit the tech.

Why Terraform?

• Treated as a first-class API citizen by all major hyperscale vendors
• Ample community support and adoption
• Integrated into the OCI platform as the "Resource Manager" service

General Purpose Compute: OCI - Flexible VM Shapes

If you read my previous article on OCI's foundational capabilities, it would probably come as no surprise that I recommend OCI as the de-facto target for general purpose compute workloads. Taking full advantage of its late-to-market positioning, Oracle architected something that as a practitioner and consumer, is a delight to work with. Deploying compute in OCI is cheaper, faster, easier, more scalable, more reliable... just better than the experience in any other hyperscale cloud. Period. The only reason I'd see you considering an exception is if you have an app that is so latency sensitive that it needs to run in the same physical location as its data source in Azure, for everything else, it's OCI.

Why OCI?

• Fully flexible VM deployment options (cores and memory) - good riddance to the complicated analysis process around fixed shapes
• Only major cloud player with performance and manageability SLAs at this layer
• Fewest hidden "gotcha" costs across the primitives
• Absurdly high spec/low cost block storage options
• Zero egress costs over dedicated FastConnect

Identity: Azure - AzureAD

Active Directory is near ubiquitous in the enterprise game, and its cloud based incarnation in the form of AzureAD has long been the complete package thanks to a close integration with Office365. The Identity space in OCI is still evolving, with the tack-on "Identity Cloud Service" (IDCS) slowly making way for the OCI native IAM stack, but at no point in the future do I see IAM usurping AzureAD as an organisation's "source of truth" IDAM solution. Federate both IDCS and IAM back to AzureAD and you'll never find yourself painted into a corner or lacking feature/functionality.

Why Azure?

• Ubiquitous adoption and support
• Complete IDAM service offering

Oracle DB: OCI - Database Cloud Service / Autonomous DB

I don't think it's any surprise here that Oracle workloads run best on OCI. With the full gamut of service offerings from roll your own on IaaS (the only option for Oracle DB workloads in Azure), to a semi-managed Database Cloud Service (which streamlines DB operations but still gives enterprise access to the VM to install agents and customisations), to the fully self driving Autonomous Database which patches, tunes, scales and repairs itself - in my mind, the opt-out target for any database workload in the cloud, it doesn't make sense to run these workloads anywhere else. Add to that the double license benefit of bringing your existing Oracle licenses to OCI and Support Rewards and you have all the technical, financial and operational ammunition you need to make this a very easy argument for Oracle on OCI.

Why OCI?

• Full gamut of "as a service" options
• Existing Oracle DB licenses are worth twice the BYOL currency in OCI vs other clouds
• Performance SLAs and low cost, high IOPS SKUs
• Exadata as a cloud service
• RAC for the only supported active/active Oracle DB clustering solution in the cloud

MSSQL DB: Azure - Azure SQL

Just as OCI helps drive Oracle DB deployments "up the stack", Azure SQL does the same for MSSQL. For those customers who aren't yet ready to take the leap to the latest, fully managed MSSQL service, there are benefits to falling back to IaaS in Azure too, such as the Azure Hybrid Benefit which allows you to BYO Windows and SQL Server licenses (with SA) to Azure VMs. When doubled up with free extended support for older (eg. 2012R2) MS OSes and Applications, a move to Azure can potentially save organisations $10s or even $100s of thousands.

Why Azure?

• Delivers MSSQL as a managed service
• OS license mobility to Azure VMs with Azure Hybrid Benefit (VMs in other clouds need to be deployed in a license included model)
• Free extended support for older OS/App workloads running in Azure

Open Source DB: OCI - MySQL Database Service / Flexible Compute

There's been a concerted move away from "expensive" closed source database platforms over the past 5-10 years. It's a move I don't necessarily agree with in the enterprise space, as I think more often than not the additional support, operational and re-platforming costs, not to mention the level of functional compromise you typically need to accept exceed any true benefit of "freeing" yourself of the tyranny of either Oracle, Microsoft or IBM. That said, I'm not a developer, and I appreciate there's a sense of liberty that comes from shaking a licensing millstone.

To this end, out of OCI and Azure I think former provides the richest set of options and best underlying platform for serving up open source database solutions. On the one hand, you have arguably the most popular open source database solution, MySQL delivered as a service, by the supporting vendor and with Enterprise support included (the only cloud platform to offer this). When I was running teams utilising open source DB platforms, the quality and cost of enterprise grade support probably stuck in my craw more than anything.

Move away from MySQL to solutions that require you to self-deploy and self manage the infrastructure, and all the reasons outlined in the General Purpose Compute section come to the fore. And this is particularly pertinent for DB workloads where performance and reliability tend to be paramount.

Why OCI?

• MySQL Enterprise delivered as a service
• Infrastructure with Performance SLAs and affordable high-grade IOPS/networking for non-SQL/IaaS deployed DB workloads

NoSQL DB: Azure - MongoDB Atlas / Cosmo DB

There's nothing fundamentally wrong with the OCI NoSQL Database Cloud Service... it's just that everything it does functionally, MongoDB Atlas and Cosmo DB (which are both available as managed services on Azure) do better.

Why Azure?

• Certified MongoDB and MongoDB-like managed services
• Full feature/compatibility set
• Extensive community support
• Reasonably cost competitive

Data Warehousing: OCI - Autonomous Data Warehouse

The Autonomous Data Warehouse has long been touted as the jewel in the crown of the OCI platform, and to a degree I think Oracle's maniacal focus on it has actually detracted from commentary on the quality of the rest of the platform. That said, it is phenomenal. A couple of clicks, and you're away, with a self-tuning, self-repairing, self-scaling relational data warehouse that destroys anything else (Teradata, Snowflake, Azure Data Warehouse, Redshift et. al.) in a TCO/performance shoot-out thanks to its underlying Exadata platform and AI/ML smarts. It's just set and forget, and that's my kind of service.

Why OCI?

• Fully self managed platform in the form of Autonomous Data Warehouse
• Highly perfomant with online scalable (up and down)
• Attractive TCO vs the competition

Analytics: Azure - PowerBI Pro

This could be the closest call in the whole list and the proviso here is that you have a functioning data integration/warehousing pipeline - with that in place, the community support and quality of PowerBI visualisations is impossible to overlook. For organisations looking to start their journey into a unified data visibility platform, you have a couple of options: OCI's Oracle Analytics Cloud Service (OACS) and Azure's Synapse which both offer fully managed light-touch ETL, Visualisation and data democratisation services, but OACS is that little bit more mature, and a little more polished when it comes to the quality and capability of the individual components underpinning the platform (specifically, the Data Integration and Warehousing services), not to mention it's considerably cheaper than the Azure alternative.

Why Azure?

• Almost universal adoption of PowerBI as "the people's" visualisation tool
• Quality of visualisations/reporting is second-to-none

Application Integration: OCI - Oracle Integration Cloud

Oracle Integration Cloud (OIC) and Azure Integration Services (AIS) are both capable iPaaS solutions, with low code message flow canvases and a large overlap of out-of-the-box connectors for third party services. If you're a heavy Microsoft shop (Dynamics, Sharepoint et. al.) AIS is going to make the most sense for you, but if you have a gravity of Oracle enterprise applications, an existing Oracle SOA deployment or are yet to build out your Enterprise Service Bus, OIC is the more mature, cost effective and capable product.

All this said, if you're an existing Mulesoft, Boomi or Informatica cloud customer, I don't feel there's enough in either of these products to have you considering a migration/consolidation.

Why OCI?

• Rich set of pre-packaged enterprise application connectors
• Evolution of long-established integration pedigree in the form of Oracle SOA Suite
• Lower TCO when factoring in API Gateway and networking costs

Data Integration: OCI - OCI Data Integrator / Golden Gate

OCI offers a rich suite of data integration solutions and as you'd expect from the company who pioneered data storage and movement - they are rock solid. Batch and near-real-time data integration/ETL is handled by OCI Data Integrator which is the cloud native evolution of Oracle's on-prem Oracle Data Integrator. If real-time replication is your poison, then the venerable Oracle Golden Gate is also available as a fully managed cloud service. I think the justification for this rests in the fact that LinkedIn, a Microsoft owned company still use Golden Gate to replicate their data globally. Azure's Data Factory is good. But OCI's solutions are best-in-breed.

Why OCI?

• Years of investment and evolution culminating in cloud native iterations of proven data integration services
• Batch, near-realtime and realtime ETL data replication capabilities across a range of source and target data technologies
• Zero egress costs if using FastConnect to move data to external data stores

Developer AI: Azure Cognitive Services

For the purposes of this section, I'm focusing on the suite of AI APIs available to developers to enrich their applications and workflows - image recognition, sentiment analysis, speech recognition et al. It's interesting that whilst Oracle boast of the power of the AI they've embedded into OCI, the amount of AI exposed to the user for consumption is still disappointingly sparse with OCI Vision and OCI Language only recently being added to the suite of services (and still pretty MVP in my books). Azure on the other hand has been going toe to toe with AWS and Google for several years now and has a really rich and capable set of AI services available for direct user consumption. This one isn't even close right now.

Why Azure?

• Long term investment in cloud based AI services
• Wide gamut of capabilities with proven outcomes and reference cases

Machine Learning/Data Science: OCI Data Science

Now this one is a little more interesting. Machine learning, and more specifically data modelling is very (surprise, surprise) data focused, and depending on application, extremely compute intensive too. Both OCI and Azure deliver Jupyter based notebook platforms for managing enterprise ML projects, but when it comes to training and executing these models (whether on commodity compute or HPC/GPU) the performance focused design of OCI delivers results faster and cheaper.

Why OCI?

• Jupyter notebooks as an enterprise platform through the OCI Data Science service
• Support for all popular open-source data transformation and visualisation tools
• Cost effective, industry leading performance envelope in the HPC/GPU space

Logging and Observability: Splunk Cloud Platform

I'm going to deviate from the script here a little and recommend a 3rd party cloud service in the logging and observability space. Splunk is far and away the industry leader when it comes to collating, organising and responding to log data. Whilst both clouds have Logging and Observability platforms that are capable of ingesting data from external sources, this is the sort of thing you want sitting in an independent, tertiary domain so you always have access to critical security and operational data in the event of a disaster. Collect on source, ship to Splunk, standardise IT and Sec Ops to a single platform.

Why Splunk?

• Industry leader both in terms of market share and capability
• Independent to your multi-cloud solution
• Too important to compromise on

Kubernetes and VMware: Both Clouds

I'm bundling these two together as the reasoning and ultimate cloud targets hold true for both. Cop out? Maybe... but there's a method to my madness here. OCI and Azure both have mature and capable managed Kubernetes and VMware cloud platforms and given both are effectively industry standard manifolds they represent the perfect "common ground" for highly portable workloads in your multi-cloud environment. Now I know there are a number enterprises who have sufficiently abstracted their app stack away from the underlying infrastructure (through one mechanism or another - Kubernetes being one of them) to be able to deploy agnostically without VMware, but for the vast majority who haven't, VMware on both hyperscalers is a rapid way of getting your "traditional" workloads to the cloud, and a great way to tick that BCP box as you decide on your ultimate cloud pathway.

Why both?

• Both OCI and Azure have mature and capable K8s and VMware platform services
• Allows for easy workload portability, particularly useful in DR/high-demand scenarios
• Low risk assessment of adjacent services (determine where workloads run best without over-committing)

Summary

So just a quick recap of the blueprint:

And that's a wrap for now. I see this as an evolving document - as new services and requirements surface, my thoughts and positioning will undoubtedly pivot. Just to stress again, these aren't absolutes but rather what I would be leaning towards today if I was looking after EveryCorp Pty. Ltd. and its set of common ICT requirements. I hope it helps those looking to embark on a multi-cloud journey and look forward to the discussion I suspect this will provoke!

I'll leave you with this final thought: just because you can, doesn't mean you should, but if you've at least sketched the art of the possible, you'll have conviction in your why.