.shock - Fotolia
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.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
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
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
Want more of Cameron McKenzie's opinion pieces?
- Software ethics and why ‘Uber developer’ stains a professional resume
- It was more than user input error that caused the Amazon S3 outage
- Why the Amazon S3 outage was a Fukushima moment for cloud computing
- Stop adding web UI frameworks like JSR-371 to the Java EE spec
- Why the whole '12-Factor app' discussion is a fraud
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?