​Microservices 101: The good, the bad and the ugly

Grassroots developer support is driving the adoption of microservices architecture to new heights. It's good stuff but it's not the answer to world peace, according to Red Hat middleware expert Dr Mark Little.
Written by Toby Wolpe, Contributor
VP engineering middleware Dr Mark Little: Adopting microservices doesn't mean your badly architected ball of mud is suddenly really well architected.
Image: Red Hat

With microservices riding a wave of popularity, those with short memories may have overlooked the approach's striking resemblance to service-oriented architecture, which first emerged two decades ago.

But Red Hat VP engineering middleware Dr Mark Little likes to see microservices as the good bits of service-oriented architecture, buoyed by the arrival of more sophisticated engineering and operations technology and techniques.

"The difference is that this is being heavily driven by new approaches to developing software and distributed software. Things like Linux containers - Docker is a prime example. You've got your immutable services now, you've got things like Kubernetes for coordinating those services - and obviously you've got DevOps, which is heavily influenced by Agile," Little said.

"Those things are making people really look back at the ways in which we've done distributed systems in the past - and service-oriented architecture is an example of that - and picking the best bits that match those technologies. Or vice versa, finding those technologies that match some of the good bits of service-oriented architecture. That's probably the difference. The architectural approach isn't different but the technologies behind it really are."

In microservices architectures, apps are built as a suite of small, semi-autonomous processes that perform specific tasks and use APIs to communicate with each other. Microservices are meant to be easy to use and scalable, and increasingly figure in web, mobile and internet-of-things apps.

Among the historical shortcomings of service-oriented architecture, Little cites a failure to provide good contract definitions between a client and a service, and the shortcomings of WSDL - or Web Services Description Language - which was poor for loose coupling and distributed systems.

However, just because a number of factors and technologies have come together to make microservices the architecture of the moment doesn't make it plain sailing.

"It's important to realise microservices is not the answer to world peace. It's good for some things. It's like anything. Just because you adopt microservices doesn't suddenly mean your badly architected ball of mud is suddenly really well architected and no longer a ball of mud. It could just be lots of distributed balls of mud," Little said.

"That worries me a bit. I've been around service-oriented architecture for a long time and know the plus points and the negative points. I like microservices because it allows us to focus on the positive points but it does worry me that people see it as the answer to a lot of problems that it's never going to be the answer for."

If you are considering microservices, the best place to begin is with good software engineering practice.

"Fundamentally, that was what was behind service-oriented architecture anyway. And if you don't start there, it doesn't matter whether you're using Docker or virtualisation or a Java virtual machine or whatever, the right tool is not going to solve your architecture problems for you," Little said.

Where microservices - or even service-oriented architecture - really comes into its own is with logic services that should be deployed independently of each other, that scale independently of other services and are capable of independent failover.

"One of the things that concerns me about microservices is you've got a monolith and let's say you start to decompose it into services and you do that arbitrarily, you could end up decomposing it too far and you end up with 10 or even 100 or 1,000 microservices," Little said.

"But they're all so dependent on each other that if one of them goes down, the rest of them might as well have gone down as well. In which case you've bought yourself nothing. You've got 999 services sitting around waiting for the other one to come back up."

According to Little, those starting out with microservices should identify software that is failing to fulfil its function, rather than pick out software simply because of its age.

"Take something that's really not working for you - and I emphasise the bit about not working for you because you could have a monolith today that's been working well for the past 30 years and is quite happily dealing with the load, 365 days a year, that you throw at it," he said.

"In which case, breaking it up into microservices is probably not going to buy you much. But you could have a monolith that is completely the opposite, where something has been built up over years by different teams who've come and gone, and you're having to patch it continuously.

"It may even be fairly unreliable, implemented in a number of different languages and you're thinking about reimplementing it anyway. That could be a good candidate for microservices."

Along with a good grasp of the application's function and where it is failing to deliver comes the need to understand what components within it could be broken down into microservices, but no further.

"You don't want to break it down into too small a microservice. Some people are even talking about nano services, which is going a little too far. Don't go too far. Understand how you're going to measure success. That's critical in general but it is even more so for microservices," Little said.

Even where software is not working, avoid reimplementing everything from scratch because there may be elements that could be retained.

"If you've got something that doesn't work, you should still look to see if there's some of it that you could carve off and keep - particularly if you've had it deployed for 20 or 30 years and lots of people have, and particularly if it's implemented in COBOL, then it's battle-tested," Little said.

"It may not be all working for you today because the scale of your requests on Christmas day, for instance, are orders of magnitude more than they were 30 years ago. But that doesn't mean there aren't fundamental bits in that COBOL code that you could take and use again. You should, because if you're going to put bugs into a new system, you want to them to be new bugs. You don't want to reimplement old bugs that you've fixed."

So having identified a unit of work that can be deployed separately from everything else, that can fail and not cause the rest of the application to grind to a halt and that can also scale independently of everything else, the next step is to look at what contract you might define with it.

"That contract will include its interface: how do I invoke it remotely, what do I invoke it remotely with? A lot of people talk about microservices and REST [Representational State Transfer] and, absolutely, REST is a fundamental approach for microservices. But it's not necessarily the only way that you might want to talk to your service," Little said.

"You might want to talk to it using a binary protocol. You might have no choice but to talk to it using some legacy protocols. With COBOL, even though you're moving to microservices, you might still have a significant amount of your architecture that's still tied to CORBA [Common Object Request Broker Architecture]. It might not be the exclusive way to talk to your microservice but you might have to have a CORBA adapter in there somewhere."

Then come the typical distributed systems issues, because once you start to create microservices that scale independently, remote interactions over HTTP or a binary protocol are going to be slower than in-memory procedure calls.

"So you have to worry about what it means to invoke remote services, particularly if you have hard requirements on response time. The more you break these things up into services, whether they're macroservices or microservices or nanoservices, the more you have to start worrying: I'm running in a distributed environment. What does that mean to me and in fact can my application tolerate it?" Little said

"Because it might be I really want microservices, but unfortunately until they invent a network that uses tachyons to send messages around, I can't actually invoke anything because I can never fulfil my contractual obligations. I have to have everything in a big ball of mud."

More on microservices

Editorial standards