As the term “microservices” climbs its way up the Gartner hype cycle, Luminis fellow and former NLJUG leader Bert Ertman provided a good reality check in his recent JavaOne session called “Microservices for Mortals.”
(Watch an interview with Ertman about the session and check out his slides below.)
A Java champion, coder, and software architect, Ertman has been involved in implementing dozens of large scale systems over the last 20 years. His session on microservices provided insight, humor, and common sense while addressing a number of thorny questions: Exactly what are microservices? More important, do you need them? Are microservices just SOA (service-oriented architecture) repackaged?
Don’t Fall for Microservices Hype
“Developers have been doing Ajax, NoSQL, and SOA before the microservices name existed,” Ertman told the audience. The microservices architectural style is particularly well suited to modern software development, Ertman said, because it is all about creating disposable building blocks. But he warned developers not to think a single technology is going to solve all their problems.
Ertman cited the history of SOA as a warning. Vendors got into SOA and productized much of the technology, he said, while promising a panacea. But vendors excessively complicated good advice into what he described as “giant, overpriced hairballs sold as fake middleware.” Now Ertman sees that history beginning to repeat itself as vendors start to release microservices-style products, and he warned developers to beware of false prophets.
Microservices for Business Agility
The essence of microservices, Ertman said, is structuring systems differently. It’s about modularity, separating concerns and addressing business agility through technology.
Microservices are supposed to be about business agility. Having your back to the wall because your current technologies don’t meet your business needs is a good reason to move to microservices. There has been a client-side revolution in both technologies and devices, and often existing infrastructures do not serve them well. For example, Netflix, often seen as the poster child for microservices, had to overhaul its architecture to service its move from sending out DVDs to providing videos online.
From Monoliths to Microservices
“Monolith” is the current derisive term for large, existing applications. But just because an app doesn’t use microservices, it isn’t automatically bad, Ertman said. That said, large existing applications can be hard to work with. They often take long to QA and test cycles build up massive technical debt.
How do you know if you should keep your existing app or move to microservices? The most important measurement is, How quickly can you change your app without breaking things? You must enable your architecture for change. But Ertman warned that moving a monolith to microservices requires a significant investment, starting with metrics and analytics. You must know your current state in detail in order to measure any improvements.
Before you consider moving to microservices, Ertman suggested asking yourself how agile (in both senses of the word) is your shop? Are your continuous integration/continuous deployment pipelines automated? If you are running two-week sprints, but then a six-week QA cycle, you aren’t ready for microservices. You need a solid CI/CD process first, he said. If your build and deploy processes are automated and you have embraced DevOps, then microservices could be a natural next step.
The Microservices Mindset
To make the move to microservices successful, developers have to change their mindset, Ertman noted. First of all, microservices are not meant for reuse (note: SOA was all about reuse). And while most developers were raised to believe that data redundancy is a bad thing, microservices require data redundancy. Ertman recommended separate data stores for each service.
Microservices also require a different attitude toward failure. Many developers believe failure is bad and must be avoided. In a microservices world, though, developers are encouraged to expect that failure will happen and to prepare for it. You should be ready to move to a graceful degradation of service when things fail, with minimal human intervention. After all, despite our best efforts, failure happens all the time, so coping with it shouldn’t be a big deal.
Finally, Ertman said, remember that microservices are hard. To make it all work out right, you need to keep on educating yourself. Don’t listen to just one vendor, he warned. Build a rational thought process that can help you overcome the hype.
If you ask me, listening to experts like Bert Ertman is a good place to start.
Watch an interview with Bert about his session:
Flip through his slides:
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}