The Rise and Fall of SaaS Islands

Large companies often deploy Nasuni because they want to do away with the expense, hassle, and management complexity of maintaining dozens or even hundreds of file storage silos at different locations around the world. We began solving that original silo problem years ago. Unfortunately, a new type of silo has arrived on the IT scene.

As software vendors encourage users to shift to the SaaS versions of their trusted apps, the data associated with those apps starts flowing into vendor-specific cloud silos. This is not necessarily a problem when you’re dealing only with that app. But who works in a single application these days? At any large company, the average end user is jumping between multiple SaaS applications in the course of a day.

History repeats. The dominant model for computation that made companies like IBM giants was the mainframe model: data and applications were entangled in a proprietary embrace. Software was made by the manufacturers who saw it as a necessary evil to sell their wares. Features were limited. Innovation was slow. The 1970s and 1980s were defined by the enormous gravitational pull that the personal computer exerted on every aspect of the mainframe world. The term user experience was born out of the shift to make computation, for the first time, revolve around the end user. Yet this focus was fleeting. Data was a competing center within this new world order and applications (computation) revolved around the data. Network file system protocols like NFS and CIFS were introduced in order to enable the separation of data from applications. This is also when we saw the rise of a vibrant Independent Software Vendor (ISV) community.

Unfortunately, for all of their goodness, cloud and SaaS in particular have moved compute further from the end-user again. In a return to the mainframe model, applications, in their current SaaS incarnation, are constraining data portability, making it difficult to move data  across these SaaS silos.

Consider Microsoft Office and Teams. Both integrate with SharePoint. All three of them live in a SaaS silo that is controlled and maintained by Microsoft. If you are only working in Office, Teams, and SharePoint, you will manage just fine. But what if you are an architect at a major global firm? Let’s say you’re working on a critical proposal for a major client. You have Excel spreadsheets loaded with key financial models. You have a Teams meeting scheduled in an hour. And you’ve just been asked to move a wall within the proposed design.

That work has to be done in a structural engineering program such as BIM360, but when you’re finished, you want the changes to propagate out to the other applications as well. The revised design will alter the budget, so you’ll want the Excel spreadsheet to reflect that. You’ll need to be able to share the relevant files via Teams, too, so the key parties in the meeting can review these changes. All of this must be done in a way that preserves access controls, too, and you’ll need to share everything externally, in a secure way, with your clients.

The rise of SaaS silos makes this as easy as a mission to Mars.

How is this different from Snowflake?

In the database world, this has played out differently. Snowflake has risen to prominence in part because they found a way to solve their spin on this problem with databases. They evolved beyond data warehousing and developed technology that can be used to integrate databases and SaaS applications across companies for database-intensive workloads.

They’re doing exactly what needs to be done in the world of files. So, naturally, large enterprise customers are wondering why file workflows can’t be integrated in the same manner.

The short answer is that they can be integrated, but the challenge isn’t quite the same. Snowflake merely needs to integrate metadata to facilitate SaaS workflows across distributed databases. I’m not saying the work Snowflake has done is simple. This middleware integration is very complex and very impressive. But from a performance and capacity perspective, mapping metadata fields from databases to a data lake is undeniably easier than integrating file workloads.

Why File Workloads are More Challenging

When a firm creates a 3D rendering of a building, it’s an intense operation. Engineers and designers in different locations need to be able to manipulate that file at the speed of thought — delays kill productivity. This we can manage. We’ve figured out how to store, share, protect and synchronize the associated file data through our cloud-native file services platform. Making that file data available to other SaaS applications both inside and outside that SaaS vendor’s world proved to be more of a challenge. But thanks to our core technology architecture and a dedicated team of very talented engineers, we found a way, developing a solution that supports the shift to SaaS apps while meeting the needs of the enterprise and its end users.

I don’t blame the SaaS vendors for this new cloud silo problem. Of course they want to pull as many users as possible to their apps and store the associated data. It’s a beautiful and more scalable business model. But the SaaS vendors have a myopic view of the needs of large global enterprises. They see the world through the lens of their application. They don’t see it as part of a complex, interconnected web of SaaS apps that each play an essential role within the modern global organization.

This is the sort of problem Nasuni was designed to solve. Our technology isn’t optimized for one file type, use case, or application. Nasuni is built to manage all enterprise files – at any scale. Nasuni unifies the file data associated with all of these SaaS apps through a single global file system backed by unlimited cloud object storage. You won’t have pools of app-specific file data stored with different SaaS vendors. All enterprise data lives in Nasuni and your chosen cloud(s) — and the SaaS apps connect to Nasuni. We knocked down the original silos and we are doing it again with the SaaS-specific clouds.

Let the SaaS vendors focus on their applications.

We are here for the files.