Summary Bullets:
• These days, everyone is doing containerization in a mad, industry-wide rush toward what appears to be true cross-cloud compatibility.
• However, enterprise buyers need to be aware that when it comes to containerization and microservices, there’s a huge difference between compatibility and capability.
Back in 1964, media futurist Marshall McLuhan penned the often repeated but somewhat baffling phrase, “the medium is the message,” in an attempt to highlight the importance of the “where and how” of storytelling. To Mr. McLuhan, a film, a novel, and a comic may all tell the exact same story about a boy and his dragon, but importantly each would do so using very different conventions regarding the unfolding of the story, let’s say the manner in which each handles flashbacks. Those differences in turn shape our understanding of the story in unique ways.
Flash forward to the present and among technology providers, particularly those endeavoring to make the architectural leap from premises to cloud, Mr. McLuhan’s more than 55 year old notion seems strangely applicable if not downright prophetic. Let me explain: as a global market trend, the idea of abstraction through containerization technologies like Docker has entirely reshaped the global software landscape, forever altering the way developers create software. In short, abstractions allows developers to write once and run “virtually” anywhere by turning monolithic applications into a series of highly standardized yet extremely malleable microservices.
But there’s a lot more to gain than mere portability. A properly containerized microservices application allows software developers to innovate much more rapidly, since discrete functionality can be in essence walled off from the rest of the application via independent API calls. If done properly (as in consistently across all microservices), these APIs also allow individual functions to be re-composed (or reused) by both the original developer and any authorized third party developer as well. Any technology provider that promises Platform-as-a-Service (PaaS) capabilities is likely leveraging microservices in this way.
In fact, whether building a full-borne PaaS or simply standing up a stand-alone app, most independent software developers (ISVs) are currently opting to re-architect their software using microservices. Just last week, analytics player Sisense issued a press release touting the fact that it had fully re-architected its software, citing massive gains in delivery, reliability, and scalability. This makes sense for a vendor like Sisense, which specializes in embedded analytics, where its partners and customers take features from Sisense and drop them into their own line of business solutions.
This endeavor was no small task for Sisense, mind you, as the vendor had built its original solution directly on top of a predominantly on-premises rendition of Microsoft Windows. Clearly for Sisense (and for many ISVs), the cost of re-architecting software via microservices appears worthwhile.
And that brings us back to Marshall McLuhan. On the surface, microservices appear to be the perfect solution to the problem of platform portability, particularly across disparate cloud platforms (e.g., Amazon Web Services and Google Cloud Platform). So long as Docker/Kubernetes are in play, enterprise buyers can run their containerized applications of choice on their containerized platform of choice. This in essence blows Mr. McLuhan out of the water, as the medium (that is the platform) is in fact no longer the message. The software is the message. The platform, sadly, no longer matters — at least in terms of defining the shape of the stories told on that platform.
Not quite: as with most complex endeavors, containerization may indeed make software truly portable, but trust me, the platform still matters, as does the way in which ISVs containerize their software. For example, if an application has been converted to a set of microservices and written in a monolithic programming language like Java, which presumes the need to handle tons of memory allocation complexities for a large application, the resulting set of containers may end up running less efficiently than before.
Similarly, if the newly containerized application has no visibility into the platform’s underlying services, that software will in essence be running blind. On AWS, as just one example, developers can stand up their own container services, but if they don’t use the Amazon Elastic Container Service (Amazon ECS), then their software won’t have access to a staggeringly large array of beneficial underlying services. These features include the ability to provision containers without having to first provision server instances, direct access to valuable services such as machine learning (ML) modeling, edge computing capabilities, global (or regional) data storage, responsive system-wide monitoring specific to containerized environments, microservice-level security, and even steeply discounted runtime costs through automatic resource allocation.
This same story repeats across each and every major hyper-scale cloud platform on the market. This is why major ISVs typically anchor their software to a given platform, as it allows them to gain access to these substantial benefits and pass those along to their customers. Enterprise buyers, therefore, need to ask their ISVs to carefully and completely specify both how their containerized software was built and how well it integrates with the underlying services on a given cloud platform. In short, portability does not equal capability. The medium is still very much the message. And the cloud most definitely matters.
IT Connection 