Microservices, am I able to use it?

We in Peykasa used to design and develop monolithic software solutions for many years. When I joined the company, almost all of our products were state-full, complex, monolithic, and unfortunately, unreliable software products developed for Telecommunication industry. Maybe the nature of this industry forced my predecessors to use such design or maybe the technology was not mature enough to offer them new ways to think. Those days, there was an idea that every software engineer in Peykasa believe in: we have to develop our software products as a stand-alone software running on a single machine.

Now that I look behind I can see problems clearly (with the benefit of hindsight, though). Five years ago, when I joined the company as a novice programmer, we had to deal with these problems in almost every product we created:

• Unreliability: We had software products that were not well-tested and we faced crashes day to day that caused our services to be unreliable. It was obvious that every single bug in code have a direct impact on the service and we will have a broken service soon or late. This problem annoyed us specially during software upgrades.
• High cost of changes and maintenance: We had to develop and maintain big chunks of software as a whole and the code got bigger and complex with time. Users requested new features and we had to develop it in a messy and big code base.
• Unscalable services: Each year the network traffic goes up and we had to deal with more packets in our software. We had created multi-threaded, complicated software product but the demand was one step ahead. We always had a concrete wall in front of us. For example, we used to tell our marketing team that 20k is the limit and we have no idea to improve system's performance, even with better hardware.

Initial problems in developing complicated software systems lead my colleagues to use a distributed architecture to separate concerns and there were successes for sure to coupe with increasing complexity of our products. But it was not enough. Quality of software improved dramatically during these five years (using rigorous testing techniques) but our services were not reliable enough. Performance remained our nightmare for years because we always had to deal more packets year to year and the code base got complex because of multi-threading and synchronization techniques.

When I learned more about Docker, software containers and microservices architecture and their benefits, and took a look at our problems, I realized that if we could use microservice architecture, maybe some of our challenges could be loosen. I thought that how people are lucky creating web applications and I wished I could use same technologies.

It was a raw idea at the beginning. My mind didn't let me to think about using microservices architecture in our products. Then everything started to change. About 1 year ago we started a new project and I had a chance to design it from beginning and the managers let me to try a new architectural design, microservice architecture. It was a unique experience and I've enjoyed the process and I think it worth sharing.

I started by separating concerns. I tried to create services that do one thing and do it well. Sometimes my services are tiny but I tried to resist to combine them to bigger services. It was rough at the beginning because my mind was biased towards creating something bigger and full-featured. At the same time, I had a goal to create services that can be used in different applications. I found that in some of our products, there are some pieces of functionality that are common enough to be separated as a single service. My experience in designing object-oriented software helped me. It's clear now that the problems and solutions are the same but the scale is system-wide.

During the process, I faced with problems that today I know they are common problems in microservice architecture. I devised solutions for some of them and, fortunately, I've found them standard solutions that are used by other engineers. It's really enjoyable to know that you are solving problems the same way that great software engineers solve. I'm reading this book that helped me to better organize my thoughts and experience and widen my knowledge. These are the problems:

• How to hide the microservice architecture and give a unique service view to the users?
• How to transfer packets between services with high performance?
• How to handle setting, reporting and other features in a general and reusable way?
• How to develop, test, deploy and maintain a microservice application?

After some months of trial and error and getting familiar with Docker technology, I realized that all pieces of puzzle get together to form a complete picture and I've created my first solutions with microservice architecture. Today I understand that almost all of guidelines from 12-factore app has a constructive role in good architectural design of a microservice application.

Today we had a software product that contains more than 10 services. Some of services are developed in-house and some of them are of-the-shelf open-source solutions. We freely use multiple database technologies based on our needs and we have a common platform for developing, testing, deploying and maintaining microservice applications.

Thank you for reading and I hope it's helpful to you.