✅ wanting to learn microservices for new job opportunities.
I’ve successfully deployed an api to docker and connected to MySQL on my network. Now I’d like to learn a few things:
1. If I build a second api then connect it to the first, that is the microservice yes or no?
2. How do these two APIs talk to each other?
Please provide resources or links so I can learn further. Thank you.
9 Replies
1. No
2. HTTP, gRPC, Websockets, TCP sockets, take your pick
This was a surprising answer. I will start from zero without any assumptions. Thanks 🙂
The "micro" part in "microservices" is important
so it wouldn't be a second API?
An api implies something bigger, I guess
Microservices do just one thing each
Hard to call them apis, imo
I see. thank you for this insight. I'm very intrigued.
There are many guides out there that present microservices to something they are not.
You can think of a true microservice as a Function, that takes an input and produces an output
in an idealistic scenario (which almost never will happen), It should also be pure, meaning no side effects inside the microservice like a pure function,
In the real world we're leaving you can think of a microservice as the minimal viable code for a single functionality you want to achieve.
for example an ImageResizer, for your app, a user uploads an image, and by spec you want this image to be resized to 400x300. This would be a microservice which would accept a path to the the image, and it will produce another image as its output (just like a whole cli app)
there's a catch here though, If you did an ImagePostProcessor which would resize the image, compress the image, and generally make more than one operations to this image, while by today's standards would also be considered a microservice, it wouldn't be the purest form of a microservice.
However its acceptable.
Note again: if this ImagePostProcessor would start to expand even further, doing more stuff than it should, then it would be considered a service instead of a microservice.
For example on the company i'm working currently, our main product consists of 29 microservices.
In reality, there are 3 microservices, and the other 26 are just services that are interconnected via RabbitMQ (async messaging) or HTTP (sync messaging)
and as examples for these thress microservices, they are the following:
Auditing Collector (collect audit events , processing them, and forwarding them to be persisted)
Input Validator (gets some input validates and returns whether it passed validation or not)
Pdf Generator (gets an html as its input and produces a pdf on its output)
An example of a not microservice would be our Report Builder which is doing several things, even though in the end it produces one ouput:
1) It fetches data from our Search Engine
2) it fetches data from our database
3) it cross corelates the data
4) It fetches images from web / filesystem
5) it augments the data with the iamges and other metadata
6) It performs aggregations on the data
7) it generates graphs based on these aggregations
8) it compiles report templates with the given data context
9) it finally produces the desired reports.
Also it processes 3 different kind of reports.
As you can see this is a far bigger service, and the scope is way bigger than what the Pdf Generator does for example.
Therefore this is not considered a MicroService, however its still a service.
When jobs ask you to know about "microservices". They do not mean it in the traditional way,
All they want you to know is, Async Messaging, Queuing, Back Pressure, Sync Messaging, and understanding of how to split functionality into self contained apps.
@Candyroll93
Reading now just saw this
Wow this explains a lot! How the he’ll do you keep track of 29 different code bases? How does pub/sub factor in differently than a rest api? Wouldn’t a rest api be a better option?
It depends on what you want to achieve
some things take time
and when you have a a high throughput system you can't calculate everything in real time
if you keep hammering the REST API it will fail eventually
therefore you use async messaging to have queing and back pressure
for example if i want to generate a report, an operation that takes > 10 seconds,
i wouldn't call a REST API
what if 50 of these reports reach at the same time?
A) either the service will fail with an out of memory error,
B) it might overload the database
C) it might overload the search engine
D) it might overload the host since image manipulations are going on there, that are cpu intense.
you don't want that, you want controlled behavior
if i have an async queue i can say exactly how many concurrent calls i want to process at a time
without losing any request in the process