.shock - Fotolia

Opinion

Is fear-mongering driving the adoption of microservices and containers?

Nobody questions the importance of microservices and containers, but is unfettered advocacy becoming problematic?

Cameron McKenzie
By
Published: 11 Apr 2017

We've seen this all before. We've seen the industry get overwrought with high-profile thought leaders prognosticating about a beautiful future that will be brought to fruition if the patterns and the approaches they advocate are embraced across the board. And it always goes without saying that bringing their vision to reality means using the tools and leveraging the services of the vendor for whom these thought leaders work. As was said, we've seen this all before.

Thought leadership without integrity

Organizations successfully implementing SOAP based web services using XML were convinced to switch everything over to RESTful web services that marshaled JSON across the wire. Software that was running well against a relational system was re-architected to use a NoSQL database for fear that the legacy system wouldn't scale. Sometimes the change was needed, other times it was not. Every time, the vendor profits.

In terms of fear-mongering and hype, there is currently an ongoing mania in the world of microservices and containers advocacy that is bothersome. This isn't to suggest that microservices and containers advocates are all wet, or that there's something wrong with EIP patterns. A wealth of articles on microservices and containers clearly demonstrates that TheServerSide is a promoter of these technologies, not a detractor. But when promotion turns predacious, which is how some vendors in the enterprise Java space are behaving, it's time to call foul. 

There's nothing new under the sun

It's perplexing to see microservices and containers advocates behaving as though they've run across something new and earth shattering. Stateless services seem to be the revolutionary concept microservices design advocates espouse, as though nobody prior to them had ever consumed Roy Fielding's twenty year old dissertation on REST and the design of network based software architectures. Personally, I remember talking to Mik Kersten at JavaOne 2009 on how the whole industry was moving state out of their applications, and how that was having a positive impact on scalability. The other obvious benefit was that it made applications more capable of taking advantage of cloud-based resources. It was obvious to Kersten way back then, and it was equally obvious to me. But it obviously wasn't that obvious to those who are peddling microservices and containers as some kind of brand new concept. 

Microservices design and cloud-native

One of the mantras the Chicken Littles of this space keep chanting pertains to the need for everyone to start writing cloud native apps. The Linux Foundation has a Cloud Native Computing Foundation that promotes the development of technologies like Kubernetes, CoreDNS, Linkerd and Prometheus, all of which are pivotal to the world of managing containers and container based deployments. When millions of microservices are deployed to millions of containers, managing and orchestrating those containers is hard, which is why the aforementioned projects exist. But from what I have seen, the term cloud native has been hijacked by those who want to scare enterprise organizations away from successful RESTful development methodologies and move them onto revenue generating proprietary ones. It's a marketing strategy that's as disingenuous as it is disgraceful.

A recent Gartner report actually recommended that organizations design their applications to be 'cloud native', regardless of whether they need to be used in the cloud or not. That's how crazy the fear-mongering has become. Othewise intelligent people are advocating for it even if it isn't needed. According to Gartner's Anne Thomas and Aashish Gupta, organizations should "design all new applications to be cloud-native, irrespective of whether or not you plan to deploy them in the cloud." This type of 'one size fits all' mentality is never correct in the world of enterprise software development. It's a simple-minded philosophy not worthy of respect.

Enterprise fear-mongering at its best

Everyone in the industry gets it. Ever since software developers were coding stateless EJBs in version 2.0 of the spec, it was understood that if you wanted to scale, you had to move state out of your applications. And on the client side, everyone that can is pushing state down to the browser by using JavaScript frameworks such as Handlebars and AngularJS. This isn't a new concept. It's been how the middle-tier has evolved over the past ten years, making true middle-tier development more powerful and focused.

Microservices design and implementation, along with the use of container based deployments and cloud native tools like Kubernetes and CoreDNS is another important piece of the enterprise software puzzle. But treating microservices and containers like a panacea, telling organizations to adopt them even if they aren't going to need them, and suggesting that successfully deployed projects will spit and sputter if these technologies aren't integrated into them is nothing more than cowardly fear-mongering, and quite frankly, it's getting a little tired.

You can follow Cameron McKenzie: @cameronmcnz

Tweet this article!

Want more of Cameron McKenzie's opinion pieces?

Next Steps

Here is the unified theory of DevOps and cloud native you've been looking for 
Will cloud based performance ever compete with Java performance on cold iron? 
Will the term 'deprecated Java class or method' be given meaning in Java 9?

Dig Deeper on Core Java APIs and programming techniques