To Cloud or not to Cloud?

Moving into the cloud can feel like an imperative for CIOs. The reasons seem obvious, including the more obvious scalable infrastructure, pay-for what-you use financial model, high availability and potentially robust security.

The downsides are not as well articulated: financial treatment of Capex to Opex shifts, requirement to refactor legacy infrastructure, some potential security concerns if not setup correctly, and the costs when running constant workloads.

At CoreLogic we operate a Hybrid cloud / Multi cloud model, across three data centers and multiple cloud providers. This has prompted us to build guidelines to work out the optimum posture for our different products and environments.

We have needed to answer questions such as: should we run this product exclusively in the cloud? Should we build in the cloud and run production locally? Or should a single product span both on-premises and in the cloud?

To do this we came up with a cloud operating model, specific to our company, which articulates the major drivers to consider and which teams across our business need to be involved in ensuring we have optimised our cloud posture.

Principles of the model are:

Control of where a workload runs rests with the product owners

Product owners own the P&L for their product, they get the information to make informed choices about where it should run.

There is full transparency of costs

• Weekly reports are distributed to P&L owners of what their products cost to operate.
• We ‘tag’ all workloads in the cloud. This provides a highly granular view of what is executing where. It allows decisions such as ‘UAT can run in the cloud, production on premises’.
• We consider the move from Capex intensive purchased hardware to Opex intensive workloads.
• We also consider the cases where we build models that are an asset, and therefore cloud costs can be capitalised. 

We build new products in a cloud agnostic way: using containers and where possible without vendor lock in

• Where necessary and with full transparency we ‘break’ this principle if the cost to refactor is lower than the speed to market and operational cost benefits to build to a particular vendors architecture. Serverless computation is an example of a ‘transparent break’ of the principle.

We differentiate data intensive operations

• These often have high ingress / egress costs to move data into and out of the cloud. These are particularly important where our customers or suppliers have not yet allowed us to store their data in the cloud.
• This may mean we do development and testing in the cloud where we only move the data once and the environment cost is lower, but then run actual production on premises

We differentiate variable / burst loads from constant loads  

• This includes how fast we need to respond to external traffic. Our consumer websites have to be able to scale almost instantaneously, while our banking systems can take a little longer to scale up.

We consider software licensing 

• Unfortunately some legacy vendors have not updated their licensing models, resulting in high costs to operate their software in the cloud. Where possible we keep this software on-premises and then reduce costs by refactoring to remove the legacy vendor

We consider our partners and their needs to share data

• In some cases co-located services in a cloud environment are the best option, in others a simple API integration means our partners don't mind where our service resides.

We have a holistic approach to security

• Understanding the role people play but also monitoring all new environments for security issues. Cloud environments can be tightly secured, the right monitoring and testing as part of setup is critical to ensure obvious mistakes aren’t made

We have the right contracts / legal cover

• Not all of our customers and suppliers want us to store their data in the cloud, but most are comfortable or encouraging once they understand our processes, our security certifications, and our overall security posture.

We have the people with the right skills

• Training our people to have an end to end lifecycle view of software and the process to build, test, release, operate and update it is imperative to making the right decisions. The cloud demands skills that encompass a business view of how code is built and operated, and challenges traditional developers to have a wider context on the code they build: how it performs and scales, and the demands customers place on it

Choosing to move to the cloud is a complex decision, it is seldom an ‘all in’ or ‘all out’ solution, the decision needs to be per product and even environment, and needs to consider legal, financial, customer, technology and people aspects.  We have had fun getting the whole business across the tradeoffs, and every Friday when I get my report from finance on our granular operational costs I know the whole business is on board and living our cloud model.