The Cloud as a Tectonic Shift in IT: The Death of Middleware

Written by: Heidi Gilmore

This is the fourth in a series of blogs about  The Cloud as a Tectonic Shift in IT, authored by Sacha Labourey , CEO, CloudBees.  In the series, Sacha examines the huge disruption happening across the IT industry today, looks at the effect the cloud is having on traditional IT concepts and reviews the new IT service and consumption models that have emerged as a result of the cloud. Finally, he makes some predictions about where this tectonic shift will lead us in the future.

The move to the cloud represents one of the largest paradigm shifts to ever affect IT. More than just a simple technology evolution, the cloud fundamentally changes many of the cornerstones on which IT evolved. From redefining the concepts of operating systems and middleware, to revolutionizing the way IT services are built and consumed, the cloud is ushering in an era of change unlike any we have ever seen.

The Death of Middleware

As the move to the cloud accelerates, companies will slowly stop caring about the underlying infrastructure and OS. But they will care about the type of services and SLA that will be delivered to them – just not how those services will be implemented. But is the OS the upper-most layer that will be impacted in this death-by-abstraction?

When Salesforce.com started their “no software” campaign, the idea was to make people pause and think. Obviously software was not dead: Salesforce has thousands of engineers producing software on a daily basis. But, does it matter? After all, the company’s value lies in the service it delivers, not the software it creates.

Think about it another way: When you are booking a trip through a travel agent, do you care whether their back-end system is running on Windows or Linux? Whether they are using pencils or pens to do their work? No, you care about the value you are getting from the agent. The same concept applies to Salesforce.com. Since moving to a service approach has relegated software to an “implementation detail,” what impact will PaaS have on traditional middleware?

What is Middleware Today?

Historically, a successful middleware implementation had to win the heart of two very different audiences, each with very unique conditions to satisfy.

On one hand, middleware has to please the developers that would be interacting with it on a daily basis. Developers want technology that will make their application cooler and faster. They care about ease of use, productivity and being able to prototype things fast. They have a mission – implementing a solution – and middleware has to aid in that quest, hiding all possible lower-level complexity and providing shortcuts for their most frequent tasks.

On the other hand, middleware also has to please IT operations teams. These individuals demand that software is rock solid, scalable, resilient and easy to monitor, manage and patch. IT operations teams know that the value of an application is lost if it goes down at 2 a.m. They are being paid to ensure the company is able to operate at all times, under any circumstances, and have a backup plan in case things go wrong. IT processes are designed to cover all possible cases, with no surprises, not just 80% of what could happen. In this way, IT operations has a lot to do with resilience and inertia.

Yet, in real IT life, a lot of activities require these two teams to work together. Do you need to create a new application? Provision a new application server? Perform load testing? Get a new database instance? Cluster your application? IT life in any company is a constant, high-friction interaction between development and IT operations teams. Nothing is ever quite as easy as it should be and even the most basic request can lead to time- and energy-consuming processes.

Producing new applications and new services results in friction between these two teams because each has totally different DNA, with the only common ground being their love for technology and their desire to see their company be successful. And middleware, as its name implies, naively sits in the middle.

Middleware in the Cloud Era

How does this change when it comes to the cloud? Let’s first start by looking at the IT-operations side of the house. As we’ve seen previously, PaaS is all about providing a service that will allow developers to create and run applications without having to directly care about the infrastructural and operational aspects.

IT has a completely different role in this setup. IT will not be involved in building the infrastructure required to operate the application and they are not going to be monitoring, maintaining and patching the stack. Plus, they will not need to worry about delivering top-notch Java clustering, or setting up firewalls, databases and load-balancers, to name a few. The PaaS vendor will. As such, PaaS becomes the new engine developers will use to get their environments setup. It will be responsible for provisioning, managing, monitoring, patching and evolving that environment.

And don’t forget the “S” in “PaaS.” PaaS is more than just a set of well-orchestrated software processes. PaaS providers will act as the new support organization developers approach when things don’t happen as expected. And even though 99% of support requests have to do with a bug in the application, most developers still need guidance from the platform-support organization to understand the problem.

The bottom line is that from an IT operations standpoint, PaaS acts as a major friction-killer. Infrastructural and operational aspects are now owned by the PaaS provider and are delivered to the developer as higher-level concepts – such as “create an application” or “scale an application horizontally” vs. “give me an application server” – on a set of standardized notions. Obviously, this helps to significantly reduce friction. Consequently, from an IT operations standpoint, middleware becomes pretty-much non-existent – simply because they do not have to worry about it anymore!

