Lessons from the DevOps shop floor

DevOps – Recently I’ve been investigating just how much time and effort companies put into building, configuring, using and maintaining their messaging middleware environments. And here’s what I’ve discovered.

1.  Everyone is using multiple messaging middleware systems.

I have talked to at least 20 large enterprises recently. And it’s clear that everyone has at a minimum 3 different releases of IBM MQ, and tactical installations of Active MQ, RabbitMQ and Kafka somewhere in their environments. Each time a new application is developed it uses the latest version of messaging middleware, but older applications are not upgraded, because it is never a simple task, so old releases stick around. I know I’m being a little emotional here, but check out your own application stack, I’m sure you will be surprised just how many different variants you have in production.

2.  Once installed and configured, people will do whatever they can to never have to touch their messaging middleware systems ever again.

Working out how to connect a large number of components together isn’t actually that hard (in the scheme of IT tasks), but once it’s done and running, making changes can be quite risky. And over time the people that make the initial installation have moved on, and their documentation wasn’t that easy to understand, because it was written for them, not for new people, so it isn’t totally complete. It’s just easier to let sleeping dogs lie. It’s only when old releases become issues such as when an end of life notice is issued or a zero-day security notice is broadcast, are any changes considered. And then it can be a multi-month regression testing nightmare process before it can be deployed. And the best you can hope for is just not breaking anything.

3.  While everyone thinks their moving to the cloud, it is always harder than you expect.

Migrating business applications has been a consistent headache for IT. Since the mid 90’s everyone has been planning to get off their mainframes, and now were all planning to get off our datacenters and into the cloud. It makes financial and business sense, but it’s always a lot more complex than planned. And as time and expenses increase, many projects never get to the point of switching off the old platform, instead choosing to run legacy apps on the old platform and new apps on the new platform. The old platforms end up being a drag on the business, and it’s only when the impact is so great that it’s consuming a vast amount of available staffing and money does the truly massive cost of the change effort become viable.

The Solution

And this is where Nastel comes in. Nastel Navigator takes the complexity, cost and time out of managing complex heterogeneous messaging middleware environments. It’s literally the only platform that provides a single pane of glass approach to enterprise level messaging middleware. With administrator controlled secure (and private) user level access across all queues and streams, Nastel Navigator allows previously impossible tasks such as cloud migration to be delivered in seconds using concepts we’re all used to in our daily IT lives in other areas namly, such ideas as Cut, Paste, Copy, Move, Search, undo, and schedule.

Sounds simple I know, but these core functions just don’t exist within the architecture of most messaging middleware systems, which causes tasks you would think should be simple, to take months of work to deliver. Nastel Navigator fixes this (and much more), allowing many thousands of FTE hours of effort to be avoided. This can change everything.

Check it out for yourself.