AsyncAPI AsyncAPI Conf 2022, 3 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Adopting AsyncAPI in Enterprisey Contexts - Daniel Kocot, codecentric

Description

AsyncAPI Conference 2022 - Day 1
3rd November 2022

When working on API enablement projects in an enterprise context, the team relatively comes to the point that new technologies and specifications need to be introduced. But how does one deal with this situation in concrete terms? How many experiments are possible? How do you put the brakes on the emerging best practice euphoria? I would like to address all these points using AsycAPI as an example. In order to enable a kind of golden path that helps us to deal with such enablement situations in a more relaxed way.

A

A

Api in Enterprise e-contexts, so, as you see we're moving into the Enterprise, my name is Daniel coz that I'm working for code Centric in Germany as a head of API experience and operations and also I'm a senior solution architect there. If you'd like to contact me just use the email address, spot it there or go to Twitter or go to LinkedIn what you ever like. So you can find me there. You find maybe a lot of things about what I'm doing there and maybe we'll get in contact, but first challenges of Enterprise this.

A

So when we are working with Enterprise companies, we see a lot of challenges actually, not only in regards to apis or anything like that. So it's it's really more about there's a lot of things moving on, so we have a lot of complexity there, so very complex systems, normally something like sap involved or any other systems around. So if there's a lot of things around, there are a lot of tools actually there. So every team uses its own tools, so we are missing a lot.

A

What we might be needing for having and the teams actually have a lot of ideas, but these ideas are totally different to things on Persons you find normally in Enterprise. So when you look at an in at an Enterprise in an I.T Department, you always find these Enterprise Architects there. So they have their own view on things and things they will and they think they will always write what they do. So they don't really trigger the needs. A team has they always just focusing on what is the status and how to keep the status available.

A

So there is no real Innovation or something like that. So we're really moving into things that we need to to Really move on and every team all the teams there are looking for yes, some kind of solutions, so they want to get faster. Actually they want to have the opportunity to to really move on to to learn or to do the things actually that are all proven by others, so that we really can think about and say, okay yeah. This is what we really like to do, but not the really old stuff.

A

Maybe in some kind of Legacy part, so in this case Legacy is nothing really ugly or something like that. So it's really thinking about the stuff that always existing there so doing things with the existing yeah systems around actually so really focusing on Solutions and normally, when teams think about solutions, they always have apis in mind, so they really think about how it is like some kind of puzzle pieces or when you look at Gardener or not any other technology analysts in the market.

A

They always talk about something like composable Enterprise and anything like that, so that we really have puzzle pieces, as I said, to put together and make things available.

A

So this is the this is the trick behind doing doing things or what the team is really like to achieve in the end, and sometimes it happens that people misunderstand or have have a misunderstanding actually of what is an API I learned a lot of things from talking to Enterprises here in Germany, and there was always this quote: everything is an API, so a lot of people are worth thinking.

A

Okay, everything must be an API which is not quite incorrect, actually to be honest, but it's yeah somehow hard to to say something like that, because when it comes to the upper level, so we're getting more on the sea level side when there are something pops up like everything, is an API.

A

People are some somehow concerned about this, because sometimes there is no need for an API because we're just delivering services in the field of of integration or stuff like that. So there is no API available, there's just a service running, but this is something to really reconsider and you can think about this.

A

When you have a deeper look into things of governance yeah, you have to be very hard in governance and very quick and moving on into towards the things what we have in in yeah, API governance or service governance and all the things that are that are actually around to to really think about it and make sure that every team understands what is the standard the organization would be would be like to follow actually, and then you have the possibility to really evolve.

A

Something really really big, because in the end, when you think about apis when you think about Solutions, you have to be very fast. You can't say: oh yeah, we delivered this in three months or so so it's a really short time to Market. So you really have to be aware of what is happening there. So you need a lot of governance actually to to really make sure that people do the things right, as you already talked about with them.

A

Actually, so it's really something you have to achieve to to really move on and to really think about what is what is really needed? Actually in this in this case, and for that you again need a lot of tools. Actually, so there's nothing that you just buy uh one size, fits-all solution. You could do that, but it's not really helpful. Actually, because when we, when we talk about this, we we are here at the Asian API conference. Actually, so we have a different type of apis.

A

So this is something where we have to think about. So there are a lot of yeah API interaction patterns as I always talk about this and there's a lot of tools needed actually to to Really involve this this API package as a whole. Actually, so the thing is when we think about again and the solution part the teams. What they would like to achieve is really adapting apis, but the thing is: how can they really do this?

A

What do they need for and what? What is the purpose they would like to achieve in the end? So just saying yeah, we need apis yeah for what what would you like to achieve in the end? So this is really the the thing about the purpose, so you really have to think about.

A

I need something to enable the teams to really think about apis, and it's really a good start to think about this. This API enablement to to have some kind of framework for this or or process, or something to really make sure that the people follow these I wouldn't say guidelines, I, wouldn't say also wouldn't say, process that they really follow. Steps to really engage over time to really bring value. To the company, because in the end these apis should stay forever, but there will evolve over time.

A

So there will be changes we can really think about. So they will be also breaking changes. Yeah everybody's aware of this out there, when there shouldn't be breaking changes, but there will be because sometimes we don't take the right decision at the right time. This is quite normal and in the end, forcing teams to really think about this API enablement in this Enterprise context.

A

It's really good because in the end, it's all about documentation and normally, when you, when you, when you think about apis in Enterprise context, it's always about restful restful is at the beginning. Everyone everybody wants to have a documentation of what is available as restful apis, but nobody really talks about restful apis. In this case, they're saying ah we we have apis here. So it's really, starting with with the restful stuff over time. There's something happening because there's a lot of Technologies around we I talked about that earlier.

A

