7 Things to Worry About w/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 sub-units 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. You really have nothing to worry about if the working area is very big and the project is very small. 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 micro-service create a better engineering process or you simply want to use micro-services 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 micro-services would definitely change. Even if not for the cost of the servers, the cost of getting more Software for managing micro-services 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 micro-services, data would have to be replicated for some situations.
7. Lastly, remember that organizations that currently use microservices have plenty of staff members 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 concerns an organization looking to move its application to micro-services needs to consider before making this decision. Again, these are things to consider and are in no way, stating micro-services should not be used.

Join Red Hat Developers, a developer program for you to learn, share, and code faster – and get access to Red Hat software for your development.  The developer program and software are both free!

For a framework for building enterprise Java microservices visit WildFly Swarm.