In the last post, we talked about how the ultimate nirvana is for the business to do self-service provisioning of services from a service catalog. This is somewhat easy to think about when we consider compute, storage and network services – the virtual bare metal gets provisioned within a short period of time and is made available for the user. The SLAs are typically around uptime, recovery point objective (RPO) during failure, recovery time objective (RTO) after failure, etc. This concept becomes more interesting when we talk about PaaS.
The Platform in PaaS refers to a set of capabilities that start with a base of (mostly) software components sitting above the virtual bare metal – examples we have talked about include basic capabilities such as a database, web server and application server but also extend into larger value-added capabilities such as application frameworks (Spring, .Net, force.com), content management, integration, security and information lifecycle management.
Now, once the slice of the platform is provisioned, who can configure or program to the platform ?
In the former basic case, the business user could provision much like the IaaS model – e.g. pick a database service from the catalog and have it up and running within a short period of time. The user can do the usual steps to set up a schema, populate the tables, and go to town with it. More and more users today, including non-technical ones, have the ability to do this these days – for instance, using visual tools and visual query languages – but the more complex stuff is usually left to the programmers.
This gets more acute when you consider the value-added capabilities. You typically need people with the ability to program to work with application frameworks or integration or even content management. Yes, the industry talks about the business user being able to visually program everything – experience indicates that the business user can do this for ‘happy path’ scenarios but the error conditions and the ability to handle them are what requires the programmer-like abilities.
But can real programmers not be in the business ?
Yes, they can and they will be (in the case of EMC, there ARE real programmers in the business!). This makes the case for a PaaS model actually. Several of our business users can develop applications on their own outside of IT, but this model falls down when their applications run afoul of audit/security/risk considerations. Often the applications they write are not supported within the IT data center environment and may not have basic authentication/backup/etc. What PaaS offers to them (within governance constraints) is the ability to program within a controlled environment, yet have the agility they desire.
But really, don’t they have better things to do than write IT apps ?
The answer is absolutely yes – they DO have better things to do. For different reasons of timing or prioritization or …, they go ahead and develop these apps that ‘run under their desks’. From our analysis, we believe that a majority of the apps that the business has built out are reporting apps of various kinds. They take data from the corporate warehouse and do slice-dice operations on the data for their needs. This can be mitigated through a PaaS/SaaS offering – our plans to offer BI-as-a-service squarely fits into that model. In addition, our plans are to provide other programmable elements of the stack through Spring and .Net on our private cloud infrastructure along with force.com, so other apps can be built in an agile, yet controlled manner as well.
Let us talk to what the PaaS services are starting to look like. The service is now more than the run-time aspects more common to IaaS. A service bureau may be needed here that can help configure and program what got provisioned from a nuts and bolts perspective. So, for instance, in the case of a database the service can include (a) getting a slice from an already consolidated grid environment like we have in EMC (b) the general support involving management and administration, monitoring, health & welfare and incident management (c) the capability to create and modify schemas (d) the capability to write transactions against that database, (e) the capability to add reports to that database – could be simple reports involving a single database, complex reports involving multiple databases, or higher level features such as OLAP or data mining, and so on. Capabilities (a) and (b) involve more infrastructure-style SLAs but (c), (d) and (e) require expanded sets of service levels – how long does it take to configure or program, what is the testing cycle, etc.
All the capabilities above are what we have traditionally provided as an IT organization when delivering solutions to the business, but what is different now is the disaggregation of these capabilities and the ability to deliver them separately and in bundles. Of course, the important thing is not to get too granular about this – we will end up slowing things down, we will all become bean counters and overall services will suffer.
As we in EMC IT look to provide the PaaS services to the business users, we are focusing on a few elements.
- The technology : We have made good progress in standardizing and consolidating environments (including database, web server, application server, content management) but we need to automate, on a cookie-cutter basis, the provisioning of different parts of the PaaS stack and how they get integrated into the overall model of monitoring and management.
- The service management approach and process : We are evolving our service management discipline to support programmable solutions and how they are offered and priced overall. Furthermore, the model has to be flexible enough to allow our own IT department to program to it, or if the business so chooses enable someone else to program to our offerings and deploy on top of the platform (governance bells start to ring here).
- The overall governance, demand management and metrics : Even with or without PaaS, IT has an important role in guaranteeing that the service levels desired by each business unit as well as the overall enterprise are met. PaaS makes it more complex due to the ability of different entities to program and use the platform. The rigor needed to provide the guarantees cannot be relaxed in favor of agility. It is an AND proposition here – the dual needs for agility and rigor will both have to be met. This requires a more detailed governance model than we have been used to, where IT was typically only one entity both providing and programming to the platform (by using its own ‘sub-contractors’ as necessary but still in control). Needless to say, the service levels will also have to include detailed metrics to go hand in hand.
More of the PaaS journey in the next couple of posts. Cheers.