When people hear this, they quickly interpret this as the death of IT. But that’s not quite right. The growth of the cloud actually means new challenges are ahead: IT will certainly want to be involved in choosing a PaaS provider, reviewing the SLA and determining on which IaaS solution it can operate. And as they define what solution should be used across their PaaS and SaaS vendors, IT will want to maintain the map of what company data is made available to what application and audience, and what new security guidelines should be added as a result of moving to the cloud. IT will very much remain in charge of protecting the crown jewels of the company – they will now be delegating most infrastructural and operational aspects to specialized cloud providers.

PaaS also radically changes the picture from a development standpoint. Typically, middleware solutions focused on a specific runtime behavior, such as running an application within an application server, running processes or working with rule engines. Some of these providers go as far as delivering a set of tools – or plug-ins – that make the development of solutions for that runtime easier.

This is all well and good from a vendor’s perspective, but is this truly satisfying from a developer’s standpoint? Developers are using a myriad of runtimes that have to properly integrate with each other. And software has to be developed, tested and validated. Middleware vendors typically never help with those steps. So development teams have to resort to specialized tool vendors for solutions as diverse as continuous integration, static code analysis, code repositories, bug trackers and binary artifact repositories.

To do their jobs properly, development teams typically need to have a relationship with at least a dozen vendors to get the point solutions that are unified to provide the complete workbench they need to achieve their goals. However, throwing together dozens of tools from different vendors still doesn’t build a usable workbench. Those tools have to be integrated as a proper whole, versions need to be compatible, custom code has to be written to facilitate integration when it is not provided out of the box and a common identity solution needs to be applied across the board.

To further complicate matters, as each individual tool evolves, patches and new versions for each must be applied without breaking the chain. Doing this properly requires time and diligence: Any service interruption can severely impact the development team’s productivity. But who is responsible for building and maintaining that complete development-to-production environment? Some of the most sophisticated IT shops have dedicated teams responsible for that job. But the average – and even above-average – IT team doesn’t get anywhere close to that level of sophistication and organization. In most companies, the IT operations team will even refuse to touch that side of the process. Development tools must be handled by developers; IT operations provides only the raw hardware and focuses instead on production-related issues.

The bottom line is that development teams will spend a significant portion of their time and resources building, maintaining and extending their environment, all of which comes at the expense of building software and creating value for the company.

But when using PaaS, the situation is very different. Obviously, middleware is still very much present. Developers still need to handle transactions, security, persistence and asynchronous communication. Thankfully, PaaS solutions offer all of this and so much more.

First, a PaaS vendor will offer a complete, ready-to-use environment to code, build and test your software. Need to create a new project? No problem: In one click you end up with a complete, pre-integrated, fully managed development toolset. All you need to do is add the co-workers of your choice to the project and you are ready to go and collaborate. This way, you can store code and binary artifacts and perform builds and tests in a continuous fashion, without ever having to care about servers, storage or backup – or talking to IT operations. You’ll have more time to focus on your job.

Should you need additional tools, just go on the vendor’s marketplace, enable that other SaaS and you’ll instantaneously get access to a new resource that is properly integrated with the rest of your development toolset. There is no need for your team to spend any time on non-productive activities or ask IT operations for access to the resources you need.

Consequently, while it is very tempting to initially pitch PaaS as the “middleware of the cloud,” this thought process is akin to reducing a jet to an engine and a couple of wings. While the features provided by middleware are still part of the features exposed by PaaS, these solutions will provide much broader functional and lifecycle coverage, handle all infrastructural and operational aspects and integrate and deliver these best-of-breed capabilities as a unified, fully managed service. Furthermore, PaaS vendors also act as the support organization for any issues you might encounter during software development, helping you avoid the need to decide where to route your requests. Just ask your PaaS provider – it covers all of that.

The bottom line is that for a developer using a PaaS, the notion of “middleware” is pretty much as visible and interesting as the more technologically intensive aspects of your platform.

While this might seem like a semantic change at first, it is actually a fundamental shift in how developers work and where they are spending their time. And as with any paradigm shift, you must experience it in order to fully understand the implications.

As IT moves to a service-oriented world, much of the friction we have been accustomed to in our daily activities will disappear. We are entering a new world of efficiency – one that eliminates the need to worry about middleware and intensifies the focus on creating value.

To learn more :


Onward,

Sacha Labourey
CEO
CloudBees
cloudbees.com
 


The Cloud as a Tectonic Shift in IT:


 

 

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.