Friday, May 27, 2022

What’s the Difference Between APIs, Services and Microservices?

Hi my name is Alan Glickenhaus I'm the IBM API business strategist probably the question I'm asked more than any other one is what's the difference between api's and services this is especially asked by those people who have spent the last 10 or 15 years working on service-oriented architecture and services so I thought we'd record a .

Video and just finally answer this question once and for all and I threw in micro services as well which is a new topic that's come up that we get asked a lot about the positioning as well so first of all from an API perspective so this is our definition chart for API as we talk about API is application programming interfaces and really the .

Term we should be using is business api's or web api's we're distinguishing business api from the traditional technical api that has been around for decades these are business assets that we want to make available in a self-service manner for a particular audience and so we want to package these assets up as a consumable entity that we .

Call the business api and market this to an audience which is an app developer that's going to consume this api and use it so business api is the context of what we're talking about with api's my previous role at IBM I was on the service-oriented architecture came for IBM and I use this chart a lot and so we talked about a service as being a .

Repeatable business task something like check customer credit open a new account and so that sounds a lot like what I just said in API ones and so there's a little bit of obvious reason why there might be some confusion in fact it gets worse if you look at what we were doing with SOA and services we mostly were using soap but in the more modern times .

Have started to use rest there as well in API is we most often use rest but we could also use soap the purpose for an API I said was to exposed a business asset as an API and for a service we said to is encapsulate a repeatable business task as a service which sounds very similar and do they both do integration tasks yes they do so so this .

Is what's causing the confusion and it's pretty easy to see why that someone was very familiar with SOA and services might be confused by api's and isn't it something that they've already done and maybe this is just a new name for the same thing in fact what we've done is just look at what they have in common let's take a look at maybe some of the .

Things that are different right so in the SOA world the focus was on connectivity and Reeves we were building these services to drive reuse of these services so we had a single view of an entity a single view of a customer or single view of an account a single view of an order and anyone who wanted the information about .

That particular asset would come and reuse that and then we focused a lot on the connectivity of the different services in that in that environment typically inside the enterprise dealing with the systems of record the sharing was about effectiveness and cost were going to reduce the cost of future projects that we did in the enterprise .

And most of the audience that we were targeting the services for internal if we did make the services available to a few partners it was difficult to do that we had to set up the security and do some training for them to consume this this particular service and so it was not something we could do for the masses and the encapsulation aspect was about .

Less the change we were going to change what maybe was behind that service interface and we wouldn't have to change all the consumers of that which is again back to the cost issue the focus for API is is about consumption and speed to deliver it's about reaching new markets and the audience is internal but it's more often and going to be a larger .

Number of external users so while we might start with internal the focus is to get these assets out there to a much larger external community and it's really about less to learn and speed and consumption and that's really the focus for api's so if you think about these things working together the systems of record that are running at each of our .

Businesses today are critical systems that can't go down meet high availability high security we're going to have robust connectivity capabilities and that was done through an enterprise service bus like the IBM integration bus big level of focus on governance to be sure that we got the services right and that we didn't change them without .

Concern for all the things that we're consuming them possibly breaking if we made a change without testing it correctly so systems a record absolutely critical to not go down high security needs lots of governance now it won't come things like mobile and social and big data and analytics and these things are moving at .

An incredible rate of speed and I can't change the systems of record at that kind of rate of speed so to solve this problem and let the business do the things that they need to do quickly we're going to encapsulate these systems of record services as self-service API is that someone could sign up for and consume themselves we're going to .

Predefined the security aspects in the terms and conditions around that and make that available through an audience and a secure gateway that'll access these back-end systems and so the idea here is that the API is and services do work together they're not one is a replacement for the other and the api's will be accessing the services from the .

Systems of record but we can change these things and we can create them on a much more rapid basis and make these things available in a self-service manner so let's look at what these things have in different I have as differences and not just what they have in common so most of the time people who worked on services or provider oriented .

Services based on the system of record if you had a customer system that had customer data they might be one or more customer services that people would access and if you needed customer information you would come to the customer service so it was a provider oriented service same thing for the account for the inventory for the .

Shipping system any of these systems might have services that represented what the system did and those would be services that you would access to access those back-end systems of record the API is our consumer focused and if you think about what a consumer might do with the back-end services they will access potentially more than one service in a .

