Why Middleware Teams Need an Event Portal; Supporting Applications that Disseminate Real-Time Data

Since my background is as a service owner for middleware products, I am very excited at the value our new PubSub+ Event Portal product offers middleware and integration teams in large enterprises. And I’m happy to report that those kinds of folks share my excitement – one of them even exclaimed: “this fills a huge hole that we didn’t know we had!”

So why am I, and why are they, so excited?

These people and their teams are responsible for the support and engineering of an important piece of application infrastructure, serving multiple application owners across different business lines. It’s mission-critical stuff that affects not just applications and user interfaces, but customer experience, decision making ability, and the company’s bottom line!

The service owner responsibility all starts off well. You start with a handful of well understood applications serving as the anchor tenants to your new service offering. You know where the real-time flows originate, their purpose, who consumes them, and the business context it takes to triage and troubleshoot any operational issues.

They say no good deed goes unpunished, so you become a victim of your own success. The service grows, and sparks a demand wave of applications wanting to onboard to it, which brings about the following challenges:

1. How do you understand the real-time flows that make up an application before onboarding them?
2. How do you do so across development teams in a way that’s consistent, efficient and scales?
3. How do you make sure whatever has been captured stays current and does not go stale?

Even with the best of intentions, as the service grows it gets increasingly difficult to provide all teams an excellent onboarding experience where you capture all the necessary information to effectively support them.

How an Event Portal Helps Middleware Teams

Event portals meet the needs of many stakeholders. An event portal is a game changer in that it becomes a common tool to bring together the different stakeholders for a given application. For application and data architects it is the place to design your real-time flows, discover what already exists, and model new components that make up the overall application. For developers it is the place to collaborate with architects, further the design and eventually generate the boilerplate code that is required to build application components. For middleware teams it is the place where they can see the big picture of all the flows that make up an application, the components that are involved, and the necessary context around any operational alerts.

Here are some of the questions an event portal can answer:

• Which publishing components would be impacted if a certain queue fills up?
• Which downstream systems need to be notified if a publisher has disconnected?
• How many consumers are expected for this particular topic?

Without an event portal, one of the main difficulties in documenting such information is that it may exist in different formats such as wikis and spreadsheets, depending on the application team involved. So not only is the tooling not consistent, the quality of information about the application varies as well.

Instead of introducing “yet another tool” just to enable information sharing between development teams and middleware teams, an event portal helps each stakeholder perform for their own core function, avoiding the need to deploy a tool focused on just the needs of middleware teams.

It’s important to keep the information you capture about an application during the onboarding process up to date, and an event portal is just what the doctor ordered because they give you an always evolving real-time view of all your application flows.

Discovery and Auditing Event Flows

It is at this point that I’m sure you are thinking “how does this help me with existing service users?”. While it would be easy to apply a new onboarding process in a ‘greenfield’ scenario, a new approach also needs to bring your existing applications along for the ride.

This is where our PubSub+ Event Portal’s “Discovery” capability comes in to play. You point it at your event brokers and it automatically discovers all of the current real-time data flows and populates the event flow design. Development teams can, of course, refine it by confirming or correcting assumptions made about the flows.

PubSub+ Event Portal can also audit your environment to make sure real-world runtime behaviour doesn’t deviate from the intended design by highlighting differences so you can either update the design for new changes or remediate unexpected runtime behaviour.

PubSub+ Event Portal for Technology Agnostic Tooling

For all the reasons that I am excited about our PubSub+ Event Portal product, I’ve saved the best for last. Acknowledging that it is also common to have middleware teams be responsible for many different products as part of their portfolio, PubSub+ Event Portal is a broker agnostic tool that supports multiple technologies as part of the runtime discovery and audit functions. The first broker technology that PubSub+ Event Portal will support for Discovery and Audit capabilities is Apache Kafka. This will be closely followed by Solace PubSub+ brokers, and then others as determined by customer demand. And to avoid becoming a bottleneck on support for more broker technologies, the framework for such support will be open source so anyone in the community can build the capability for the brokers they are interested in.

Conclusion

I hope by now you too are sharing in my excitement for what PubSub+ Event Portal brings to middleware teams, and can see how it fills a huge gap in providing effective support and engineering capabilities at enterprise scale.

Check out this video for a quick walk-through of PubSub+ Event Portal and sign up for a free trial by creating an account.