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.
Your Existing SDLC, Enhanced with EDA
Enter PubSub+ Event Portal – a powerful tool that helps application teams design and manage event-driven systems. Event Portal enables you to:
- Prevent chaos by easily governing shared resources across environments
- Get more use out of existing events by making them visible across your organization
- Help you understand how events move back and forth between applications—and how that could impact your organization
- Expose events with partners so they can incorporate them into their business processes and customer-facing services
- And much more…
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.
Event Portal Plays Nice with Your Tools
To facilitate the integration of SDLC tools and Event Portal, Solace has developed several plugins that aim to:
- Sync Event Portal with your existing SDLC process with minimal impact on people and processes
- Use Event Portal to provide better governance, reuse and understanding of your event-driven applications, event streams and system as a whole
- Enhance SDLC processes by including Event Portal’s information in the format that makes the most sense for each tool.
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.
Meet the Plugins!
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.
Collaborate and Code
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:
- You can use the command /solace to pull in the latest designs of the applications, events and schemas. No more misunderstanding about what the latest is – it’s right there in the Slack chat. Each result includes a drop-down menu that lets you examine more details, and a deep link to the Event Portal.
- You can take a URL from Event Portal, paste it into Slack, and the info will automatically populate within the Slack channel.
Once you’ve defined an initial version of your application, you can view it in Confluence without needing to cut and paste. And as the application evolves over time, your documentation automatically adjusts.
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.
Continuous Integration & Continuous Delivery (CICD)
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:
- Validating the AsyncAPI
- Verifying the semantic versions are correct
- Ensuring that best practices are followed by coders
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.
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.
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.
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.
Are you Ready for Event-Driven SDLC?
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.