Loosely Coupled - Adopting Event-Driven Architecture

Hello, hello, good evening, good afternoon, good morning, or well, maybe good night for some people watching in India, if anybody is in India.

Welcome to loosely coupled, our first live stream from Bridging The Gap.

I'm your host Karol Skrzymowski, I'm the co-founder of Bridging The Gap, an open source project aiming at educating about enterprise application integration.

And with this stream, I want to bring some interesting topics loosely coupled with the field of application integration, and very loosely coupled with technical topics.

Now I made a mistake of having too many windows open, so I'm actually hearing myself all over the place.

All right.

A little bit of housekeeping.

We're live on YouTube.

We're live on LinkedIn.

Please keep the comments and questions and everything coming.

If something will be relevant for the topic, we'll be showing that on stream and asking that directly.

If not, we will still have some time at the end for a Q&A.

And with that, let me welcome our first guest to this lovely live stream.

First edition, Fran Mendez.

Hello, Fran.

Hello.

Well, how is your evening so far in Spain?

Packed and hot.

As you can imagine, I'm in the south, I'm in Balakot next to Portugal.

And, you know, we have a saying here that 35 degrees Celsius is getting cold, you know.

So, yeah, it's not getting cold.

It's quite toasty in the Netherlands as well.

The morning was cloudy and a little bit chilly, but the afternoon is quite, quite, quite warm.

So, very nice indeed.

All right.

We're having a lovely topic today related to enterprise application integration and software architecture as it is.

We're talking about event-driven architecture.

And who better to talk about event-driven architecture than the creator of AsyncAPI himself?

So, Fran, tell us a little bit first about AsyncAPI and your context and your background here.

So, for the people who don't know you, who only heard about AsyncAPI from, let's say, when they used MuleSoft or Solace or any other technology, so they have the proper context of who you are and what the hell is AsyncAPI and why did you even create that?

Oh, that's a lot.

Yeah.

I can own the whole live stream just with that.

Let's keep that part brief.

So, yeah, my name is Fran Mendez.

I live in Spain, as mentioned.

I don't even know how to categorise myself.

Like, I've been a director of engineering in my last position, but before I was a manager, but before I was an architect, but before I was a CTO.

So, I've been, like, jumping from role to role.

And I keep saying that I'm just an engineer, and I do whatever it's needed to do, and I'm always adapting to whatever it's needed in each situation.

So, I don't like to label myself as one thing, for the good, for the bad.

And, yeah, so, I created AsyncAPI, as Carole mentioned.

So, this was almost nine years ago.

And the reason I created AsyncAPI, it was just for me.

It might sound egocentric looking back or explaining it like this.

But the reality is that I wasn't expecting this kind of success.

I was just building it for me for two reasons.

One of them is I wanted to learn OpenAPI well.

So, I had to create AsyncAPI.

I had to go from top to bottom of OpenAPI specification and read it and change whatever didn't make sense to me.

Didn't make sense for my use case.

And what was my use case?

That's the second reason.

My use case was I was using RabbitMQ to coordinate some microservices and, you know, and communicate between them and so on.

I was building an event-driven architecture.

And there was nothing like OpenAPI for that.

So, I decided to go ahead and modify OpenAPI.

In the beginning, it was mostly me.

Like, okay, maybe when it says GET, the documentation generator can say SUBSCRIBE.

And when it says POST or something else, it can say PUBLISH.

And that might do the trick.

Well, for documentation, it kind of did the trick.

For code generation, not so much.

It felt a lot like a hack.

It was a hack.

So, yeah.

And then that's when I realised I had to go through the whole thing and change it.

And it was all done in open source because that's always my default.

So, I was not...

I already had, like, a bunch of other open source projects, but they never took off.

And this one started taking off because, you know, I started talking about it in conferences.

And I saw some interest from people and so on.

And it started to show some traction, let's say.

So, I created Slack and so on.

And started inviting people there.

In the beginning, it was me mainly talking to the wall, as we say in Spanish.

So, I was just like, hey, so today I did this.

And today I added that.

And the funny thing is that the other people on the Slack was the people from my own company, from the company I was working on.

And they already knew that.

And they were like, hey, we don't care, Fran.

We already know.

So, they were not interacting with me.

And that was funny and desparating at the same time.

But eventually people start getting in and asking and so on.

So, yeah.

So, that was...

And here we are.

Here we are.

And now I had a look through the AsyncAPI Slack.

Wow, that's a busy place.

I get so many messages.

There are so many pull requests going through the channel.

So many conversations happening around various topics.

It's crazy.

And so many people participating also with the AsyncAPI conf and all that.

And I already saw a few streams online of the community.

It's interesting how that can grow.

Yeah, this is something I would love to highlight is we do everything in the open.

So, we aim for total transparency.

Not as a way to...

Not as a way to show off or something like that.

Or to justify our behaviour or something like that.

Because we believe in transparency, in radical transparency.

So, we try to do everything in the open.

We are conscious.

We are aware that just because you make everything in the open, it's not necessarily transparent.

You need to publicise it.

You need to advertise it so people know where this information is and how to consume it and so on.

We try to do it, but as you said, we generate a lot of content that is almost impossible for us to promote all the content we create.

All these live streams, all these meetings and so on.

So, meetings are not recorded.

They are live streamed.

Always.

All the meetings.

Unless there's something like code of contact stuff that is obviously handled separately for privacy reasons.

But other than that, everything is open.

Everything is live streamed.

And that's really cool because when someone wants to land on the community, the only thing they have to do, the only thing, is to start watching these live streams.

Start joining these meetings if they can.

If not, they can watch the recording.

Following these certain issues on their favourite repo and so on.

And it's really...

And it's easier, I would say, to get on board.

It's not easy.

It's easier.

It's not easy, though.

Because, as you said, it's huge.

It became a huge project with lots of people.

So, filtering in the noise is always difficult.

Okay.

But we met today to talk about even-driven architecture.

An adoption of said even-driven architecture.

Now, the key question I have is, how would you define even-driven architecture?

Because I'm pretty certain that from your perspective, the definition's a little bit different than from my perspective.

Okay.

So, I mean, in general terms, I would say, I want to make a...

I want to clarify something here.

So, we often talk about even-driven architecture.

All of us, including myself, when we mean message-driven architecture, right?

What's the difference?

So, to me, I don't think it's only to me, but the difference is in the meaning of the message, right?

So, message is like the broad concept.

There's a piece of data flowing, usually through a broker, from producers to consumers, and so on, right?

But to me, even-driven architecture is when you work with events, with facts that happened, right?

That's it.

Like, you send events to a broker and consume them from other consumers, and so on.

For which purpose?

That's not defining the term to me.

That's something that's kept open, right?

So, I just live there.

Even-driven architecture is something that is...

It's a kind of architecture that usually relies on a broker and where you exchange events as facts, let's say, right?

But some people, as I said, like, some people also, including myself sometimes, because it's useful to talk about EBA all the time, if you send an action, a command, and expect a response over a broker, which is also possible, we sometimes also talk about these things as even-driven architecture.

When it's not, it's not an event, right?

It's a command.

But that's a different discussion, let's say.

So, that's what I live at usually.

This can be just to communicate microservices in your team, your domain, or something, or it can be as a means to integrate, to build integrations inside your company, or with partners, or with public, you know, with the public audience.

That depends on your business.

For instance, robotics.

We see a lot of this in robotics with MQTT.

They offer their OpenAPI as an I think you pay file defining an MQTT API, right?

So, and anyone can consume it, right?

Anyone, you only have to apply for a token.

And that's it as a token that it's going to be prepared to your MQTT topics and so on.

So, it's effectively like the counterpart, or let's say the sister of a public REST API, but using MQTT in this case, right?

So, yeah, there are many usages of event-driven architecture.

There is a talk that we have it on the Cinque Bay website on the documentation.

