Don't build an enterprise non-cloud!

Updated: December 12, 2019 Updated: Cloud

Going to the cloud? Sure, you are!

Pretty much every enterprise is in the process of moving compute and data resources to the cloud. Some of them are finding that not all their expectations have been met. While some of these expectations may have been inflated in the first place, moving to the cloud without a clear strategy is a likely cause. While it’s OK for the first learning steps, the lack of strategy is bound to negatively affect the migration as different stakeholders will have different expectations. It’s going to be very hard to meet all of them – cloud is amazing, but it’s not a miracle cure that can magically solve all of IT’s ailments overnight.

This fancy looking sports car is unlikely to meet your expectations

Another major reason for enterprise cloud migrations leading to disappointment stems from a migration journey that deprives the cloud of the great properties that it was going to bring in the first place. Good intentions don’t always lead to good results. And a compromise is unlikely to make everyone happy, rather the opposite. Let’s see how bad cloud happens to good enterprises.

Enterprise Cloud Considerations

When enterprises move to a commercial cloud provider, such as AWS, Microsoft Azure, Google Cloud, or Alibaba Cloud, they don’t just grab a credit card, sign up, and deploy away. They have existing policies and regulations to meet, need to exercise spend discipline, and often have special data encryption and residency requirements. Therefore, almost every IT department has a cloud transformation program underway that attempts to marry existing ways of working with the operating model of the cloud. Now, because the amazing thing about cloud is that it rethinks the way IT is done, we can imagine that this translation process isn’t trivial.

Enterprises don’t just grab a credit card, sign up for a cloud provider, and deploy away.

When I work with large organizations on their cloud strategy, a few recurring themes come up that guide the use of commercial cloud in the enterprise context:

• Onboarding
• Hybrid Network
• Virtual Private Cloud
• Legacy Applications
• Cost Recovery

Each of them makes good sense:

Onboarding

Enterprises have special requirements for cloud accounts that differ from start-ups and consumers:

• They utilize central billing accounts to gain cost transparency instead of people randomly using credit cards
• The need to allocate cloud charges to specific cost centers through billing accounts
• They negotiate discounts based on overall purchasing power or “commits”, stated intents to use a certain volume of cloud resources
• They may limit and manage the number of cloud accounts being shared in the organization
• They may require approvals from people whose spending authority is sufficiently high

Most of these steps are necessary to connect the cloud model to existing procurement and billing processes, something that enterprises can’t just abandon overnight. However, they typically lead to a semi-manual sign-up process for project teams to “get to the cloud”. Likely, someone has to approve the request, link to a project budget, and define spend limits. Also, some enterprises have restrictions on which cloud providers can be used and for which types or workload (using a multi-cloud “segment” model).

Once onboarded, developers who need access to cloud instances from their machines connected to the corporate network, typicaly need to setup VPN’s and firewalls such that access to cloud resources is restricted to authorized developers only. In many cases, endpoints, i.e. developer machines, have to be registered and undergo device management.

Hybrid Network

No CIO is going to wake up one day just to find that all applications have migrated to the cloud. This means that Hybrid Cloud is not an option, but reality (see Slicing the Hybrid Cloud Elephant). This’ll mean that applications running in the cloud communicate with those on premise, usually over a combination of a cloud interconnect, which connects the virtual private cloud with the existing on-premises network.

Virtual Private Cloud

Enterprises aren’t going to want all their applications to face the internet nor are they too keen to share servers with other cloud tenants. Most cloud providers can accommodate this request with the concept of dedicated instances or dedicated hosts.

Legacy or Monolithic Applications

Many applications in the enterprise portfolio are going to be third party, or architected as single instances. These applications cannot easily scale out across multiple server instances. Re-architecting such application is either costly or, in case of commercial applications, not possible.

Cost Recovery

Lastly, preparing the enterprise for commercial cloud, or the commercial cloud for enterprise costs money. This cost is often borne by the central IT group so that it can be amortized across the whole enterprise. Most central IT departments are cost centers that need to cost recover, meaning any expenditure has to be recovered from business divisions, who are IT’s internal customers. It’s often difficult to allocate these costs on a per-service or per-instance basis, so typically IT adds an “overhead” charge to the existing cloud charges, which is reasonable.

