Cloud-Native Technology As a Service

What does it mean to deliver cloud-native technology as a service? The “as a service” moniker has become an irresistible marketing tag. What we used to call software as a service (SaaS) has mushroomed into web services, infrastructure as a service (IaaS), platform as a service (PaaS), cloud services or just cloud.

The challenge is how to distinguish real “as a service” technology from cloud-wash or lipstick-on-legacy imitations. Here are 6 things to look for in technology that has been architected to be delivered as a service:

1. It must be someone else’s problem.
2. It must offer superior, consumption-based economics.
3. It must be resilient and reliable.
4. It must be scalable in every dimension that matters.
5. It must be easy and fast to connect into and provision.
6. It must reach everywhere that is wired to the Internet.

These aren’t simply potential characteristics of an “as a service” technology. Each one is a requirement. Let’s look at them one by one.

1. It must be someone else’s problem.

The original SaaS was Salesforce. Their radical new idea? Let us run the software for you. This expanded the market for CRM tools dramatically because many companies that needed CRM did not have the resources to run their servers. Today, the entire productivity suite (think Microsoft 365) has been subsumed into SaaS. I haven’t met one person in IT who misses running their own email servers. Virtualization and faster, more reliable networks have allowed for every critical function in data centers to be delivered as a service. What you should end up with is a near-zero-maintenance solution. You shouldn’t have to worry about your service solution operating properly. The provider should do that for you.

2. It must offer superior, consumption-based economics.

Although the idea that it’s someone else’s problem makes “as a service” sound a lot like a Managed Service Provider, the cost structure is very different. Salesforce had to re-write the entire CRM stack as a multi-tenant, scalable and resilient Web Service. That gave them real technology leverage which they were able to translate into lower operating costs for their tens of thousands of customers.

Salesforce set the standard. Today, a service offering must deliver superior economics via a consumption model. Analyzing the costs will not necessarily be a straightforward, apples-to-apples comparison relative to legacy offerings. But when you consider the total cost of ownership of all the solutions and functions that a new service renders redundant, the economic advantage of the new alternative should be clear.

3. It must be resilient and reliable.

A successful service also needs to be resilient, durable, and reliable. It must be always on and deliver the service no matter what. Many enterprises were reluctant to adopt cloud services in the early days because the very idea of relying on someone else’s hardware instead of deploying and managing your own IT infrastructure felt too risky. Today, the cloud and services like Snowflake have proven so reliable that the inverse has become true. Choosing to depend on your own hardware is now the riskier strategy. I’d much rather rely on Microsoft or Google to keep our company email functioning than an array of internal email servers distributed at our offices around the globe.

4. It must be scalable in every dimension that matters.

In the age of cloud, there is no excuse for delivering a service that hits scale limitations. A modern service solution should be infinitely scalable and infinitely available. Nothing should have to be redesigned or installed to deliver additional levels of scale or availability. There should be no architectural limitations that force customers to set up and deploy new volumes once they grow to a certain point, as with the NAS giants and their cloud wash solutions . These cloud-in-name-only offerings force customers to manage multiple volumes and sacrifice both the hands-off simplicity of requirement #1 and the favorable economics of #2.

Unlimited, efficient scalability should be non-negotiable.

5. It must be easy and fast to connect into and provision.

A true service technology must be easy to deploy and make available to any user, division, department or any third-party systems that need to work with it. This should be as close to instantaneous as possible, so that new employees or newly acquired companies can immediately start taking advantage of the functionality the service provides, whether that relates to applications, data, or virtual infrastructure. No hardware should be necessary. You shouldn’t have to enlist local technology experts or fly your own staff across the world to make it work. Provisioning new sites and connecting new people should be simple, fast, and seamless. The technology must provide an API that allows every function to be configurable and monitored from an external system.

6. It must reach everywhere that is wired to the Internet.

Finally, the true service must be available anywhere with an Internet connection. Think of Spotify. If I want to play my favorite album for everyone at a friend’s dinner party, I don’t need to bring a copy of a CD and a music player. I open Spotify, connect to the local speaker, and we all listen. The music service is available wherever and whenever I need it with absolutely no hassle or difficulty. Every enterprise service offering should operate the same way. At Nasuni, we can all read and write emails, message each other on Slack, manage campaigns in Salesforce, access and share files and more from anywhere with an Internet connection.

The “as a Service” providers delivering on all six requirements are upending their respective markets. Cloudflare challenged Cisco’s networking dominance and increased revenue by 17X. Datadog had the same impact on the performance monitoring space, taking over an industry once topped by Solarwinds. These companies and others like them are not experiencing massive success because they leveraged the right marketing terms and declared themselves to be services providers. They were built to provide services. They were architected that way from the ground up, and their success proves that architecture matters.

This is precisely what sets Nasuni’s cloud-native technology apart from our competitors in the file data space, including both the cloud-era startups and the traditional, legacy file storage providers and their cloud-washed offerings. We deliver on each of the requirements outlined above, and the legacy NAS technologies do not, because Nasuni and its services were built for the cloud.