If you were to position ‘microservice architectures’ on the Gartner Hype Cycle, right now, judging from the drip-feed of cautionary articles making the rounds, they’d probably be poised near the summit of the trough of disillusionment. Today we spoke to Mark Little, who was in London to lead Red Hat’s Microservices Architecture Developer Day, for a best-practice flavoured opinion.

For Little, what’s striking about the microservices movement is just how quickly it’s accelerated in adoption, given that it was only 18 months or so that Adrian Cockcroft really first initiated the conversation. Conversely, it’s also been a rapid climb to this new territory of doubt. However, Little is pragmatic about the inevitable barrage of FUD coming hot on the heels of the initial hype. “What we’re seeing today in terms of whether microservices are good or bad for you,” he says, “really comes back to traditional distributed systems.”

“You would assume that if your current system isn’t working for you that using microservices is the right solution. But that’s simply not the case”

If you look at the current backlash, Little attributes most of the complaints to “people who were really pushing it at the beginning and who are now just starting to realise it’s not all sunshine and roses, or people who never felt the need for it at all.”

But, he explains, all this negativity isn’t necessarily a bad thing – in fact, in a way, Red Hat “welcome this backlash.” Moreover, Little comments, it’s specifically the parties and individuals that are currently presenting microservices as a quick plug-in solution to solve all enterprise ills that represent the real thorn in the side for the architectural style.

What the anti-microservice discourse really represents is people starting to truly get to grips with these architectures and discovering more about how they work – for better and for worse. As with SOA, “Microservices does introduce new complexities. And, it turns out in some cases at least, you’re better off sticking with your monolithic architecture.”

Little’s overriding concern at this point would be if the current flaming increases, and people keep talking about microservices as a uniformly bad thing, “and slowly start to ignore the good practices that are behind it.”

“if you want to do microservices and you start with Docker and Kubernetes, or any other technology, you are closer to failure than to success.”

In this scenario, “We don’t learn anything. We’ll be here in five years time coming up with a new term, and we’ll have wasted five years.” This situation is something Little views as analogous to the fate of agile in certain quarters over the last few years, and certainly a potential threat for ‘reactive’ methodologies down the line. “Things that have sound practices underpinning them, with some religious ‘fervor’ behind them.”

Little believes that one stumbling block people routinely hit with microservices is to take the ‘tools first’ approach, telling us that, “if you want to do microservices and you start with Docker and Kubernetes, or any other technology, you are closer to failure than to success.”

With microservices (just as with SOA, and distributed systems in general) the key is to start “from a design point of view. What is it you’re going to accomplish? How are you going to design that in terms of services? And, if you’ve got more than one service, how are you going to deploy these services and coordinate them?”

As you experiment, certain technologies will no doubt prove more successful for your system. “Kubernetes and Docker definitely rank highly here, particularly if you’re looking at things like immutable infrastructures and you’re looking at running on Linux. But perhaps you’re not into Docker yet, or you can’t use it, or you’re just really more into Java. There are other ways of doing microservices that don’t require you to use Docker and Kubernetes. But you definitely need to start from the basis of design and architecture before you go into the tooling.”

Ironically, tooling is an area where most microservices beginners tend to focus their efforts. But, Little says, what seems to cause the most anxiety is the question, “How much of this is hype?” When it comes to it, “You’ve read so much about them, and heard so many people talking about them, you would assume that if your current system isn’t working for you that using microservices is the right solution. But that’s simply not the case.”

“Microservices does introduce new complexities”

Before you start smashing your monolith, Little cautions, “You’ve got to understand that, whether you’re looking a microservices, or whether you’re looking at SOA, if you’re looking at distributing your components around a network, then you’re immediately looking at potential network bandwidth issues, performance issues – you’re hooking multiple services across a network, it’s going to be a lot slower and less reliable than they’re only in the same cluster.”

Whilst the microservices bandwagon might be shiny and new,  the issues around it – namely performance and best practice – have been an industry focus for the past few decades. “Microservices doesn’t make them go away,” Little concludes. “In fact, the more fine grained you make your servers, the more you need to consider these things.”

 

Red Hat: Microservices Backlash is a Positive Thing

About The Author
- Editor of Voxxed.com, focusing on all things Java, JVM, cloud-y, methodical, future-fantastic, and everything in between. Got a piece of news, article or tutorial you'd like to share with your fellow Voxxians? Drop us a line at info@voxxed.com

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>