According to RightScale’s 2019 State of the Cloud Report, from Flexera, enterprises are prioritising a balance of public and private clouds; with 28% prioritising hybrid cloud and an additional 17% prioritising public and private cloud equally.
There is value to be had for sure, however, the complexity increases significantly when you move to the cloud, particularly in a multi-cloud or hybrid scenario.
So how can you ensure a consistent operational management approach between your on-premise and your cloud environment? For starters, understand your limitations, and capabilities; contain your cloud spend; and know that governance is not a once-off activity, asks Grant Morgan, GM for cloud at Dimension Data.
Understand your limitations
The big three hyperscalers are Microsoft Azure, Amazon Web Services (AWS), Google Cloud Platform, and if you’re in Asia – then Alibaba Cloud. They are by nature, there to provide companies with the ability to scale up and down, as and when needed. It sounds easy, just like ticking a box to ask for an extra few terabytes of storage or computing capacity, in reality though, operating across multiple clouds is very complex, particularly when you don’t have the expertise, or tool-set to handle it.
One of the things hyperscalers all have in common — besides their massive investment in datacentres — is that they all do things differently. Just because you are an expert on one platform, doesn’t necessarily mean your skill-set can translate seamlessly to the other. Making the move to one of the them is a big step, going multi-cloud, or hybrid, makes things infinitely more complex.
Most people are finding that they don’t have the skills necessary to operate in the public cloud environment. You cannot take your existing on-premise tool-sets, and expertise, and hope they are going to work on cloud. In fact, you will need to change your operations processes and procedures entirely to operate successfully in cloud. Your operational environment needs to be able to scale up and down, just like you scale your resources up and down on cloud, as the amount of your required services grows, and you cannot do that in a static environment.
What to expect when moving to cloud
When it comes to normal disciplines in the operations environment, there are certain process and rules that need to be followed. Consistency is important for your configuration management database (CMDB), for example, but how do you achieve and maintain a consistency in your CMDB, when the environment is flexing, demanding and inducing change as it does on cloud? To maintain consistency, you will need to build an automation that will handle the dynamic scaling up and scaling down environment that is inherent in cloud’s nature.
Another area where cloud differs to on-premise operations is best practices, as those that govern operations in a typical on-premise environment often clash with the cloud-native mode 2 application developers that work in a completely different way. Cloud developers want to continuously release code through a DevOps process and in some cases, this is totally in conflict with the on-premise, traditional ITIL processes. It results in clashes of operational culture, with one side wanting to act fast, and the other saying wait, slow down, we have operational change processes to follow.
Monitoring is another challenging area when it comes to cloud. Most people are going well beyond infrastructure-as-a-service (IaaS), and they’re going up to platform-as-a-service (PaaS). They want to move to Cloud because they want to use the PaaS service options that exist like, machine learning; IoT; or database-as-a-service. These services need to be constantly monitored, the problem is that most people’s monitoring tools have been set up to manage a virtual machine, in other words a Windows operating system, where you can load a monitoring application and draw statistics out of that server, and manage it.
With cloud servers there is no operating system, so there is nowhere for you to load a monitoring agent. The only way to instrument these PaaS services in a cloud environment is to use APIs. Your monitoring system needs to call the cloud vendor’s API. In a multi-cloud environment, it will need to call multiple vendor’s APIs.
The thing is, all of the cloud vendors APIs are different, as are all their PaaS services, so you will need to set up unique monitoring for each cloud platform. Without automation, this becomes extremely time-consuming and difficult, therefore many clients are turning to manage service providers (MSPs) to handle this for them.
Disaster recovery (DR) and management operates completely differently on cloud than it does on-premise. In order to contain costs in the Cloud environment, you don’t want to pay for disaster recovery services that you don’t use.
The key is to only create that environment the day you have a disaster, but that is a big job to rebuild your entire production environment and the DR environment. It will need to be done through DevOps pipeline as it will be near impossibly to meet a two or four-hour recovery time if you are going to rebuild the DR environment on the graphical user interface on Azure for example, and start configuring the entire environment all over again, without it being automated.
So, if you want the most cost-effective DR — which is what the cloud vendors promise — it places a huge automation burden on your operational team in order to execute it effectively and reliably. Disaster recovery management is incredibly more complex because the expectation is a lot higher.
Contain your cloud spend
Rightscale’s report states that 13% of enterprises spend more than $12-million a year on public cloud, while 50% spend more than $1,2-million annually. If you’re not careful, if you don’t put limits in place, and if you don’t cost optimize, runaway cloud cost will likely be one of the biggest issues that you face.
Azure came to South Africa in March 2019, and AWS will likely have cloud in South Africa in the first half of 2020. The more options a consumer has, the greater the chance to keep a provider honest as you can then benchmark their rates.
Managing costs becomes critical, particularly if you’re wanting to achieve the cost reductions that everyone says cloud can bring. You’ll need automation in place if you’re wanting to spin down your development environment, after 8pm to 7am the next morning, and you want to spin it down over weekends, switching things off when the developers are not using them, for example.
The more dynamic releases you have, the more often you spin up and spin down, the more costs need to be monitored. Add the complexity of two different Cloud vendors in a multi-cloud environment that do things totally differently, and you can see you’ve got an operational challenge on your hands.