Building Services Is Hard – And We Like It That Way
A tool can be simple, but it is usually singular in its purpose. And when a product or technology changes, any given tool can be quickly rendered useless. Some probably have a wrench at home, but when the plumbing problem turns complex because of new and more automated systems, many are likely to turn to a plumbing service.
I know this isn’t the first time that ‘backup’ and ‘plumbing’ have been used in a technology blog. But in the context of Clumio’s secure backup as a service, the analogy holds water. Clumio is not a tool, it is a service. It is a short and simple statement. However, it has profound implications when it comes to software design and operation. We will go over a couple of examples in this blog to illustrate the point.
Simplicity vs Complexity
When delivering a software tool, it is always hard to strike the right balance between ease of use and advanced features that benefit the user. Those advanced features come at the cost of added complexity. Complex software means mistakes can be made by the end-user or special training is required – slowing implementation and time to value. Sometimes the advanced features are sacrificed in the name of simplicity, but the result can be watered-down software that doesn’t actually solve the user’s problem.
On the other hand, software as a service providers like Clumio develop software on the public cloud to be operated by them – not directly by the end user. We live in it every day, so we are highly motivated to get it right. The Clumio software stack is created and operated by experts with deep domain and public cloud expertise. This means that we can focus on building the perfect backup service without transferring any of the complexity to the end user. The user can subscribe to a service (simple) that provides business value while Clumio worries about the details (complexity) completely behind the scenes. It is in this way that we deliver backup as a service with no constraints.
Proactive vs Reactive
Unlike the example above where we discovered that a well-designed service can solve for both simplicity and complexity, IT will always want to be proactive wherever possible to avoid being in reactive ‘fire-drill’ mode. Because Clumio is built on the public cloud, we can design in ‘observability’. This is an absolute requirement to provide an easy to use and reliable service (proactive) yet is nearly impossible to retrofit into an existing software suite written for the legacy, on-prem world (reactive).
Observability means our software stack can and must detect failures and collect metrics and logs to provide an accurate view of the entire system. This is done per-customer and also per-customer per-operation. A tool is not expected to magically detect problems and fix them, but a service must do both.
Clumio detects failures and sends alerts to the engineering and support teams with a detailed description and context of the issue so that the problem can be diagnosed efficiently. At Clumio, almost all issues are automatically filed by the support team and fixed without any end-user intervention or alerts.
These are two important principles that guide Clumio as we build a secure, backup as a service for the enterprise that we call Authentic SaaS. And I would be remiss as I close this blog if I didn’t point out that a tool cannot be made into a service after the fact. As enterprises move aggressively to cloud, they can use Clumio to protect workloads like VMware Cloud on AWS and native AWS services. Our service, built with these principles, will adapt to future workloads so the enterprise can have one data protection strategy regardless of where its data lives. No single tool designed for a singular purpose will be able to transform itself into this kind of service.
In a future blog, I will go into more detail about how we do it. In the meantime, stop by our booth #233 at VMworld and learn more about how the Clumio service can eliminate backup complexity for your enterprise, on-prem and in the cloud.