It's linked there from Martin Fowler.

And the talk is titled, the many meanings of event-driven architecture.

And I think that perfectly illustrates what I mean, this talk.

So, if you go to the website, and you go to the documentation, if not the first page, one of the first pages, I'm sorry because I don't follow closely the docs anymore.

It's too much.

It's fine.

But I'm sure we can find it later and put it in the description of the recordings for people to find.

That's going to be fine.

See, one of the highlights I have in terms of event-driven architecture, I have two perspectives on that.

First one is the interoperability and the way we design communication within the system, which, for example, like microservices, microservices go well with event-driven and choreography and all that, right?

Which is usually not of my concern because I don't design domain systems.

I look always on an ecosystem level, so the communication and interactions between various systems.

And there, event-driven architecture has a lot to do, but it differs slightly in certain areas, like, for example, do we use data-based contracts or key-based contracts?

So like anaemic events, usually in business systems, key-based contracts would be quite normal, while in ecosystems, they're actually more of a considered as an anti-pattern.

So there are these kind of small discrepancies of what would be acceptable on the level of a system using EDA and what would be acceptable on the level of an ecosystem using EDA.

Then also the differences are like the sets of patterns sometimes differ or what is the database topology.

So we usually work with completely distributed separate databases, separate sets of models, data, everything separated.

So that's my kind of take on EDA.

For me, these are just two types which drive my conversations in enterprise application integration at least.

I would say even more than two types.

It's like inside a certain domain, a domain understood as a domain-driven design.

It's inside a single domain to coordinate stuff in between a domain.

Sometimes you have services or microservices inside the same domain and they need to coordinate for whatever reason.

Usually these events are not useful for anyone other than these people in this domain.

But then you have cross-domain that starts behaving as integration as well, but inside the company, inside the organisation, doesn't have to be a company.

But then you have cross-organisation.

Cross-organisations in plural, and you have partners, integrations, and so on, or public.

So the scope can go well beyond my truth.

The funny thing is, because I've been sitting recently with a lot of domain-driven design people and discussing the overlaps of domain-driven design and interoperability topics, and the most amazing thing is that actually if you look at it from the perspective of domains, a domain can span across several systems.

And a specific system may represent within itself several domains.

So those overlays we can draw over those system boundaries and different block diagrams are quite elaborate at times, depending on how the company was built, how much design went up front into those systems.

And then the world of cloud comes in and with SaaS solutions, everything is wrecked all over again because obviously SaaS solutions have a completely different philosophy and they again represent multiple domains.

And it's over a layer, on a layer, on a layer, depending how we want to approach those layers, but there's so much to it to walk around.

And with that so much, I think there's a level of hidden chaos in all ecosystems.

I mean, entropy creeps in everywhere, so I would guess sooner or later everybody will experience chaos somewhere.

But in terms of even-driven architecture, I think one of the biggest challenges of a hidden chaos might be the overall lack of standards in a lot of companies or a lot of organisations.

While we have very robust standards for synchronous communication, I think not a lot of companies actually know how to standardise async.

Yep.

What's your take on that?

That's a good point, actually.

You're touching on the point of governance, right?

So there are standards.

There's AsyncAPI.

There's cloud events that Aleksandr has mentioned on the LinkedIn comment.

There are a lot of different standards for messaging.

Then you have Avra.

Then you have for schema definition, right?

It's the schema itself.

Then you have this protobuf and so on.

So there are many different layers, different levels, but there are different standards for that.

Now, the thing is that it's funny.

Something that I'm seeing lately is that maybe I'm biassed.

So bear with me.

But way more companies now are starting to adopt an API-first mindset.

And I'm talking about synchronous, right?

So now they are starting now.

It's like the bulk of it, the bulk of the companies like everywhere you look around or almost everywhere you look around in tech companies or in companies with a mature, let's say, technical team.

You'll see more and more people adopting OpenAPI, adopting API-first mindset and so on, right?

So that's cool.

That's really good.

But that's just, to me, as I see it, that's just starting to happen now.

It started to happen many years ago.

But now is when I'm seeing it like, oh, it's starting to be everywhere.

Cool.

That's good.

Finally.

It only took us 20 years now, not 20.

But yeah, like when I was working, when I created AsyncAPI, we were already building a product to work with OpenAPI.

So OpenAPI was already around, not Swagger, OpenAPI.

So OpenAPI was already like, Swagger was already renamed by then.

So it means that it was there for a while already.

What I mean with this, and this reminds me to a panel I got invited in Silicon Valley, I think 2018, or something like that.

And I was there.

I remember my phone sitting there in the panel and listening to everyone, not speaking at all, and thinking, everyone was saying that how cool OpenAPI was, how cool, how everyone was using standards, how beautiful everything was, right?

And I was just sitting there and it's like, that's not what I'm seeing.

Like, what's wrong with this?

Like, is it just me that I'm not seeing enough or what's happening?

And I recall someone from the event, I don't recall the name of the guy, sorry for that, but someone from the event said, like, mentioned my comment in Twitter, I think.

And he was like, the point, the whole point of the day was this take by Fran Mendez saying, hey, get down to earth, like, this is pretty cool.

But we're just a bunch of us using it, right?

Like, we're those nerds that love APIs and OpenAPI and so on and API first and sign first and we're thinking about these things, but nobody cares, nobody out there cares, right?

Many people are building microservices and they don't even know what OpenAPI or Swagger is.

And it's not that they care about or not, it's that they don't even know what it is.

They don't even know it exists.

I'm talking about 2018, right?

And I was like, I don't want to disappoint people here, but my feeling is that this is still very niche, looking as API nerds, right?

Then now I'm seeing this with this in KPI as well, or with even driven architecture, driven in this case by this in KPI and or cloud events.

I'm seeing that more and more companies are adopting it.

But it's still very early in the days for these companies to even, some of them, they don't even know if these standards exist, right?

And I could even, I could see it from the Postman surveys.

So Postman was organising a survey every year and I think it was around 1% of people knew what API was.

And I was like, I know it's a very specific target audience, APIs, but precisely, it's very related.

It's actually coming from that same world when I created this in API, I created it from OpenAPI.

And I was always advocating for it on API days conferences and in API related conferences because that was when I was feeling comfortable, not for any other reason.

But you know what, I was like, when you're talking about the standards and the old nerds like hyping about those standards, I'm like looking back at my career, when I started doing application integration, REST was nowhere to be found.

Nobody was using JSON because it was non-existent.

We were using XML.

It's still nowhere to be found yet.

I'm going to get to that one in a moment.

So looking back 14 years ago when I started as a junior developer, we were building SOAP services over HTTP or SOAP services over JMS. And that was already a very robust standard and was already a very established standard.

Very rigid, had to be very precise, so it was very prone to errors.

You could do a lot of errors and everything will be just returning you a 500 HTTP error, right?

Which is fine because where I worked, we actually needed very high rigid standardisation of the APIs so that we can have that quality of data.

But even though that was a very established standard at the time, we still stumbled into people who had no idea what they were doing, even if they were senior, right?

So I remember this lovely conversation some time ago where somebody was debugging a SOAP service and the guy had no idea why it was not working.

The message was sent according to specs.

The specs said that the specific element could be empty.

Like no string at all, right?

So basically in the XML, they got an empty tag.

So a tag that doesn't have two elements has one element so it's already closed.

Self-contained, yeah.

And I remember the lovely comment from that developer debugging that communication because it was wrongly interpreted.

It's like, I'm getting a very weird tag here.

It's neither open nor closed.

I don't know what that is.

And I'm like sitting there and it's like, after a few years later, I mean, when I started doing proper research into interoperability and why we're doing certain things the way we are doing things and I started reading the specification of the XML, I was like, that self-contained tag is in the first version of the specification.

It's old as hell.

It was there for a reason.

It's pretty common in HTML as well, yeah.

