If you haven’t already watched this hilarious video I made with Ray Le Maistre over at TelecomTV, you totally should.
In it, I channel American late-night TV host Dave Letterman to share a list of the top five signs your vendor’s “cloud native” product may not be cloud native. It’s my attempt to cut through all the buzzwords and B.S. from telco vendors trying to convince their customers that they’re jiggy with all things cloud.
TELCODR FOUNDER AND CEO DANIELLE ROYSTON BELIEVES THE TERM ‘CLOUD NATIVE’ IS BANDIED ABOUT TOO FREELY AND SO HAS COME UP WITH FIVE KEY QUESTIONS TO CONSIDER WHEN CONFRONTED WITH A VENDOR’S CLOUD NATIVE APPLICATION.
We had a lot of fun filming it, and I hope it makes you seriously LOL! But I also wanted to go a little deeper into each item on the list to talk about why these are really great litmus tests for your vendors and good questions for telco CTOs and CIOs to ask when you need to suss out who’s really doing it right. To that end, I started with a helpful chart.
Regular readers know I love Twitter (even AFTER Elon has bought it), and that’s where I saw this chart, drawn by an unknown genius and posted by Jeff Barr, the cloud evangelist for AWS (basically, he’s like me, but WAY MORE IMPORTANT).
The graphic explains the difference between on-premise, infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS) using… DELICIOUS BACON. It’s a great analogy to explain the different uses of the cloud.
At the top, we start with the whole hog: on-premise software.
On premise is the world that telco is used to—and is the completely do-it-yourself option. You buy (or build) and manage everything—the hardware, software, and operations of the application—yourself. That means installations, customizations, integrations, upgrades, security updates, hardware failures … everything. AKA, the HARD WAY to do things. Brutal.
The next level is IaaS, the “raw bacon” option.
Here, you don’t have to manage the hardware, like with on-premise, but you still need to manage everything else. Someone else is managing and paying for the hardware refreshes, but you still have to do a lot of work that isn’t the primary focus of your business. Slightly better than on-premise, but not by much.
PaaS is your cooked bacon.
There’s a development environment and orchestration environment for the software, so it’s easier than IaaS, but you’re still doing some work. You’re abstracting some of the management of the software, but you’re still having to manage the system upgrades, customizations, and integrations. Again, a step in the right direction, but you still need to do some technical work to manage the system instead of focusing on what matters: your business.
Last on the list is where I think telco needs to be: SaaS.
Someone else does the hard work; you just enjoy it. There is a loss of control of upgrades and management of the applications, but on the upside, they’re someone else’s problem. These activities are now included in the cost of software. Analysys Mason recently released a report on SaaS software being able to reduce OpEx costs for telco by 25 percent; IMHO, I think it’s more.
Now, let’s get to the fun part: the Top 5 List. Even though I was a little tongue in cheek with my list, there are some easy questions you can use to evaluate your vendor’s claim that its application is “cloud native.” I put that in quotes because the term is everywhere, yet there are definitely differences in how companies are approaching the cloud. So, I put together this little list to help you telco execs out.
If your vendor says “private cloud is the same as public cloud,” it may not be cloud native. You know what it definitely is, though?
Lipstick on its on-prem pig! (Well played, Alpesh Desai.)
Private cloud is NOT the same as public cloud. With private cloud, the computing infrastructure and services are bought, maintained, and deployed over a private network by you. To be honest, it’s closer to on-prem than cloud, except that it’s MORE EXPENSIVE than on-prem. It’s also more complex to operate.
With public cloud, it’s at least IaaS, and at best, SaaS. You hand over some control and responsibility in exchange for lower costs, no maintenance, infinite scalability, and high reliability.
Watch out for ambiguous jargon. If your vendor says its solution “runs on all the clouds,” or that it’s “cloud agnostic,” or if the team won’t specify whether it’s public or private cloud, it may not cloud-native. Your vendor may have done something to make its old on-prem solution run on the cloud, but if it doesn’t use native components, then it’s #fakecloud. You want the real thing.
Questions to ask your vendor:
Telltale signs of real, cloud-native solutions:
If what makes your vendor’s solution “cloud native” is Kubernetes, it may not be cloud native! Kubernetes is a cloud-native container system. Just because Kubernetes is cloud-native, and your vendor’s app uses Kubernetes, it thinks it can now say its app is cloud native.
While I suppose that’s technically true, it’s probably the number-one approach vendors are taking to move their application to the cloud. It’s a little bit of a cheat, though, and really just “lift and shift.” My friend Forrest Brazeal calls that approach a ticking time bomb. And I agree.
Don’t get me wrong: Kubernetes is a great tool, and sometimes it is the right approach. Make sure you (or your vendor) are using it the right way for the right reasons. It can accelerate getting to the cloud quickly, and help you realize some quick cloud benefits without taking on the full risk and expense of rebuilding. I advise companies to use it as a first step in a more complete move to the cloud; it begins the shift of capital expenditure (CapEx) of an on-prem solution to the operational expenditure (OpEx) of the public cloud. That can be useful in the first moves to the public cloud.
Questions to ask your vendor:
Telltale signs of real cloud-native solutions:
If it uses an expensive, third-party database—that starts with an O!—instead of a cloud database, it may not be cloud native. You-know-who is going to be a suuuuuuper grumpy cat when I say: cloud databases are better and cheaper! Sorry-not-sorry, Larry.
Most of the apps in telco were built before the cloud. Most of them are designed to use great-but-expensive relational, SQL-based, third-party databases: SQL server, Oracle, Postgres, etc.
For those vendors that have made the investment to refactor their legacy apps for public cloud, most have ported or changed their product to use a cloud-native database from the public cloud vendor they’re running on. For example, Azure has Cosmos. Google Cloud Platform (GCP) has Spanner. AWS has DynamoDB. Cloud databases are more robust and scalable, have built-in elasticity and failover, AND they’re cheaper.
What’s so great about public cloud databases is that there are different types for different workloads: single table, relational, graph, or even dumb storage. Each type has pros and cons depending on the problem you’re solving. If your vendor has started to use different databases for different types of problems, it might be doing it right.
It just doesn’t make any sense to run non-cloud databases in the public cloud. Licensing costs to use them in the public cloud are high, and options are limited. Just ask GCP about running an Oracle database in its cloud—it won’t let you, due to an Oracle-Google licensing limitation related to the Compute Engine hypervisor.
Questions to ask your vendor:
Telltale signs of real cloud-native solutions:
If you ask your vendor if its solution is serverless and it sticks its head in the sand, it may not be cloud native. Don’t be an ostrich!
I know I said I was going to clarify the buzzwords, and here I am bringing a new one to you. I wouldn’t do it if it wasn’t important.
“Serverless” apps aren’t really serverless; what makes them serverless is that they don’t need pre-configured, pre-reserved compute instances. That means the software itself knows what it needs and decides what compute to use. No manual intervention required! Serverless computing allows you to keep costs low because you’re not reserving preconfigured instances and capacity, so your app can run as lean as possible until it’s necessary to scale up. These apps are truly dynamic, and as a result, oftentimes cheaper to run.
Not every system can or should be serverless, but it can be more cost effective and faster. Here’s a true story: For our charging system at Totogi (where I’m acting CEO), we first built the system using Kubernetes, and then switched to serverless because it was faster (K8s was operationally expensive, and speed matters a lot in charging).
Your vendor should definitely know what this is, but most won’t. It’s a tough question for a telco to ask a vendor because it’s a hard thing for them to fake.
Questions to ask your vendor:
Telltale signs of real cloud-native solutions:
If you ask your vendor if its cloud solution is 80 percent cheaper than the on-prem version and their face looks like this, it may not be cloud native!
If your vendor is succeeding at numbers two through five in this list, the price should be significantly lower than its on-prem version. If your vendor isn’t doing it right, it’s going to HATE answering this question! Over at Totogi, we’re doing 2-5, so a low, low price is easy for us to deliver.
Questions to ask your vendor:
Telltale signs of real cloud-native solutions:
That’s the list! We’re hearing vendors say a lot of things these days to describe how they’re “in the cloud.” Everyone wants to check that box so they can be in the cloud club—without really doing the work or having the expertise to bring you the benefits. Don’t believe the hype! Carefully evaluate the solutions you’re picking as you make your move to the cloud. I will channel my inner mom voice and say: make good choices, kids, and if you need help evaluating any vendor’s solution, give me a holler—I’m here to help you out!
Recent Posts
Get my FREE insider newsletter, delivered every two weeks, with curated content to help telco execs across the globe move to the public cloud.
"*" indicates required fields
