You are here

Migrating to the cloud? Don't forget your middleware.

public://pictures/jasonbloomberg-tight-300x412.jpg
Jason Bloomberg, President, Intellyx

Cloud computing. Containers. RESTful APIs. To IT pros, these are the sexy parts of enterprise IT. Middleware, however, has never been sexy. But it has always been essential, and as your organization moves to cloud-first IT strategies, your middleware must keep pace, and you have some decisions to make.

Middleware has been around for decades. From the message queuing (MQ) applications of the 1980s to the proprietary enterprise application integration (EAI) technologies of the 1990s, followed by the XML-based enterprise service buses (ESBs) of the 2000s—each one essentially moved messages from one app to another.

And then the cloud came along and changed everything.

By abstracting parts of the corporate network, the cloud changed the middleware game. Enterprises increasingly came to depend upon cloud-based SaaS apps, and wanted to integrate them with on-premises apps. Traditional middleware was simply not up to this task.

However, the cloud played an even more disruptive role, as integration-platform-as-a-service (iPaaS) offerings hit the market. These cloud-based services delivered most, if not all, of the functionality that middleware had been providing.

Today, IT leadership faces a choice: Do you keep that old middleware in place or migrate to a cloud-based integration approach? As with most modernization vs. migration choices, the decision is far from black or white. Here are a few considerations to take into account, and some risks to consider. 

[ Enterprise Service Management brings innovation to the enterprise. Learn more in TechBeacon's new ESM guide. Plus: Get the 2019 Forrester Wave for ESM. ]

Take a cloud-first approach to middleware

As organizations increasingly rely on the cloud and challenges with legacy technologies (including middleware) continue to mount, IT leaders need to know where to start. For many organizations, the answer is to take a cloud-first approach.

Cloud-first doesn’t mean cloud-only. Rather, a cloud-first strategy considers cloud-based options for addressing any IT issue, and only when no such option meets the needs of the business should you look to non-cloud solutions.

Your first thought regarding middleware migrations should be to review your cloud-based options. 

Integration platform as a service

One such option, iPaaS, is essentially a cloud delivery model for integration. It provides connectivity to back-end systems of record, cloud-based applications, and systems of engagement, both on-premises and in the cloud.

iPaaS provides an abstraction layer between endpoints, thus offering a measure of loose coupling that allows for flexibility across environments. Most iPaaS offerings also provide basic queuing capabilities, guaranteeing delivery of messages once and only once.

iPaaS isn't the entire cloud-first middleware story, however. Many service providers take related but different approaches, including business process management platform as a service (bpmPaaS), mobile back end as a service (MBaaS), and various B2B cloud-based integration services.

Keep in mind that advanced middleware functionality such as data transformations, monitoring, and administration, and various capabilities such as on-the-fly encryption are product features that typically go beyond what iPaaS vendors offer.

Middleware as a service

This broader set of options now goes under the umbrella term middleware as a service (MWaaS), bringing enterprise-class middleware capabilities to cloud-first IT strategies.

MWaaS consists of a suite of cloud-based integration services that are particularly well-suited to hybrid IT scenarios, rolling up iPaaS, API management, B2B integration, mobile back-end integration, and even Internet of Things (IoT) integration. Some MWaaS offerings may be more business process management-centric, focusing on process integration and orchestration use cases.

The cloud-first middleware story doesn’t stop there. As enterprises implement containers, both on-premises and in the cloud, the integration story becomes even more complex, and with it the challenges of middleware.

Middleware, whether it be a cloud-based service, software running in the cloud, or on-premises software, must rise to the challenge of containers and microservices. The days of preconfigured middleware are long gone. In the modern enterprise environment, configurations are as dynamic as is the software the middleware connects to.

[ Also see: Scaling containers: The essential guide to container clusters ]

Tackling the migration

Once your organization has made the decision to migrate middleware to the cloud, it's important to handle your migration initiative appropriately. "Big bang" migrations are rarely successful, and in some cases lead to catastrophe.

The first step, therefore, is to understand the risks and plan accordingly. Integrations can break, applications may cease to function, or the migration initiative can introduce delays or performance bottlenecks. Be sure your team understands and addresses all such eventualities.

Next, it's essential to place the middleware migration into the broader migration/modernization effort, which may be part of an overall digital transformation initiative. By its very nature, middleware doesn't stand alone—and thus, switching from one type of middleware to another rarely occurs in a vacuum.

This broader context for the migration initiative should emphasize an important point: Modernization efforts are rarely simply about migrating from old to new. They typically include leaving some assets in place essentially untouched, while updating (but not replacing) others.

The same is true for your middleware. A middleware migration project may still leave some older, on-premises middleware in place. The fundamental principle here is "if it ain't broke, don’t fix it."

[ Also see: Infrastructure services made easy: 4 essentials for transparent IT Ops ]

Address middleware-related performance issues

As the migration effort progresses, the team must have sufficient visibility into the overall operational environment. Remember that middleware migration essentially changes the production environment. Rarely does an organization have the luxury of a test environment sufficiently similar to production to run a middleware change through its paces.

Therefore, the ops team must work hand-in-hand with the migration team to watch the performance, not just of the middleware, but of every system the middleware touches, and such management must take place across each iteration.

Make no mistake: There will be problems and, except in rare situations, those problems will adversely impact customers. Reducing the risk of such adverse events should be a top priority. In many cases, the root cause of such issues is the complexity of middleware configurations in place.

Simply migrating from an older to a newer version of a particular middleware product may be problematic due to such configuration differences. When the migration is to the cloud, configuration differences can make the difference between success and failure of the migration.

[ Learn how to transform your IT with AIOps in TechBeacon's guide. Plus: Download the analyst paper on how AI is changing the role of IT. ]

Middleware and digital transformation

Digital transformation requires end-to-end IT transformation, as enterprises move from a closed, on-premises mentality to a web-enabled context, and then to cloud-first. The final step is hybrid IT, where you abstract infrastructure choices to provide the flexibility necessary for applications to empower the digital needs of your organization.

None of these transitions can take place without middleware. Middleware has always been the glue that holds enterprise IT together. In the early days, tightly coupled, fixed integrations met the needs of the business. Today, you need loosely coupled, cloud-native integrations that let you abstract away the underlying infrastructure, whether on-premises or in the cloud.

Today, enterprises are more likely to use an open-source, scalable package such as Apache Kafka or Apache Spark rather than a proprietary integration product from an incumbent vendor. And leveraging the cloud to abstract the middleware is even more common.

In the final analysis, cloud-based options such as MWaaS may not look like the middleware of old, and eventually we may move beyond the terminology altogether. But IT will always need integration technology. It may never be sexy, but it has always been, and will continue to be, mission-critical for enterprises in the digital era.

[ Learn how robotic process automation (RPA) can pay off—if you first tackle underlying problems. See TechBeacon's guide. Plus: Get the white paper on enterprise requirements. ]