... or: 6 questions to ask your vendors (and 1 to avoid)
The world is getting saturated with cloud-native solutions. At least, if you believe in marketing copy it definitely is. With more than 30,000 SaaS apps in the world today, it’s easy to believe that anyone who claims to have a cloud-native solution are telling you the truth and the whole truth.
Cloud-native is in fact a well-defined term with real requirements. But this gets obfuscated behind jargon designed to get around that fact. So you will see announcements talking about
- Cloud-first
- Cloudified
- Cloud-based
- Designed for Cloud
- Virtualized for Cloud
- Running on Cloud
- Cloud software
- Cloud friendly
Not so fast, partner
This matters. It matters because actual cloud-native software consists of small, interdependent services called microservices running on a cloud platform, making them agile in a whole different way than legacy, non-scalable software. And if you fall for the trick of cloudwashing, you end up with a something that costs more, scales less and works poorly.
Cloudwashing? Yes - the practice of dressing up legacy, on-premises solutions and making them look like cloud-native solutions - but without the actual performance and benefits.
So how do you make sense of the terms? How do you ask vendors the right questions to uncover their bona fides? And what is the one thing you shouldn’t ask?
1: What kind of virtual machine are you running in the cloud?
If the answer is ready to hand and sounds suspiciously like the specs of a desktop under your desk, then they are suspicious. The easiest way to lift and shift legacy software to the cloud is to spin up a machine just like the one you run on-premises, in the cloud. Cloud providers are happy to supply this of course, at a quite high cost. There are many problems with moving something designed for one environment into another without changing it, but the biggest failing of this practice is that scaling becomes so difficult - whenever you reach the capacity of one such “cloud machine” you have to spin up another one, adding a whole lot of highly inefficient resource usage - and cost - inevitably passed onto the end customer.
Remember the microservices from earlier, that form part of a true cloud-native solution? The Holy Grail of cloud native architecture is what is known as serverless. This means that the cloud provider (such as AWS) fully manages the underlying server structure. Microservices are engaged and turned off as and when they are needed, and there is no single central entity (i.e. server) to talk of. The developers of the software focus fully on functionality and not on architecture. Your IT team is the cloud provider’s IT team. And for the end user this means the ultimate in cloud efficiency. Services only run when needed which means higher efficiency, better performance and lower costs are passed onto the end customer.
2: How long does an upgrade project normally take?
There is only one correct answer for this question. No time whatsoever. One of the great advantages of true cloud-native architecture is that microservices can be individually updated, deployments can be incremental and that words like “downtime” no longer apply to updates because they happen on live systems as they are running. If it is necessary to “change virtual machines” or “update the software on your virtual servers”, then you are dealing with cloudwashing again - on-premises solutions have been moved to the cloud and you have gained nothing from the move. The true value of no downtime for upgrades is twofold - obviously there is no downtime, so no lost production hours, and no half-assed backup solutions that cost valuable quality and time. Secondly, end users are always on the latest version, have the latest functionality, integrations and security patches - and they are all on the same version.
3: How often do you release?
Closely related to the first - this one is critical to understand. If you want to truly comprehend, use and leverage cloud-native computing then the words Continuous Delivery have to enter your vocabulary.
If the answer to this question is biannually, quarterly or even monthly, and if the software in question still has a proudly published version number, it is not cloud-native software. Product guru Marty Cagan says great product companies should release at least once a fortnight - for true cloud-native SaaS products the natural frequency is several times a week. If development teams have done their jobs, the individual microservices comprising the cloud-native solution are always ready to be updated and deployed. So whenever a change is done and tested, no matter how big or small, it can be deployed to not just a single deployment but to every production environment globally.
Why is this a good thing? For the end customer it means that upgrades never turn into projects (see the previous point). It means access to the latest in technology. It also means security issues can be addressed immediately and globally, often before the customers themselves discover any problem.
4: What are your integration points?
This is a less-publicized but equally important factor in separating cloudwashed from cloud-native software. While the former addresses integrations in the old way, often with customer-funded major development projects, cloud-native software by its very nature is easier to integrate - especially with other cloud-native software.
Leveraging well-documented APIs and new technology, great ones offer low or no-code integrations, using web hooks or simple URLs to trigger actions. This puts a great deal of flexibility and power into the hands of the end user, because they are able to mix and match best of breed solutions and build a solution from off-the-shelf cloud native software, and not be locked into a walled garden of static legacy software only compatible with some options.
5: What kind of choice do you offer in AI integrations?
In 2024 if the answer here is “none”, you have a problem. If it is “We have a built-in default integration with ### only” then your problem is almost worse. In a world where the AI competitive landscape shifts on an almost daily basis, as a media creator you have to avoid AI vendor lock-in.
A piece of cloud-native software built with good, easy-to integrate technology, should be able to offer you the ability to hook into your own choice of AI service for anything from translation through transcription to generation. It is impossible for anyone - including so-called AI experts - to forecast which specific service will be best a year, quarter or even month down the line. The right answer to this is “You can choose to use whichever supplier you want and change whenever you want.”
6: What does your roadmap look like?
Why does this matter? Because if someone already has decided and are willing to tell you what they will develop for the next 6 quarters, then this is not a display of planning strength - it actually comes from two problems: First, it is likely that they are working on an inelastic stack that locks-in the direction of the software so much that the cost of straying from this path is so high it will not happen.
Second, with the speed of current technological changes it is OK to have long term goals, but they have to be nimble, agile and possible to drop at a moment’s notice. The good answer is; we have a product vision - a long term stretch goal to help us make the product the best it can be. Beyond that - we are currently working on X, are considering Y but are monitoring the landscape and listening to our customers to learn everything we don’t know.
So... what should you avoid asking vendors to find out if their tools are cloud-native?
7: Are your tools cloud-native?
If you are very, very lucky, the answer will be yes, and be true. Much more likely; you will get either a yes that is untrue or misunderstood. Or, you will unleash a torrent of prepared marketing speak designed specifically to “message” around this very question. Some, several or all of the words in our list at the top will be used to give the impression that software X and Cloud are best buddies. There will be talk of “code rewrites from the ground up” and “tight partnership with cloud platform providers”. But all of that will not make the actual answer yes.
Working on-premises has it’s perfect-fit use cases. So does hybrid. And cloud-native is great for many modern live production workflows. But inefficient, cloudwashed on-premises software is a poor fit for anything and everything.
