Looking beyond basic cloud economics: Part Three

In Part Two of this series, I discussed how Oracle licensing in an elastic consumption model has the direct ability to reduce the cost of running a system in the cloud, contrasted with an on-premises deployment. Here in Part Three, we will look at a perhaps more abstract, but no less important scenario: costs savings relating to operational efficiencies.

Firstly, let’s get this out on the table: no cloud vendor (or software company in general) is likely to say a migration to their platform won’t improve your efficiency. After all, ’do less with more’ is hardly a compelling value proposition. However, our real world experience is that in many cases operational efficiency is where cloud migration offers the most value to companies across the piste, no matter the size of their estate. Let’s dig into some examples.

Many organizations have traditionally used ancillary technologies alongside their core application. These present a clear opportunity to reduce operational costs when measured in terms of both tangible and less tangible gains.

To illustrate using a specific technology example, many organizations implemented Oracle Identity and Access Management (OIAM) for functionality such as starter/leaver process management and Single Sign On (SSO). This was typically installed across a number of servers and underpinned by technologies like Oracle Database and Fusion Middleware, as well as the underlying operating system. While these technology stacks would likely have been familiar to customers already using Oracle technology, they brought their own operational overheads. With each system, most customers would have at least one or two non-production environments and likely a disaster recovery (DR) environment, as well as the actual production environment. Each requires monitoring, security scanning, backing up, patching (ideally on the recommended quarterly basis), upgrading, and, almost as important, licensing.

Where the technology stack is deployed to Oracle Maximum Availability Architecture (MAA) standards, this would also have meant clustering. This means increasing server counts and adding  Load Balancers and Oracle clusterware to the mix, bringing in extra patching and maintenance. All of this to support a set of services that provide user access and compliance without adding direct value to the application...

Now suppose that within a cloud deployment we simply spin up the cloud vendor’s identity solution—in Oracle’s case Oracle Identity Cloud Service (IDCS). We’ve eliminated multiple servers, multiple operating systems, multiple databases, multiple mid-tiers, and with it days or weeks of patching and management activity. Instead, we utilize the cloud vendor’s economies of scale and support, and their SLAs (which most organizations are unable to match internally).

Here’s an illustrative example of the differences in effort we see between on-premises / IaaS and PaaS models:

Go ahead and look within your own organization—how many other services exist such as File Transfer or Data Integration, log management and aggregation, or even BI tooling? Imagine shifting the burden of the support for some or all of these to someone else, possibly with elastic licensing added into the mix. With all that overhead taken away, how much employee time could then be devoted to delivering reduction in technology debt or project backlog? With IT moving away from being a BAU function to something much more agile and business aligned.

Before leaving you with that thought, we’ve also seen the power of a cloud migration as a forcing function to unlock other avenues. With any migration comes the ability to think differently, and with that the chance to break the ’if it ain’t broke, don’t fix it’ mindset.

We saw this recently with a client with a large multi TB data warehouse that migrated into Oracle Database Cloud Service (DBCS). During the migration we looked at the non-production environment refresh process that was being done via combinations of traditional database backup/recovery and logical export/import—each of which was a process managed by technical resources and often taking a considerable amount of time.

In newer versions of the database (somewhat newer, as it was introduced in 12.2 back in 2016!) the Container Database (CDB)/Pluggable Database (PDB) model allows for network cloning of a database while active, as well as post clone triggers that can implement things like data redaction. Historically on-premises, this newer CDB/PDB model had been resisted as too big a change or too much risk, but as part of the cloud migration, this would have moved our client away from the Oracle standard approach (which we’ll explore in the next blog entry) and left them as an edge case. Using the migration to cloud as the forcing function to adopt this, the non-production refresh is now a single command that requires considerably less management and is much quicker than the previous approach by an order of magnitude.

In the final part of this series, we look at the significant advantages that come with standardization.