Microservices - A beginner's perspective

#microservices #architecture #beginners

During my first days as an entry level software engineer, I heard a lot of discussions happening about microservices in my workplace. I had absolutely no idea about what they are and how they work as I had not studied them in my university. I believe most entry level engineers have little to no knowledge about them. After working on a project with microservices and listening to discussions between my seniors I have come to understand the basics. Here are my thoughts from a beginner's perspective.

1. What are microservices? - Simple to understand, difficult to implement.

In microservices architecture, there are a collection of services which individually does a specific work and collectively obtain a single business objective. They have separate codes, are deployed separately, and if needed they talk to each other via a network.
Say you have a project where you have a machine learning component that identifies an object from an image (let's call this MS1), one component that saves and retrieves the data of those objects (MS2) and another component that evaluates the results (MS3). Now, if you want to train some data -

a. First you have to fetch the data from MS2
b. Send it to MS1 to process and get back the results
c. Send the results back to MS2 so save it in the database.

If you want to evaluate the result -

a. Fetch the data from MS2
b. Send it to MS3 for evaluation, get back the response
c. Send the response back to MS2 to store it.

You can have another mircoservice MS4, a controller microservice, that does all these calls and expose only endpoints '/train' and '/evaluate' to make it easier for the client. While this sounds very simple, ensuring smooth communication between these microservices is not that easy.

2. Microservices are selfish

Each mircoserivce should only know what it is doing. It should have no information nor care about what other microservices are doing. Each mircoservice usually has it's own database or repository (might be different instances of the same database) and use only the data given to it via a request or the data present in it's repository.
Another important thing to remember is changing one microservice should not break the other ones. I am sure all of us have faced this at some part of our development career or college life that if you change a single thing the whole project breaks.
This is solved when a microservice strictly does one job or a collection of dependent jobs (which are independent of other microservices), and others just use the output. Other mircoservices might know how the output looks (e.g. the response json object), but not what it actually is.

3. When to introduce a microservice?

The most challenging thing about microservices is defining what part of your work can be a microservice or if your project is fit for microservices architecture. Key questions that need to be answered are:

a. Is your project large enough? - Your project has to be large enough to be broken into microservices. If not, you maybe good with a monolithic architecture.

b. Are there codes in your project that are independent? - If yes, they are potential microservices.

c. What should be the size of your microservice? - It should be large enough that it is reasonable to have a separate codebase but simple enough to achieve a similar goal.

d. Are two microservices talking too much to each other? - If yes, they can usually be a single microservice.

e. Are there duplicate codes between your microservices? - If so, they might as well be a single microservice.

4. Look before you leap

Don't jump right into microservices. Discuss within your team and try to understand if you need them and how to break apart your project. A good discussion leads to a lot less hassle in the future.

5. Documentation is the key

Good documentation is a life saver when you are working with microservices. If you are confused and don't know how to communicate with other microservices while working on one, you can jump right into the documentation. So be sure to stay updated with your project's documentation and document things whenever necessary.

6. Why use microservices?

The main objective of using microservices is to gain -

a. High maintainability and decoupling - You can have people work on different microservices without knowing what others are doing or worrying about breaking other's code. It also makes planning a sprint much easier.

b. Scalability - If you want to scale, you can create a new microservice rather than changing the whole project.

c. Fault tolerance - If one microservice fails, others will keep working. So fixing an issue is also easier and faster.

7. With candy comes a little cavity

Everything about microservices is not positive. Here are some issues that you will definitely face.

a. Very easy to mess up - If you do not maintain good documentation, you will definitely mess up. If you are not updated with the documentation or don't communicate well with your team, you can also mess up.

b. Takes very long and detailed planning - Breaking down a project into microservices require a lot of detailed planning, which takes up a lot of time and the meetings might seem endless.

c. Network Latency - Solving network latency is a real challenge in microservices. It can often happen that your network latency exceeds your actual processing time.

d. Complicated deployment - Creating and maintaining separate deployment pipelines for each microservice can be quite challenging for the operations team.

Thanks for reading!