(c)iStock.com/Jeffoto

By Jason Deck, VP Strategic Development, Logicworks

Nearly half of organisations meet major roadblocks after the initial stage of a digital project, according to a recent survey. These early failures are potentially disastrous for a project; when IT teams fail to deliver early successes, the entire endeavour starts to look like a bad idea.

A misstep in the early phases of a cloud project can take all the momentum out of cloud adoption. Failure or strain in proof of concept migrations not only threaten the success of current cloud projects, but also dramatically reduces the likelihood of the organisation continuing to invest in cloud technology. This is bad news for IT modernisation efforts and the long-term transformation of enterprise infrastructure.

What causes these early failures? Is it poor strategic planning, insufficient training, or bad technology? The solution requires enterprises to adopt new risk management strategies — and leave behind strategies that were effective when IT was a static, monolithic back office provider.  

Cloud automation

The traditional IT service model says that infrastructure needs to be updated every five years and manually maintained in between. But the cloud finally gives IT the opportunity to design infrastructure to evolve continually.

When you treat your cloud like a system that needs to be manually maintained and upgraded, you quickly reach the point where new rapid product development cycles clash with static infrastructure. IT tries to make changes to the cloud manually to keep up with demand, and because there is no central change management and everything is “custom”, phase two cloud projects stall.

The answer to early stage failure is to stop treating your infrastructure as a system that must be manually maintained, and instead equip your team with tools that allow them to centrally maintain the cloud with minimal manual effort

The answer to early stage failure is to stop treating your infrastructure as a system that must be manually maintained, and instead equip your team with tools that allow them to centrally maintain — and make changes to — the cloud with minimal manual effort. The answer is cloud automation.

Cloud infrastructure must be built from day one to evolve. It must be built so engineers are only touching the abstraction level above server-level maintenance, so that changes are centralised and immediately system-wide. This dramatically accelerates cloud maintenance and also ensures that the system has the proper controls to validate, control, and version changes to infrastructure.

Cloud automation makes it possible to spin up fully-configured resources in minutes. It guarantees compliance and governance across the enterprise by automatically and consistently checking on the status of logs, installing monitoring tools, and shipping data to cold storage.

This reduces friction between development teams and operations, allowing developers to keep up with business demands and systems engineers to focus on improving what matters, not on manual patches and reconfigurations. Automation reduces human effort, streamlines processes, and therefore reduces the disjointed, process-less quagmire that usually plagues new cloud teams.

However, there is a potential pitfall here. Some enterprises believe they can build their cloud environments from scratch and then automate “later”, when their team’s experience grows. But cloud automation is a difficult task that requires a specialised set of skills and a lot of time. Unfortunately, by the time that team gets around to figuring out AWS CloudFormation, configuration management, and deployment automation, they are already knee-deep in the cloud issues.

Successful cloud project leaders realise that they cannot wait six to 12 months for internal staff to write custom automation scripts. Instead, they turn to an external provider to integrate and automate their cloud environment from day one. This requires more than a consulting engagement, and usually means bringing in a managed service provider like Logicworks comes in during the early stages of a project to create automation scripts that can continue to manage automation after migration.

As I have written about before, cloud automation should be the core service offering of every MSP. In the coming years, enterprises will clarify the support they need — and find that of all the many tasks in a cloud adoption process, cloud automation makes the most sense to outsource. MSPs will develop a core library of automation scripts, and this intellectual property will be the foundation of their success. MSPs will accelerate cloud adoption and allow enterprises to run on top of more secure, more highly available clouds.

Enterprise support

Even when clouds are fully automated, enterprises rarely cut system support teams. Instead, they use them with greater effectiveness, focusing them on supporting a greater volume and velocity of product development.

But it takes enterprise teams some time to adapt to a new cloud process. At early stages, having your main compute cluster fail at 11am on a Tuesday could spell disaster for the entire project. To mitigate these risks, enterprises with successful cloud projects usually invest in AWS Enterprise Support.

Cloud automation should be the core service offering of every MSP. In the coming years, enterprises will clarify the support they need, and find that cloud automation makes the most sense to outsource

AWS Enterprise Support is fast, reliable, expert service. We have seen detailed email responses to technical issues from experts in less than two minutes and resolution in 10. Infact, the only problem with AWS Enterprise Support is that more businesses want it than have the budget for it.

As you might expect, these time-intensive services come with a price; it costs a minimum of $15,000 a month or 10% of your usage bill, whichever is greater. A selection of these services is available at their Business Tier starting at $10,000 a month. For many SMBs, AWS Premium Support is simply not an option — especially when they are experimenting with a limited number of POCs and a limited budget.

The answer? Find an MSP that gives every client – even the small ones – access to AWS Enterprise Support — included in the regular cost of maintenance.

How is a $15,000 service ‘included’? You can take advantage of the fact that the AWS MSP Partner has other clients, and your collective budget gives your service provider access to AWS support engineers. It is a little-known benefit that you can get access to AWS Enterprise Support and fund your MSP for the same cost as you can get AWS Enterprise Support on your own.

Set up your team for early wins

Pairing AWS Enterprise Support with automation significantly de-risks cloud adoption.  

When you bring on a strong, automation-focused partner and AWS support in early, you have a better experience and derive greater value from the cloud faster than if you rely on internal teams alone. A good MSP will not only ensure the success of early projects, but will use early projects to establish migration patterns to facilitate future migrations. They maintain early momentum, accelerating all-in cloud adoption.

It is easier to avoid early cloud issues than climb out of them later. The usual strategy — hire more short-term consultants and give workshops on DevOps philosophy — are usually more expensive in the long term that implementing the real structural changes necessary to automate and control your cloud.