Bring Your Own Cloud Keeps You in Control of Your Data

When StatelyDB first started out, we only supported fully-hosted databases run by us. Not only was it faster for us (and customers) to get started that way, it let us take on all the operational pain of running storage.

Working alongside our customers, we found many examples of users who preferred this approach. However, we soon discovered that there are customers who are deeply interested in benefitting from StatelyDB’s Elastic Schema and effortless scaling, but have unique operational constraints that made a fully hosted solution challenging. These include:

• Organizations have strict security requirements that make SaaS offerings a challenge. Information Security teams want complete visibility into where data lives, who has access to it, and if that data is at risk of leaving the perimeter.
• Compliance frameworks often require specific data handling requirements. Stately is SOC-2 compliant, but oftentimes customers are more comfortable self-hosting.
• Bespoke discounts and committed cloud spend are crucial for large customers. A common pattern for enterprise-scale customers is to use their size to negotiate discounts with cloud providers, who in turn ask their customers to commit to spending a specific amount per year. We think asking customers to stop putting dollars against their cloud commitment in order to use StatelyDB is a false choice.

Bring Your Own Cloud

The solution to this is a “Bring Your Own Cloud” or BYOC deployment model. StatelyDB is already separated into three layers: a storage layer (DynamoDB), a compute data plane layer, and a control plane or metadata layer.

In a BYOC deployment, the compute and storage layers run in your own AWS account, while the control plane continues to be hosted by Stately. This lets us continue to manage much of the operations and present a “single pane of glass” through our console and CLI, but the actual stored data doesn’t leave your account - and Stately employees don’t need to access your infrastructure at all.

In this model, you deploy the StatelyDB data plane as a container right next to your application code. You then provision a DynamoDB table in your account to use as the backing storage for your StatelyDB store. Then your application can call the StatelyDB API on the local container directly, and the data plane then talks to your DynamoDB table using standard IAM access controls. The data plane containers make read-only requests to the control plane in order to learn about schema changes or discover maintenance and backfill tasks. Your team still interacts with the Stately web console and CLI to manage your schemas and control tasks.

In this shared responsibility model customers are fully in control of their data, while delegating the control plane operations to Stately and the storage layer to AWS DynamoDB.

Keep in mind that this is a true BYOC model—Stately doesn’t require access to your VPC or special IAM roles, and we won’t deploy anything into your account on your behalf. In fact, it’s self service—you can set up a BYOC StatelyDB deployment yourself without our involvement. We went with this zero trust model by design, because we’ve been on the other side and we know how high a bar we’d set for bringing a third party database into our environment.

Why BYOC is a great fit

The BYOC deployment model has a lot of benefits:

• Data privacy: Your data lives in a DynamoDB table in your own AWS account, so you get to fully control who has access to it. Stately doesn’t need to access your data, and couldn’t even if we wanted to.
• Data sovereignty and compliance: Data only lives in the regions you’ve provisioned, and you can audit traffic and compliance to maintain strict compliance requirements.
• Use your AWS discounts and committed spend: Typically, large AWS customers have negotiated discounts that come with a committed spend amount. Since data lives in a DynamoDB table in your own account, you get billed for it directly at your negotiated rates, and 100% of that spend counts against your committed spend. We launched on AWS Marketplace earlier this year but many customers are surprised to discover that only 25% of their committed spend can be spent on Marketplace.
• Reduced bandwidth costs: You also don’t need to pay for bandwidth between your AWS compute resources and StatelyDB’s API. Instead, you run the StatelyDB data plane colocated with your application, and talk directly to DynamoDB in the same account, avoiding bandwidth fees.
• Improved performance: Since the StatelyDB data plane runs on the same machine as your application code, latency associated with a remote service call and authentication are eliminated.
• Control: While we can help you manage your DynamoDB table, you have final control over its autoscaling parameters, backup settings, storage class, and more.

Of course, you are taking on more setup and infrastructure management than in the hosted deployment model, but not much—following our setup guide is quick and the data plane requires almost no configuration. We have examples for how to deploy the data plane on both Kubernetes and AWS Elastic Container Service (ECS). Let us know if you have another compute environment you’d like us to support.

Keep your data in your own hands

StatelyDB’s BYOC model is the safest and most cost efficient way to get StatelyDB. It’s the best way to get the development velocity advantages of Elastic Schema and StatelyDB’s growing set of features, while maintaining the cost and security benefits of running on your own infrastructure, all in your own AWS account.

To learn more about how StatelyDB can work in your specific environment, contact us. Or if you want to try it out, you can get started with a BYOC deployment or a hosted store self-service today.