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 partner says the data never got there. Your awesome 3rd-party middleware management and monitoring solution would have alerted you to a problem if the data never left the Queue Manager, so now you need to know if it’s the app or the database. The application owner can confirm if the process happened but you need to confirm with the DB Admin if the data ever appeared there in either state. This means bothering your DB Admin to investigate the situation and get back to you.
Instead, be nice to your DBA. Just like Infrared360 enables the secure, smart, self-service IT administration for the IBM MQ Admin’s internal business “customers” to securely identify and resolve transactional issues on their own, it can also enable the Middleware Admin to resolve database issues on his/her own without having to bother the DBA. In the case above, for example, you’d be able to monitor any number of tables in any relational database and set alerts on thresholds, conditions on count or values in a DBA row/column(s) in order to identify whether the problem existed in the Database.
Another Way to Be Nice to Your DBA
Infrared360®, the product I manage, uses databases to store configuration data; connection factories, groups, roles, users, alerts, services, etc. But it also uses historical data repositories to retrieve historical data for charts and/or reports. This data can be voluminous and can be quite detailed. Having it available when needed, however, is essential. As we discussed before, the statistics might show transactional anomalies, they might show capacity of servers to handle the transaction load, they might show straight line data that can validate service level agreements the site may have with its internal or external customers.
In the case of Infrared360, there are a slew of powerful visualizations, reports, and charts built right in so you can get historical data. There is also True Real-Time monitoring so you can get visualizations of what is happening at the moment. This gives the IBM MQ Admin or manager (and anyone he/she wants to provide insights to) full observability of the Middleware environment. But, in some enterprises, higher IT management wants to have that data embedded in broader IT status dash boards like SNOW or embeddable analytics and visualization tools like Grafana. This would normally put more work on the DBA, at least from an oversight perspective. But, once again Infrared360 lets you be nice to your DBA. Infrared360’s built-in SOA service interface makes it super-easy to pull any metrics you need form your IBM MQ estate, databases, or other middleware like Kafka, WAS, and more. So, you just saved your DBA a ton of aggravation.
In any case, the DBA is your friend not only when creating the structures to store vital data about your middleware environment, but in managing the timeline of its existence and backup & recovery in case of outages. For a more detailed explanation of the types of statistical data transactional systems can capture and report, please feel free to contact me @AvadaSoftware.
