Cloud services are for the most part extremely attractive because they let the provider (vendor) of the cloud service focus upon what they do best (manage some set of layers in the hardware and software infrastructure), and let you focus upon what you do best (typically concern yourself with your applications and your data). Great examples of cloud services that promote agility include simple IaaS services like those available from Amazon or Rackspace, a PaaS service from Engine Yard or Heroku (now part of SalesForce.com), a SaaS service like SalesForce.com, or a storage service like DropBox. For a lot of use cases for for a lot of customers, these services are the computing equivalent of “Look Ma, no hands” in the sense that they deliver what you need with little effort on your part.
Now there are two very well known issues with cloud services as well. Those issues have to do with the security of your data (who gets to touch it, who gets to see it, how is in protected, and who is in the control of all of these decisions), and the performance management of systems in the case where it is your applications running on the cloud vendors infrastructure. This article is about a third challenge.
The Cloud Services Management Challenge
Let’s say that you contract for some cloud services that are not the standard things that you can buy with a credit card. Let’s say you contract for this:
- This is not a shared tenant environment. Your hardware, maintained for you by the cloud vendor, is not shared by any other customer of the cloud vendor (with the obvious exceptions of the parts of the network where the bits flow in and out of the data centers)
- The cloud vendor is responsible for all of the hardware (storage, SAN, network and physical servers)
- The cloud vendor is responsible for the VMware environment on the physical infrastructure
- The cloud vendor is responsible for the Windows and Linux operating system that run in the VMware virtual machines
- You are responsible for the Java virtual machines and the .NET CLR’s that run on top of the Windows and Linux operating systems
- You are responsible for your Java and .NET applications that run in the environment
Under this division of responsibility, you do not have access to the Virtual Center for “your” VMware environment. You do not have admin rights to your Windows and Linux servers and cannot remote into them to administer them or install any software on them. You can push files to the directories on your servers that contain your application run time environments (the JVM’s and CLR’s) and you can push files to the directories that contain your applications. But you cannot really “install” anything, as you do not have the right to run a process with admin privileges in the context of a system admin account.
When Separation of Duties Impedes the Agility from DeveOps?
What you have in fact constructed for yourself in the above environment is a situation where your team can focus (as they probably should) upon your applications, and the team at your cloud vendor focuses upon the infrastructure. But the nature of the relationship is in fact the exact opposite of DevOps and the productivity and agility that comes from DevOps. DevOps is all about there being no daylight between the team that develops the applications, and the teams that support those applications in production. In fact DevOps is about those teams collectively having the keys to the kingdom, and being able to make any change that they need to in production instantly without having to meet with the Change Control Board.
So the situation above is in fact the exact opposite of DevOps. If DevOps is an important trend because it dramatically helps organization agility, structuring your relationship with your cloud vendor in the manner above goes in the exact opposite direction of DevOps. Look at what you have to go through to make a change that might in fact require the installation of something in the underlying OS in order for the change to work. Let’s say you are trying to install something that has an installation program where a human being has to make configuration choices during the installation process. Let’s that this something is something that you and your team understand very well, but that the admin team at your cloud vendor has never seen. Here is what has to happen:
- You have to open a ticket with your cloud vendor to schedule the installation of this new thing on a server
- You have to write a document on exactly how to install this new thing, that is sufficiently detailed so that someone who knows nothing about this new thing and how it interacts with your applications can in fact follow the steps
- You will have to get on a conference call with the person at your cloud vendor, probably along with a webex, and manually babysit them through this process
- You will have to do this for each of your servers in production individually.
- You will have to do this again, whenever that new thing has a new version or needs to be updated.
The bottom line is that in the above scenario you have combined the worst possible aspects of legacy change control boards, ITIL (which is designed to slow down change and impede agility), with negative impacts upon how your most valuable applications architects and application support people spend their time.
How to Get Separation of Duties and Agility from things like DevOps
The bottom line to this issue is that with DevOPS one team can control the entire environment with great agility and productivity. If you enter buy a managed service cloud offering, you could be tying your hands, and dramatically impeding and impacting your ability to be agile and responsive to the business. If you need to outsource the operation of a layer of your infrastructure, then it would be wise to take the following steps to make sure that you can still manage what you have to:
- Make sure that your contract with your managed services cloud provider specifies that you have access to certain things on a read only basis (for example, even if you have no responsibility for your vSphere environment, you should still get a read only account for your Admin’s.
- Make sure that you have the right to install both infrastructure management and applications management tools that may pull data from the environment that is being managed. For example if you want to install a tool that reads data from the vCenter API’s, you should have the right to do so. If you want to install a tool that puts and agent in the guest OS, the JVM, the CLR or all of the above, you should have the right to do so.
- Consider management automation solutions like Puppet, Chef, ScaleXtreme and rPath. All of these solutions allow you to create a recipe or a model for your environment and then push the deployment of the software in the recipe to N servers automatically. Obviously for this to work, your agreement also needs to let you install agents like this that need admin rights on those servers to run.