It still surprises me just how many times I come across misconceptions around Micro Services and APIs.
Often hearing phrases like micro services are fine grained web services or API is themselves are equivalent to micro services. These all sort of show fundamental misconceptions under the covers.
So, I've written this just to really break that out and explain about what the key differences are in those two concepts.
What is an API?
An API, fundamentally Application Programming Interface, that is an interface. It's a way of making requests into a component. So it's the route that you go in to make those requests. In modern use that typically means a REST API, that's a call made using HTTP protocol using JSON data as the payload.
What are Micro Services?
So let's ensure we also have a clear crisp definition on what a micro service architecture really is. Micro-Services architecture is about breaking down large silo applications into smaller components.
That are more manageable fully decoupled pieces with the aim of gaining benefit in terms of greater agility, more dynamic scalability and more targeted forms of resilience. Really it's about the shape and the size of the component that's within the application itself.
So, Micro-Services architecture that is really about breaking things down into small components. it's really a micro component architecture. An API is/are the interfaces that could be used to expose the functionality in those components but the two of separate concepts. They're not directly related. There's no particular reason to assume.
For example, we changed our design from a large application to that of a set of separate micro service components. It would change the number of APIs that the overall application exposes or indeed change their granularity. Those two things are completely independent of one another.
So, Micro Services are components that are used to build up an application in a more agile framework. APIs are a way of exposing functionality of an application whether it's written as micro services or not. There's no one-to-one correlation between the two. We could easily have Micro Service exposing multiple APIs or just one or indeed none at all.
A micro service component could be working on asynchronous messages, picking messages and manipulating, enriching them and putting them somewhere else. There may be no API whatsoever. It's just a component of an application.
Micro services and APIs are related, but they are not the same. Micro service is a component. referring them as Micro-service components may improve clarity.
We've skimmed over some pretty deep concepts here. Micro Services architecture is non-trivial to understand, when you start comparing it with things came before it like service oriented architecture and trusting between them that can really get quite sensitive.
Hope this helps to understand the fundamentals!
Often hearing phrases like micro services are fine grained web services or API is themselves are equivalent to micro services. These all sort of show fundamental misconceptions under the covers.
So, I've written this just to really break that out and explain about what the key differences are in those two concepts.
What is an API?
An API, fundamentally Application Programming Interface, that is an interface. It's a way of making requests into a component. So it's the route that you go in to make those requests. In modern use that typically means a REST API, that's a call made using HTTP protocol using JSON data as the payload.
What are Micro Services?
So let's ensure we also have a clear crisp definition on what a micro service architecture really is. Micro-Services architecture is about breaking down large silo applications into smaller components.
That are more manageable fully decoupled pieces with the aim of gaining benefit in terms of greater agility, more dynamic scalability and more targeted forms of resilience. Really it's about the shape and the size of the component that's within the application itself.
So, Micro-Services architecture that is really about breaking things down into small components. it's really a micro component architecture. An API is/are the interfaces that could be used to expose the functionality in those components but the two of separate concepts. They're not directly related. There's no particular reason to assume.
For example, we changed our design from a large application to that of a set of separate micro service components. It would change the number of APIs that the overall application exposes or indeed change their granularity. Those two things are completely independent of one another.
So, Micro Services are components that are used to build up an application in a more agile framework. APIs are a way of exposing functionality of an application whether it's written as micro services or not. There's no one-to-one correlation between the two. We could easily have Micro Service exposing multiple APIs or just one or indeed none at all.
A micro service component could be working on asynchronous messages, picking messages and manipulating, enriching them and putting them somewhere else. There may be no API whatsoever. It's just a component of an application.
Micro services and APIs are related, but they are not the same. Micro service is a component. referring them as Micro-service components may improve clarity.
We've skimmed over some pretty deep concepts here. Micro Services architecture is non-trivial to understand, when you start comparing it with things came before it like service oriented architecture and trusting between them that can really get quite sensitive.
Hope this helps to understand the fundamentals!
Comments
Post a Comment