Software manufacturers are leaping on the idea of containerisation as a quick route to true cross-cloud compatibility; however, enterprise buyers need to be aware that there is a huge difference between compatibility and capability.
Among technology providers, particularly those endeavouring to make the architectural leap from premises to cloud, the idea of software abstraction through containerisation 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 standardised yet extremely malleable microservices.
Data abstraction and microservices
But there’s a lot more to gain than mere portability. A properly containerised 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.
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.
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 endeavor was no small task for Sisense, since the vendor had built its original solution directly on top of a predominantly on-premises rendition of Microsoft Windows.
However, this was a wise move for Sisense, which specialises in embedded analytics, where its partners and customers take features from Sisense and drop them into their line of business solutions. Clearly for Sisense (and for many ISVs) the cost of re-architecting and thereby modernising its software via microservices will be worthwhile in the long run.
On the surface, microservices appear to be the perfect solution to the problem of platform portability, particularly across disparate cloud platforms, such as 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. Does this mean that platform no longer matters, at least in terms of defining the shape of the software running on that platform?
Not quite. As with most complex endeavours, containerisation may indeed make software truly portable, the platform most certainly still matters, as does how 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 containerised 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 AWS’ own 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 containerised 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 containerised software was built and how well it integrates with the underlying services on a given cloud platform. In short, portability does not equal capability. And the cloud most definitely matters.