So you have made a decision to make the switch to the cloud — you want your organisation to take advantage of the automation, scalability, and cost savings that the cloud brings to the table.
But what do you need to know before embarking on the cloud path?
Public cloud vs. private cloud vs. hybrid cloud
If you’re an organisation with standard service offerings that have relatively repetitive or straightforward workloads, then shifting to a third-party managed public cloud where you no longer need to carry the infrastructure burden would seem like a smart business decision.
If, on the other hand, you’re an organisation running applications that store highly sensitive data with a focus on governance, security, and compliance, then you would want to look down the path of a managed private cloud.
However, if you’re a large organisation that has a mix of custom in-house applications and standard applications, then it is more than likely that you have already invested quite a bit in bare metal infrastructure with your own datacentre. Moving to the cloud doesn’t necessarily mean you need to forfeit past investments.
Hybrid cloud models allow organisations to benefit from the automation of public clouds whilst reaping the security and privacy benefits of the private cloud. It also enables organisations to run their custom applications in their existing datacentre with the option of leveraging a number of software-as-a-service (SaaS) applications in the public cloud.
There are plenty of cloud models for enterprises to consider, but it is important to understand that there is no silver bullet. The cloud often acts as a catalyst for IT maturity. This means that it is necessary to understand your own processes before thinking of using infrastructure as a service (IaaS) or the cloud. This leads me to my next piece of advice.
Cherry pick your apps onto IaaS
Does your company have a well-defined application or service catalogue? Having a clear understanding of your organisation’s service catalogue will help you make a more informed decision as to the applications or infrastructure layers that can be moved to the cloud.
Giri Fox, the manager of the Australian branch of cloud management provider Right Scale, reiterates the importance of having a filter against which you can check candidate applications.
“Some applications go quickly to the top of any list, such as those that are already web delivered on the intranet. The considerations for the lower layers of infrastructure include dependencies on other systems for user authentication, access control, queries, latency sensitivity, and the volume of data moving between systems,” said Fox.
With some good fortune, there will be a few discreet applications, which generally make for ideal candidates to move to cloud infrastructure first, as they tend to be less mission-critical applications with considerably lower system dependencies.
Have contingency plans for when things go wrong
You have to design with the assumption of failure in the cloud. For example, the recent massive Azure outage was only a problem if you had not designed around the possibility of that cloud failing. Amazon Web Services (AWS) has had outages of a similar impact.
A backup strategy, such as adding copies of your server instance in multiple regions and datacentres, will ensure that you’re covered even if multiple regions or cloud service providers experience outages.
A disaster-recovery strategy should also be part of any contingency plan. A number of cloud service providers offer cloud disaster recovery where they can recover physical or virtual machines in a cloud within minutes, but it is important that you have the backup server processes in place to avoid unnecessary downtime.
Understand vendor risk management
Many companies tend to view cloud companies with rose-coloured glasses and not ask the hard questions that would otherwise be the norm for any vendor qualification process.
What’s the history of outages? How can I get my data out if I stop using your services? What format is that data in? Is the service extensible with its own APIs? What happens in the event that the data is leaked or lost? What processes does the cloud provider have to mitigate this risk?
These questions should have a dramatic weight in the overall criteria of selecting a suitable cloud provider.
This is a business and cultural change as much as one of technology
Do not assume that your existing ideas, processes, resources, and tools for monitoring, backup, configuration management, licensing, and availability are appropriate for the cloud. Mostly, they need to change toward an agile, service-oriented approach.
This also means internal IT teams that were previously developing software and system administrators that were maintaining bare metal infrastructure will need to learn new cloud-era skills. These resources certainly still have a place within the organisation, but some will need to shift toward support and maintenance, and traditional support engineers will need to adopt more of a product management or project management role.
It’s important that you engage with the internal IT teams from the outset and help them understand how this new service should operate or how it will affect their career and value to the organisation. After all, it will be the very same teams that will be the number one consumer of this cloud.
This process may also involve hiring a new cloud administrator, which leads me to my final piece of advice.
Partner with a proven cloud-oriented consultancy or hire a cloud admin
Partnering up with a proven cloud-oriented consultancy or hiring a dedicated cloud admin to act as a coach to senior management and the internal IT teams is key in driving the transition process. The value in having a developer or architect, who approaches the cloud not from the traditional infrastructure up, but as a service, will go a long way in aiding your organisation’s transition to the cloud.
Don’t assume that your IaaS provider is appropriate for this role, or that you are aware of all the possibilities the cloud has to offer.