Why Sometimes Microservices Take Too Much & Give Too Little. Part 1

I spoke with Serge many times. He’s the founder of Symfa and has been in software development for almost two dozen years. He’s a seasoned professional who has seen projects and businesses rise and fall, so I’m confident he has something valuable for me to say. So, here my first question goes:

What if a monolithic application written on an old tech stack wants to move to the cloud? Can it stay monolith and not migrate to microservices? (I’m being ironic here. For sure, I don’t expect a positive answer.)

— Great idea! Actually, this is what I would recommend to 95% of our clients.

This was the beginning of a most interesting, slightly longer than a one hour talk on why businesses should stay monoliths.

But I have to pause here to take you back to the exact moment when microservices hit the stage. Let’s see why everyone got crazy about them and how they got so immensely popular.

First there was a monolith. It has served us faithfully since 1948, when the first software program was invented. A monolith is basically a single program that has a bunch of functions, all running as a whole piece.

As software complexity grew, it got more modular. Thus, a multi-tier architecture came into being and a program turned into a software package comprising several reusable components. Sometimes those components could be deployed and updated separately, so it would give the company even more flexibility. But we’re still talking about tightly coupled systems.

The next step was allowing those components to talk directly to each other. This was the beginning of the SOA (service-oriented architecture) era, and during this age, software delivery picked up speed, with more reuse happening thanks to the new architectural approach.

Wasn’t it good enough? Nope. With the widespread adoption of the Internet, global corporate giants needed to change (grow, spread, innovate) even faster. The components grew smaller, so that independent teams could innovate and deliver on their own, with no unnecessary approvals and waiting for the others. The new approach was called microservices.

Spotify is among the happy adopters of the microservices approach. In this brilliant video, Kevin Goldsmith, VP of Engineering at Spotify, shares the reasons why the streaming giant chose to migrate. Here they are:

With 810 services running happily, Spotify and microservices seem like a match made in heaven. What about other companies?

Google, Amazon, Uber and many more also quickly moved their capacities to the microservices. Ubiquitous cloud adoption sparked even faster microservices spread and the rest of the market rushed to go micro before we knew it.

Long story short, what did those giants gain after they migrated to microservices?

• Quick development and deployment
  Loosely coupled modules can grow separately from one another and be deployed whenever they are ready to go.
• Scalability
  Scale up and down dynamically whatever capabilities you need.
• Freedom in choosing the technologies
  This one is probably the best thing for the developers, as it promises a lot of fun to them.

Why are we talking about it after all? We wanted you to see the story behind the widespread microservices adoption. It isn’t without a reason that the big players praise it so much. It meets their specific “big” needs, and what they are — I personally, as a tech observer at a 200+ talent company, — can only imagine.

Back to Serge and the insights he has to share.

— At Symfa we know how to implement microservices and have been practicing it for a long time. This gave us valuable experience. It’s harder to do, but this distresses the client in the first place, not us, as they have to pay higher rates for more qualified talents. What distresses us is that later on the client may come and say, — I don’t see the reason why I had to go through all of this. It doesn’t work any better now, it only got harder. What can I say? At least you’re running this trendy stuff in your company… But I wouldn’t do that.

Now let’s find out why it happens so with microservices.

What you’re saying is — in order for microservices to show themselves at their best, there must be a real business need to adopt them.

— We’ve seen many loud cases over the Internet where microservices helped the big players grow even bigger without compromising on flexibility. However, sometimes customers tend to forget that their project isn’t that big, although no less important for their own users and clients.

Do you want to replicate the practices that worked out for Google? Don’t do that. If applied thoughtlessly, just for the fashion’s sake, microservices will cause more harm than good, and you’ll leave frustrated and deceived. The Internet says microservices are cool and stuff, but what you may get in the end is a mishmash that cost you dearly. Not some cool project you can be proud of.

So, where did those clients go wrong?