Yeah, exactly.

The new line tag, that's basically what it is, right?

Line, link, all this stuff, yeah.

Yeah, plenty of those.

And I was like, right, perfect.

So we have standards but nobody actually even reads them.

They apply to the use case.

Sometimes good, sometimes bad.

And now looking at the REST standard, I would say that over 95% of REST services are not aligned with the REST standard.

We call them REST services, but they're not actually up to par.

They don't have the next page.

They don't have the related objects, nothing like that.

We just use this to convey messages based on CRUD, create, read, update, delete.

And we have standards.

But who read the REST API standard?

I mean, hands up, probably nobody, other than the two of us, I would guess.

No, no, no, I haven't.

I just went through it like a little bit, but couldn't finish it.

I mean, it's an interesting one, probably.

I just didn't have the time or energy to do it, or even the need to do it.

So if I have had the need, probably I will have done it, and that's fine.

Yeah, the need is also quite important.

So I never had the need to have, let's say, a proper REST API.

Because what you said, even consuming this kind of APIs will become more difficult for teams that are already like being pressured to deliver quickly, quickly, quickly.

Right?

So yeah, this sort of SCRAM methodology that we have been applying for the last decade, it's a little bit of a culprit there as well for telling people that you should be rushing out and delivering things quickly in the next two weeks without looking farther than just two weeks.

So I know it's not exactly what SCRAM says, but that's how it was usually applied.

So in the end, we'll get back to the same thing.

So basically we could say that, yes, we have standards, but nobody's adopting those standards.

So we basically live without standards.

And that's one of the usual problems.

Now, I would love to give, let's say, a vote here to these people who never reach standards and try to build things and so on.

I'm one of them as well.

And I think everyone is, everyone, like we all do it with certain things, not with all of the things, right?

But the thing is that if you are under pressure to deliver, deliver, deliver, you could not be reading MSN.

All the standards that are out there and so on, sometimes it's faster and easier for you to deliver something that is, meh, it works, right?

And you're not going to be fired because you deliver.

Then to say, you know what, let me properly read this and let's build this in eight weeks instead of two.

But the cool thing is that next time we have to build something like that.

Actually, next time we have to build a feature on the API, we don't have to change the API.

Like the whole API will adapt itself, right?

Like the web is doing with HTML, for instance.

You don't have to encode each website in the world, like everybody got a language, which is HTML, and then you can create the content.

And then you have link tags and so on, script tags, and all this kind of references to other webs, the A tag, the anchor tag, and all this stuff, which are hyperlinks.

So there's a system there, right?

The thing is that for some reason, at some point, we decided to say that XML or HTML is not good enough.

Let's just jump to JSON because it's more readable.

I can relate to this, like I failed myself.

I prefer to read JSON than to read XML.

But it's true that it's not compatible, so we're losing features when we jump from XML to JSON.

I mean, I know a few people who would argue that nowadays JSON already has those features that XML has.

That was like a kind of patches and so on, but at the time, it's already late, let's say, because people have too invested in using plain JSON with no structure and so on.

So it's a bit of a mess, but I will not point to those who are using the standards without reading the standards.

I will instead point to these organisations who don't give enough space to these engineers to iterate and to experiment and to build better systems, right?

And instead, it's like ship, ship, ship, ship quickly because we need to go to another feature and another one more feature, one more feature.

We don't care.

It's like technical debt.

Who cares, right?

This is not going to give us money, right?

So I will point to these people instead.

Like there's company cultures, organisation cultures that don't enable for engineers to experiment and fail and develop things in a calm way while you're reading things and develop things properly.

In the automotive industry or in the aerospace industry.

I'm pretty sure it happens to some degree, but it doesn't happen as much as with software, right?

Why?

Because she cannot just ship a half-baked plane into the air with people, right?

Because if it fails, it will kill people, right?

So that's why it takes so long time to build something that is, okay, this is now properly tested.

It's not going to kill anyone.

And if at some point there's an accident because of a failure of an aeroplane or something, that will become the rare news of a plane accident.

That's really rare.

But bugs, software bags, we see them daily.

Because who cares?

Who's going to die for this?

I mean, yeah, one could argue that there are certain systems where people could die of software bags.

But in general, who cares?

Like, well, what's going to happen?

Like, someone's not going to be satisfied.

I don't care.

Let's just keep rolling.

That's why we say that if we're testing software, we're never 100% sure that there are no bugs.

There are always bugs, and software we just haven't found them yet because we just found that the right deterministic situation is everywhere.

That's the situation.

Hardware as well.

It happens as well.

So the thing is that if you are serious enough about it, if you have that need, like in the aerospace industry, you don't want to be in the news constantly because you killed a lot of people, you want to make sure that you reduce this probability to the very minimum you can, right?

And you do a lot of tests.

And so before you even launch something, right, before you even launch a beta version, right?

Yeah.

That's something they do at all.

So that's my point.

So I will not point to these people who don't understand the standards and so on, but instead point to our shitty organisation, organisation cultures, and that don't provide psychological safety to engineers to experiment and to fail.

That is my take.

And learn from those failures.

Yeah, exactly.

And this is a very nice segue to the next topic at hand, which is the non-technical barriers, but also the mindset shift that is required for proper governance and proper placement of even driven architecture within organisations.

Because from my perspective, it's extremely easy to jump into doing point to point.

That's amazingly easy with OpenAPI spec, with just all the libraries that enable you to put in just a REST API in seconds, with LLMs that just give you a definition of a REST endpoint in matters of seconds, and with a spec that you can send to somebody and they will use it.

I mean, it's extremely easy.

But to properly govern asynchronous communication, I think that's something completely different in that sense.

That's really happening by the way.

So you can really do that.

And with LLMs as well, like you can generate AsyncAPI and you got pretty much, I will not say the same coverage as with OpenAPI, but this is not yet as mature as OpenAPI.

I like to remember that OpenAPI has been around for probably around 10 more years, or a little bit less probably.

Yes, while you can generate, that doesn't really change anything in terms of governance or the non-technical obstacles.

That's my point.

That's my point.

So you can generate even mocks or stops for like people can use postman, for instance, for OpenAPI, but people can use also microx to generate mocks for, you know, for, I was going to say a Kafka topic, but I have to learn myself to stop saying Kafka for everything that it's even doing architecture because it seems like it's the same.

So let's say for an AMQP topic or an AMQP queue, depending on your configuration, or an MQTT topic or whatever, right?

So you can mock this already with microx as well and with AMQP contracts.

And you can have people who are, let's say not very technical, like product managers who understand a little bit about the topic, but not so much.

And they can already create some mocks, some fake data that will be published to a broker and things like that, right?

So it enables, let's say, non-technical people to go one step, let's say one step ahead, one step beyond without having to wait for the engineering teams to apply these things.

And you have similar technologies like Spectral that it's used to create, to link OpenAPIs, to link this into API as well, right?

So you can use both, right?

All right, but going to the mindset shift.

Yeah.

And that's actually a very nice, also a point where we could pop this lovely QR in.

Fran is actually writing a lovely book about, what is that about, more human challenges of adoption of?

No, no, no, actually, lately I'm talking about a lot about these things, the human challenges of adopting engineering architecture, because that is the most overseen aspect of it that I found out, right?

So I know, like I can write a book about the technology needed to build an event-driven architecture and apply some governance to it and so on.

That's fine.

That's what I've been doing for the last 10 years or so.

The problem usually relies on a more human side of things, right?

So like, I'll give you an example.

So for context, in the last four or five months, I've been interviewing more than 20 people from different companies at different stages, but they all were doing event-driven architecture for the sake of the book, right?

I want to understand how people are doing, what are their challenges and so on.

So I wanted to make sure that it's not, this book is not just based on my experience or in my opinion, but also on facts, let's say, right?

And I'm glad I did because I was not going to even mention anything about the human side of things, right?

