Cloud Native/NFV

Automated Service Provisioning: Getting It Right

For IT administrators, demands from the business are growing, while headcounts are trending downward.

The responsibilities of today's systems administrators typically revolve around the provisioning of various digital services within public, private and hybrid infrastructure-as-a-service (IaaS) clouds. These processes, if performed manually, can be a tremendous time sink.

The best defense against these types of routine tasks is to look toward automation.

The problem, however, is that if not done properly, automated provisioning can cause more harm than good. That's why it's so important to lay out an automated provisioning strategy that satisfies organization requirements while keeping the process streamlined and easy to manage.

To create the ultimate automated service provisioning plan, your first step should be to set the right expectations regarding what automation can realistically provide within your environment.

Get it right
(Source: Geralt via Pixabay)
Get it right
(Source: Geralt via Pixabay)

The amount of potential that automated provisioning could have on an organization hinges on several factors. One such factor revolves around the overall number of differing data center -- public and private -- environments and architectures you must automate for.

The more differences you have between disparate environments in a multicloud architecture, the more complex your automation deployment is going to be. Processes that are manually performed today must be documented across all data center architectures, so they can be properly automated in software once the time comes. (See AWS, Azure Dominating Multi-Cloud Expansion – Study .)

As you can imagine, the same processes will have to be documented over and over depending on the number of different environments you operate.

A second critical step -- one that's often overlooked -- is to work to optimize the way manual provisioning processes are executed. Once they are optimized using manual processes, these processes can be documented. Not optimizing prior to documentation almost guarantees that inefficiencies are built into the automation process that could haunt the IT department for years to come.

Our third automated provisioning step is to hypothesize the types and variations of applications or services that an organization is expected to deploy now, and into the foreseeable future.

The goal of an automation provisioning service is to build the fewest number of pre-defined "standard" automation profiles -- or templates -- as possible. IT shouldn't build profiles to fit every situation. Instead, the goal should be to build profiles that will meet 80% to 90% of the most common deployments.

The idea is to reduce as many manually configure services as much as possible.

There will also be organizations that find it easier to allow the end user to create and modify their own templates to suit their needs. However, for larger companies that might want to stick to standardized builds, forcing users into using a handful of standard templates is ideal.

Finally, it's important to choose the right tools when it comes to executing your automated provisioning plan.

This is the part that is largely dependent on the data center architecture or architectures a business operates. As we have seen, automation is far easier in a homogenous data center architecture environment.

However, many enterprises are spread across multiple cloud providers with vastly different infrastructure architectures. One solution to this is to develop multiple automated service provisioning plans -- one for each environment. This allows administrators to leverage the best automation tools for any given environment.

The downside, of course, is that administrators must build and manage each cloud separately.

This dynamic is making many IT departments looking at multicloud management platforms to help to streamline automation processes across two or more clouds. (See VMware Debuts Multi-Cloud Management Services.)

This gives administrators a single pane of glass for automation profile configuration, while leveraging the cost and resiliency benefits a multicloud architecture can provide. However, keep this in mind: Multicloud management services are still in their infancy stage.

These services have a long way to go in terms of providing a robust set of management features for a wide range of cloud providers.

Related posts:

— Andrew Froehlich is the President and Lead Network Architect of West Gate Networks. Follow him on Twitter @afroehlich.

mhhfive 12/4/2017 | 1:08:47 PM
Multi-cloud management... > "many enterprises are spread across multiple cloud providers with vastly different infrastructure architectures..."

Managing multiple clouds is apparently in its infancy, even though it's somewhat common. I wonder how long this situation will last -- and I think the tools for managing multiple clouds may be coming very soon -- with widespread adoption in less than 2 years. Anyone else have a prediction for the maturity of multi-cloud management tools? 
Sign In