To Cloud or Not to Cloud?

There’s a question I’m sure is keeping some IT managers and CTOs up at night. How do you know when it’s right to move a workload to the cloud? And when you finally make the decision to migrate, how do you choose the best location for your application? As mentioned in my previous post, cloud is a buzzword that carries with it a lot of white noise that IT managers and departments need to cut through to see whether it’s a worthwhile venture for their organisation. New three-letter initialisms and hyperbolic marketing campaigns are hitting inboxes daily. Vendors are using studies and figures from advisory firms like Gartner, IDC, and Forrester to back up their elaborate stance on cloud. Yet there is no denying that more companies and applications than ever are transitioning to the cloud. Before I go further, I just want to level-set a few things. Firstly, “cloud” is a service-oriented architecture. Depending on the amount of abstraction you want within the application stack, we have Infrastructure as a Service (Iaas), Platform as a Service (PaaS), and Software as a Service (SaaS). As we move towards SaaS from IaaS, we sacrifice control to gain flexibility and scale. More often than not, “cloud” is used in reference to the public cloud, a collection of services available to the public to consume, at will, via the internet. Private cloud, on the other hand, refers to everything from the data center, the racks, the servers, and networking, through the various operating systems, to applications. The intent is to provide a service or services to a single company or organisation. It can be argued whether this private cloud infrastructure requires the ability to be controlled via a programmable interface to facilitate self-service and automation. To decide where a piece of software or software stack runs, we need to look at the different aspects that can come into play between public and private cloud. One of the first things to do is consider the total cost of ownership for each deployment. While the public cloud gives you the ability to quickly deploy and rapidly scale with known operational pricing, you still need to monitor and assess whether you’re gaining the right amount of agility to performance. With on-premises hardware and software, you can have greater control over costs because you can calculate your requirements then add in the environmental, management, support, backup, disaster recovery, and decommission costs before spending a penny. The downside to this is that you have to “guesstimate” how much your application’s usage will increase over its lifespan. What will happen if your company takes on 1,000 new employees or acquires another business unit that needs to be integrated? If you go too big, you have overspent and underutilized, which nobody wants to do. Yet a benefit from running it on-premises or in a private cloud is that you have far greater control over the versioning within your stack as well as maintenance windows that work with your company’s fiscal calendar. In the public cloud or off-premises, you probably have very little control over these factors and may have to add layers of complexity to deal with things like maintenance windows. Which leads us into decisions that will need to be made regarding disaster recovery and the ability to avoid disruption. With a private cloud, you’ll need to purchase two sets of infrastructures (identical if you want complete disaster recovery), which then poses the question—do you sweat that asset and spread your workload over the two sites, thereby increasing the management overhead for your organisation? This leads to a greater initial capital expenditure (although financing options are available) and then a longer delivery, setup, burn in, benchmark, and tuning period before you can go live. On the other side, we can code site fault tolerance into the majority of public cloud services at deployment time, with several providing this as a default setting with services like databases and others where it can be “retrofitted” as required. Reading this, you probably feel that the public cloud is ahead in this race to acquire your next application deployment, but there are drawbacks. A large one that needs mentioning is, “Can the data live there?” Regulatory bodies like HIPAA, FERPA, SOX, and GDPR have rules to help protect customers, consumers, and patients alike, so decisions on which cloud and usage of technologies like VPNs, encryption, and more are detailed in their frameworks. There are also concerns that need to be addressed around how you connect to the application and manage security for this environment so you don’t end up on the front page of the Wall Street Journal or Financial Times. It is very rare to find an organisation that is solely in the cloud. There are a greater number of companies who still operate everything in-house, but we are now seeing a trend towards the hybrid cloud model. Having the ability to run different applications on either the public or private cloud and the ability to change this during the lifespan of an application are becoming requirements for organisations trying to go through digital transformation. While there are many cloud options available, it’s important not to get hung up on these, as an application may move during its lifecycle, just like a server or VM. It’s about what’s right for the business at that time and having the ability to react quickly to changes in your marketplace. That’s what will set you apart from the competition. I have only touched on some of the points that I see as the ones of greater concern when discussing the various cloud options, but spending time investigating and understanding this area of computing and application delivery will put both you and your company in good stead. A colleague recently mentioned to me that if you are not speaking to your customers about the benefits of cloud, you can be sure your rival is, so let’s make sure we frame the conversation correctly.