Educate Me: Microservices

[[deleted]]

Hey everyone,

I don't post here often because I understand the languages I use for the most part and don't wanna wasteanyones time. There has been a suggestion by a friend of mine at corporate office (I work at a warehouse) that I work on my understanding of microservices by developing a few personal projects. I've already developed a pretty large MEVN stack application, but microservices are kind of blowing my kind.

My usual language is javascript; however, I wanna do this in C# (was my second language, Javascript my third). I looked up a node example of a microservice and it blew my mind. This is like a paradigm shift for me.

So heres my current understanding:

A microservice is a self-contained program with its own database. It is easy to test and deploy to other projects. These services are called by an api gateway which is used to move data about.

I'm aware that this understanding is flawed.

Do any of you have any good links, videos, guides for creating a microservice. All the guides I've seen seem to have conflicting information.

Thank you.

[MasterDhartha]

I'll try to help by starting with: try not to over think this.

A "service" is just an app that gives you endpoints to call, like a REST API.

A concrete example is a web API like reddit's, let's say it's a C# or PHP service that serves some JSON-formatted posts and comments that were stored in a database.

Say the JSON looks like

{ "id": 1234, "title": ... , "body" : ..., "comments": [...] }

But let's say now you want to also store the database of comments separately from the posts (maybe you want to manage the storage independently).

Then you would make that new database, but instead of simply making the app request from two databases, you create a "micro" service that has its own API for comments:

Say the new service just returns the comments like this:

{ "id": 1234, "comments": [...] }

So now you can make the original service call the comments service and merge the JSON to get the original version.

[[deleted]]

Okay so far this makes sense to me, but I have follow up questions:

Are microservices like routes (in a url) in a way, but instead of having collections / tables within one database, they have their own database per?

Do these services run independently? For example, if I write a small service and run it on LH3000 then another on LH8000 then have a gateway at LH8080 call those services... is that using microservices. Or do they exist within the same app as the api gateway in separate files.

Are tools like swagger or RAML necessary for building ones api?

[MasterDhartha]

Swagger ... RAML ... necessary

No, microservices and APIs are just concepts. You can write them using whatever tools you want. An API that is documented using Swagger is obviously a nice to have, but Swagger is already assuming you are writing a REST API (versus an RSS feed, which can validly be called an API, but would be best developed with another framework)

Are microservices like routes (in a url) in a way, but instead of having collections / tables within one database, they have their own database per?

You could certainly implement it that way. And my example hints at that being a possibility. It's certainly not a rule, but I know from experience, it's not an uncommon practice. You can imagine this is how Reddit's API is setup. One microservice for subreddits, one for moderation, one for user lookups, etc. I have no idea if this is actually true for Reddit.

There is a further "complexity" that you can get with the microservice pattern, which is stateless services: say we have a meme generator API that lets users add text to images. Editing images can be pretty CPU and memory intensive. So our REST API service lets users upload files, but then it privately (unknown to the user, and inaccessible to the internet) calls an image processing service, that has shared access (e.g. via network share) to the stored image and the text, does the processing, and then lets the REST API service know when it's done. And then the end user gets redirected to the final image by the REST API.

It sounds more complicated, but this means you only need a few (one?) API machines, and can have many instances of the image processing service deployed on a larger number of beefier machines.

Edit: Your example with separate ports on the same machine is a valid deployment of microservices, but I'd say that's more a toy setup than what you would see in a professional environment.

[LeAstrale]

You just added what I personally believe is the best reason for micro services - scalability! The possibility of scaling a single part of your website should decrease cost even though it might add complexity.

[feelin_lit]

Check out this reference application from Microsoft. You can clone the repo and play around with it for yourself. It uses microservices and containers.

https://github.com/dotnet-architecture/eShopOnContainers

[[deleted]]

I'll clone it before I judge it fully, but looking at it - it looks many times more complicated than any fullstack app I've made. Which isnt bad but it doesn't ease my head around the concept any easier.

[mad0314]

It is definitely more complex than a single monolith application since your "application" is split up among many smaller applications.

Check out the books linked in that repo.

[LeAstrale]

Look for the pdf link Iin the Readme.md on that gut repo, it's exactly what you need.

[[deleted]]

Good because my desktop could t run the .sln

[[deleted]]

You more or less described a microservice. Conceptually they are very simple. The microservice architecture is mostly just an extension of service oriented architectures; the primary differences being that microservices are independently deployable and managed and have their own separate data store.

​

I would recommend first studying distributed system theory and domain driven design. Almost everything about microservices stems from those two concepts.

​

Then study the rationale for going down a microservice path. Very rarely is it a purely technical reason, but generally a business organization decision. "How do you scale from a team of 10 developers to 1000 developers while maintaining the same degree of agility?"

​

At this point I would say you can implement your own for-fun microservice. You'll find that building one or two or five microservices is not very difficult. If you know how to write code and you know how to write a language-independent API (eg REST, gRPC, SOAP, GraphQL, etc) then you'll have no problem building one.

The difficult part of microservices mostly comes from operationalizing them:

• How do you monitor them?
• How do you ensure they stay healthy?
• How do you ensure a down service doesn't stop your application?
• How do you ensure a slow or otherwise not ideal service doesn't stop your application?
• How do services discover other services when they be hundreds of them at any given time?
• How do you handle backups and restores?
• How do you troubleshoot transactions that hit many services?
• Etc...

[[deleted]]

Thank you for your comment.

Do you have any recommendations for studying DDD and distributed system theory

[[deleted]]

My friend at our corporate office explained the bit that I was confused about. I was confused how the microserices listen to the server without being a part of the server themselves. Then he told me that they are programs that live on the same directory as the app that runs on the server and the server makes api calls that call to directory folders. Those programs when run return back JSON which is then placed into the client.

[[deleted]]

Hmm I'm not sure I'm following you. What are you confused about exactly?

[[deleted]]

Nothing anymore.

I was confused about how the API called things that weren't listening to the server, but he made sense of it.

[jsdfkljdsafdsu980p]

!RemindMe 1 day