Common Cloud Mistakes and Fluffy Cows

Shampoo and blow dried cow.
Shampoo and blow dried cow.

A few years ago a few presentations from various companies touting the newest buzzword at the time “cloud” had slides comparing how we treat our existing servers which were like pets, to how we should be treating them like cattle. At the time it was a bit cringe worthy, now its even worse, but it does highlight well what a large percentage of customers are trying to do.

The below slide may ring a bell.

Pets v Cattle

Pic Credit: Bill Baker, Distinguished Engineer, Microsoft

The unfortunate consequence is that most companies are now running cattle sized operations but treating the cattle like pets. Meet the fluffy cow:

Shampoo and blow dried cow.

Shampoo and blow dried cow.

Obviously this is not what anybody had in mind when designing or building cloud infrastructure.

Here are the common thinks that are overlooked when designing a cloud:


Let’s be realistic, you are not Netflix, or Facebook, you have old apps that are monolithic, you can’t just put SQL in AWS and expect it to be fine. If you want to start developing web-native applications that is great, but your core enterprise apps still need to be highly available until you transition everything to a micro services web native architecture, you have 2 options here:

  1. Build 2 environments a low cost, CI/CD environment, and a high cost, highly available environment with DR.
  2. You only have budget for a single cloud then leave the Oracle/SQL cluster outside the cloud, not everything is a good candidate for cloud and trying to put RDM’s functionality in your cloud so you can migrate in an extra 2 applications in is not worth the complexity.

Bi Modal IT is the answer here, start with a new greenfiled cloud. You cannot kill 2 birds with one stone and trying to do so will often end up with a service nobody wants to use.


You want to rapidly deploy new applications, and spin up test/dev environments, and create a VM in 30 minutes, but the security/network/other team want you to integrate with CMDB, IPAM, Change Request, and ticketing system that was built in 1990.

This is about as greenfield as building a new nuclear power plant at Chernobyl. If you want to deploy in 30 minutes you need to shed the legacy tooling, true greenfield is built ground up with cloud like components and integrations.

As a result of this some of your apps will never be migrated to this new cloud as they are built with a legacy application architecture, application transformation can help fill these gaps, again you cannot kill 2 birds with one stone.

Legacy Network:

This is part of greenfield I know, but often overlooked. In the past you needed all VM to VM traffic to go through your hardware firewall, the network team will insist that you still do this in your new cloud.

They don’t want your automation software to do this though they want to “automate” it by receiving an email then manually creating rules, this is not automated, again 30 minutes just turned in to 3 days, this is not a cloud.

Cloud Operations:

Cloud Ops (aka support) needs to be cross domain, you cannot afford to troubleshoot issues with a team that is siloed between networks, virtualisation, storage, and middle ware, you will end up in finger pointing and slow resolution, you need to have a team that can look at issues across all components, getting provisioning time down to 30 minutes but support that takes a week to resolve is not very cloud like.


Yes we know in AWS/Google/Azure you can spin up an elastic load balancer, and Barry from the web team does have 2 apps that might need this, but building this in to your cloud day 1 will add a lot of cost and complexity, start day 1 with a basic Windows and a basic Linux build, pick the low hanging fruit and leave Barry on the old infrastructure till you are mature enough to support his specific requirements.

Same is true for containers, multi machine blue prints, relational databases, or anything else. Sure it can be done, but start simple and grow your capabilities so the cloud operations team can keep up. Having a feature you cannot support is not going to end well.

Automating everything:

Often I will be asked if it is possible to automate bare metal provisioning. My response is how often do you provision new hardware. If you buy new hardware a cluster at a time every 6 months, then why are you wanting to automate this, sure its possible, but the best candidates for automation are the day to day tasks that use up all your time, not the once a year task.

This is even more ridiculous if you are using a VCE VXblock and paying them to do this for you, why would you want to automate something you don’t do anyway?


Engaging all stakeholders and gathering and qualifying requirements is the first step to building any cloud, without this you risk delivering something the business doesn’t want or need, but is often overlooked. We end up with a cloud that is full of complex services that are hard to support, costly to implement, and not wanted by the business. Remember ITaaS is about providing IT to the business, you need to know what the business wants.