Over the past decade, enterprises have invested lots of blood, sweat and tears into building software development lifecycle (SDLC) processes that meet their unique requirements. Tools like GitHub, Jenkins and Ansible are now crucial for moving services from concept to production, while tools like IntelliJ and Postman make developers more productive.
Unfortunately, event-driven architecture (EDA) tends to bedevil these tools and the processes that IT teams build around them. The decoupling of services makes for better error handling, stability and efficiency, but no application (or microservice, or SaaS) is an island. With widely shared events and common infrastructure like event brokers, it’s become harder to anticipate, manage and prevent conflicts during the SDLC.
Enter PubSub+ Event Portal – a powerful tool that helps application teams design and manage event-driven systems. Event Portal enables you to:
What does that mean for your SDLC? Event Portal’s API-first design and robust capabilities let IT organizations use it in a variety of ways. Some users want Event Portal to handle everything event-driven, from application design to environment promotion to infrastructure configuration. But many want Event Portal to play nice with their existing SDLC tools and add a crucial EDA perspective and governance.
To facilitate the integration of SDLC tools and Event Portal, Solace has developed several plugins that aim to:
The plugins are independent, so you can pick the ones that make sense, and they’re open source so you can modify them to meet your unique needs.
There are dozens of popular SDLC tools, and hundreds in total, so we talked with tons of developers and architects inside our walls and in our customer base, and decided to start with these:
The next two in the queue – already in development – are Confluence and Logstash.
So how do all these plugins work…and work together? Here’s a diagram that summarizes the big picture, and I’ll explain them one at a time and show them in action with a brief video.
There are many ways of getting information about your event-driven system into Event Portal. At one end of the spectrum, you can use two methods that Event Portal provides: Designer is a GUI you can use to define events, schemas and applications – describe them, annotate them, enforce governance, and foster best practices and consistency in the design before they’re deployed. Runtime Event Manager can discover and audit events from brokers like Kafka and Solace and show you what’s there–versus what you thought was there. Either way, all this data becomes part of a searchable catalog of all your event streams across environments so consumer apps can find and reuse them in a self-service manner.
But increasingly, companies are using AsyncAPI to standardize their event-based APIs. As you might guess, AsyncAPI lets you define asynchronous interfaces, effectively serving as an OpenAPI for the event-based world. It’s a relatively new standard but surging in popularity and acceptance.
AsyncAPIs can originate from many places. You can create them in development tooling, or use products like ASAPIO to automatically generate them. Either way, our AsyncAPI Importer can get them into Event Portal where other developers can find and reuse them.
The AsyncAPI Importer is a command line tool that can be used on its own, but it can also be used by other applications. For example, GitHub actions for Event Portal (which I’ll discuss in the video below) uses the AsyncAPI Importer under the covers.
See Event Portal with AsyncAPI Importer it in action!
Once Event Portal stitches together information about your existing system, you’ve got an initial view, but let’s say the business needs a new application. Event Portal eases the way from concept to staging to prod to retirement with help from your existing SDLC.
Let’s step through the process:
As you plan out a new application, there are two ways you can use Slack to display the latest information in Event Portal in one of two ways:
See Event Portal with Slack in action!
Check out the Solace-Slack source code!
After design approval, it’s time to start coding. At this point, instead of starting from scratch, developers can fire up IntelliJ, find the latest application details in Event Portal, and generate an event-driven application.
If you’re not clear about what applications, events and data schemas are available, the plugin can get more details about them all without leaving IntelliJ. For example, if you’re interested in more details about a data format, check out the schema file. If you’re interested in how an entire application is defined, you can view the AsyncAPI specification.
Frequently teams fall back on REST not because it’s the best way of doing things, but because it’s easy and familiar. To overcome that common bad habit, the plugin can create a Spring application based on AsyncAPI, including connectivity information to brokers like Kafka and Solace. So instead of wasting time building boilerplate code, developers can focus on business logic.
See Event Portal with IntelliJ in action!
Check out the Solace-IntelliJ source code!
Once the coding is done, the CICD portion of the flow begins.
The remarkable thing about defining interfaces in AsyncAPI is that developers can modify them without leaving their coding tools. But because of shared resources like events, you want governance guardrails to prevent chaos. So when developers change events and applications and open a pull request to merge them into GitHub, Event Portal takes charge of the global governance:
The plugin also alerts reviewers to potential issues. If the initial checks pass, and a code reviewer approves, then Event Portal synchronizes the applications, events and schemas in its catalog.
See Event Portal with GitHub in action!
Check out the Solace-Github source code!
Next in the pipeline is Jenkins, which migrates the services through environments. As I said in the introduction, the decoupling associated with EDA makes it challenging to make sure an application doesn’t blow up as it migrates. Will the well-behaved application suddenly consume millions of events in production? Or none at all? Event Portal can prevent scenarios like that by giving you a graphical view of which applications will consume which event streams.
To do this, after a whole pipeline completes, Jenkins informs Event Portal that an application is now in a new environment. Within Event Portal you can see your application, and see what other applications will feed it information, along with warnings about possible issues.
See Event Portal with Jenkins in action!
Check out the Solace-Jenkins source code!
Your event driven applications need to have things like queues, topics and subscriptions to work. It would obviously be better if you generated those things automatically. Even better still if the auto generation used an open standard. The Ansible plugin for Event Portal does exactly that: it uses AsyncAPI bindings, (which are an open standard, so no weird proprietary stuff), to generate objects for a particular application.
See Event Portal with Ansible in action!
Check out the Solace-Ansible source code!
Once an application is in an environment, the Postman plugin for Event Portal can automatically create a Postman collection that lets you test an event-driven flow as easily as a REST service by repeatedly sending in the same event, which is fantastic for demos and testing.
See Event Portal with Postman in action!
Check out the Solace-Postman source code!
No one wants another stand-alone tool, so we’re excited to introduce these plugins which enhance your existing SDLC tools by tying them into the world of EDA. We want to help you better exploit the power of events, without making you give up the processes you know and love… or do a whole bunch of manual work.
Sign up for a free trial of PubSub+ Event Portal, or learn more about the plugins at solace.dev.