Actually so at some point somebody pops up and says: oh, we have also events and messages and normally then something happened that somebody says: yeah, I read a blog post or something about that. So I read about that amazing API is the rescue for it, so everybody wants to use a zoing API to yeah, whatever describe things in regards to this asynchronous conversation stuff, actually so everybody's. So oh, this is this. Is this? Is the the Holy Grail?

A

We have to use it, but when you talk to the people directly, no one really understands from the beginning what what it means actually for for a lot of people. It's just another description, standardization or whatever, but when they look deeper into this, they see. Oh, it's a little bit different. What we see from the open API side, so we we have to think about more that we need more knowledge on knowledge on the back end.

A

Actually, so it's it's not about just having things done with open, API yeah, it's easy to start with async API, but but having this context, and normally you have this department type of style. When you, when you talk with Enterprises, you always have to get them all with this API enablement to to really make sure that they follow all the guidelines.

A

An API enablement team puts up actually so this API enablement team is to be always on top of them. Actually. So when, when you think about when we see this async API stuff and see that we need more knowledge on the back-end technology, it's a totally different approach. What we have with open, API, actually with open API, we just write about a contract or describe a contract between a provider and a consumer on the other side. Actually, so they both know each others other, but the provider doesn't want that.

A

The consumer does have any knowledge about what is happening in his back ends, actually so he's just providing this contract and as a whole. So he's always talking about the contract. With the with the consumer and saying ah this is the contract you have actually- and this is what I provide to you- you can use it. Does it fit to your needs or do you need something different and in the end having these apis, which which are just Vehicles actually to transfer transport actually or transfer um some kind of data stuff?

A

It's really something you you really have to think about, because when you now describe things where you need a lot of knowledge of the backend technology, it's really hard for people doing this API enablement or being enabled to use apis to really understand the difference at first sight.

A

So it's really something you have to move very slowly and very slowly forward actually to to make sure that everybody understands so in the end, when you think about to to yeah, to describe things or to describe your architecture with async API, it's a totally different approach, because you have to know to to gain knowledge about the back-end technology.

A

So, in the end, when you force the teams or would like to have the teams describing their topics or whatever you have when you use Kafka or when you use mqtt or something like that, you have to specify design principles and also libraries to cover the needs, and this is really something which which is a really step forward, because in regards to open API, you can always specify design principles. You should do that, but you don't need libraries.

A

These libraries will come up over time because a lot of teams do the same things or you have some kind of error codes, or something like that that you would to provide in library actually. But you are not needed to in this case, you you. You have to actually have these libraries, because there will be people that just use the technology to provide events and messages, but they don't have any insights about what does the technology really do or what is consisting of?

A

Actually so they don't have any of these about a Kafka cluster or anything like that. So say just using the things- and in this case it's really needed to think totally different, say: okay before we do, we follow. We really do that. We have to really specify things and we have to deliver libraries in this case really design, libraries saying okay: this is what you need. You just can reference to it, which is possible within the open within the async API specification. So far,.

A

So in this leads again to another step, to be honest, maybe to automate things in the end to really to really rethink what we what we've done, because normally it would be better to have something like code first. So there are some code, first type of type of tools available actually for the for the async API stuff, but that might be not the needs for an Enterprise, because the Enterprise is not thinking and having spring boot having c-sharp or anything like that, they just need an overall thing type of thing.

A

So this is what what I'm really thinking about when I talk to um tutu and to Enterprises actually to really.

A

We need an automation that that is slightly code first, but not really code first actually, but it's something that is not API first in this case, because API first would only work with the people who really administrate or do the operational stuff with uh with the um yeah, with the components in regards to your synchronous apis actually- and this is really what something, what what really comes to to my mind when I'm really think about this is this is actually my opinion.

A

So when I think about what might become next, this is just an idea what I have in mind. Actually it's not that there's something still existing or that there is something that you should do or anything else. It's just my opinion. Actually, to be honest, and for me it's it's really something to to really think about that. There must be a need to to Really use tools that that really admire this. This Library this principle stuff to really make sure that people can do these API definitions in an easy way.

A

They should not hinder them to really uh think about what is needed and and what what they need. They should support the things that they would like to achieve. In the end, this is really what must happen to to to bring to bring value to the whole topic, actually not to say. Oh, this is an another specification. Oh we have another technology. This is what you should use and uh how your message should like and is really thinking about.

A

What is what is needed on the developer side to really also understand what I am I using there when I have to describe the the topic that I provide to to other consumers actually and and that they could use this and that we have value within the company to to Really present data with with this topic and so on and so on. So it's it's really thinking about as a whole, not to just saying oh yeah, we do we do open API. Now we do async API.

A

The next step is we do something to live in the graphql and all the stuff to really think about what what is the? What is the purpose and what? What is the value we achieve by creating a zoom, API specifications or definitions in in this case? Just what? What is the purpose for for the company and what is the purpose for for the users to see what is available and- and this is something we we really have to think about for all this, we need to specification.

A

There's there's no thing that we can really just discuss about. We need a specification to be more sufficient in describing asynchronous apis.

A

There is there's no need to to discuss this or or already or in any case, it's really about more thinking about how to adapt the possibilities I have- and this is in somehow my closing words with with this uh short presentation. I should be honest. I would have more time actually, but I I wouldn't stress it too hard, because it's it's quite quite late. Actually- and this is what I leave for now, it's more something to to Really rethink off, and maybe we can start a discussion about it.

A

So wrapping this up, you find a lot of informations by using just the link tree. You you see here in in the slide tag, and if you like, you can contact me via Twitter or LinkedIn, and we have a purely full discussion about what I what I actually talked about is just my own idea of things that could happen in some ways. Thank you for listening to my talk and enjoy the rest of the conference. Thank you.