Buying technology is often considered to be the easy part, whereas implementation is where the bulk of the effort and resources are generally expended.
When a company has spent relatively large sums of money on procuring a cloud management platform (CMP), it wants the technology working as quickly as possible.
There are big wins to be had by deploying a CMP, but also some potentially big losses depending on how well the CMP in question is implemented.
Here is some advice to help with the initial deployment stages – accrued through personal experience of using cloud, automation and CMP technologies – to help enterprises avoid some of the most common implementation problems.
The first thing is to have a detailed outline of what the organisation wants to achieve by going down the CMP route. If there isn’t one yet, the project is behind the curve in terms of what should have been done.
This should set out what the business wants to achieve, in terms of timeframes and project milestones, and should be completed before anything else. These goals could focus on reducing time to deployment, enabling self-service capabilities for requesting/managing infrastructure, controlling who has access to it, and managing cloud costs.
Those are all macro goals, but the key is to be specific in what you want to achieve. For example, a good goal could be: “Reduce time to deployment so that a typical end-to-end request for a virtual server can be completed within a thirty-minute timeframe.” Another goal could be: “Enable approved users to request virtual machines from the self-service portal and allow them to be able to perform day to day tasks on them.”
Aligning resource access
Unfortunately, resource access for users does tend to fall into the “damned if you do, damned if you don’t” camp, and effective management goes hand-in-hand with cloud governance.
There may be occasions where, for whatever reason, several groups get involved in using the platform and the management process goes out the window. Who decides who has what level of access and which teams can do what in the environment? This is where an awful lot of plans fall short, but that is typically only discovered once the project is under way.
Mindset is crucial to a good outcome. Everyone needs to understand the way things currently work will change. Securing buy-in from all levels is key. People are, by their very nature, resistant to change, so getting them onboard before it even starts is going to pay massive dividends.
Giving access to all and sundry during the development stage is to be avoided. Instead, keep a core set of users (preferably power users) with reasonable understanding and knowledge so that – as development progresses – management and communication stays consistent and predictable.
Alongside these goals, it is equally as important to look at the deployment processes. Don’t rush in, but do set logical and achievable goals – you are changing the what and how of doing business, and if done wrong it could be disastrous. There are, however, ways to mitigate some of the risks.
It also pays to create a parallel stream for the purpose of developing the CMP environment. The key point is that it is an iterative process, being small and often. Frequently, a cause of failure is trying to do too much too soon and not getting the desired outcomes.
Alongside creating a parallel stream, a good suggestion is to isolate the development environment from the production stream – be it separate resources, accounts or new hardware for on-premise and hybrid cloud. There will need to be some degree of connectivity between the two, but this will need to be dealt with as they pop up.
Furthermore, being able to easily identify which stream a machine belongs to makes life easier, so use an alternate naming format for the servers and services created.
It is important that you don’t rush into production. Class these machines as development machines so people realise they are not yet tier-1 production class offerings. This also gives the administrators a bit of leeway when accidents happen.
Equally important is the fact management processes need to be around from day one, and this relates back to the governance aspect (such as decides who has what, from the top down). Failure to manage “the who” (managers or consumers) and the resources (on-demand cloud or hybrid) could result in a nasty case of bill shock or potentially give rise to uncontrolled proliferation of servers and services.
A tip here is to get the quick wins in first to ensure victory. For example, once the CMP is installed it should be a relatively simple step to enable portal use and assign machine management to users. This may sound trivial, but if your environment is deployed by the administrator, the ability to pass that deployment decision and automate deployment gets easy.
As a closing thought, a cloud management portal is quite a new technology and it will continue to develop at a massive pace over the next several years.
A multi-cloud strategy for most companies is barely on the radar yet, but using a well-documented and thought out plan alongside a maturing CMP platform from the outset enables the implementers to leverage the best of multi-cloud in terms of flexibility and costs.
It also allows users to manage their servers and services without having to learn and understand several different cloud environments. By hiding the complexity, it makes everyone’s life that bit easier to manage, implement and use.