And what I found out is that every single company out there, their major challenge is about communicating, you know, like convincing their thoughts.

I'll put you an example.

If you're an engineer, if you're an architect that you want to introduce event-driven architecture or certain practises related to event-driven architecture, and you are in a well-established company, old company and so on, the rest of the teams, the rest of the engineers are super comfortable doing what they used to do, right?

They don't want to change, right?

So how do you convince them to adopt this new mindset?

Likely if you are a, if you're a leader in the company, like let's say head of engineering, CTO, whatever, how do you convince the rest of the teams, the rest of the engineers that EDA is what they should be doing and there should be a mindset shift in this case.

That's why it's called shift, right?

So why, how do you do it and why?

Because what I found out is that people were sure that EDA is what they needed and what they should be doing, but they struggled to convince their thoughts, their peers on the why.

Like why is it what we need?

Like we've been working with without it for years.

Why is it needed now?

And what I found out is that most companies don't even know where to start.

I only found one, by the way, one company that I think in my opinion, either they were lying to me or they're doing it pretty well.

So it was like a combined effort.

Like it was a bottom up and top down approach.

It was a combination of both.

That was alignment from, let's say architects, but also senior engineers, staff engineers, all the stuff, stuff plus in here with the leadership.

So everything was coming from, let's say from the bottom of the organisation, not right and sideways as well as much as possible.

But when someone was not buying the idea, then you have leadership saying, no, this is what you have to do.

I'm not asking for your opinion.

Like we want to convince you, right?

We give you the option to be convinced by faults and so on, right?

And everyone is pretty much in, but sometimes you have the black sheep around, right?

That said, I don't care about that.

I'm disobeying whatever they tell me.

I don't buy it.

Well, in this case, it's useful to have someone from above, right?

And say, no, no, you have to do it.

Like there's no chance I'd say that this or you leave basically.

I mean, they should never be using that card if possible, but it's useful to have it, right?

I'll put a opposite example of not adoption.

I've seen many companies adopting new practises in terms of interoperability.

And I've seen some really bad examples of those adoptions, one of which was to create a whole integration team from scratch from former database developers and database administrators.

And if we put people that don't have the right mindset into these kinds of roles where they need to do interoperability, I mean, some really wonky stuff happens.

The wonky stuff that happened there was that they, with their database mindset, they persisted everything.

Imagine just purely persisted communication, like everything has to be written down, persisted in the database, then redistributed by usually point to point.

It was magical.

And one of the reasons I observed why they did that is because that company, in terms of how they communicated between teams or how they communicated between departments, between each other, was mostly on meetings and with robust documents.

Like they just made humongous paper trails.

And from my observation over the years in application integration is that if we look at the way that a company communicates internally, that translates directly to how systems communicate in that company.

So if we have lots of meetings, we're going to have...

Yeah, Conway's law, pretty much, yeah.

If we have meetings there's going to be a lot of request reply.

Yeah.

If those people are accustomed to using...

And synchronous.

Yes, definitely synchronous, yes.

If that company is accustomed to using chats and they're accustomed to not rely on instant reply, well, we'll probably have some even driven in the systems, a decent amount.

And then if a company is relying on documents, that's going to be batch, batch, batch and file-based transfer, file-based transfer and file-based transfer all the way.

I mean, it's fine if it's proper ETL, ELT or batch, but if file-based transfer, I mean, come on, are we like in the 70s?

That's still useful sometimes.

It is.

I mean, think about it.

Like if your system is not...

I mean, if it's not relevant for your system or for your company, to have this information right straight away, like in real time, as much as real time, you want to define it.

File transfer, like a batch overnight, it's completely fine.

Like if it works, if it's not, let's say...

If it's not a problem, if it's something that can be done secondarily, it's not critical for your system and so on.

That's another technology.

Like I said, it's a technology.

Use it whenever it makes sense.

Exactly.

And I agree on that.

Whenever it makes sense, but then...

Exactly.

Don't use it for everything.

If you have 90% of your communication being robust operational communication because batch is great for analytics, batch is great for long-running processes, it's fine.

But if you're doing your operational communication with file transfers, there's something definitely very wrong in the way people do not communicate with each other.

Because if I'm looking, if most operational work is done over sending a document...

Honestly, I think, again, like every time I dig down into this topic, I find out that it has nothing to do with technology.

So every time I found that, and I scratched a little bit of surface and asked, why do you keep doing these file-based transfers, these batches overnight and so on?

Every time I kept scratching, I instantly found that...

Instantly, sometimes even in the same meeting, like one question away or two questions away, I was just not even asking directly, just asking around.

And instantly what popped up is it's a psychological safety in the organisations.

So picture this.

If you are an engineer that's been in a bank for 20 years working there, you know the system inside-out, right?

Now someone comes to you and say, we now have this Kafka broker, right?

And we are doing...

We're now doing everything over Kafka.

But you still have to deliver stuff, right?

So what you will probably do is either say, no, I'm not going to do this because I don't need it.

If you have the psychological safety to do that, and meaning that you know that you're not going to be fired for disobeying, or you say yes, but you don't do it, right?

Which is even worse, right?

That's even worse because everything...

What happens in this case is that everything seems to be working.

Everybody is buying the argument.

Let's use Kafka.

Let's react on real time or, yeah, as it happens, to all the events and everything.

We process them and so on.

And we do the calculations in the very moment as we get the event, right?

Instead of just relying on overnight batches, right?

It seems that everybody is buying your argument.

But then you find out that adoption is like, this is not happening as fast as it should.

What's happening here?

They keep putting excuses here and there, like we have some deadline that we have to match, whatever, which might be true as well.

And then it's almost impossible to migrate to this new kind of system, right?

Let's say in an acceptable time because these people are boycotting you, right?

Even if you are their boss, right?

Because for different reasons, it can be because their manager is not aligned with the leadership making this change.

So their manager is still like putting them pressure, like you need to deliver this, this, this, this, this, more feature, more things, more blah, blah, blah, whatever.

So we don't have time to change our mindset here or to study or to start experimenting because it's a new technology.

You have to experiment because you don't know how it works.

So you've got to experiment, right?

So the manager is not letting them experiment.

So they never have time to experiment.

So since they don't have time to experiment, someone, some colleagues, some peer come to them, maybe an architect, usually an architect comes to them and say, hey, why are you not already publishing this information to Kafka or consuming from Kafka or whatever, or from, I mean, why to bother, right?

Why aren't you doing this already?

Like it's been two months or whatever.

Then you have this problem that they need to keep shipping because the manager is putting them deadlines.

Now, the other thing that I've seen is this is if the whole technology changes, I may become redundant in this company.

I may lose what makes me special and what makes this company not fire me, right?

And so I will lose this job and I don't want to lose this job because as opposed to us who are passionate about software, many people are working in companies just in exchange of a salary just because of debt, which is perfectly fine.

You don't have to have a passion for software or for your job.

That's completely fine.

And it's totally acceptable, right?

The thing is that if these people fear for their job and they know they've been doing this for 20 years, so they know that if they go out, they're going to struggle to find a new job because that world is not there anymore, right?

It's only in a few companies here and there.

Very true.

And they're not hiring for these roles anymore.

So that is creating a lot of stress and their instant reaction is saying...

Resist, exactly.

Resist here.

I'm going to boycott this initiative because that doesn't make sense.

Sometimes, I will even argue, most of the times, if not all of the time, they don't do it on purpose.

No.

It's just unconsciously.

And it happens to all of us in every aspect of our lives.

So what I'm researching a lot for the book, for writing the book, is precisely on the organisational psychology.

I mentioned the safety.

I mentioned also the resistance and so on.

Aleksandr is in chat, he's mentioning the architectural comfort zone.

Totally agree with that.

It's the comfort zone.

And nobody wants to leave the comfort zone because the comfort zone is comfortable.

