Microservices are the “new kid on the block” when it comes to designing an architecture for your system. Just like when you are introducing a new shiny language or framework, if you have a “clean slate” (i.e. no legacy) you are good to go, but if you are carrying years of developed source code on your back, you need to be aware of "a couple" of things.

In this blogpost, we'll guide you through our experience on implementing Microservices in brownfield applications. 

Whenever someone starts a new trend in the software development arena, everybody starting new projects (usually called Greenfield) rushes to raise the "accomplished" flag. Unfortunately, many of us are working in well-established/mature/old code bases (i.e. brownfield projects), and it is hard to incorporate these new trends, namely frameworks, languages or even architectures. It's not only hard in the technical perspective, but also to convince your organization to spend thousands of dollars or euros to change a piece of software that is working.

This has happened to us at Processware in what regards to the Microservices Architecture.

So what is the underlying problem? The monolithic application!

A monolithic application is built as a single unit. Obviously, large enterprise applications aren’t composed of a single monolith, but usually by several monolithic components.

The following characteristics are usually associated to monolithic applications:

• It is hard to detect and correct components responsible for stability or performance problems (example: if your application is consuming excessive memory, what is the offending component/feature?)

• These applications can evolve into a “big ball of mud” - a situation where no single developer (or group of developers) understands the entirety of the application;                            
• Re-use of components is hard across monolithic applications;

• Scaling monolithic applications can often be a challenge;

• Continuous delivery is almost impossible;

• These applications are implemented using a single development stack (i.e., JEE or .NET), which can limit the availability of “the right tool for the job”.       

And how can we solve this problems? Microservices!

So, to try to solve or mitigate the issues described above, a new software architecture was proposed in May 2011 in a workshop held near Venice. This new architecture was called “microservices”, and it is a generalization of the UNIX abstraction where “everything is file”, but in this case “everything is a microservice”, so in that sense, the main philosophy is the same: "Do one thing and do it well"!

Let us describe the main characteristics of Microservices architecture:

• The services are small - fine-grained to perform a single function;

• Componentization (the ability to replace parts of a system), comparing with stereo components where each piece can be replaced independently from the others;
• Organisation around business capabilities instead of around technology;
• Smart endpoints and dumb pipes, explicitly avoiding the use of an Enterprise Service Bus (ESB);
• Decentralised data management with one database for each service instead of one database for a whole company;
• Infrastructure automation with continuous delivery being mandatory.

Martin Fowler used Amazon’s “two-pizza team” as a great rule of thumb regarding the right team size: if your development team working in a single code base is bigger the “two-pizza team” (between 6 to 10 elements), then you are probably building a Monolith!

Not everything comes out smelling like roses!

As you are probably imagining, microservices are not the “silver bullet”, and will not solve all the problems of your system. In fact, microservices create some additional complexity:

• It's harder to test an application because you need to guarantee that all services are up and running;
• It's harder to deploy, because there is an explosion of services to be installed and configured;
• As services need to communicate with each other, the network and processing (serialization and deserialization) consume more resources;
• If not well designed, the services may end up too-fine-grained, which can increase the cost of maintenance;

Therefore, a microservices architectural strategy should take a careful, measured approach to reap maximum benefits: we strongly recommend designing and building microservices that encapsulate capabilities for particular business domains and with security in mind.

I have a monolith! Now what?

We at Processware have a well-established and stable product, with more than 15 years, called O2P. Therefore, we regularly feel the burden of the monolith (as described above).

In that sense, whenever we see the need (and have the opportunity) we are splitting features across separate services. In one of the examples, we split a monolith component in 11 microservices!

These are our first impressions:

• We are using less resources (namely memory): as O2P is installed in several customers, but not all use all features, we are having the opportunity to switch off the microservices that are not being used;
• We are more aware of the less stable or less efficient (CPU/memory) components;

Whenever we feel that we have new stories regarding our microservices journey, we will write other blogposts, so stay tuned!