Microservices for business or perhaps a monolith?


When you start considering microservices and their importance for business, it is worth considering the specificity of the times in which we live. Is constant development still possible without rapid adaptability? What about a flexible approach of business not only in the context of customer needs but also changing social and political conditions? We hear about constant development and the need to compete at every step. The concept of microservice architecture is currently one of the first plans for the development and construction of applications. The question is, should this trend be blindly followed?

We must provide the answers according to our knowledge and experience. It cannot be anything other than “it depends.”

Monolith or microservices for business? Which approach is better?

Until recently, most of the world’s giants, such as Coca Cola, Zalando, Netflix, started from monolithic architecture. The main advantage of using this approach is the implementation time. If we are talking about the initial stage of development of a relatively small application, it is often the monolith that wins over microservices. Why? Because it allows you to efficiently launch the application and thus start your own business. At a start or in the case of small systems, operation on the same code can be carried out efficiently. And most importantly: there are fewer developers involved. Creating a solid monolithic architecture is the first step. The question is what about the further development of the system?

Imagine a situation in which we very schematically discuss the process of building and developing an application to support the complaint process:

If we want to create such applications quickly, a monolithic architecture can really work very well. We have simple functionalities (icons) and each of them is an integral part of one code (circle symbol). The implementation of such an application will be relatively quick. However, if there are any problems with one functionality along the way, it will automatically stop further actions in all others. The situation will be very similar when the company plans to expand the application further:

  • adding new functionalities
  • developing current functionalities

If your company’s business goals assume constant development and you plan to flexibly react to the changes that surround you, think hard about choosing a monolith. However, if you understand the differences in the two approaches, but you want to launch the basic application quickly, then you are in the right place. You can go ahead and start with a monolith and then switch to microservices. This was exactly the approach of the giants mentioned earlier.

How will the similar situation look in terms of microservice architecture?

Opsenio custom software

The creation of an application based on microservice architecture in business will pay off when the system is complex or you immediately know that it will have to be significantly expanded. The separated functionalities become microservices then. Dedicated teams work on their development, each of them focuses only on their own task. Connected microservices create an efficiently running application. A great advantage of this approach is the possibility of flexible development of selected functionalities and quick error elimination. In the case of microservices for business, it is worth paying special attention to optimizing communication between the separated services and the infrastructure itself.

Pros and Cons – a quick summary

Microservices for business enable unlimited application scaling. Today it is an invaluable asset that allows you to effectively build a competitive advantage. In the event that specific functionality requires increasing resources, it can be done immediately, without the need to expand the entire application. Managing the whole thing is a more complex issue – without an experienced partner who knows the secrets of creating and expanding complex systems on an Enterprise scale, the entire project can turn out to be quite a challenge. The basis is the optimal design and implementation of communication between individual microservices. Only in this way will the entire application perform its functions efficiently. We cannot forget to constantly monitor the operation of individual services in order to prevent unplanned breakdowns in advance.

You may get the impression that the monolith in the context of meeting your business goals is now considered an obsolete approach. Honestly? This is not true! An application developed in accordance with the assumptions of the monolithic approach may work effectively for a long time. Of course, when it is well-designed. It is good to mean in such a way that it is able to achieve the business goals of a specific company. If we add to this regular care for the application itself and keeping it functioning properly, it will not disappoint us. Monolith is perfect for those enterprises where we deal with a low variety of services. The sector of activity is also important. If the observed changes in the business environment remain at a similar level for many years and it is a specific area of activity – a monolithic application will probably be the best choice.

Usually, the reality of many companies at the start is very similar: there is a need to create one central application. One that will allow you to start business and enable you to achieve your basic goals. In such cases, the monolith architecture is not very complicated and the development team can start work very quickly. If we assume that the entire system will be burdened with only one process, the entire system will be very efficient. In the case of operating on one code, there will be no problems with communication (services are not scattered here after all). However, problems will arise when the company wants to expand the scope of its activities. In the case of a monolith, usually only the entire application can be scaled and the whole system is … fragile. One mistake is enough for the entire application to stop performing the assumed functions. And this is a serious business complication. Thus, introducing any changes is often very costly. The relatively slow reaction to the occurrence of a failure also does not make things easier.

An individual approach is the basis

When you create any IT system, it is worth keeping in mind one basic principle from the very beginning: the real strength of your company will be a system tailored exactly to what you need. And it’s not just an empty slogan. Monolithic application or microservices – choosing the right approach allows you to eliminate possible problems in the later stages of operation and development of the system. That is why we cannot speak of a universal approach and thesis based solely on favoring microservices as a more modern concept.

So who are these two approaches for? We answer with an infographic:

Opsenio custom software

Have you ever wondered why such powerful brands as LinkedIn, Twitter, Netflix started with an application created in a monolithic architecture? There may be several answers, but the following arguments undoubtedly supported it:

  • it is very easy to define the starting requirements here
  • monolith is easier to maintain at startup than microservices
  • business can take off quickly
  • ensuring security is easier here, because communication takes place in memory (microservices – over the network)
  • the infrastructure that enables the proper operation of the application is not growing as dynamically as in the case of microservices
  • this approach is good for companies that have difficulties in defining the exact directions of development at the beginning (which is extremely difficult in the case of young businesses)

Does the golden mean in application development exist at all?

Of course! If the system your company needs is to be small and should support one process – choose a monolith. It’s a good option to start with. If you also want to not hinder your future development opportunities, choose a modular monolith. Why? In practice, the modular monolith was developed as an evolution of the traditional monolithic approach. All this so that you can easily transform a monolithic application into microservices. And this is a real plus and a chance to seamlessly divide the system into microservices when your business actually needs it.

This path of software development will allow you to optimize costs and control the effectiveness of business goals. You also gain time to clarify a detailed vision for your enterprise, which will help you build a complex microservice architecture in the future. Finding specific functional areas is easy once you understand your long-term business goals thoroughly.

Wondering which approach is right for you? After reading this article, additional questions arose in your mind? Tell us about them. We will advise you on an optimal approach when we get to know your company and its needs. Contact

Monolith or microservices for business – conclusion

The examples described above do not fully exhaust the topic of differences between monolithic architecture and microservices for business. In our opinion, the features selected for discussion are the elements most often used to present the superiority of microservices over monoliths. Always keep in mind that these are alternative or variant approaches. There should in no way be any assumption that one approach is absolutely superior to another.