Middleware Managers: Be Kind to Your Database Admins
When people think of transactional middleware, like IBM MQ or AMQ or Kafka, etc., they think about data being sent from point A to point B or posting to a topic so that others can subscribe to that data. Even if persisted data is really just data in some type of storage, most middleware professionals don’t think of their queues as databases and don’t dwell too much on the world of databases and database management – beyond some initial configurations. But, when it comes to observability and performance optimization for your IBM MQ estate, there’s a few reasons for you to feel like you just might owe your database administrator a little homage.
Databases are mostly thought of as accessible by SQL type structures – tables and joins – which are not sent from point A to point B mainly due to size and complex structures of data. Transactions are generally a block of data, though sometimes they are chained blocks (not block chain!) of data in a sequence that must be read in that exact sequence. Database middleware, conversely, controls the flow of data in and out of the database while permitting developers to perform fast queries and updates. A database Admin or Manager is often tasked with monitoring and managing these database environments, usually through some imbedded database management solution.
Most transactional systems, like IBM MQ, are performance oriented to send, receive, post, get. Most Middleware Admins or Managers utilize 3rd-party middleware management and monitoring solutions to provide observability and maintain the performance optimization needed to meet Service Level Agreements. These 3rd-party solutions usually capture statistics to a database to provide the historic data and real time visualizations needed for that observability.
Ergo the holder of the database is the holder of the information that may be used to debug, or justify, or capacity plan for these transactional systems. So! Middleware people, be nice to your DBA.
How to Be Nice to Your DBA
Depending on the need, statistics that measure metrics of transactions flow from server to server or application to application can be voluminous. Many sites simply need summarization data – i.e. the average of all those metrics for the last 24 hours. Some need it at a more granular level, especially when trying to debug an issue with transactions that may or may not being delivered on time, or to the right topic or queue, or simply vanish. Therefore, companies may capture statistics at wide intervals (24 hrs) or granular intervals (every 3 minutes). Either way it needs to be stored, organized, effectively retrieved, an archived. In this way the keeper of the database instance, tables, row, columns, data types, etc. are the middleware administrator’s best friend.
Middleware Admins or Managers are frequently bombarded with requests for information on the transactions that are happening across their IBM MQ estate and the connected applications or systems. When those requests are related to an unknown state of a transaction (a message that did not end up in its proper final destination, for example) it can mean a lot of work for a Middleware professional. But those who are equipped with the proper 3rd-party middleware management and monitoring solution can ease that burden through:
- a) proactive management of their middleware environment and
- b) enabling secure, smart, self-service IT administration that allows developers and other internal business “customers” to securely identify and resolve issues on their own.
Think about how much work and time that saves you as a Middleware Admin.
Now, think about it from the other perspective: that of your Database Admin. Let’s use this as an example to do so:
In your IBM MQ environment, something that was supposed to get written to a DB by an application reading messages from a Queue, processed, and then put back to the database in its new state, taken by another application which puts a new message an an outbound queue headed to a partner’s app. But, the partn