— Microservices is primarily an organizational approach. Say, you’re a major industry player with a bunch of digital services and products in your portfolio. Each product/service is following its unique development route. So is the IT staff that supports its development and promotes its further growth. I’d say your transition to microservices will happen naturally, i.e. will flow out of the necessity to decompose your big IT team into separate smaller teams in order to enable them to take better care of their specific chunk of work. In such a way, each product/service team will have its responsibility zone and thus will stop messing with each other’s code and breaking it.

By the way, Kevin Goldsmith mentions exactly the same thing in the video above. Empowering independent teams to take better care of their specific modules is key to microservices success. This is a whole new organizational workflow we’re talking about. More of it later, on to the next question.

Can such a product/service in a big company be represented by a monolithic application? Or a bunch of digital services equals a bunch of microservices?

— Not necessarily. If your monolithic application isn’t experiencing any performance issues and your team is doing a great job maintaining it, there’s no need for an architecture revamp. On the other hand, if there are any performance issues, the reason for that may be as simple as a wrong SQL query, which is tackled by optimizing SQL indices, not an architecture revamp.

How big should that company become in order to qualify for microservices adoption?

— It depends on the business specifics. Let’s say, you're a company of 5,000 talents. For sure, you’re a big one. Do you need microservices? Let’s see. If those 5,000 employees are the only users of your software, and you are planning no vigorous growth from 5K to 50K in months, I’d say you don’t qualify for migration. All in all, microservices are a justified effort to meet three major business needs: rapid growth, performance issues on an architecture level, and complexity issues.

However, expanding from 5K to 50K shouldn’t necessarily call for migration to microservices. Even if you’re planning to grow 100 times from now, let alone 10 as in the example before, microservices may not be a way to go for you if the technical resources you need for such scaling will cost you less than rebuilding your whole architecture.

Although, you definitely should try microservices if you have to deal with ‘unbalanced’ scalability. Say, in time, as the system grows, some features may require more resources than others and thus cause the entire system to scale up. In such a case, those troublesome features are better off isolated (= microservices), so that the rest of the system may continue working without unnecessary scaling. (More on this and other reasons to migrate to microservices in the next blog post on the topic)

 

To stay competitive nowadays, cloud is a must for a business. How can an application take advantage of cloud computing if it doesn’t migrate to microservices?

— A monolithic application leverages exactly the same cloud benefits that a microservice-based one does. I don’t get why people think a monolith can’t jump to the cloud. This will be a slightly slow-motion leap, but it will definitely hit the target.

Why do you think the Internet rarely talks about that?

— ‘Cause it’s boring. The team copy pastes only those code sections from the old monolith that a business will need in the future, leaving out those sections that are no longer required. You move it in small chunks, see if it works in the cloud, and if it doesn’t, you fix it. Or you can move it as a whole piece and do some facelifting of the system in the cloud. Doing it piece by piece is just simpler, ‘cause you can validate the code during the migration. Sometimes you just retire up to 30% of that code that business no longer uses. Once in the cloud, you’re on a higher software version and can add any new cool features. That’s it. Not much of an action movie, isn’t it?

Absolutely boring, I do agree. Let’s talk about the benefits that are out there in the cloud for a monolithic application.

— Pay as you go, fast and convenient deployment in Kubernetes. With K8s tons of cool out-of-the-box features go, like load balancers, hot reloads, no downtime. Basically, you could switch to a different software version and no one would even notice that. Failover prevention in the cloud — this is just the thing. For instance, we run several nodes, which is a super simple thing to do compared to making a server run. If one of them fails, the other takes the lead. Configuration-as-a-code, better system manageability, easy migrations and a rich set of CI/CD and QA tools – here's a few more cool features that K8’s provides for a monolith, just the way it does it for microservices. All in all, almost anything that is available to a microservice-based application in K8s is available for a monolithic app, too.

We’ll stop here just to be back very soon with more exciting revelations in the next blog post on the topic. The second part of this microservices discussion will cover:

• Three cases when migration to microservices is a reasonable choice.
• New architecture means new team structure (read new complexities). Let’s see what they are.
• A microservices to monolithic architecture migration story (not vice versa, you got it right) from a star team of the Google, IBM and Lyft talents.

 

This story continues in Part 2.