Event-Driven Applications to Dominate IT Landscape – Shawn McAllister, Solace

This is Techstrong TV Hey guys. Thanks for the throw. We're here with Sean McAllister.

Who's chief technology officer and chief product officer at Solace And we're talking about event driven architectures in the rise there of Sean. Welcome to the show. Well, thank you very much Mike.

I'm glad to be here. I think the first time I heard the term event driven architecture, I was much much younger than I am today. And so the concepts been around but it was always something of a niche space and now lately it feels like there's a lot more of these event driven applications starting to show up.

So what's driving that Yeah, so so you're right. This has been quite nichy for some time, but it has been around for a long time. I used to have hair actually when it just started but yeah, it started off in places like Capital markets right where Wall Street went from Human trading to electronic trading and what they needed to do then is to respond to events in real time.

So as people placed orders and trades happened people needed to be notified quickly so you could see what the price was quickly and then you could place an order and hope to you know, hit a certain price point and so for them what really drove it is real time, and this is what's happened now in so many other Industries now, right you look at so many things consumers expect things in real time now and in order for you to build applications that respond to events in real time, you need to have an event driven architecture. So that's one of the things that's driving it from a business point of view and then from a technology point of view as people move to the cloud and they build Services and they decouple their applications and they have hybrid Cloud deployments. You can no longer build applications that are tightly coupled anymore because you know for many reasons.

So these are the things that are driving the adoption of event-driven architecture not to mention of course analytics as well. As one of the kind of the killer apps that started off also very much wanting to have or pushing people to have real time information real-time dashboards available to them. See your point.

We want to be able to process and analyze data closer to the point where it's being created and consumed that seems to be driving a lot of their core digital Transformations that people are talking about. But what do people underestimate when they go to build those applications? Because I think everybody looks at something like I don't know whether it's Uber on my phone or whatever it is and go.

Well everything's gonna be like that, but it's not so easy to build these things. It it's not so easy. And there's a few reasons.

Some of them are technical. Some of them are cultural. Right?

So if I start maybe with the cultural one where organizations who adopt an event driven mindset like they have to start thinking differently, right? So many people are used to accessing a database. They're used to using making rest calls where everything is synchronous, right?

So now you have to think more about emitting an event. You don't Target a rest call to where it needs to go. But you admit an event that says a boarding pass was scanned or an account was opened or a purchase, you know was s*** or an order was shipped.

And so you have to start thinking about emitting events and then consuming these events and doing something with them. And because if you don't if you use a new tool and you don't think about it differently, it doesn't work that tool doesn't work very well. So that's one thing the other thing is that up until you know, recently event-driven architectures are really focused on event Brokers the broker itself moving events around and if all you have is a broker building event driven applications is hard because there's a lot of other things you need to do.

And now and and this is what capital markets did right they had a broker and they built a lot of stuff around it, but now with a much broader adoption of Eda and so many other markets you're seeing platforms evolve where you know such as us for example, where we provide a platform to build event-driven applications, which makes it so much easier because as you build distributed applications, you have to have them all coordinated, right? And so you need things like better distributed tracing so you can see what's going on. You need to be able to have tools to be able to Define your events and catalog them so people can find them so that they're reusable right which is a key point.

You need to be able to know that if you change an event which applications are going to be impacted by that change so you don't make an event and you know take out a bunch of applications and production. So the tooling around building event driven applications and it's improvements there need to happen to make this easier I would argue this is one of the fundamental reasons that rest. So successful, first of all, you know much simpler than SOA first of all, but then also the tooling around it, you know made application development much easier.

That's starting to happen now. Do I need Specialists to build these applications or is it more going to be we need to just teach the current rule of developers how these architectures work? I mean because anything that requires a specialist seems to be more expensive to build and takes a lot longer a hundred percent and and stifles adoption for sure.

Yeah. I know. So this is absolutely while it is it's it is difficult to do anything new right often because of tooling and mindset.

This is absolutely something that all developers can pick up if you think about it differently, especially because there's new Frameworks that are coming about like, you know Frameworks that have been around for some time like spring Cloud streams, for example that I had a bunch of the infrastructure and really very much allow app developers to focus on the business logic that they need to build. And so as these Frameworks become better the you know developing these apps will be better but it's absolutely something that application developers who you know develop applications now can take on 100% Each have to learn new things right to your point. You have to learn new things which which was I think right you kind of like as things mature you want to learn new things you need to develop new skills.