There may be additional fixed costs passed on a per division or per project team basis, such as common infrastructure, aforementioned VPNs, jump hosts, firewalls, and much more. In these cases, internal customers pay a base fee on top of the cloud service fee.

Remembering NIST

The US Department of Commerce’s National Institute of Standards and Technology (NIST) published a definition of cloud computing in 2011 (PDF download). It used to be cited quite a bit, but it seems safe to assume that everyone by now knows what cloud is (and the ones who don’t, are too embarrased to ask), so I havent seen it cited much recently. The document defines five major capabilities for cloud (edited for brevity):

On-demand self-service	A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction
Broad network access	Capabilities are available over the network and accessed through standard mechanisms
Resource pooling	The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically
Rapid elasticity	Capabilities can be elastically provisioned and released to scale rapidly outward and inward with demand
Measured service	Cloud systems automatically control and optimize resource use by leveraging a metering capability (typically per-per-use)

So, after this academic detour, you start to feel like something doesn’t 100% line up, you may be on to something…

The Enterprise Non-Cloud

Putting the enterprise “features” from above next to the NIST capabilities, you realize that they largely contradict:

• Lengthy sign-up processes contradict on-demand self-service as they often require manual approvals and software installs - corporate IT processes say “hello”.
• Your corporate network isn’t going to be quite as broad as the internet.
• Dedicated instances aren’t as widely pooled and have poorer economies of scale. Your network interconnect is also dedicated.
• Traditional applications don’t benefit from rapid elasticity as they don’t scale out.
• And a high baseline cost charged from corporate IT makes the cloud a lot less “measured”.

That’s bad news as it means that despite all good intentions your enterprise didn’t get a cloud! It got yet another data center, which is surely not what it expected.

Be careful that your cloud doesn’t become yet another data center.

What Now?

So, how to avoid building yet another data center? While there’s no sure recipe, here are a few thoughts for consideration:

Calibrate Expectations

Realization is the first step to improvement. So, being aware of these traps is a first major step towards not falling into them, or at least not without knowing. Also, often cloud initiatives are started by rosy visions of cost savings and digital transformation. It behoove us to moderate these and set realistic expectations: if you move all the old junk to a new house, you’ll be living with the same junk.

Bring cloud to you, not vice versa

Cloud isn’t a classic IT procurement, it’s a fundamental change in IT operating model. Therefore, you should be cautious not to transport your existing operating model to the cloud as that’ll lead to the results cited above. Instead, you need to bring some elements of the cloud operating model to your environment. For example, you can replace cumbersome manual processes with automation and self-service so that they benefit both on-premise systems and those running in the cloud.

Measurable Goals

A cloud migration without clear measure goals is likely to get off track as IT departments get lost in all the shiny new technology toys. Instead, be clear why you’re going to the cloud: to save cost, to improve uptime, to launch new products faster, to secure your data, to scale more easily, to sound more modern - there are at least a dozen reasons for going to the cloud. Prioritizing and measuring progress is more likely to keep you on track.

Segmentation

One cloud size doesn’t fit all. Not all applications need to undergo all firewall-compartment-peering-configuration-review steps. Perhaps for some applications, going straight to the cloud is actually OK, perhaps as long as billing isn’t on Jamie’s credit card.

More traps

Cloud migrations navigate in treacherous waters. Many enterprise are falling into the avoid lock-in at all cost trap and aim to achieve that by not using cloud-provider-managed services because most of them are proprietary. This means no Aurora, DynamoDB, RDS, AWS Secrets Manager, SQS, BigQuery Spanner, and so on. Now, you may still have a cloud, but one that predates the NIST definition from 2011. Also not the place where you want to be. If you embrace cloud, you should embrace managed services.

Happy Clouds

Without a good map, even the most fun road trip can turn into a nightmare. The same is true for cloud migrations. It pays off to have a clear plan and strategy that acknowledges both business objectives and the current IT environment.

Read more on cloud strategy:

• Slicing the hybrid cloud elephant
• Multi-hybrid Cloud: An Elevator Architect’s View
• Don’t run software you didn’t build