Developers Want Public Cloud [Easy Button]…Due To [SLOW] Private Cloud Server Deployments.
Long before there were frustrated developers waiting on VMs, there were frustrated developers waiting on RAW metal servers. So what has really changed, right? Well, I think we would all agree something is still wrong!
Here’s another question…
“Wasn’t virtualization supposed to fix this?”
Now here’s my answer…
“Yeah, kinda” – but the server build process is still hitting roadblocks because though virtualization improves hardware utilization it doesn’t always fix the build steps IT groups create and jump through to deploy a server.
There’s a lesson here for beginners.
“Developers don’t care what label is on your hardware or software if you can’t give them the compute power they need when they need it.”
Both Amazon and Google have been building their own (non-branded) low-cost and highly redundant infrastructure for years. Their focus has been on making their services as easy as possible for customers to use, not boasting 3rd party brand names. Yet, traditional IT departments who have purchased every whistle and bell Cisco, NetApp, VMware, and others vendors offer have still not learned this lesson. And now they’re being left out in the cold with their cool blades and storage while Dev Teams have given up on them and are already full speed ahead deploying in the cloud, the public cloud that is…
Let’s drill into what’s going on behind the Ops Scene.
Steps For A Typical VM Build (once a request is made via a ticket) A typical VM deployment may take the following workflow steps from start to finish:
- Carve out the VM, CPU, Memory, Nic, and disk space (the first step in the process, granted the capacity is already available)
- RDM, iSCSI, or NFS mounted storage is created (done by the storage team on a separate task or ticket)
- IP Address and DSN reservation is created (done by the network team on a separate task or ticket)
- VIPs and Alias are created (yup, done by another team or ticket)
- The app, Web, or database installation and configuration (yup, done by more teams and ticket shuffling)
- Security scan (yup, done by another team and more ticket shuffling)
- Monitoring, antivirus, and other agents enabled (done by yet other teams on multiple tasks or tickets)
- Release to Production Check or QA (a task to make sure everyone has finished their tasks and tickets)
And the list can go on and on with slight differences depending on controls.
The Customer Problem
The problem with our process is we virtualized the hardware but we left all the legacy roadblocks in place. So instead of making the server request process faster we really haven’t cut much of the provision time except for the racking, cabling, and powering of hardware. Sure the end result is you have built an awesome private cloud but nobody wants to use it because they don’t want to wait weeks while teams throw tickets back and forth over the fence to get tasks done. This alone has led to many software development teams giving up on their internal IT departments and going straight to the cloud via AWS, Azure, or Rackspace. With a few clicks – within minutes – they are coding. Now granted there isn’t any governance around this and yes, in the long-term it will need to be reigned in, but for now, it’s solving the problem of waiting on IT.
The Root Cause of the Problem
Simple answer. CONTROL. The long answer… The problem is controlling who presses the easy button. Unless you have converged your teams, there are at least 4 or 5 teams owning tasks in the server build process and each does not want to give up the power needed to create the easy button.
“All AWS and Azure really creates is an easy button. Put in your credit card info, click, click, and get coding!”
3 Solutions for Improving Slow Server Deployments:
Number 1 (Self Service Portals)
I’m talking about something like vCloud Director or Openstack. Or here are more self serve portals to choose from. Install the tool, set up the resources on the backend, and give the power to the developers to push the easy button. Gotchas: The main risks are keeping up with the server sprawl it creates and running out of capacity.
Number 2 – Temporary Converged Team (War Room)
Whether the resources are dedicated or only grouped together at set times every day or week, they need to be available to complete the tasks fast. No waiting days or weeks. Get it done now. This keeps the ticket from waiting in the queue for the next task to be completed. Basically, it’s an assembly line and the end result is servers are turned over to the developers in much shorter times than if tickets are thrown over the fence. This is also called a war room and can be used for other services that need fast turn-a-rounds. Get all the needed people in a war room together. No phone calls, emails, or IM – they are communicating face to face. Gotchas: The gotchas here are some people cannot be pulled away from the day-to-day for long and too much time cooped up with others can [will] cause conflicts.
Number 3 – Dedicated Converged Team (DevOps)
You really need to take your service seriously and be willing to change to do this one. Basically, this team has all the keys and controls from start to finish to push servers out. We’re talking about server builds, configuration, and deployment wrapped into one package. Think DevOps Storm Troopers who use technology such as Chef, Puppet, and other automation tools to rapidly get servers stood up. And the same group then works closely with developers to support any config changes and code releases. DevOps is sometimes confused with Agile but they are different both are designed to get services completed quicker. The gotcha with DevOps is the time it takes for the culture change which is needed to get it going. The more the automation the better.
The real proof of DevOps skills can be measured in improved service delivery. For example shorter times to get tasks done, fewer tickets, closer collaboration, and automated builds, deployment, and release processes.
So regardless of how you chose to streamline your server deployment process, get it done ASAP. Chances are the train has left the station and you’re playing catch up with Dev teams already in the cloud. Worst, maybe you’re trying to figure out how to bridge the environments (internal and external) and clean up the cloud sprawl mess which is costing your company $1000s every month on zombie servers that are not used, but you are getting billed for. So I’ll say it one more time in closing – STOP throwing tickets over the fence and streamline your server build process!