Scenario for example where I want to check my order status I might have to check the customer service I might have to check the inventory service I might check the system the the shipping service all in one API call and not have three separate api's for that person to do that so one consumer oriented API might call three or more back-end .

Services to come up with the answer from an integration perspective while they both do integration away and services were very focused on integration and had a complete robust set of connectivity capabilities integration is not really the primary focus of api's we want to take an API call and get it into the backend as .

Quickly as possible it's about securing that and making it perform very well and and and making it consumable it's not about complex integration we do need to do some integration to get the API call to the backend and so that minimal amount is done as part of the API solution why do you care connectivity and reuse is what .

We talked about for services self-service consumption security analytics and speed for API s and finally for services the focuses for governance is very strong and for API is it's really just enough we need to be able to move very fast in the API space to get to market very quickly so there is a difference in perspectives and use .

Cases for API as far as the services really the best scenario is that we're using these together so three questions lead to good API is the first question you want to ask yourself when you're thinking about what API you want to create is who is the audience what what what audience are we talking about is this an internal user that is going to .

Build a mobile app or use it somewhere inside the enterprise is a partner I mean making a public API the second question probably the most important one is what do they want so we're focusing on that consumer what do they want not what do you have we're not going to put an API in front of every service that we have and just say to the audience you .

Figure out how to make these things work together the better API is are going to be consumer oriented and map to my potentially multiple back-end services it might be the case that we're going to call one one back-end service and that's fine but let's not focus on what we have as the things that are driving the API .

Creation and then the third question that we're going to ask is under what terms and conditions are we willing to share and this deals with the security around the API who's authorized to use it and also the policies around the API rate limits how many times per minute our second whatever it is that we want to make it available and so we'll .

Understand what conditions we want to make this available to them and that's what leads to good API so after we've answered these questions of course then we have to build the API and we're going to map that what do they want to the what do we have but that's not something that should drive the creation of the API itself so let's talk a little .

Bit about how micro services fit into this traditionally every project that we've done for the history of computing has three components to it there's some kind of a user interaction in some way whether it's user interface or something that a user is going to interface with the new project to tell you what they want to do there's going to be some kind .

Of business logic that they deal with that is going to make the decisions on what should happen and then maybe some data manipulation on the backend some updates or some reads that are going to get done to access and massage the data in some way and as we did these projects we thought about it from an antenna perspective and we delivered that .

Project as a whole and that would take a certain amount of time to deliver whatever amount that was we needed all the parts to come together to deliver the project successfully with micro services what we're going to do is do the exact same thing but we're going to break it up into the component parts so each one of the parts the user interface .

The business logic and the data manipulation can be built separately by individual teams on a separate schedule with the idea that these will be working together but also that others might use them as well so if you think about this a mobile app let's say is being created has a user interface it's going to call in and do some business logic and do .

Some data manipulation and maybe that's the first solution you come out with but the second solution might have the partner doing something that's going to invoke that same business logic and that same data manipulation in this case you don't only use your interface someone else does and you can come to market much quicker if you built this on micro .

Services as an architectural style rather than as a whole monolithic project and really that's what the trend would microservices is let's think about the components that we can build together in consumable ways so that we can do projects faster and still get great results for the enterprise so how does that work with api's so the micro .

Services can be built either in the systems of record or in front of the systems of record based on your needs and add the business logic for the you interface if you want to do that there for the business logic and for the data manipulation and then you'll control the access to the micro service through an API layer that makes that micro service .

Consumable by the audience that you want to consume it so if you're making it available initially to the internal developers for the mobile app with the web that's great and then you want to make an API available to your partner to consume that same business logic that's fine too and you can have different terms and conditions for each audience .

And so really that's how API is and micro services will work together with the services in the systems of record to provide a complete solution and it gives us tremendous amount of flexibility it gives us the control and the availability for the systems of record while giving us the speed and consumption and security that we want .

From a an API layer and so think of an API as a managed micro service and you're good to go for bringing these things to market hopefully that helped to answer this question once or for all I'm sure it's not the last time I'll be answering it but I'll be pointing people to this video so they can see the answer for positioning api's and services and .

Micro services Thanks

RELATED ARTICLES

Most Popular