FacebookTwitterDiggGoogle BookmarksRedditTechnoratiLinkedinRSS Feed
Pin It

Potentially an Unpopular Article: Creating the Necessity for Automation in Other Teams

It's been a very busy few months with VMworld in San Francisco as well as Barcelona. The best part for me, by far, was being able to participate in all the discussions on automation and self service. I ended up noticing some pretty strong themes in the discussions, and the main things I took away were:

  1. Virtual Infrastructure teams know that they need to automate and provide self service to end users for requesting abstracted resources (virtual infrastructure) to remain the technical partner of the business -- Great!
  2. Not all of the teams that virtual infrastructure depends on feel the same need to use abstracted layers or automation -- Not so good...

This is a problem. If it only takes 2 minutes to provision a virtual machine (the virtual infrastructure part), but 5 weeks to do everything else, we've still failed at delivering a service to the business that is in line with their expectations. With unacceptable service like that, we continue to drive end users to the public cloud. For more on the risks of end users going around the IT team to get resources, check out one of my other articles: Why Your Business Doesn't Think It Needs You

Let's remember the history of infrastructure a bit here, because we're going to talk about some things that might make me unpopular with some people. Years ago, resource requests were taking an excessively long time to procure fulfill. In a worst case scenario technical teams needed a new machine then to rack and image it. To keep up with the business needs, infrastructure teams moved to an abstracted platform (a hypervisor) which allowed them to quickly create, tear down, and automate the provisioning of resources. The implementation of hypervisors were propelled primarily through an onslaught of requests to support the business. Let's keep this in mind as we move forward.

Here's where I might become unpopular--in all the sessions I sat in, the feedback was that the networking team is the choke point at which machine provisioning process slows. I also heard that because their processes aren't abstracted and automated, or aren't automated using a tool that infrastructure teams can utilize, infrastructure teams aren't able to fully automate the infrastructure provisioning process. This, and lengthy approval processes, are the largest reasons why a resource request goes from taking 2 minutes taking 5 weeks.

I would argue that it doesn't matter that you can't automate the networking. Going back to our history from above, until people can't keep up, they don't automate. To that point, sometimes something has tom come along to create that necessity to automate. Below is the track that I suggest taking in order to bring the most change to your organization:

1. Implement a self service catalog that automates the creation of virtual infrastructure. I might be so bold as to suggest VMware's vCAC
2. Within your self service and automation solution, create or enable a the concept of a lease which limits the amount of time that an end user can have a resource for. vCAC allows you to do this, as well as determine if users should be able to extend those leases on their own, with approval, or not at al. This is going to help ensure that resources that aren't being used get torn down-- increasing the efficiency of your physical infrastructure. 
3. create a manual task for the networking team for them to go off and complete their actions in whichever way they deem necessary. You can even make it so that they can simply enter the information into the approval in your provisioning tool to make life easy.

This approach is going to add value and immediately improve your organization's physical resource utilization but also, it's going to cause churn as machines will be provisioned and destroyed with higher frequency.

Automated provisioning processes ensure that the infrastructure teams aren't feeling the impacts of the increased VM churn but the result is that the networking team will start to see issues in the form of people having to sleep at their desks to keep up. The sheer volume of requests, just like the infrastructure teams experienced before compute abstraction layers, will push them to look for a solution to abstract and automate as well. Luckily, products like NSX exist to do just that. Your moves should the go as followed:

4. Encourage abstraction and automation within the networking team
5. Call out to the networking automation from the infrastructure self service and automation solution
6. Configure your self service and automation system to require an approval by the networking team before the resources get delivered to the end user. This gives them the ability to confirm the settings that the resources were given while they are working out potential kinks and getting comfortable with the idea of automating their processes.
7. When they're comfortable, take off the training wheels by removing the networking team approval.

The fact of the matter here, is that networking is undergoing the same transition to abstraction layers that infrastructure went through years ago. The driving force in both situations is to support the business by delivering services they require within an acceptable time frame. The difference is that the virtual infrastructure teams have had a few years head start. That head start is at a detriment to the teams like networking as public vendors have started to come out with offerings that your end users can access. The pressure on these teams will continue to build until they adopt a more efficient model of fulfilling requests, and it's in your organization's best interest to build that pressure early in attempt to minimize the risk to your organization of end users attempting to get a faster, not necessarily better, service in an unregulated public cloud.