And this is how things move forward. Yeah to that end the folks who manage the back end tend to be devops teams or their things that they need to know about these types of applications when they start coming through their pipelines and when they get on the back end, what should they be thinking about? Yes, for sure because you know, so a couple of things right in terms the things that they need to know but it is synergistic as well.

Right? So as you move into ci/cd deployments and infrastructure as code these types of event-driven microservice applications play very well in that space. So there's there's kind of synergies that way now that said from an operations point of view, you know, you get into you know capacity planning and load Management in your environment.

So there's new things that they need to know there because good event Brokers provide you lots of visibility actually in what's happening and among your micro Services, right? So they would give you information like if microservice a set of microservices is not processing events fast enough you could know that from your event broker because it will give you indications that queuing is happening and things are processing and taking too long. So there's new sense points that they need to be aware of that.

They need to Into their monitoring to be able to know that the applications are working well, but again because you have this broker in the middle you have, you know, you have infrastructure that can monitor the behavior of these applications right shorts up very well. But does require additional tooling and does require them to be integrated into the rest of your monitoring environment. Do you think these event-driven architectures will essentially supplant all the bad joint and stuff that we have today or all the bad joint and stuff become more event driven.

Like what is going to be the balance between these two different architectures? And that is a great question. Yeah.

So I really do believe batch is going to go away as we know it because as so many things become more real time and as the real-time infrastructure grows even things that you think might not need to be real time. It'll just be easier to put them on this infrastructure for one thing, but they really evolve so that you have things, you know, like change data capture for example to be able to extract information in real time from your databases and then to be able to you know to transform them into more canonical forms that then multiple applications can consume and because you know, if you think about you know, you build a new application Give an example, right? So let's say in a bank you open As people open accounts and you're told to from a business point of view you want to send a text.

To a customer who opens an account, right? You don't want to send that text tomorrow after your batch load has occurred and you've extracted all the new accounts right and send them a text tomorrow saying I really appreciate your business. They'll go if you really appreciated it.

Why didn't you send it to me when I opened the account? Right? And so as all these things move to become R is he take your systems of record and have all these changes that happen in your systems of record and make them available in a publish subscribe event driven manner.

It really removes the need to have ETL processes at all because all this information is available to you in real time. And the thing is what that means is then you can innovate much more quickly and you can be much more agile. So if I have to wait for you know, an extract transform and and load an ETL batch job to be run and I have to get somebody to create it and deploy it and build it the cost for me to create such an application is very high because getting access to the data the cost is high whereas in an advent driven architecture environment.

If you've truly embraced it you've taken your systems of record and changes that happen in them. You have pushed them out. In real time onto this fabric that allows application teams to consume them in real time.

You know, why would you ever want to go back to batch because the Innovation that you can do from that is is massive now, right? Who's gonna drive this conversation? Because I don't think we're going to do it for the sake of computer science, but People encounter this issue all the time.

They go to the store and this or whatever they're looking for isn't there and then somebody looks it up online somewhere and tells them it's across town and it's in a shelf over there drive across town and it's not there because it was bought in the last half an hour and nobody updated the system. So are we moving to point where business exactly even the consumers themselves just not gonna tolerate these older bad joint and models where everything, you know, no one wants to admit it but is severely out of date. I 100% agree and you know the example that you give actually from a retail space is where we've seen a ton of adoption, right especially since covid where people had to change their business models right where yeah consumers are just not willing to put up with that anymore.

Right and I'll give you even examples so consumers aren't willing to put up with it and you know the value to businesses as well. We have a client of ours that what they do is they do real-time pricing and grocery stores so that and and so what they literally do for their own benefit, is that as the day progresses and they have perishable goods and they know from Real Time inventory monitoring that these particular goods are not moving quickly enough. They will in real time alter the price of these perishable Goods push that out to real-time displays in the store to encourage customers to buy them.

So they're not left with wasted inventory. So to your point about what's going to make the business interested in this definitely there's going to be customer pull of they just won't tolerate this anymore. And then there's all kinds of business efficiencies that go with this as well if you have a real-time control over your information.

All right, folks. You heard it here those bad joining applications that you've been nursing for. The last three decades may just very well be the definition of antiquated.

Hey, Sean. Thanks being on the show. No, perfect.

Thanks a lot. Mike was nice chatting with you. All right guys back to you in the studio.