Customers frequently ask how to avoid a “wild wild west” situation as they move from tightly-controlled traditional infrastructure to the self-service, highly abstracted model that Cisco OpenStack® Private Cloud provides.
They have concerns over quality assurance, security, costs, resource utilization, and more. There’s often a hesitation to take the handcuffs off their developer teams by giving them access to real cloud, even though they clearly realize that if they want to let those teams innovate faster and roll out new features faster, it’s necessary.
Here are five tips for maintaining control of your developers as you move to OpenStack, in no particular order:
#1 – Just don’t do it
If moving fast is your goal, meaning that you want your development teams to be able to create and roll out features faster than ever before, you may need to trade control for speed. That’s right. Don’t do it. There’s a real argument to be made that if your goal is to move fast, you need to get out of your developers way. To summarize a quote from Adrian Cockcroft (@adrianco) in a great talk he gave at Monktoberfest last fall: when big-company CIOs ask how he found such awesome developers at Netflix, his answer is that he hired those smart developers away from those same CIOs, got out of their way, and they built amazing things.
There’s a ton of truth to this. When you give people a box of random Legos, they can build anything you want. When you give them a Lego kit where 90% of the pieces are custom, or even worse, super glued together, there’s very little room for them to build anything interesting. If you’re trying to be innovative, and move fast, you need to give your smart people the freedom to do that. Tight controls and fast innovation just don’t go hand in hand.
#2 – OpenStack Heat Templates or curated DevOps recipes
OpenStack has a project called Heat, which is very similar in function and syntax to AWS CloudFormation. You can also use Chef, Puppet, Ansible, Salt, or any other modern automation platform for this. The idea is that you can describe your stack or your app, and in a single click or API call, your developers can execute the deployment of that stack without having the ability to tweak it. So you could pre-define the VM images and sizes, versions and configuration for things like your web servers, databases, network, security and firewall rules, etc. This forces your developers to deploy the exact “stack” for your apps that you prescribe. Don’t confuse this with PaaS, which we will cover later. This is just a pre-configured stack that you’re making available to your users, the same way you might make a pre-configured “gold” VM operating system image available to them today.
#3 – Platform as a Service (PaaS)
Many organizations are evaluating and starting to use Platform as a Service on top of OpenStack private clouds. While most modern PaaS platforms (Cloud Foundry and OpenShift come to mind) can run on bare metal with a hypervisor or container to deploy workloads, they also run well on top of OpenStack. In fact, many would argue that the better model is to run your PaaS on top of OpenStack because it gives you better management, scale, and flexibility than running it closer to the bare metal.
A PaaS platform gives your developers speed of deployment and scale, because you’ve made most or all of the decisions for them. They don’t have the ability to pick the database or queuing service or web servers of their choice. You’ve decided and made one or a list of them available. The configurations of them are generally pre-defined by your team. They push fresh code into the PaaS layer, it auto-deploys it, and it runs. It’s all about speed, but you compromise on developer flexibility and configurability. Your team maintains that. In a way, it’s a developers dream if they’re writing simple apps, and a pain if they’re writing complex apps that don’t exactly fit the pre-determined configs and platforms available to them in the PaaS.
#4 – Third-party abstraction layers
There are a number of third-party tools and platforms that sit on top of OpenStack (and other platforms like VMware, AWS, etc.) and provide a single pane of glass to your users. The underlying platforms, like OpenStack, become a target for deployment. Generally, the administrators of the abstraction system decide where your workload will run, not the developers. There’s a rules engine to determine which “target” a particular app should get deployed to, what the settings should look like, and who has to approve it before it moves from Dev/Test to QA to Staging to Production. One example of a company that some of our customers are using is Apprenda. Define your targets, define your “stack,” define your policies and rules, and then your developers upload their pre-packaged (binaries) in .NET and Java and they get deployed with those configs and policies.
The upside to this is that your developers are insulated from the underlying platforms, and your central IT teams get to fully control and manage what’s happening. The downside is that your developers are insulated from the underlying platforms, and that your central IT teams get to fully control and manage what’s happening. Again, it all comes down to what you’re looking for. If it’s FAST and giving your developers freedom, you may be looking for a blended model of cloud, which I recently blogged about.
#5 – Human abstraction layers
Last but not least, there’s the human abstraction layer. No sophisticated platforms or automation tooling, just tried and true documented policies, procedures, and configurations that are enforced by humans. Open a ticket, a human (or many humans) go through a time consuming process of approving, processing, and implementing your request.
Upside to this? You can do it today. You’re probably already doing it today with your current platforms. Downside to this? You’re doing it today, and probably not seeing the pace of innovation you’re looking for, which is leading you to want to invest in cloud. If there’s any way at all that you can move away from the “human abstraction layer” model of IT as you journey down the cloud path, I highly encourage it. It might make sense for your legacy platforms and applications, since there’s generally no easy way to automate around them at a granular level like there is in cloud. But please consider automation, and not humans, as you move to cloud.
In Closing
For most companies I talk to, moving faster (innovation) is a clear driver for the cloudy future they envision. Cost management/savings comes in a close second. Use this as an opportunity to really take a look at how you “manage” your developers today, and how tight you have the handcuffs. There’s only so much magic even the best development team in the world can pull off for your business if you’re not giving them room to move.
Cisco OpenStack Private Cloud delivers a remotely operated (SaaS-like) private cloud in your own datacenter, providing a public cloud experience to your developers, but behind your firewalls. One of the things developers love about public cloud is that they don’t have the traditional IT handcuffs. What if you could provide that same experience in-house, without having to give up the control or visibility like you often do with public cloud? There’s many ways to find the right balance of control and developer freedom using OpenStack, and we’re helping our customers strike that balance every day.
For more information on Cisco OpenStack Private Cloud, click here.
Follow me on Twitter: @scottsanchez
CONNECT WITH US