That's why it's called comfort zone.

Nobody wants to leave that.

It takes a lot of effort to leave your comfort zone.

It's very annoying to leave the comfort zone.

It takes a lot of courage and a lot of energy to get used to pushing that comfort zone further and further.

But it's a fallacy in its own if you don't do that.

Because those people will, sooner or later, will end up without the job and they will realise how...

Maybe these people are already 55 years old and they're aiming for less retirement without any complications.

So that's also valid.

The software industry is already becoming so old but it's already common to see people over 50 years old in teams.

So we're getting there.

Just last week I spoke to Mark Riches on a live stream with Utrecht Mulesoft Meetup.

And Mark has...

Let me not get that wrong.

42 years of experience in IT, 31 years of experience as an architect.

I mean, he's a dinosaur in the field.

An absolutely amazing guy and an absolutely amazing architect and he's very comfortable with moving his comfort zone and stepping out of his comfort zone which is an amazing thing to watch.

But he's one of the rare people there that actually is still capable to do this with his years of experience.

That's amazing but that's such a rare thing to observe.

That's passion.

That's passion.

That's only possible because of passion.

And there is...

If we look at our organisations, I mean, those people are there to make a buck.

They want to make a living and move on with their lives.

They don't have to have that passion.

It's fantastic if they do.

That's awesome.

But it requires really strong leadership and actual leadership that leads to spark the minimum of passion for those people to be able to step out of those comfort zones without fear with that psychological safety somewhere there.

And that's difficult.

That's extremely difficult.

It is because we all have a boss, right?

So that's the thing.

We all have a boss.

Even your boss has a boss, right?

Nobody wants to be the guy that is like, why are you so weak with your team?

Like why don't you tell them what they have to do and if not, fire them, right?

There's still this mentality, especially in these old industries like banking.

It's the mentality, the very specific mentality called the Peter Principle.

You heard probably about that.

So for those who don't know Peter Principle, it's a concept described in 1969 by Dr. Lawrence J. Peter

It basically means that, especially in larger environments, the smaller the company, the less it happens.

But in large corporate environments, people tend to be promoted to higher positions based on their time with the company, not based on the competence for that next position.

So they're great at their role.

They're like, let's say, you're a great junior developer.

Okay, you get a promotion to a mid developer role, right?

You're a great mid.

You get promoted to senior.

And then all of a sudden, you get promoted to a team lead, right?

And then you become incompetent because being a team lead is something completely different in terms of skill sets than being a senior developer.

Because being a team lead requires a different set of skills in terms of soft skills.

Being a senior developer, you just need to communicate clearly about the code you're writing and the technology, maybe a little bit of a coaching of juniors, etcétera, your colleagues in the team.

But as a team lead, that's something different.

So if you never have any interest in psychology or any interest in building your soft skills as a developer, and you get promoted on the basis of a Peter principle, then all of a sudden, you become completely incompetent in your job.

And that's horrendous.

And I've seen managers and directors being promoted that way.

Where they're completely incompetent to lead the whole departments and they destroy the company from within.

And then you have a large turn of employees and it all becomes very costly and difficult for everybody.

I must say, I face that myself.

In my last job at Cosmo, I was a director of engineering.

I don't know how to be a director of engineering.

I still, I mean, I more or less know now after four years being in that position.

But when I landed there, I was like, I mean, can you imagine the imposter syndrome on me?

Let's not get started on my imposter syndrome.

Can you imagine that like, yeah, I created this AsyncAPI, cool, whatever.

But when I quit my job to work 100% of my time, full-time, on AsyncAPI, I was just recently promoted as to manager position at New Relic.

But I think I was in the manager position.

I was just one month and then I quit.

So I didn't quit because of the company.

I quit because I had the opportunity to dedicate full-time to AsyncAPI and I took this opportunity and not looking back, right?

So it was a different reason.

So I jumped straight from lead engineer, let's say that I was usually playing that role in different companies.

Sometimes architect but of smaller companies.

So it's effectively it's like lead engineer.

I was instantly promoted to director of engineering, managing other managers managing people, managing the project, the budget, the strategy, you know, all these kind of things.

Aleksandr says I figured that we make it.

That's what I did usually is I kept going.

I kept going because also I was like, there's another point by Kubilay saying that is it really being an imposter?

Well, if you hide it, and you don't try, you're imposter.

In my case, I was trying hard.

I was trying to learn as much as possible, learning from peers within books, taking courses and so on.

I was trying hard.

It was just not made for me.

It's not what I should be.

It's not what I like.

It's not what I enjoy.

And it's not what I'm good at, at managing.

I can be decently good.

At least I'm not.

I'm really good at the human level in the sense of like something that I'm proud of is that I acted as a as an umbrella for my team.

kind of like a two way, two ways umbrella.

So I was filtering all the shit from the organisation so they don't have to worry about things happening at the higher level.

But letting them shine to the rest of the organisation and promoting their work and their achievements and so on.

So I'm happy with that work that I usually did.

And even when I quit and when they all were fired one month after I quit, the whole team, right, at Postman was led off.

Even after that, I was on holiday time and I was trying to find them a job and so on and talking to people so they could find a job.

So I'm happy.

I'm proud of myself at the human level.

But I don't know how to do that.

I don't know how to properly do that and I don't and even more important I don't enjoy it.

So yeah.

I mean, I must compliment you because this kind of behaviour absolute leadership.

Well, and I must say as well, I appreciate that but I must also mention something that I don't want to miss.

I want to make sure that everybody understands this point.

So and this took me a few sessions of therapy.

I'm not joking about that.

It's true.

It took me a few sessions of therapy.

So it was really painful for me to see my team being led off this way.

it's really like it takes true leadership as you said and as many people say that this is what you should be doing and so on.

But if you ever if you are ever in this position my piece of advice is don't do it.

Don't do it to that extreme.

So I've spent more than a year at Postman being burned out just to protect my team because I knew or I felt it that if I quit they all will be fired.

Because our hire basically was a marketing hire.

It was not a technical hire or product hire it was a marketing hire so if they don't have the founder of AsyncAPI why keep investing it in this ship right?

Or they don't care.

And I felt that because of their comments and so on.

I don't agree.

I would have left the whole team there because also Lucas was still the director of the initiative so the director of AsyncAPI was still there.

So it could have continued even as a marketing hire or as a marketing investment.

Now the thing is that my biggest mistake there was allowing myself to stay there to protect the rest of my team.

Don't ever do that because you can get to a point where recovering from the burnout is not recovering from the burnout anymore and it's recovering from the depression.

So because you are trying to you are trying to protect people that first of all they never asked you to protect them.

That's the first thing.

You're doing it just because you want to and you feel that you should be good.

That's like the saviour role like you want to save everyone from the pain and so on.

And secondly, they are very good professionals and adults and so on.

So when they were laid off nobody was like or almost none of them was like hey, let's rush out to find another job.

Most of them were like who cares?

Cool.

I've got holidays now and they were fired in June by the way.

So in the beginning of summer like it's been a year now.

So most of them thought like cool, let's just have holidays and proper holidays and so on and now slowly find another job at the end of the summer.

That was like I've been worried.

I've been worried for all these people when and yeah, they are sad that they've been laid off but they're not worried for their financial situation or anything like that.

So don't overload yourself with things that are not your problem.

Right.

If your team loses a job it's not your problem.

I know it's hard to say but it's not your problem.

Yeah.

It's their problem.

So it's something they have to solve, not you.

You can try to make it harder to happen but not at the expense of your own health.

That's what I would say.

Never at the expense of your own health.

And you're touching a very, very important topic which I didn't really expect to land in this stream which is mental health.

We discussed that offline that the industry is just a perfect hiding spot for a lot of people with a lot of different disabilities as in ADHD or being on the spectrum of autism.

A lot of the issues we're having we are having in our works especially also burnout and like the comment from you to Bright Hair will burn out middle name, right?

