To say the term “cloud” has become overused and misused over the past several years is an understatement, particularly in the enterprise software realm. While I dare not coin a new term, I will humbly submit that at least some qualification of “cloud” software is in order. So how about we start with “cloud-native”? Let’s start with an analogy…
Let’s say you wanted to purchase a new car. You go to a new car dealership that touted its exemplary new car inventory. You went to said dealership and test drove a few new cars with a salesperson who listed their features ad nauseam. You notice that none of the car radios even have a CD player, but it’s not enough to dissuade you. You buy the one you like and take it home.
At some point you open the glovebox and check out the owner’s manual – but there must be some mistake – the owner’s manual is for a car built in 1992! You call the dealership and ask what is going on, to which they reply that it is in fact a new car (the odometer says so), but it was also built in 1992. The dealership explains that they carry unsold inventory from many years in the past – it’s still “new” though.
Should you care? It is still technically a “new” car – it drives ok, has a radio, uses gasoline, etc. What is there to be upset about? Maybe you should’ve qualified “new car” by asking for “brand new car” – but even that’s subjective.
And now to “cloud” vs. “cloud-native”…
Webiplex, my company, is a cloud-native software company. Our software (DocuPeak) was built from day one using cloud technologies, continues to evolve and incorporate cloud technologies, and was designed to provide a 100% cloud experience through all aspects of its life cycle. From installation, configuration, customization, extension, integration / ETL, and of course production operational usage – everything is performed via a Web browser or Web services. No exceptions.
In addition to providing a 100% cloud experience, DocuPeak leverages separate computing resources for separate services all running in a single distributed computing environment. This is how all cloud-native apps work – they are “one big” system with their parts (e.g. UI servers, database servers, background task servers, micro services, etc.) running in separate, scalable, shared and redundant resources.
Furthermore, cloud-native architectures by their nature can leverage 3rd party cloud services as components such as storage (e.g. Amazon S3) or more sophisticated services for things such as big data or AI tasks. Since cloud-native software is built in a distributed component manner natively, using Web service components in a heterogeneous, distributed software architecture is perfectly natural – and sort of the whole point!
So, surely a customer looking to leverage an enterprise software product that’s “in the cloud” will get all of the aforementioned technology and benefits therein, and will place their own business on the cutting edge, in a brand new car. Right?
Wrong. Most are getting a new-old car.
Unfortunately, the majority (and more recently vast majority) of enterprise “cloud” software products deliver their vision of the cloud through what I’ll refer to as “Option 2”. Option 2 comes into existence when an existing legacy software company (e.g. “client/server” or “thick client”) realizes they need some sort of cloud story. “Option 1” is their first thought: Build a new cloud-native solution that might be able to incorporate some parts of the old system, but be prepared for a full rewrite. However, Option 1 is very expensive and would require years of development using talent that the software company cannot hire, and patience the shareholders do not have.
Thus, Option 2: Take the existing software, install it on a cloud VM and call it a day. With merely a decision of where to install the same software, the software company can now market itself as a cloud software product. Is it any wonder this model has gone from derided to acceptable?
So who cares, right? The car still runs fine, even though it has outdated emissions, no safety features, and can’t use new parts or navigation features much less integrate with your iPhone. If you were the customer, and you thought you were purchasing Option 1, a new-new car or a cloud-native solution, which had all the next generation benefits mentioned earlier – how would you feel if you found out you actually purchased a 25+ year old legacy solution simply installed in a different place? How would you feel being duped into buying the new-old car?
So, as an admittedly self-serving public service, I’ll offer some words of advice below in the form of a checklist of questions the enterprise software buyer can ask during demos or slick sales presentations regarding that “new cloud” software from a decades-old software company (answers are provided at the end of the article).
- Are any remoting technologies (e.g. Citrix, Remote Desktop, et. al.) required or optional? (Note that even “optional” is a warning sign).
- Do you have a Web services API layer that provides 100% coverage of all configuration and data application entities with full fidelity to the underlying data layer?
- Is all customization and configuration performed via a Web browser?
- What other cloud-native applications have you integrated with (or they to you)?
- Do 3rd parties develop extensions to your solution through cloud technologies too (i.e. without installing your software locally)?
- Can I access the underlying OS (e.g. VM/Windows/Linux) the software is running upon?
- Is the software broken into distributed services (besides the database) that can run on separate devices?
- Has your software previously been marketed as an “on premises” solution?
- Is my company given a dedicated virtual machine to run my instance?
- Does your solution only work in a certain browser?
- Do I need to install anything on my own client devices?
- Most importantly: Is your solution cloud-native? (If they cannot answer, point them to this article).
Correct answers: 1) No, 2) Yes, 3) Yes, 4) Many, 5) Yes, 6) No, 7) Yes, 8) No, 9) No, 10) No, 11) No, 12) Yes.