Database as a service …

Let us jump in feet first into ‘database as a service’. So what do we mean by this ? We have three database platforms that we can provide ‘slices’ of to our business users. Oracle and SQL Server have been the traditional platforms we have built upon and Greenplum is something we have adopted quickly and which lends itself to ‘database as  a service’ very well.

How have we done this ? Tier, Consolidate, Virtualize

Of course, this has been a journey on its own merit. We started off by looking at the database tiering models required based on business criticality, required availability and I/O profiles. At EMC, we separate the mission criticalapplications and databases (as in revenue impacting and/or customer facing, typically with stringent RTO/RPO and data loss constraints) from the business critical applications and databases (impacting subprocesses vs enterprise processes).

To gain efficiencies of scale, we decided to consolidate mission-critical Oracle and business critical into 3 and 8 node Oracle grid architecture (and along the way reduced the number of Oracle versions from 9 down to 1). We also consolidated and virtualized a number of production and non-production databases for the business critical side. This consolidation and virtualization exercise resulted in the reduction of databases and database servers from 50+ to single digits. This has provided the basic technology foundation for implementing database as a service on the Oracle platform. The current environment provides us a mechanism by which a large environment can be sliced to service different needs at different points of time, with standardized and published service levels and predictable scalability and performance.

Continue reading

Platform-as-a-service – a shallow dive

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 ? Continue reading