Is that common?

Yes, that's very common in the industry.

But it's common also not because the industry is burning us out or the bad leadership or bad management more likely is burning us out.

It's because we also suffer from ailments that we are not even aware because our industry and our jobs are great at hiding those.

So, for example, there are actual studies that certain industries like IT, events, etcétera are absolutely great at hiding ADHD.

People with ADHD can hide there indefinitely.

But that also means that they will suffer because they don't even know that their ADHD is causing them a lot of problems including that burnout.

So, as we're talking about mental health and as a person that I've been diagnosed this year with ADHD, right?

Go seek professional health help and dig into the topic because if you're having depressive thoughts if you're having a burnout that might be just the symptom.

That might be just the symptom of the fact that you have ADHD and it's wrecking up your life because you left it unmanaged for too long and you're overburdened with certain things and it starts kicking you in the butt.

If you're overstimulated constantly if you're constantly feeling overburdened if you're constantly feeling tired there might be something more to that.

It's not only your imposter syndrome kicking you down it's not some sort of a depressive thought or something.

It actually might be something that was hidden because you work in IT because the amount of changes you need to go through oh man ADHD people love changes.

If the environment changes around them in the fast-paced yes I'm really great at that right because I have ADHD we love those changes but then you don't realise that you actually have that.

You don't realise that your brain works a little bit different you kind of think that oh everybody has that everybody everybody's brain works the same way.

no it doesn't that's not normative that's neuroatypical so for those finding themselves in what Fran just said about burnout about depression about having that kind of a a little bit of a saviour syndrome because what you described in protecting your team was kind of that saviour syndrome there.

Take a look at that.

Dig into the topic.

If you're feeling burnt out, if you're feeling depressive and you feel like it's because of your work, it might not have nothing to do with your work.

Your work might be contributing to the state you are in, but you might be just neuroatypical.

And that's also perfectly fine, but go to a specialist.

Yep, exactly.

I agree with that.

And that links back to what I was saying that this psychological safety and organisations, like it's not just for experimenting.

It's not just for, you know, for adopting a new technology and so on.

It's also for feeling this burnout, which by the way, I would like to clarify, burnout is not a clinical term, right?

This is a beautiful name we invented to describe depression.

So that is depression, right?

So when you feel burnout, depending on the stage of it, you might be in the beginning of a depression, you might be like straight into a depression.

So let's call it for what it is.

It's cool to call it burnout because most people are searching for this word, but let's call it also for what it is.

The clinical term is depression, right?

So search for help.

That's what I would say.

And yeah, and if you are a manager, if you are a team lead or something, or you're managing people, I'm not gonna say that you should be acting as a psychologist, because that's probably not your problem, again, but at least give them space for expressing their thoughts openly.

And if they need help and the company supports it, like for instance, paying for the treatment, paying for the therapy sessions.

Paying for coaching, ADHD coaching sessions.

Paying for holidays.

Like for instance, I remember a friend of mine, like he was in my team.

He was, I immediately detected him to be like, like super, like about to collapse, you know?

And he was not taking holidays because in his own words, I have to finish this.

I have to, and I said, no, no, you don't have to.

It's good if you do it.

It's good if it happens, but you don't have to.

You don't have to finish this.

We're an open source project.

It's okay if you need this for the community to complete it, to contribute and so on.

And if it doesn't happen this summer and it has to happen next summer, that's completely fine.

We're not a product company.

We're not trying to sell anything.

We're building an open source project.

So if something is not developed as fast as you like, then maybe we should focus in inviting more people to join our community and contribute more, not you doubling down the hours and the effort you put in, right?

So, and I sent him like four weeks straight into holidays, like finish whatever you have a time today.

Tomorrow you're on holidays already.

And I don't want to see you connecting for weeks, right?

He came back recovered and with a mind clear like shit, I was like so deep into this that I was even like believing that this was all my responsibility.

Yeah, down the rabbit hole you go.

Down the rabbit hole exactly.

And so this is something that I also ask managers whenever they detect this kind of things, protect your team, don't protect the company.

Right.

I mean, if you protect your team, you're going to protect the company anyway.

So, but don't look up, look down, look to your team, protect them, right?

Because in the end, the company is going to fire you someday, right?

You're just an asset that is easily removable.

Whatever company you work for, they're going to either you're going to quit or they're going to remove you.

So protect your team because they're probably their colleagues as well.

And also for humanitarian reasons, don't let people suffer for the sake of just a few millionaires, right?

I don't care about that, but I'm a little bit punk here, I will say.

But you know what, from my own experience, when I learned that I have ADHD and I started sharing and talking about that with people, and I told that over a team meeting with my previous employer.

And that was very interesting that all of a sudden I had pings on Slack from people I didn't even know at the time in the company.

They were like, hey, I heard you have ADHD.

I also have ADHD, but I haven't come out of the closet.

Nobody knows, but I want you to know because you have ADHD so you'll understand.

And there was so many people that didn't feel psychologically safe in the company to be themselves and to be open about themselves.

So instead of being open about themselves, we just basically created an internal community of people with ADHD.

And that worked to an extent because we started doing body doubling sessions, etcétera, to just help us work through certain blocks, right?

You don't feel alone as well.

And then you feel that you belong to somewhere, right?

But it's very difficult.

The psychological safety topic is a very broad topic.

And there are so many reasons why somebody might not feel safe psychologically in a company and then act out based on that lack of safety and create even more troubles in the core topic that we were talking about, for example, so adoption of event-driven.

Yeah.

Yeah, so let me get back because I was reading the comments.

And we have some questions.

We have some really good technical questions.

And I think we can jump to another point of a discussion, meaning the evolution of AsyncAPI, which some of those questions would be very fitting.

So let me quickly scroll that up because I found one that was somewhere at the beginning of.

Yeah, Aleksandr, I have first question.

Yes, there we go.

Yes, cloud event specification.

If it's, you want to reply?

Go ahead.

I mean, it's about included as a recommendation to AsyncAPI.

I have nothing to do with AsyncAPI at this point.

I'll say it's mature enough, yes.

I'm not sure how widely adopted it is right now, but I think I see it more and more, which is good.

So everything that, whatever it is sticking to standard is always good.

So I always celebrate that.

Now I must clarify something.

Some people think it's either cloud events or AsyncAPI, and they are complimentary.

We actually tackle different problems, right?

So I wrote a blog post about it in the AsyncAPI blog, because I found out at some point people were like, even like throwing fire at us, right?

Like, hey, come on, say something bad about cloud events.

And some hot take about it.

And it's like, no, I'm not gonna say something bad because I always recommended myself.

I was, when I was consulting with Adidas, I was helping them to adopt AsyncAPI.

They were using Kafka as well, and they were already using cloud events.

And I saw it in action, and I think it's pretty cool.

So let me clarify.

So cloud events, it's defining a, what's it called, like the envelope?

The envelope of the data, right?

Pretty much, it's not exactly that, but it's pretty much the envelope of the data.

I think about it like enveloped in the post system, in the postal system, right?

You don't send your letter straight away, right?

You put it inside a letter, right, an envelope, sorry.

And then you send the envelope with the letter inside, right?

So that's pretty much it.

It's like, it's a common envelope.

It's a format so that all your messages across your system, they all follow the same structure when it comes to metadata.

When it comes to specific data, then each one is different, right?

And not even cloud event patches in that point.

Cloud events has a field that it's called data, and this is free form.

You can put there whatever you want.

Now, the funny thing about this is that AsyncAPI helps you define, helps you define the communication, not the communication, the messages that your application, let's think about microservices, for instance.

Your service is sending and or receiving from a topic, from a broker, from so on, right?

You define this communication.

But when it comes to defining the message itself, the message piece, there is a field called payload, right?

And this one is free form.

So we don't dictate how the payload of a message should look like, right?

