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.

Related Company Profiles

View all

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.

How well do you really know your competitors?

Access the most comprehensive Company Profiles on the market, powered by GlobalData. Save hours of research. Gain competitive edge.

Company Profile – free sample

Thank you!

Your download email will arrive shortly

Not ready to buy yet? Download a free sample

We are confident about the unique quality of our Company Profiles. However, we want you to make the most beneficial decision for your business, so we offer a free sample that you can download by submitting the below form

By GlobalData
Visit our Privacy Policy for more information about our services, how we may use, process and share your personal data, including information of your rights in respect of your personal data and how you can unsubscribe from future marketing communications. Our services are intended for corporate subscribers and you warrant that the email address submitted is your corporate email address.

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?

Containerisation

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.