APIs vs Microservices (How different are they?)

Microservices and APIs are really just the same things,s right, Wrong! They are not. If you have APIs, why do you need microservices? Aren't #Microservices just a more fancy way of saying APIs? microservices are like web services but finer grained. These and many more are misconceptions of what microservices and #apis are.
Find out the key differences and understand each term's key concepts.
See more of my articles on LinkedIn

Most of what I have learned in the MACH / headless architecture world has been while building Amplience headless cms, DAM, and dynamic media services take a look at the Amplience Website and see a MACH platform in action

00:00 introduction to APIs vs Microservices and how are they different
00:33 what is an api
01:50 what is a microservice
03:02 what is the difference between an API and a Microservice

[crisuar]

That was exactly what I was trying to understand, and you condensed it in less than 5 minutes. Superb!

[VincentCheng]

Brilliant, just cut right to the key point!

[amulkatta]

please provide video on Kubernetes vs docker

[DummyFace]

I agree with you, but you are also kind of wrong only due to why software architects ROYALY mess up about MSA: chopping up APIs by entity.
Architects don't tend to make the same mistakes with other applications. If its a website, then those will be logically split by.. by what the website IS.
If its a batch application, then the batch had to be named something. It has a purpose. It has BOUNDARIES inherent in it's application description.
APIs don't necessarily have those boundaries and thus are the primary painpoint in MSA: how to define the boundaries of an API.
When you have the goal to have microservices, but don't have multiple logical API boundaries, architects all seem to make the titanic mistake of separating a perfectly cohesive API by Entity, like a UserService, AccountService, SubscriptionService, etc.
These might just be database tables and the architect decides that each table needs it's own service.
And even if you can define an API's boundary CAN you separate them, or is there something tightly coupling them? If that is going to be a problem to decouple them, do you really NEED to?
But when the goal is to have microservices, and you don't yet have a justification for more than one API, people foolishly choose to define boundaries around silly things.
A website can be a single application with well defined boundaries, but it somehow needs to call 30 different APIs all defined around a single entity each....