7 things to worry about Microservices

So recently, the idea that Monoliths should be discouraged and that Microservices be embraced has taken over the Software Development space. A project made into a single code base is to be taken out and broken into manageable pieces. It is better to work with manageable subunits than a whole bunch of one big stuff. Well, as the saying goes, small scale always wins.

Before you consider starting that project or breaking your current project into microservices, you have to fundamentally understand exactly what microservices are. Let me create a scenario of building a house. Imagine you want to build a house and you have only one working area for all the workers on site. The engineers, the bricklayers and everyone working on the project would have to use a single location to prepare all the materials they need.

Before you go around saying this is a bad approach, consider the size of the working area and the size of the project. If the working area is very big and the project is very small, you really have nothing to worry about. Everyone is in a single place and everything would go on fine.

This is similar to a condition of a Monolith. Everything is in one place. The Database, the logic, and even the front end. You have all in one code base if you want to make a change to a single file, you have to open up your whole project. You need to redeploy your project for one single change.

But before you choose microservices, kindly consider the following

  1. Let us use the example of building a house, if you want to move the workers to their own sections, you would most likely need time to organize the movement, organize where everyone would be. If the movement does not improve the rate at which your building was constructed, what then is your reason for moving? So is microservices. Does changing your project into a microservice create a better engineering process or you simply want to use microservices because it is what is invoked.
  2. If you say moving makes for a business sense, also consider that moving would mean having to be able to manage the various sections differently. If you previously had one server to manage, you definitely would have to manage more than one server now.
  3. The cost of getting new servers to install your microservices would definitely change. Even if not for the cost of the servers, the cost of getting more Software for managing microservices would change.
  4. Keeping in touch with all of your servers to know their current state is another issue. Previously you needed to worry if one server was down. Now you need to be aware of the availability of all your servers at once.
  5. Before you break a monolith into a microservice, consider how the architecture of your project would change. How would the databases communicate with each other? Do you still want to use a single database or divide each project into various sections with its own database?
  6. Replication of data is something that would need to be looked into. In cases when you want to use different databases for each of the microservices, data would have to be replicated for some situations.
  7. Lastly, remember that organizations that currently use microservices have a lot of staffs to handle each section of the different projects. Are you buoyant enough to handle the finances of each of the additional staffs that your project would require?

These are some of the few considerations any organization looking to move its application to microservices need to consider before making the decisions. These are rather things to consider and are in no way stating that microservices should not be used

Leave a Reply

Your email address will not be published. Required fields are marked *