In some of our previous posts we’ve talked about the many different kinds of cloud services and providers, be they public, private, or hybrid. But at the end of the day, if you don’t focus on the automation and orchestration then you’re not really doing cloud – you’re storing up issues for the future, and not really getting the efficiencies and cost benefits of cloud services.
The real goal of cloud is to improve the efficiency and effectiveness of your development organisation, remove wasted infrastructure costs, reduce the complexity of services, and massively improve service flexibility and scalability. So orchestration and automation should be front of mind.
The difference between automation and orchestration
Think of it like this, automation is the equivalent of playing in a string quartet, orchestration is more like a philharmonic.
Automation allows you to automate (obviously) some steps in a process. For example, it may enable you to build a server. What it won’t allow you to define is the location of a server, its environment, the accounts you’ll need to create, the backups, the network configuration requirements, the installation of a database platform on top of the server (with its accounts, configuration etc), or to charge the consumer for its use. This is orchestration – and it’s the key to cloud enablement.
Let’s be clear, a move to the cloud could be complex, difficult, and expensive – and anyone who tells you otherwise is being economical with the truth. So why even do it?
Well if done properly you have the potential to increase developer productivity by 20% (yes, you read that correctly). So if you have a company with 100 developers then you’re looking at a benefit opportunity of around $2-3M. Per year!
How? On average a developer will waste one day a week. The time sinks include: attending infrastructure requirements meetings, waiting for infrastructures to be built, configured or changed, chasing the understaffed infrastructure team, spending time on the phone, attending more useless meetings, waiting for the application code to be installed and configured… (although generally they will hand off deployment to a support function).
So imagine being able to request a fully configured environment and receiving it in less than an hour. Or, if you go for a fully integrated development environment, in just a couple of minutes! On top of that you’ll save on infrastructure costs building and destroying environments on the fly because (of course) you’ve done a great job in orchestrating the solutions.
To implement orchestration you’ll need to really think hard about the end-to-end process, and then systematically drive out every piece that requires any human intervention. Any manual task within the process will cost you significant benefits – it really is that simple.
You may recognise that some of your production services are not suitable for the public cloud, but you still need the public cloud for your development environment. You may also want to share the same internal processes to create the service, hiding the complexity from your users. This is where cloud brokers come into play – but what are they?
Cloud Brokers – two words, two meanings
Cloud brokers can mean two different, but interconnected, things:
- A piece of technology that bridges multiple clouds to hide the complexity from the user community
- A company that provides services that abstract much of the technical, financial and integration issues away from the consumer – check out Century Link as an example. Done well, it will abstract the complexity away from the developer user community.
In the context of this blog, a cloud broker, or Cloud Management Platform, is a set of tools and processes that are designed to provide a seamless integration between two or more clouds. This is the hybrid cloud model we’ve talked about in previous posts, and may well include the existing internal data centre environments into which you are going to implement a set of cloud services.
In the context of a cloud broker the focus should be on two vectors:
- Do you really need a hybrid solution and therefore a cloud management platform? Many organisations do for example when splitting development and production across private and public solutions because of regulatory and compliance concerns.
- Really focus on the service automation and orchestration. Having common services and processes that hide all of the complexity away from the consumers without implementing a proprietary set of services or tools is critical. Hybrid solutions will increase the complexity of the services and orchestration, but don’t trade lesser automation when faced with more complex cloud models.
There are a few key services that need to be considered in addition to the normal cloud factors:
- Service management – aspects such as performance against SLAs, service monitoring and capacity management
- Financial management – metering of service, charge allocation and reporting
- Service fulfilment – provisioning, cloud to cloud migration, asset allocation, etc.
- General services – service catalogue, portal (and command line interface), analytics and reporting engine
- Policy management – enabling the allocation of resource based on company policy; for example, development public, production private
Many of the above areas are offered by CSPs already, the focus is on ensuring that you have a method that can span the multiple providers through one seamless interface.
Final point – there are a number of “off the shelf” products from companies such as IBM, HPe, Cisco as well as smaller organisations such as Cloudify or CloudBolt that provide cloud management platforms – definitely worth consideration in the context of hybrid services.
If you’re going to go down the hybrid route, bring in an expert who has done this before. It’s not for the faint hearted. Although it’s the perfect solution for many organisations, if done incorrectly the cost to your business could be staggering – largely because you end up with duplicates of everything. Organisations that get it wrong then sometimes ‘uncloud’ – an expensive mistake. For more on ‘unclouding, check out ‘Unclouding’ and How To Get Cloud Adoption Right.
If cloud orchestration seems a whole lot more complex than you originally thought – you’re right. And we haven’t even touched on the organisational elements of this yet. But fear not, remember that 20% efficiency saving – it really is worth the effort. The payback is generally delivered in less than a year and has the power to completely transform the way you think about your IT function. But before you reach for the company credit card, there are more potential pain points and opportunities to consider. Form more information on transformation strategy, check out Don’t Let a Good Transformation Go To Waste and Organisation-Wide Change is at the Heart of Cloud Transformation.
- Posted by John Shortt
- On 27/07/2017