Putting the Service Back in “as-a-Service”
The future of cloud computing has often been framed as being a debate between private vs. public clouds, with each model having its own strengths and weaknesses in terms of cost-effectiveness, control and security. The debate should instead focus on what each model can borrow from the other to deliver the most efficient, scalable and flexible service possible.
When deploying a private cloud, system administrators should take a page from public clouds by focusing on the overall services their private cloud is providing. When designing and implementing a private cloud, enterprises need to focus on meeting the needs of the line of business. By utilizing a service-oriented approach that ensures the business can easily access and rapidly deploy the services it needs, enterprises can maximize the benefits of their private cloud deployment.
Making a service-oriented philosophy work
A service-oriented approach to a private cloud deployment can be defined as falling somewhere between pure Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). In IaaS, a developer or operations manager has to create and manage every image. For PaaS, you don’t control any of these machines; the cloud takes care of it all. In a service-oriented model, you predefine and have running in the cloud a service like a database or load balancer, so developers don’t have to recreate those every time they want to roll out a new application.
The advantage of this approach is that it simplifies the solution deployment task for IT and for the lines of business that are interacting more closely than ever through the deployment of private clouds. A service oriented approach increases reliability because you’re using standardized services and not maintaining multiple different virtual machines. It potentially lowers cost in the long run because developers spend less time setting up virtual machines and more time defining applications to take advantage of the services you’ve already deployed.
There are no real downsides to adopting a service-oriented approach. What you’re trying to do is provide some of the pre-canned capabilities you get with Platform as a Service while still giving your developers full flexibility to define the applications they want to define. For example, IT and the line of business could agree to maintain a standard PostgreSQL database image, but the line of business may have an exception where an application it really needs requires an Oracle machine. The line of business could deploy its own Oracle database server for this specific application. They have all the flexibility in the world, but they’d be responsible for maintaining that image.
Deploying a service-oriented approach doesn’t lock you into anything. It just allows you to predefine certain capabilities which will make it easier in the long run to deploy and maintain new solutions. There might be additional work for the IT staff to define the interfaces, but if you choose, you can turn to a vendor the delivers preconfigured services in the cloud.
If you don’t adopt a service-oriented approach, you’re not taking advantage of measures that could improve the agility and responsiveness of the line of business. You’d be running cloud, but you would not be taking full advantage of the private cloud model.
To turn the model into a reality, you need to start by working with the line of business to analyze what services make sense to standardize across the set of services that will run in the cloud. The analysis should focus on the services that are common across all the various solutions you’re bringing to your user base. You identify the services used the most and are most similar to each other, and those that offer no advantage to being customized. IT then takes responsibility for maintaining the frequently used services and publishing APIs to let people know how to get access to them. It’s similar to what Amazon does around its relational database service. IT defines a set of services that ultimately get instantiated as cloud images, but you also define what APIs developers can take advantage of to get access to those solutions.
When does an organization know it has successfully deployed a service-oriented deployment? The short answer is, you know you’re successful when your development groups use pre-defined services instead of creating their own. This is the Amazon model: customers start off using Amazon EC2 to stand up their own application server and database server but migrate over time to using other Amazon services. If you’re taking full advantage of the cloud, it will be easier to use the newly created model, and your customers will switch as well.
In the future, it’ll be easier to gear services to specific business lines because we’ll see more private cloud providers offering these services prepackaged as part of their cloud solutions. You’ll be able to deploy a set of services in your cloud – with a set of APIs and documentation that allows you to take advantage of that. The aim is to take advantage of all the value that private cloud computing has to offer, and adopting a service-oriented approach is the most direct way to accomplish this goal.
By Peter Chadwick