Why Sometimes Microservices Take Too Much and Give Too Little. Part 2

Meet HQ. This is how we call our in-house custom-built ERP system. Our dev team is working hard on the second version, which will feature tons of new great functionality, but the current one will suffice for demo.

HQ, the ERP for IT companies, is a monolithic application. It covers day-to-day operations of 200+ talents. It features the following modules:

1. Sales & Marketing
2. Service
3. Finance
4. Operations
5. Commerce
6. HR
7. ERP System Submodules

 

All in all, our project meets our demands in analytics, financial reporting, time tracking to enable transparency for our customers and short/long-term company growth planning. My question to Serge is:

Do we need to migrate HQ ERP to microservices in order to make the system operation more effective?

— Not for now. And you’ll see why after I’ll give you this example real quick. Say, you buy a Mac Studio. (Apple's most powerful desktop computer ever, — the auth.) It has 128 Gb of unified memory and can easily cover any business needs of a small to midsized company that would want to run the HQ ERP for them on it. What I mean is that up to 1,000 people can use HQ in their daily routines (vacation/time-off requests, time tracking, relocation requests, project/job history, compensation info, training info) and the computer that cost them several thousand dollars will do just fine for that. It can host a server of a website, CRM and what not. If you need to get insured against future growth (1K → 2K), buy yourself another computer. Pay $3,000 more and you’re done.

In contrast to that, migration to microservices won’t cost you nearly as much. If I wanted to decouple HQ into microservices, I’d have to pay at least $40,000 at cost price. Would it be a reasonable move to invest so much to get insured against a hypothetical future growth? Like I said, I’d better buy another $3,000 computer to cover my back, but I’m not sure at all I will need it. As for the microservices, I will probably need them if I go from 300 to 300K in a 10-year time. But as much as I’d love to achieve that, I’m a reasonable man and don’t believe it is attainable even in 10 years. If in a few years Symfa is a 1,300-talent company, which is a healthy pragmatic growth, 128 Gb that this good old Mac Studio provides will do us just fine to run HQ on it. Moreover, Mac Studio will easily support 50 such instances (50 companies up to 1000 employees), so why pay more?

Can you imagine a situation when you decide to migrate HQ to microservices? What could it be?

— I can give you a few examples when decoupling would be a necessary, even a highly recommended act for HQ.

Case 1
HQ hits the market and 1,000 companies want it immediately. Those 1,000 clients love our ERP, but want to add a little bit of personal touch to it. So I’m left with 1,000+ new features that my users ask me to implement. What I do is extend my current team of 10 engineers to, say, 100 engineers in order to cover those development needs. You wouldn’t want to teach each and every dev how the whole system works. So I just cut it into smaller modules and a 100-person team naturally divides into smaller teams, too. Now I have 10 efficient teams, each of which knows all the ins and outs of their specific modules, be it authentication, analytics, email, whatever. The teams will have some communication contracts established so that the modules still can talk to each other, but they don’t interfere with each other’s work. The development process is smooth, the customers get their new features delivered on time, everyone’s happy.

Case 2
Let’s stick to the same story: 1,000+ customers have recently got the license and are enjoying HQ ERP. At some point, I notice that one module is acting weird. My analytics module, which doesn’t take so much operating memory, swallows 100% of my processor. In order to serve those 1,000 clients properly I need 1,000 processors, which is basically 1,000 computers. Hey, why should I buy 1,000 computers if I can detach one trouble module into a microservice and find a cloud vendor to scale out processing capacities?

My analytics module may require little operating memory (say, the whole system needs 5GB and the analytics module asks as little as 100Kb), but it needs so much processing power. Scaling the whole system up for 1,000 users would be unwise as I will get 5TB of the operating memory. In order to grow only processing capabilities of one specific module (10GB), going microservices is a great choice. I can scale up and down dynamically and use as many or as little nodes for my analytics module as I need at a given moment in time — be it 3 processors at night or 133 processors during the day.

Case 3
My ERP system is a cool thing. Especially its analytics module. But, oh my, this analytics module is so complex and has so many dependencies. Its code spreads all over the system. If I want to change a thing about my analytics module, I’ll have to revise my entire system. Who wants a headache like this? So I detach my troublesome but very useful analytics module into a microservice, establish some communication protocols between the analytics microservice and the rest of the system to enable data collection and that’s it. I can make changes to my system just like that, while an independent analytics team takes care of the analytics module.

The isolation of the super complex analytics module may go even further. We may cut it off together with the repository and the team and wrap it up as a separate product (or even company, who knows?) only because of the module complexity. We may build a new expertise area based on this analytics module and even get its own pool of clients who would want only this analytics module and not the entire HQ system (but I wouldn't do that, ‘cause they’d miss a lot).

Hence, microservices will be a great strategic choice if you’re:

• Planning a rapid growth
• Experiencing performance issues at the architecture level
• Struggling with complexity.

 

You’re a lucky guy. You won’t have to spend a gazillion of money to go to microservices. Moreover, if you need to update your tech stack or migrate to the cloud, it’s all available to you. Even better — it will cost you less than to your “trendy” peers who migrated their monoliths to microservices.

If there are other cases of migration to microservices you’d love to read about, be sure to leave them in the comments and will be back with more examples!

You’ve mentioned before that a shift to microservices arises from an organizational necessity. But we didn’t really talk about the efficient microservices teams and how to build ones.

— Yeap, let’s fix that. So, microservices is a complex distributed architecture, and you should keep it in mind when building your project team.

Thus, you’re going to need two types of teams — infrastructure team and module teams. I’ll refer to the infrastructure guys as the master team, and you’ll know why in just a minute.

The cloud has made microservices more affordable, but it’s still not a piece of cake. In order to keep the whole microservice-based system running properly, you’re going to need a master team composed at least of an Architect and a DevOps engineer/Senior developer. Despite loose coupling which microservices are widely known for, they’re not 100% isolated from each other. The master team is in charge of establishing sound contracts between all the system parts that would enable its balanced functioning, so that multiple microservice don’t affect each other’s work.

Say, you’d like to update your existing microservice #4. Without a deep system knowledge, you may neglect some of its dependencies on other microservices, minor as they may seem. What if microservice #4 is loosely coupled not only to module 5, but also to module 6, 7, and 8? It means you should deploy all of them together. Which is nowhere easy to do.

Microservice planning, architecture and design require higher software development qualifications. If omitted, those can make a mess of your system before you know it. So, investing in an experienced master team seems like a natural thing to do to me.

What about the rest of the team? These guys will be in charge of the separate modules providing some piece of the system functionality. For example, let’s have a look at the email module. It shouldn’t be that complex to develop and maintain, although it has a bunch of useful functionalities like analytics, logging, spam/rejection monitoring, email campaigns, open rate, click rate, etc. Oftentimes, the competencies of such module teams are lower than those of the infrastructure team in terms of the system knowledge, but they are brilliant at their specific responsibility zone like an email module.

So, you see, in order for microservices to make sense, I’d say your team should comprise at least 5 module teams and one infrastructure team. As for me, 25 engineer-team is a hard minimum for that. Does every project need so many developers? In our practice, 95% don’t. Moreover, microservices is a technological shift that was designed to make big projects more flexible. For a small project, it’ll just add so much complexity.

We started with the success story of Spotify, remember? But it feels just so right to me to end this blog post series with a microservice failure story from Google, IBM and Lyft. I’ll place the summary of the original text below and here’s the link for the issue (trust me, it’s worth its reading time).

 

To be completely honest, I often used to skip those articles on the Internet where monolith was the hero. I attribute that to the specifics of my job — as a tech observer, I often neglect that boring, but very functional stuff in favor of today’s trends. I hope this conversation with Serge will serve me a good lesson for the future. Does the same apply to you?

If you’re still in doubt whether your project will benefit from migration to microservices, feel free to get in touch with us for a non-biased consultation.