This is free form.

You can put there whatever you want.

Actually, in the JSON schema definition, this is, the value is true, because we always want to pass the validation.

Like, we don't validate it.

It's always, whatever you put there is valid, right?

We don't want to get there.

So there in the payload is where, payload and also headers as well, is where cloud events belong, right?

The envelope and as the envelope of the data.

So actually, I think there's a pull request or an issue discussion right now in AsyncAPI.

If I recall correctly, something I started at some point, I want to integrate the two standards in a better way.

Like if you're using cloud events, you should be able to somehow natively say it in AsyncAPI.

I'm using cloud events.

The format of the message is cloud events because the cloud events format itself is then going to tell you which format your data is in.

Is it XML?

Is it JSON?

Is it following certain schema definition?

So it will be cool if they could, you can already use both together, but it will be cool if it could be blended even better, right?

Right.

So, so yeah, so that is

Just to be clear on the article, because I did some quick Google searching, would that be somewhere around May 2019?

Yes, but the thing, I have to update this article at some point.

It's not exactly how it's done anymore.

But you see, like six years now, and I was already recommending this.

Yeah.

So that's the original article to be updated.

I see the differentiators in the description is there, as you just said it.

Maybe there would be probably some discrepancies over the past six years because things have changed, but that's pretty much it.

At this point, I was exploring and telling people the different ways you could use both, different ways to use both.

Now there are, let's say, best practises for using both that are not described in this article, because now in version three of the spec, things have changed a little bit, so now it's easier.

We have traits.

I think we had traits at that point, but there are other ways to do it.

Honestly, on the top of my mind, I don't recall how people are doing it right now, but there are, let's say, best practises.

So, yes.

All right.

It's not like that, like I described in this article.

Yeah, but, you know, things change.

Article has six years.

That's only obvious that this will no longer be fully up to date, so, yeah.

It will require a little bit of a fixing up in that sense.

All right.

Let's see.

There were some, I think, oh, quite long questions from Maksim.

Really a packed one.

Best practises for designing data models for messages.

Ooh, that's a, ooh, la, la, la.

Canonical data model.

That's packed.

My personal take is I'm not a fan of canonical data models.

Never will be.

I've seen that happen.

The larger the org, the worse it gets in canonical data models.

Or if you do it, you do it as an afterthought.

So, after you've been having, let's say, probably hundreds or thousands of message types, and you notice a pattern, maybe you standardise it.

Because you make it a pattern, because it's already a pattern anyways.

So, cool.

In that case, cool.

But if you do it up front, you're probably gonna be restricting yourself.

And unnecessarily.

That's where I am a fan of domain-driven design and bounded contexts within interoperability topics.

Exactly.

Because then we can define each object several times for each bounded context or each domain separately.

So, a definition of a customer in terms of a customer domain will be a different customer defined in the order domain.

Yeah, correct.

Different attributes, even that's still the same core object, core data.

It's still the customer, yeah.

But it's a different representation of the data, yeah.

Different context of usage, which makes it better.

I will link it to the previous question about cloud events.

It's needed.

So, I'm seeing many people defining their canonical data models using cloud events as well.

Because cloud events is extensible.

So, you can add your fields, your own fields, whatever you want.

So, you just have to respect certain fields that are mandatory, I think.

Maybe one or two are mandatory, if I recall correctly.

The rest are just optional and you can add more of your own.

So, some people are opting for that.

It's not exactly a canonical data model, but it gets close.

Yeah.

And a twist, which is a lot shorter of a question.

Sharing resources data models between OpenAPI spec and AsyncAPI.

Ooh.

Many people do that, yeah.

I think that's, in general, that's not a bad idea.

Especially if you're having a integration platform, and especially in API-led architecture where you can actually do the domain partitioning.

And some of your services are, at the same time, synchronous and asynchronous, because you have a lot of orchestration and different things are happening within the composition layer.

Yeah.

That means that that sharing would be actually a very good thing.

I actually recommend it because, and actually, the reason why AsyncAPI is so similar, it's still so similar to OpenAPI, is because we want to be, both of them, as interoperable as possible.

To be, as a fun fact, while we were designing version three of the spec, that is, it's the current version of AsyncAPI, we were even considering if there could be a way to make it not the same as OpenAPI, because we were already convinced that we had to change certain things in the spec, but to, in coordination with OpenAPI, which we are always in constant touch, the two communities, right?

So to tell them that, hey, we're going in this direction because of this, this, and that, we're putting operations on the root level of the spec instead of inside the channels, or like, for instance, if you're familiar with OpenAPI, they have the operations, get, put, post, and so on, inside the path, right?

Yeah.

Instead of at the root level.

But there were some, already some people in the OpenAPI community saying, we should move the operations to the root level and then link them with $REF and so on, right?

So instead of having them nested inside paths and so on.

That's the direction we took for AsyncAPI.

So operations are now in the root level as a first-class citizen, as people call it, right?

And we were thinking, if we managed to convince the OpenAPI folks to do the same thing, at some point, we could even, if not converge into a single spec, we could build really close, really, really close, right?

Right.

But this is a philosophical problem because if you look at the days of SOA and SOAP services, SOAP had a very different philosophy because SOAP was primarily used to build business services.

So they didn't represent an object, they represent a function.

While if we're looking at REST, REST by nature is supposed to represent an object and functions on that specific object.

So moving the operations down to that level would shift back to, kind of shift back to business services rather than representing objects.

And that philosophically might rub people the wrong way when we're looking at these kinds of services.

Of course, this would be against REST principles, right?

That's my point.

So OpenAPI is not a spec for REST APIs.

It is not.

Very true.

But the underlying philosophy is coming from the REST specification.

Yes.

The thing is that it's, I will call it like it's for HTTP APIs.

That's it.

Sure, yeah.

In most cases, I would say it's just a resource-based HTTP APIs.

And in some cases, it's RPC APIs.

Like you will do with GraphQL, but instead of GraphQL, you use your own syntax with endpoints containing the action and so on, which is pretty common as well.

But that would be a very interesting evolution to actually see that shift back to that.

My point with this here is that we are, we've been trying.

We're not trying right now, but we've been trying.

The thing is that this is a little bit like forcing the things to match together when they are not the same thing, right?

And it's not even representing the same kind of world.

So it's a different thing altogether.

Now, whatever can be reused, like schema definitions and so on, they're still the same, mostly the same.

Actually, not the same.

You can use, so OpenAPI uses the latest JSON schema draft.

But the most used OpenAPI version, which is 2.something or the three, I think it's still 2.something. It's still swagger.

The most used.

It's on JSON schema draft four.

You can use any of these schemas versions with JSON KPI for that very reason.

So they were interoperable, right?

So yeah.

So we actually recommend it because it's a really good idea because think about it like, or picture this example.

You have a REST API or an HTTP API, you receive a request, and as a result, you publish a message to a broker, right?

As a result, as a side effect of this request, you publish a message to the broker containing some information that was in the request body, right?

Say, for instance, you are signing up a user or something like that.

I mean, that's a very common use case in API led architecture where you have the channel layer, the first layer, or as in MuleSoft, they call it the experience layer.

You basically call a REST service, and then that translates into a synchronous call forwarding that event.

The request is actually a disguised event, and the only reason why it's done over a synchronous call is because we want to give back the information that it was accepted for processing to that system so that system can move on.

And it's easier to consume a HTTP API than to figure out how do we connect directly to the broker from each separate team to learn that broker.

And then you move that complexity to the integration platform to learn how to use the broker and facilitate that use.

So that's a very common use case.

And also a common use case is right now popping up in API managements where they offer protocol mediation to mediate from a REST call to an event or from an event to a REST call, like a webhook.

In fact, if you are building with a mindset of microservices, you might have an API that is a REST API or an HTTP API that receives a POST call, let's say, slash sign up, whatever, sign user up or whatever.

