Building robust, highly available cloud apps should be super easy. So why does it seem so hard to get them right? A common developers’ mistake is to architect cloud SaaS applications the same way they design traditional on-premises products.
On the surface this might sound reasonable for companies cloudifying their applications to catch a new segment of customers. It is a much easier sell if customers do not need to learn a new interface or new way of doing things, but some basic cloud principles can get lost in the translation.
The share nothing model is an important concept that dates back to 1986 when Michael Stonebraker published his seminal paper on the topic. Typically, share nothing is most often associated with cloud database design or cloud storage, but at a meta level it can just as easily be applied to any component in the cloud stack.
Share nothing means that all the application components are carefully segregated so that each customer has its own self-contained environment, application, and access. If a component fails (and it will), it will ideally affect only one customer—not take down the entire customer base.
For example, let's say an application has been written so that the users need remote access to the underlying operating system—not a best cloud practice but common for traditional applications where customers or vendors might provide a bolt-on third party application to add functionality to an on-premise system.
A traditional vendor’s approach to solving the access problem might be to add a shared service in front of the application, such as an SFTP server, to give customers access to their files. Problem solved, right? Well, not so fast.
While it seems counterintuitive, the best approach if share nothing principles are applied properly is for each customer to get its own SFTP server on its own systems. By decentralizing the application and moving it closer to the customer, the risk of multiple customer outages is substantially reduced.
Yes, it might appear less efficient. After all, instead of one centralized server to manage, the vendor needs to provide service for each customer. But the risk that the SFTP server becomes a bottleneck—or worse, a single point of failure—is removed.
Even more attractive from a vendor’s perspective is when the customer manages the SFTP on its own, the risks and responsibility for administering it are shifted to the customer! Everybody wins.
This concept can be applied to all the components in the system, networks, firewalls, bolt-on tools, report generators, or remote access. Ask yourself: Does this service need to be managed for each customer? If the answer is yes, then as long as the customer’s system access can be sandboxed, it might make more sense to bundle it into each customer’s application package.
