Tag Archives: middleware

Nov 2 2012

The future of managed cloud services

At the very beginning, there were unmanaged virtual machines as a service. These services were mainly used for development and test purposes or to host horizontal, born on the web workloads. For more traditional production workloads another type of cloud service is required. This new service needs to be more fault tolerant to provide the required availability for so called cloud enabled workloads, but also provide a certain management capability to ensure a stable operation. Managed infrastructure as a service (IaaS) solutions such as IBM’s SmartCloud Enterprise+ provide these service levels and capabilities.

But is this the future of managed cloud services?

I don’t think so, although this model fits for some workloads, it is just the start of the journey.

The ultimate goal of managed cloud services is to receive higher value services out of the cloud. In my opinion, the future of managed cloud services are platform as a service (PaaS) offerings.

Todays managed IaaS offerings cause some challenges, both for the service provider as well as for the service receiver. One reason for that is the higher complexity due to the shared responsibility of an IaaS managed virtual machine (VM). In this scenario the service provider manages the VM up to the operating system level, but the client is responsible for the middleware and application on top. In such a setup it is extremely hard to make a clear separation of the operating system (OS) from its higher services. Many applications require OS settings to be set or access to operating system resources.

A managed PaaS overcomes these challenges by providing a consistent software stack out of one hand. All components are designed for the purpose of this platform. If the PaaS service is a database, OS settings, IO subsystem and storage are designed and configured to provide a robust service with decent performance. The client can rely on the service providers expertise and does not need to support a database – or any other middleware – on an operating system platform he has no real insight on its configuration and not full control over its settings.

In one of my previous blog posts on how Middleware topology changes because of cloud, I discussed the change in middleware and database architecture. This is exactly where PaaS comes into play. By moving away from the consolidated database and middleware clusters, clients require agile, elastic and managed databases and middleware as a service to be able to handle the higher number of instances.

Summary

Due to the complexity and limitations, managed IaaS will become a niche offering for accommodating non standard software. For middle-ware and database with a certain market share, managed PaaS offerings will become commodity.

Oct 19 2012

Middleware topology changes because of cloud

Once upon a time, applications ran on physical servers. These physical server infrastructures were sized to accommodate the application software as well as required middleware and database components. The sizing was mainly based on peak load expectations because only limited hardware upgrading was possible. This led to a very simple application landscape topology. Every application had its set of physical server systems. If an application had to be replaced or upgraded, only those server systems were affected.

When the number of applications grew, the number of server systems reached highs which were hard to manage and maintain. Consolidation was the trend of that time. Together with virtualization technologies which gained maturity, capacity upgrades were as easy as moving a slider bar. After the consolidation of the physical layer in the late 90s and early 2000s, the middleware and database layer was consolidated. Starting around 2005 we saw database hotels and consolidated middleware stacks to provide a standardized layer of capabilities to the applications.

Although this setup helped streamlining middleware and database management, and standardizing the software landscape, it introduced a number of problems:

The whole environment became more complex. Whenever a middleware stack was changed (due to a patch or even a version upgrade), multiple applications were affected and required to be retested. Maintenance windows needed to be coordinated with all application owners, and unplanned downtimes had a high impact on a higher number of applications.

Modern cloud computing is reversing this trend again. Because provisioning and management of standard middleware and database services can be highly automated, deploying and managing a higher number of smaller server images is less effort than it was in the early days. By de-consolidating these middleware and database blocks, we gain again higher flexibility and a far less complex environment.

There is another positive side effect of this approach: When application workloads are bundled together, they can more easily being moved to a fit for purpose infrastructure. Especially when we think about a migration of some workloads into the cloud, while others will stay on a more traditional IT infrastructure, the new model helps moving these isolated workloads, without affecting others.

Summary

I am not saying that deconsolidation of database and middleware blocks is the holy grail of middleware topology architecture, but in a cloud environment it can help to get rid of complex integration problems while not introducing new ones.