This microservice might have its own database where it stores the user that just have signed up right now, right?

And as a result, either the microservice or the database triggers a change data capture event, right?

To the broker saying, hey, there's a new user in the database for whoever is interested in this, right?

So this is very useful.

And it's constrained to this.

It wouldn't even make sense for people to connect to the broker to consume this kind of events from a browser or something like that because why would you?

You want to have immediate feedback, right?

You want to have immediate feedback if the operation succeeded or not.

And you have the database there, you don't have to send the message to some other system that will process this message at some point and will come back with a response.

No, no, no, it's just here now.

It's either saving it into the database or not.

Cool, give me the response immediately.

So that makes sense.

And then post this event for whoever else, let's say, welcome email, analytics, whatever.

Any other reason you might want to know that a user, when a user has signed up, right?

Yeah, that's an issue of system responsiveness as an architectural characteristic.

So it doesn't really matter if you put that in a database for sourcing later or you put that on a topic with a persistence.

You go on with your day, but the system goes on because it gets a response or an acknowledgement that something was published.

It doesn't matter then how it's later processed.

And that's the lovely quality of putting the event broker as a transition between two systems to decouple them on that.

Oh my God, time coupling, temporal coupling.

So in that sense, it's very lovely.

It's very useful.

All right, Fran, we've been talking for the last one and a half hour, well, nearly 1:40.

And if we stay here for two more hours, we can keep talking.

Oh, we could go on and on and on and on and on.

So dear audience, I see we still have an audience.

That's awesome.

That's awesome, yeah.

That's awesome.

Some people stay with us years.

Yeah, I love it, I love it.

So kudos to all of you who are staying still with us and still watching us.

If not, you can always watch the recording.

Before we jump into the QA, I would like to have some announcements.

And one of the announcements is that we already have a second live stream planned.

And the second live stream is not gonna be about tech.

It's gonna be about recruitment, which I think it's gonna be very, very interesting.

We're gonna be talking with Gabby Preston-Pfeiffer and Philip Poynton.

They're really well-versed people calling out the bullshit in IT recruitment.

So, you know, jump in on the 22nd of July to hear them out.

And also, I'll reiterate some things.

So if you wanna read some articles about enterprise application integration and EDA included, visit bridgingthegap.eu.com or just subscribe to our substack for the sake of it.

And then if you wanna learn more about AsyncAPI, visit the initiative site.

And if you got hooked on our conversation about the organisational problems or the psychological safety of people and you wanna be a better leader and you wanna actually start addressing those topics, here's a QR code for Fran's book.

It's still in the making, but Fran is giving the early bird available so you can take a look and read it, comment it.

I think, Fran, you would welcome all feedback, right?

Yeah, actually, it's already happening.

We're having discussions in Notion about, not a lot, I must say, which is normal, like reading a book and leaving feedback on a book might feel intimidating to some people, not just because of technical knowledge, but also like this guy might think that I'm here, I'm bothering him or something.

No, no, no, like I'm used to having, to getting feedback, respectful feedback obviously can construct it.

And we're already having some discussions there in Notion with the early readers and it's cool.

I've only written three chapters so far.

If everything goes well, I think there will be 23.

So yeah, I only have to write 20 more.

No pressure.

No pressure.

You're gonna lean pop the hell out of that.

I'm gonna be like lean pop, but a notion, right?

Pretty much the same thing, only different medium.

Exactly.

But yeah, I'll take off.

I'm taking August off, like from the rest of the work, just to focus on the book and most likely September as well because I want to have it ready by October this year.

I hope these words don't bite me in the future.

Like you said that last year.

I mean, if I don't publish it by October, bear with me, please.

It's my first time writing a book.

So I don't know how to estimate this kind of work because I've never done it.

It's difficult.

It's difficult.

Yeah.

But yeah, and especially because I'm finding things that I never expected, like having to read papers, you know, about psychology and psychology books and interviewing psychologists and so on.

That's difficult.

It's going completely unexpected route.

Which is exciting because you're learning a lot while doing that, so.

That's why I'm writing the book.

Like I'm writing the book for me, like I did with this in AsyncAPI.

It was like, so I can learn properly about this by writing it down, right?

And by interviewing people and by listening to their stories and so on and then sharing with people.

So who knows, maybe in a year or so, I'll have to write a second edition because I made a lot of mistakes.

Who knows?

I mean, I just looked through the lovely Fundamentals of Software Architecture by Mark Richards and Neil Ford.

They just released a second edition.

Completely different read.

I have the first edition somewhere.

Oh yeah, like right here next to me.

I stole it.

It was still useful there.

The first edition was still useful, but now with experience, then you get to make a better book.

It doesn't mean that the first edition is gonna be wrong.

It's just that it's probably not gonna be exactly how I want it.

Yeah, they learned a lot and they were like, yep, definitely.

Cool, man.

Yeah, all right.

So that said, oh yes, the QR code for the early reader to get access to the book.

So yes.

How that one, sorry, should have deleted the original shipped one from the list.

It would have been easier.

So if you wanna be the early reader and leave friends and comments, just scan the QR, go ahead.

Yeah, it's not a large cost to just join on the process of building that book from scratch.

It's interesting to watch, believe me.

That said, we're gonna be closing the session in a moment, but that leaves us open to any questions.

Any QA questions out of the box, out of the blue.

I mean, we do have one from Aleksandr.

End-to-end traceability, batch message splits.

I can take that one because I've seen that one.

I'm not an expert in traceability, but I know some, I mean, you can take it because.

Yeah, it's actually not that complicated as long as you have proper logging, monitoring and observability within your systems.

So basically if you wanna trace your events and you have this kind of a batch scenario where you split it up, you need to just make up a specific pattern, which means that you have some sort of a correlation ID.

And then when you split it up, just append that correlation ID with additional identifiers of those individual child elements.

And that makes that traceability really pop.

So you can still search all of those elements by using the original batch identifier, the correlation ID there, and then you can search individual child elements by the appended identifier.

So that will be sufficiently unique because if you use UL ID, that will be very unique, very nice with a timestamp.

And then if you append, you just append, that's not a big problem there, right?

So that's a good one for that.

And you can define it on AsyncAPI using the correlation ID field on AsyncAPI.

So it's covered.

Yeah, exactly.

That's a good thing.

And that's also a very standard thing to do in the OpenAPI spec as well to define those metadata and correlators.

Usually for OpenAPI, that's within the HTTP headers, right?

So it's workable.

It's just a matter of figuring out what the mapping is between those, right?

All right.

I know we do have a little bit of a delay between what we see in the stream studio and what is out on LinkedIn and YouTube, but I think we already passed through.

Yeah, and if not, people leave some questions after.

Maybe people are watching the recording.

If they want to leave some questions, ping me or ping Karol.

Yeah.

And if I don't get the notification, please Karol, let me know.

And I will reply after that.

So it doesn't have to be.

We can make it asynchronous.

Yeah, we can make it asynchronous, exactly.

So for all of you wondering and willing to share the stream, or if you found it captivating, the stream will be saved in a raw form on LinkedIn.

It will be also available on Bridging the Gap YouTube channel.

I do plan to do a little bit of touch-ups here and there over the stream and release it as a normal video.

But for the moment, it will be available as a live stream recording on YouTube.

So you can always come back, re-watch it, figure out what you want to hear, and ask additional questions.

If I find those in the comments somewhere, I'll make sure to relay those to Fran if you don't tag him, and then we'll draft an asynchronous answer to those.

All right.

That said, because I don't see any more questions popping in in chat.

Thank you all for attending.

Thank you, Fran, for coming to the first edition of Loosely Coupled.

Absolutely amazing having you here.

And.

Thank you for inviting me.

You're welcome.

My pleasure.

And everybody, have a lovely evening, rest of the night, wherever you are, maybe rest of the day.

And till next time.