Winning the ROI game with Vizion Block Storage

It always amazes me how much time and effort is invested into saving money. This is certainly the case with our cloud service, and our effort has resulted in the creation of significant intellectual property. We recently filed a few patents that focus on the unique ways we conserve valuable resources within a cloud environment. Take AWS for example.  A costly resource within AWS is Elastic Block Storage (EBS). EBS is commonly the largest component of any AWS bill. As your service grows, your databases will get larger, more databases will be created, more data will be ingested and managed, and all this requires additional EBS. More EBS can mean, as you add more customers, your cost per customer is not decreasing fast enough to meet your margin targets. This could make your life very difficult.

We have seen other companies attempt to control the growth of EBS by tiering data. To slow the rate at which they have to add EBS, they move the older data of their customers to a lower-cost tier, like one of the affordable S3 offerings. They still require more EBS as they add customers, databases, and ingest more data at a faster rate, etc., but at least they can re-use the EBS of the older data. The problem with this approach is that if their customer wants to access that data, for example, to search for critical information from a year ago, they have to wait for hours if not days for the result. All of the data from the relevant time period must be moved back into EBS and then searched. Commonly a new compute cluster with its own EBS is deployed to handle these long tail searches. This is both costly and excruciatingly painful for the customer.

A Novel Approach with Vizion Block Storage 

In, we have taken a better approach. Our EBS only grows as we add compute instances.  It does not grow as we add customers or data. All data is ingested into our own version of EBS, our Vizion Block Storage (VBS). VBS is a scale-out block-based cache that is shared by all compute instances within a cluster. It is the only component in our serverless Vizion service that uses EBS.  All ingested blocks into VBS are immediately uploaded to S3.   Only the most recently and frequently accessed data is stored in VBS.  Each compute node deploys a fixed amount of EBS to support VBS.  When a block is requested, any node can respond, as any block is only stored by at most one node. And any block can be read at any time. If a block is not cached, it and blocks written around the same time are retrieved from S3 and stored in the VBS cache.

All of the applications that comprise our scale-out service use VBS to store and retrieve blocks of data.  In fact, any application that employs a block interface can benefit from VBS. For example, a couple of our service offerings (ESS and LSS) utilize an ELK (Elastic Search, Logstash, and Kibana) stack.  Directly or indirectly, each component of ELK leverages VBS to store its data.  So, as the Elastic Search index grows or more logs uploaded, more EBS is not deployed. This also means that you can keep large data sets for an extremely long time without breaking the bank. Another example is our use of Cassandra as our scale-out database to store the metadata needed for our service.  Cassandra uses VBS to write and read records.  As the size of the database grows, more EBS is not required.  In fact, more databases are not needed as we add more customers.  A second cost optimization is using multi-tenant databases. New customers share one database with other customers. Only if the size or load of this database becomes too high will another database and the necessary nodes be created.

A third optimization focuses on performance and reliability.  To accelerate ingesting blocks and to guard against their loss in the case of a node failure, VBS employs a distributed journal.  Each block is written to both the distributed journal and the block cache at the same time, allowing VBS to acknowledge the block before it is written to S3.  This preserves optimal performance of the application, and If a node were to fail, another node would make sure the block finds it way to the object store.

Finally, is implemented as a collection of containers that are managed by Kubernetes. Kubernetes expertly employs the optimal number of each container type to maintain the desired level of service.  We have added metrics to help Kubernetes make the best deployment decisions possible for our applications.

In summary, is at the bleeding edge of cloud-based service architectures.  It uses a variety of novel approaches to keep our costs low, ultimately allowing us to pass these savings to our customers. I encourage you to try it as it provides a clear ROI by allowing you to analyze your logs and data at a very affordable cost.  And we have made every effort to make onboarding as painless as possible, allowing new customers to be up and running with their own ELK stack within minutes.