Tag: distributed database

PingCAP’s Innovative TiDB Database – Techstrong.TV

PingCAP CEO Max Liu discusses PingCAPs innovative TiDB database and cloud technologies for OLTP + OLAP, and PingCAP’s commitment to open source going back more than seven years. Max shares some exciting news about the very first HTAP Summit, coming to the bay area soon. The video is below followed by a transcript of the conversation.

Mitch Ashley: Well it’s a great pleasure being joined by Max Liu. Max is cofounder and CEO of PingCAP. Welcome Max.

Max Liu: Hi Mitch, good to see you.

Ashley: Good to see you, thanks for joining us. So, we’re gonna talk about database, one of my favorite topics. Before we do that, would you introduce yourself? Tell us a little bit about you and also tell us a little bit about PingCAP.

Liu: Well, thanks for having me. I’m Max Liu, CEO and cofounder of PingCAP. And our product is TiDB, T-I-D-B which is an open source distributed database. You know, I’m a software engineer for more than 15 years and I still enjoy coding. Before I started PingCAP I spent lots of my time, you know, designing and table schema carefully and fixing those database scaling issues and trying to make coding faster. And since, so many engineers, no developers, wasting their time again and again doing the same thing.

So, we started the TiDB project to build a dream database for engineers to handle scalability from terabytes of data to petabytes of data to let developers focus on C-code and SQL, sorry, and, for their business logic. So they can enjoy, you know, sleep so you can get more sleep. Not only, you can still keep your hair, not like me, right? So, enjoy or other fun.

And, also, many people have found that our company name is interesting. PingCAP is actually composed by two parts, ping and CAP. So, CAP is the C-A-P theorem, you know? Standing for consistency, availability, and tradition tolerance. You know, it’s like an ideal case for distributive database, right? So, Ping is just the narrowed comment while you are trying to connecting to anything you will ping it, right? So, I love this theorem so much. And, we want to keep as close as possible approaching CAP. So, that is where we, you know, use the name PingCAP. That is where the name comes from.

Ashley: Makes total sense.

Liu: Yeah, it’s quite tactile, right?

Ashley: [Laughs] well, you know, it cares meaning and that’s one of the great things. And, I can sense already about your story, Max is, it’s great to talk to fellow entrepreneurs who – you know, it’s one thing you would say, “That’s a great idea, let’s go build a product for that.” It’s another thing when you’ve experienced that challenge, you’ve lived this problem, you’ve spent maybe, many hours, maybe many years, right? Kinda, being the developer but, trying to be a DBA, and a developer, and a data analyst, and a data designer. But, you’re not really, you’re a developer, right? You don’t want all the hassles of all those other jobs. So, how do you make it easier, how do you make it better for people? Which, sounds like what you’ve tackled, what you’ve done with PingCAP and with TiDB. Am I on path here?

Liu: Yeah, it’s not easy.

Ashley: [Laughs]. Well, let’s talk about the database market in general and, as I mentioned to you earlier, you know, I started doing database work long long ago. It’s not a new topic by any stretch. And, of course, there’s a lot of database products in the market. So, what’s unique and different about TiCAP, TiDB, excuse me, and PingCAP that helps you stand out? So, why would the developers say, “Oh, that’s what I want. I’d like to use TiDB ’cause that does these things for me.”?

Liu: Well, that depends on the values you provide for you customers or developers. So, there are many key values that PingCAP brings to our customers, users, and a wide range of the community and, of course, through open source. So, first of all, we are open source believers. Now, open source is the core philosophy of PingCAP which is always leading the wheel of TiDBs development. So, beside TiDB we also contribute a lot to the community.

We have donate two open source projects to CNCF apps. One is TiPV as a distributed key value storage. And, the other is Chaos Mesh so, as a chaos testing platform. You know those projects can help other software developers to build a more scalable, more resilient system. While you’re building a distributed system you’re trying to, you know, simulate, kind of, you know, disk force and network down and network recover, things like that. So, that’s why we need, you know, a chaos testing platform.

So, second, although we know the database market, you know, is so crowded, right? But, there is no such product can be used as a primary database to solve both, transactional processing and analytical processing like TiDB. Now as a foundation, TiDB is designed as a scalable, online transaction database. So, it can easily support hundreds of terabytes to, you know, petabytes of data while still serving millions of requests per second. So, what’s more you can even run realtime analysis on the same database without moving the data from, you know, TiDB to some other OLEP data warehouse.

Let’s imagine if you are building a SaaS system, there is always a operational dashboard for your customer, right? While you’re logging into any sass system you got a summary, right? That is operational dashboard. You need to generate that dashboard, realtime, on the same database. It is more natural for developers to operate their data on the same source of code. So, this technology is called HTAP, hybrid transactional processing and analytical processing. So, the concept is not new but, the implementation in a cloud native way is fresh. I think it’s a disruptive trend in the database industry to make, you know, everyone’s life and work easier.

Ashley: That’s really interesting to combine those two things together because, often times you thought of the old data warehousing or data lakes or different environments to do analytics in. But, actually being able to do analytics on top of transactional applications and data on the same environment, what are some of the things you have to do to be able to handle those two different kinds of workloads? ‘Cause, they can be very different, right? We want really fast transactional responses.

Liu: Yeah.

Ashley: Sometimes, pretty complex analytical questions that we’re asking, right?

Liu: Yes, you’re right. So, we basically have two different storage engine, a row store and a column row store but with the smart optimizer on top of both row store and column row store, right? So, if there is occurring the optimizer will predict is busy OLTP query or is busy OLEP query. Or, even better it can be a hybrid query we can query, you know, just this single row from a row store and do some, you know, aggregation on the column row store. It’s a little bit technical, you know.

Ashley: No, no, I get it. So, I mean, I assume your analytical queries might tend to be more by column versus your transactional by row. Is that a good generalization? I mean, it starts there?

Liu: Yeah, yeah, exactly.

Ashley: Interesting. And, you can mix those and do hybrid or both. So, is it views into the data or is the data redundant so that they can handle different loads on the two types of storage or is it just views into the same data?

Liu: So basically, we have a replication algorithm. It is called a raft. So, we use raft to replicate data and store them both as a row store and as a column row store so, you have two copy, right? So, then you can design a optimizer to choose what kind of data, which piece should I use, right?

Ashley: So that –

Liu: Just by, basically, replicating them, you know.

Ashley: All that admin work to set up your analytics environment. Essentially, you get that with the database, right? It comes with it?

Liu: Yeah, but –

Ashley: You’re doing the replication for them.

Liu: Yeah. From the user perspective, they operate on the same database. There is no – I don’t need to build my skill set, you know? Like, I need to know how to do manual shouting for a OLTP database and using some kind of ETL tools to load the data to OLTP data warehouse. And, I need to learn different kind of cycle, different kind of, you know, query optimization, you know, for two database to optimize it, right? And, so many things you need a totally different skill set for it.

Ashley: Tell us a bit about the cloud part of this strategy. So, are you primarily or only working in the cloud, do you also work on premise in customers own data centers? Where does TiDB live?

Liu: This is a good question. We invest a lot into TiDB cloud. TiDB cloud is a cloud service on top of TiDB, which allows us to, you know, provide, you know, a faster attempt to value for our customers. And meanwhile, reduce the burden of maintenance. You know, maintaining a distributing system is kind of a pain, right? So, just like other open source infrastructure companies such as Elastic, Confluence and et cetera. So, as a team behind, you know, TiDB we treat the relationship between open source and cloud strategy seriously. So, I would say that PingCAP will ensure the core components of TiDB 100 open source. And, without any functional loss. We actually achieve this by three actions.

First, we build an active open source community. You know, TiDB is backed by more than 800 contributors across multiple countries and industries. We actually built a demo on top of TiDB cloud which is called OSSinside.io. So, everyone can easily check any open source GitHub repositories with details of stats, contributions, commits, and you can even compare to different projects and so on and so forth. And, for the demo itself, it is open source too. You know, as I mentioned, you know, we are open source believers, right?

So, the second, we make sure TiDB is environment agnostic. So, the goal of TiDB is to achieve consistent user experience and a multiple deployment form. So, basically you can deploy TiDB anywhere, in public cloud, in private cloud, in VNs, containers, and bare metal.

Third, I think this is the most important one, TiDB is designed as an open system. So, we keep investing the integration with different other ecosystem such as Kafka, Link, Spark, Snowflake, Data dog, and so on. So, this openness in the capability are also work to our call service as well.

Ashley: Very interesting. One of my questions is, are there different users for the analytics capabilities versus the high speed transaction or, do they tend to be the same groups of people? Is it primarily developers using both, or do you end up with different users for different capabilities?

Liu: Well, they’re, kind of, different users. Database is so generic, you know, for any digital native business company they all have a database, they have different user scenarios. Not for those huge companies, big companies, they enjoy the scalability of OLTP features. So, they don’t need to worry about how to scale my system. Those big companies, especially for internet companies, they have a big dev team, right? They have a database team. So, the database team care about the scalability of the database but, the big data system team, they care about the analysis of big data.

But, for those, you know, medium company and startup, they just want a single database and they can handle everything. So, I don’t need to, you know, hire more engineers, I have no resource, you know, for those small companies, medium companies. I have no resource to hire, to build to different large team for OLTP database for big data, right? So, they want a single technology, a single database to solve everything. So, it’s different.

Ashley: Makes sense. You mentioned distributed database then also, since you can your own data replication across the environments, the column and row environments, I assume you can also do distribution across different locations in cloud providers or a cloud provider. So, if you want it distributed closer to the edge or, you know, closer to the data center or different geographic locations that’s also part of TiDB, is that correct?

Liu: Yeah. You can deploy TiDB to different zones. In all this is basically a default capability for distributed database. If you don’t have this kind of capability nobody’s going to use it, right? But, for edge functions, edge scenarios, currently, we don’t have the ability to support that. It’s just the, everything on cloud or deployed by yourself.

Ashley: I guess, as the cloud comes closer to the edge you can be on the edge that way, right?

Liu: Yeah. The open source database TiDB chose to compatible with mass scale protocol. So, all of those mass scale users, they don’t need to, you know, do lots of migrations, right? They can simply, you know, just move the data to TiDB and everything just works. And you know, mass scale is a TCP protocol, right? So, usually if you are using some kind of scenarios, edge functions and they are talking about using a HTTP protocol. So, you need a kind of, proxy and to route the request into, you know, TiDB cloud.

Ashley: Interesting work. Tell me a little bit about the open source versus the commercial version. What are the differences in the product? Are you doing newer features, kind of, things that are more experimental, you’re trying out a market first in the open source or, are there more management capabilities in the paid for version? How do you distinguish the two?

Liu: Well, actually there are three different versions. Let me explain a little bit more. So, first one is TiDB community edition. So, it has all the core capabilities so that developers can enjoy, you know, the latest TiDB features and able to contribute back. So, you can even get a nightly version, every day to enjoy the new features, right?

The second one, and for sure, it’s TiDB cloud. So, the new features are first released in the community version and after, you know, validation and polishing by a large number of community users they will come back into TiDB cloud. And then, what’s next is TiDB long term support version. So, this is kind of, our most stable features and professional service support by PingCAP provide for enterprise users. So, this kind of users they might not be interested in the new features immediately. I will wait, right, wait until it’s extremely stable. Maybe, a year later I will use it in production, right?

Ashley: Makes sense for maybe a finance company, someone in finance industry or manufacturing.

Liu: Yeah, you’re right. Especially for those banks. So, this release model actually helps us to get feedback faster from, you know, day to day operations of TiDB cloud by ourself and from, you know, the community. And, that also creates a faster loopback to TiDB’s roadmap. So, the verified and polished features will be posted to enterprise users through LTS release faster. This is kind of like, you know a flywheel, right? So, we can drive a faster time to value for both community users and enterprise users no matter how TiDB is deployed. So, to summarize, we have three release to different deployments but, a consist user experience in the process.

Ashley: Excellent. Well, I wish we had more time, love to hear more about it. Hope you’ll come back. Where can folks find out more, download the open source, or try out the cloud version? How can they check things out with you?

Liu: Well, thank you Mitch. Good to meet you, talk to you. Thank you.

Ashley: You bet. And so, folks can go to what, PingCAP.com? That correct? Your website?

Liu: Oh, oh, oh, one thing. So, I’m very excited to share that we will host the very first HTAP summit on November 1st. Yeah, you might be in the area. It’s very, you know, meaningful value computer history museum where I enjoyed a lot with so many historical moments and memories. So, at the summit we will, you know, be joined by many dev industry leaders and worldwide developers. And, also, includes some of important customers from Asia, for Europe, from the United States to discuss disruption and innovation. And, of course, all of you are more than welcome to check PingCAP.com on the HTAP summit page. And, I do look forward, you know, to connecting all of you in November.

Ashley: Well, excellent. I hope you have a great conference on the first of November and folks head out.

Liu: Oh, thank you very much.

Ashley: As well as head over to PingCAP and check out TiDB. Thanks again Max, we appreciate you being with us. Max Liu who is cofounder and CEO of PingCAP. Thanks again Max.

Liu: Thanks Mitch.

October 20, 2022

No-Nonsense Guide to Distributed Databases

I got my first DBA job 15 years ago, and quite a few things have changed since then. The amount of data exploded, we saw the rise of NoSQL, and business logic moved away from being stored in relational databases to applications.

To this day, the three pillars of reliability, scalability, and maintainability are the banes of a DBA’s existence. To spice things up, your monthly cloud bill for managed databases just made your CTO lose the will to live.

So, now you have two extra things to worry about in addition to these three pillars: cost efficiency and vendor-agnosticism.

In this article, I’ll (try to) run an open source, new-generation database, benchmark it and touch on some of the challenges of being cloud-neutral.

TL;DR

Solving the SQL vs. NoSQL dilemma in the Kubernetes world
How to leverage a distributed SQL database in a multi-cloud world
Taming performance – single cloud versus multi-cloud
Running TPC-C as a transactional benchmark
Taming the costs – the question of egress costs

New Packaging For a New Age

Just five years ago, people were like, “Containerizing stateless microservices? Sure! No problem.”

But when you actually containerize a database, your persistence layer is asking for trouble.

Over time, containers grew on us. Now, it’s the default way of packaging and shipping software. Heck, even AWS Lambda caved and started running container images. Databases just couldn’t resist.

Once a database is containerized – say, a PostgreSQL database – Kubernetes takes over dealing with some of the more painful aspects of reliability and maintainability (with the help of middleware-specific operators).

Containers decouple data from the runtime, so upgrades and configuration are easier through infrastructure-as-code (YAML). Hardware failure and maintenance windows are covered by Kubernetes’ built-in capability to reschedule pending pods on surviving nodes. Full scheduled backups or point-in-time recovery are in the hands of the operator’s automation.

But what about scalability?

Kubernetes’ vertical pod autoscaler can adjust container resources, deleting and recreating pods with new resource settings. As a traditional relational database, PostgreSQL can have only one primary replica that writes data. This means that you’ll be facing a short downtime while the new pod comes online. The majority of workloads are about five times oversized, so while sizing is painful, it’s better than no sizing at all (please, have mercy on your CTO’s budget).

NoSQL has none of these limitations. Databases like Cassandra were built for scaling horizontally without downtime.

Enter Distributed SQL

What if we could blend Google Spanner’s ability to operate at distances with strong ACID consistency, Cassandra’s scaling and PostgreSQL compatibility?

This is where YugabyteDB helps.

YugabyteDB is an open source, relational, distributed SQL database management system. It was designed to handle large amounts of data across multiple availability zones and geographic regions, all the while delivering single-digit latency, high availability and no single point of failure.

I hate when the new kid on the block brings their own syntax language because, you know, their case is so very special – just like everybody else’s.

Yugabyte doesn’t do that. They have a wicked-smart storage layer (inspired by Google Spanner) that reuses the PostgreSQL query engine. This means no mental strain on the development team – you get to use the time-tested, marketable and incredibly powerful PostgreSQL language-level features that many are already comfortable with.

If Google Spanner is so inspiring, why is it not taking over the world of distributed SQL? Well, it’s available only as SaaS, and heavily depends on the specifics of Google Cloud hardware like atomic clocks (trueTime) and Google’s backbone network. If your private data center or favorite cloud provider is not GCP – well, no Spanner for you, my friend. Personally, I’d be hesitant to marry into the ultimate vendor lock-in. Yugabyte doesn’t have any dependencies and would happily run on any cloud, private data center, VM or bare metal – and if your coffee machine runs Docker containers, you can run Yugabyte there, as well.

If Yugabyte is robust, scalable and easily maintainable, you have the top three pillars covered. But what about the other two pillars your CTO is nagging you about (cost efficiency and a vendor-agnostic approach)?

How to Make Your Database Vendor-Agnostic

Being vendor-agnostic means being able to switch between major cloud providers at any point without depending on prohibitively expensive services like DynamoDB. This approach also allows you to leverage inefficiencies in cloud pricing so you can look for new opportunities to reduce cost and dynamically shift resources between cloud providers online.

This is something CAST AI can do.

The CAST AI platform acts as a cloud abstraction and makes the whole multi-cloud, vendor-agnostic requirement quite trivial.

Developers just interact with standard Kubernetes (no CRDs), and the complexity of several clouds is abstracted. A Kubernetes cluster in CAST AI can span across several cloud providers at the same time, bringing some unique cost optimization opportunities.

What if spot/preemptible instance interruption wasn’t totally random anymore, but something you could actually predict? You could be proactive and—by operating in several compute bidding markets at the same time—reduce the risk of running out of capacity.

Why not slash your monthly cloud bill radically by running some of the database containers on spot/preemptible nodes?

Highly Available Stateful Application on Multi-Cloud

Yugabyte on a multi-cloud CAST AI Kubernetes cluster is a robust design without a single point of failure.

Active/Passive solutions are so ’90s—failovers cause brief downtime, and DBAs tend to leave the failover to be manually initiated due to occasional short-lived network blips. Active/Passive solutions constantly require testing and validation. Will your disaster recovery work on darker days? Because these tests cause downtime, nobody does them regularly.

The best highly available solutions are active-active, don’t require user failover, and don’t rot if not tested regularly.

CAST AI has a tutorial in place that takes you through every step of building the above solution in about 10 minutes, from scratch.

Go ahead, open your cloud provider’s console and release your inner chaos monkey by killing Yugabyte, business app pods or whole Kubernetes nodes.

CAST AI, Yugabyte, and Kubernetes were built with a core tenet that nothing is guaranteed; nothing should be shared. But keep in mind, consensus algorithms work when there’s still a majority left to vote N/2 + 1.

You may be asking, what’s the performance impact of increasing resiliency when going multi-cloud with a distributed database?

Let’s find out.

Let’s benchmark a distributed Yugabyte database on top of CAST AI Kubernetes spanning AWS and GCP. These cloud providers are arbitrary choices here; Azure or DigitalOcean can be used in the mix, as well. We picked GCP and AWS because their VMs boot up a bit faster.

Mono-Cloud Vs. Dual-Cloud Network Benchmark Results

Let’s compare a Yugabyte containerized database on Kubernetes in a single-cloud scenario versus a distributed database working in two different clouds.

Setup

We took the OSS Yugabyte HELM chart with the image version “2.5.1.0” with the replication factor of 3.

Role	YB-Master	YB-Tserver
Description	Control plane, consensus	Serves data
CPU	3 CPUs	7 CPUs
RAM	3 GiB	14 GiB
Storage	50 GiB	300 GiB

Remote Network Block storage:

EBS gp2 (300 IOPs)
Standard persistent disk (R225/W450 IOps)

Nine pods, each on a separate VM to ensure plenty of resources:

Mono Cloud

Regional GKE k8s cluster with 9x GCE N2d-standard-8 distributed in three availability zones. Casual VPC network in Google’s US-East4 region.

Dual Cloud

AWS EC2 3x c5a.2xlarge

GCP GCE 6x n2d-standard-8

A network between cloud providers set up with a Wireguard-based full mesh VPN that encrypts traffic end-to-end (also inside the same VPC).

To minimize noise from compute and local storage efficiency, we didn’t optimize for cost but wanted to isolate and better understand how distributed databases would work in situations where database nodes are distributed single-digit milliseconds away (in this example, less than 9 ms).

Nine milliseconds of network round trip latency means a lot of flexibility in choosing between data center providers distributed within a few hundred miles.

The majority of cloud provider regions lack imagination and are clustered in the geographic vicinity of a densely populated metropolis. California, northern Virginia, Montreal, São Paulo, London, Frankfurt, Amsterdam, Mumbai, Tokyo, Singapore, Sydney, etc.

So, what are your options in, say, Frankfurt? AWS, Azure, GCP, DigitalOcean, Oracle, Alibaba, IBM Cloud, Hetzner, Linode—not to mention the white-label providers.

We carried out tests on U.S. East (Ashburn) and Europe Central (Frankfurt) with similar results.

How We Measured It

If we want to test relational database performance – the gold standard ruler to date is a synthetic TPC-C benchmark.

Why did we choose that? Because it’s the most mature OLTP benchmarking test suite that has stood the test of time. As stated here:

“While the benchmark portrays the activity of a wholesale supplier, TPC-C is not limited to the activity of any particular business segment, but, rather represents any industry that must manage, sell, or distribute a product or service.”

We loaded an identical Yugabyte configuration in both scenarios with 300 warehouses worth of data and then ran benchmarks several times.

Each test took half an hour, and the output was the single most important metric: transactions per minute. The test also provided different outputs per type of transaction, average and 99th percentile duration in milliseconds.

Results

This table shows a comparison of TPC-C results with the average duration for a single cloud on Google and AWS + Google in the same region, US-East.

300 warehouses	Mono Cloud	Dual Cloud
Num New Order transactions per 1800 s	113,071	113,247
TPM-C	3,769	3,774
Efficiency	97.6%	97.8%
NewOrder Latency avg msec	580.2	498.8
Payment Latency avg msec	30.8	46.7
OrderStatus Latency avg msec	33.8	32.4
Delivery Latency avg msec	123.1	174.9
StockLevel Latency avg msec	239.4	465

And comparing the 99th percentile:

300 warehouses	Mono Cloud	Dual Cloud
NewOrder Latency p99 msec	6985.6	5498.7
Payment Latency p99 msec	110.5	157.5
OrderStatus Latency p99 msec	146.3	185.1
Delivery Latency p99 msec	331.5	696.8
StockLevel Latency p99 msec	712.3	1083.3

As you can see, the difference between the mono cloud and dual cloud scenarios is quite small.

Some operations, like OrderStatus, are plain read operations. The nearest server can quickly respond with data to the client—usually, a microservice running on the same K8s cluster.

Yugabyte’s lowest isolation level is a snapshot. This means that those reads are protected from the undesirable effect of the “dirty read.”

What about writes?

Writes are a bit more expensive. Raft consensus, hybrid logical clocks and lockless multi-version concurrency control (MVCC) algorithm magic—all of this means a lot more chatter and replication between nodes to get write committed.

We see that, in payment and delivery operations duration (30ms vs. 46ms and 123ms vs. 174ms, respectively) the geographic distances start to be noticeable.

The actual network latency between nodes in different availability zones in the mono cloud scenario without network overlay and encryption is, on average, about 0.6ms. Network latency between two clouds with overlay (VXLAN) and encryption (Wireguard) is about 5ms.

The laws of physics aren’t going away anytime soon. But as we can see, the results are much better than expected.

YMMV, but industry accepted norm is that the majority of IO operations will be reads, at 70%; only remaining 30% writes, reducing the impact of speed of light even further.

Having said that, the gold standard for measuring OLTP database performance for the last two decades says that performance results are identical (TPM-C 3’769 vs. 3’774).

Data Gravity and Egress Costs

Data gravity refers to a scenario where compute gravitates closer to data.

For example, if you have a hybrid cloud or multi-cloud strategy but your data stays in a single location like an on-premises data center. Most of the compute with stateless services will tend to stay in the same data center, closer to data.

The whole point of multi-cloud and a high-performing distributed database was to get rid of data gravity. If we have the same data on two or more clouds, then the data gravity effect disappears.

If all your data is replicated to several locations, what about network traffic costs?

All cloud providers allow unlimited incoming (ingress) data. It doesn’t matter where data is coming from—if it’s your on-premises data center, a different cloud provider, the dark web or most cloud-native services. All the incoming data is free.

“You can bring as much data as you want to us. But if you want to take your data back – sorry, you need to pay.” This is universal between all cloud providers. All the outgoing (egress) traffic from your availability zone is paid! Some cloud providers, like Oracle Cloud, are very generous with egress costs, and companies like Zoom saved a ton of money when they moved some of Zoom’s infrastructure to Oracle Cloud.

DigitalOcean gives a generous egress monthly allowance per Droplet (VM), depending on size and how long you run it. But, at a minimum, it starts at Terabyte per smallest Droplet. The monthly egress allowance is aggregated in your account, and you pay only for the combined extra.

All clouds have some minimal free tier—but in general, egress costs start at around 10 cents per GB of data sent outside VPC, and, on average, 2 cents for data between availability zones in the same VPC (I bet you didn’t know that you pay 1cnt/GB in AWS and Azure for incoming traffic coming from same VPC/Vnet from another AZ).

If you send more traffic, your cost per GB falls. The first drop is at 10TB and generally flattens at around 5 cents at ~150TB.

How does it make you feel when cloud providers charge an eye-watering 97% margin on that egress traffic? It’s like we’re back in 1995 with dial-up modems, right?

There is a more cost-effective alternative. But first, let’s answer the ‘Will it Blend?’ question. Let’s add Direct Connect, Express Route, Cloud Interconnect and Layer 2 or Layer 3 providers like Equinix or Megaport. Yes, you get a Dedicated Fiber Link smoothie out of the blender.

Dedicated fiber link slashes costs to a mere 2 cents per GB. And if you have more egress traffic than 7TB, it’s more cost-effective than relying on the weird discount models from cloud providers.

You might be thinking, “2 cents for every GB?! That’s way too much! I’m using RDS—yes, I have vendor lock-in and data gravity—but at least I have none of the problems with egress cost, resilience, scalability and overall affordability of the service, right?”

That’s just the result of an opaque billing design.

https://twitter.com/QuinnyPig/status/1372598432095891458

All the traffic between Availability Zones in all clouds is paid at 2 cents per GB of egress+ingress. The only place where you pay for ingress is between Availability Zones in the same region (AWS/Azure). Some managed services offer free replication, but they charge double on compute costs, etc.

Through the ServiceTopology feature, Kubernetes can keep your application pod’s traffic inside the same cloud service provider Availability Zone and cloud, to avoid round robin, random calls between clouds. This means that you get the best latency and pay no traffic premium.

Most of the database activity is reads (70/30, YMMV) and are effectively free, egress-wise (coming from the local AZ due to the Kubernetes topology awareness). So, the only thing you replicate and subject to egress costs is your database change delta rate per month.

Now you can see that the issue of egress costs is an incredibly overstated problem.

The overwhelming push to the public cloud over the last decade brought on new challenges like vendor lock-in, data gravity and eye-watering monthly infrastructure bills.

During that time, innovation in non-traditional RDBMS, containerization and workload scheduling removed some of the old barriers.

Running a hands-free, strongly consistent, highly available and scalable database in heterogeneous data centers on a budget was a monumental task a decade ago. Today, it has become an affordable best practice for running our business applications.

June 3, 2021

Defining the Database Requirements of Dynamic JAMstack Applications
Zero-configuration hosting solutions such as Zeit Now and Netlify are taking the frontend community by storm due to their ease of use. If we add static site generators such as Gatsby/Next.js/Nuxt.js/Hugo/Jekyll to the mix and deploy our statically generated pages to a content delivery network (CDN), we get something highly desired with minimal effort: distributed auto-scaling applications with zero configuration.

The usage of static site generators and CDNs became quite popular, so much so that Netlify decided to give it a name: JAMstack. At first, this might not strike you as something very newsworthy. Haven’t we all deployed static sites such as blogs or documentation on CDNs? What is different about this approach?

To answer that, let’s first look at the definition that is typically used to explain JAMstack: The JAMstack is a static HTML site, rebuilt automatically every time you update the content, and deployed directly to a CDN.

Of course, that still does not explain why this approach is different. The first time I read this definition, I wondered how I could ever build something more dynamic than a blog with such a stack. However, note that nothing in the previous description says that every element of our site has to be statically generated. In fact, the JAM acronym stands for JavaScript, APIs and Markup, where the letter A is the answer to dynamic content.

The idea is to pregenerate markup where you can and then enrich these statically generated pages with dynamic content fetched from APIs. The APIs of choice in a JAMstack application are typically APIs from third-party services (SaaS platforms) or custom-built with Functions as a Service (FaaS). Both Netlify and Zeit have great zero-configuration FaaS offerings to write APIs for your JAMstack.
In essence, developers in the JAMstack community are often looking for a specific set of requirements:
- Zero configuration—easy setup, easy deploy, no server management.
- Scaling—your application can handle sudden spikes of increased traffic without extra effort.
- Speed—low latencies and fast page loads (thanks to the distributed nature of CDNs).
- Pay as you go—only start paying when your page actually serves customers.
By combining easy-to-use hosting solutions, static site generators, CDNs and scalable APIs in one stack, we can relatively easily get these requirements.

What If My Application Requires Highly Dynamic Data?

Imagine that you are building a social network for professionals on which professionals can create profiles. Professionals create profiles to promote their skills, and companies search the network to hire professionals for specific projects. For such an application, you need to store, search, filter and paginate data.

To build such an application, you need a database, but not just any database. Ideally, you want to avoid losing the zero-configuration, pay-as-you-go, scaling and speed benefits that a JAMstack application typically delivers. There are several features a database can possess that make it a perfect fit for a JAMstack application.

In this article, we will describe these features and explain how each of them makes a database a better candidate for a JAMstack application. Since such applications often rely on serverless functions, many of these properties also apply for applications built with FaaS.

Database Properties that Work Well with JAMstack and FaaS Applications

Multi-Region, Globally Replicated

To understand why multi-region distribution is desirable, let’s revisit why static websites on CDNs are incredibly fast. A CDN is fast to deliver your content because it contains copies of your content at different locations. When content is requested from the CDN from a specific location, it will attempt to deliver that content from the closest location to the requestor. In order to get an idea of how much that matters, take a glance at the Zeit CDN status page which shows you the difference in latency between your current location and other locations. By deploying our applications to a CDN, our pages automatically load from the closest location to the user, which results in low loading latencies. And low latencies result in a great user experience.

In order to keep this user experience, the dynamic data that will be loaded from our APIs has to exhibit low latencies as well, and the best way to achieve this is to use a distributed database. Databases that feature multi-region replicas such as FaunaDB, Google Spanner or Amazon Aurora not only provide the dynamic querying that you need, but also deliver your data from the closest location, just like a CDN.

Connectionless

Many traditional databases are not connectionless, which means that they require persistent connections with the process that queries the database. There is often a limit on the number of connections that a database can handle, and setting up a connection takes time and puts more strain on the database. A database that supports a JAMstack application will either be called from the frontend (if it’s possible to do securely) or from serverless functions. An increase in the number of users increases the number of running functions or frontend calls.

Having a limit on connections and/or creating/destroying many connections then quickly becomes a problem. An ideal JAMstack database behaves like an API; it does not require connections. There is an excellent article on this topic that describes the connection problem from a FaaS perspective.

Flexible Security

Providing security out-of-the-box takes away tedious configuration from developers. If this security layer can also provide a means to securely access the database from the frontend, we can potentially write our application backendless, eliminating an extra hop and reducing the low latency we’ve gained from distribution even more. When a database is connectionless and can be accessed securely from the front-end, we consider it to be frontend-friendly. However, security requirements can be complex. If we completely rely on the database security layer, it has to be flexible enough to express custom rules. Firebase Cloud Firestore, FaunaDB and the upcoming Userbase offer direct access via clients, like browsers.

Scaling and Pay-as-You-Go

Before we add a database, our typical JAMstack application is completely auto-scaling and pay-as-you-g(r)o(w), which is considered an advantage for many startups. We only pay for the CDN bandwidth and function calls that our application actually uses. If our database is also pay-as-you-go and scales automatically, we do not lose this advantage.

Strong Consistency

Strong consistency is quite a technical matter, so we’ll explain it briefly, and for the technical details, this article is a great resource. Strong consistency is important in distributed databases when your application stores and updates data. In that case, there are two requirements to preserve a great developer experience:
- You never lose data: When a write or update is acknowledged, it can no longer be dropped.
- Data updates are predictable: When you save or update data, a consequent read will reflect these changes.
Strong consistency (or strict serializability) is the opposite of eventual consistency. By adopting a database that does what you expect it to do, you can focus entirely on your application. Only a few distributed databases provide strong consistency without limitations.

Conclusion

JAMstack applications are not limited to pages that are entirely static; they can be partly static and partly dynamic by retrieving data from APIs. A distributed database can be one of these APIs and is essential in case your application contains dynamic pages with filtered or paginated data. Ideally, such database fulfills the six described requirements so that we can build dynamic JAMstack applications without losing speed, scalability, pay as you go or the zero-configuration approach that we love.

In case you wonder how a partly static, partly dynamic JAMstack can be created in an elegant way with modern frontend frameworks, take a look at hydration, which might be the topic of a forthcoming article.

— Brecht De Rooms
April 14, 2020
Don’t Be Samsung: Here’s How You Can Protect Yourself

Imagine a factory building 100,000 units a day, and you can see how a small error can have huge consequences. Now imagine that factory is a database.

The world’s top smartphone maker this month pulled the plug on its $882 Galaxy Note 7 after phones overheated and caught fire, concluding in a disastrous recall for Samsung that could cost the company as much as $17 billion and shutter a global revenue stream. In an unprecedented move, Samsung has told mobile carriers to halt sales or exchanges of the device, requested that users to shut off their phones and issued a mass recall while the South Korean manufacturer investigates reports of fires in original and replacement Note 7s.

This a scant two months after the Galaxy Note 7’s launch, a device that one TechCrunch consumer electronics expert raved as “undoubtedly one of the most iconic handsets around.” While it is not clear what caused these fires, there is speculation that it was due to a faulty component that interacts with the battery, rather than the battery itself.

It goes without saying that there are ample opportunities for error in the assembly of a smartphone. The complicated, highly coordinated process is fraught with thousands of input touchpoints, from hard- and software components to tightly controlled manufacturing processes to manual labor. And though there may be countless checks and balances in place, mistakes do happen. What may seem to be an innocuous error, such as not sufficiently tightening a screw or the shorting of a circuit, in this case has led to epic consequences.

The truth is, these instances happen more often than we think, and to technologies even more vital to the population than a personal smartphone.

Consider today’s era of big data and cloud applications, where enterprise applications ingest and process vast amounts of information from various sources, often in real time, to deliver critical analytics, contextual information or business insights.

This data has weight. It can influence whether fleets of airplanes are grounded at gates all across the country. It can restrict customers from accessing funds from online banking. It can dictate whether millions of online retail dollars go unspent. The reliance on accurate data, and its grip on lives and business, is growing at an exponential rate—like ever-widening ripples in a lake.

To support all of this data, new applications (such as real-time analytics, internet of things, ecommerce and others) are developed and deployed on scale-out, non-relational databases or ported from traditional relational databases.

But, like the manufacturing gaffs experienced by Samsung, corruptions and operational errors by developers occur in enterprise IT environments. Enterprises know this, and billions have been invested in traditional backup and recovery and data protection products to protect against such “err” moments. However, the irony is that data protection products like those that exist for traditional relational databases do not exist for today’s modern, next-generation scale-out databases supplying the new types of data that increasingly control our lives. We’re essentially trusting that the Ma Bell rotary phone repairman will be able to recover personal data—such as contacts, photos and messages—after your Galaxy Note 7 starts smoldering.

So how did we get from the world’s most explosive phablet to distributed databases and big data? Because, like the Galaxy Note 7, the tiniest data error can rapidly expand into magnificent, catastrophic consequences.

Enterprises are adopting cloud applications that gather large amounts of data at a high-ingestion rate and process that data in real-time to deliver actionable insights. These applications are deployed on non-relational databases. As migration to cloud and multi-cloud application environments increases, enterprises also must be able to manage and recover at scale without data loss or corruption and with minimal application downtime.

However, enterprises today face a significant gap in addressing their data protection requirements. Their most valuable data, often needed 24/7 and without fail, runs absent any point-in-time backup options for that ‘“Houston, we have a problem”’ moment. Most studies suggest that more than half of data downtime and loss is triggered by human error, corruption or virus attacks. And yes, while native replication helps enterprises meet business continuity and disaster recovery requirements by providing protection from hardware failures or even natural disasters, it is insufficient (meaning it cannot scale) to meet next-gen enterprise data protection demands. Case in point: If a minor schema corruption impacts the primary data copy, it causes a multitudinous ripple effect that impacts all replicas down the line. Yet, even without protection, industries continue to adopt and deploy scale-out database systems at an accelerated pace.

So just as Samsung witnessed an error replicate itself into such a massive meltdown of global proportions that it threatens to kill an entire product line, organizations also must understand how replication-based protection mechanism can actually act like a virus—spreading a corruption uncontrollably across non-relational, cloud databases.

Samsung’s troubles won’t end with the simple recall of a single product, and their predicament should resonate. There will be punitive measures, and perhaps even a total enterprise shift from the smartphone market. It is not an enviable position, but is does offer a clear example of how a peripheral manufacturing error can swell to engulf an entire brand.

For enterprises rushing to deploy scale-out databases, let Samsung serve as a warning: that deploying any infrastructure that could potentially lead to exponential, irreversible corruption of all data copies is a recipe for harm (if not disaster). As enterprises make the switch to next-gen applications running on scale-out, non-relational databases, an assembly line e-stop needs to be built in, in the form of a point-in-time, version-friendly data protection solution.

Data corruption is not a matter of “if,” but “when.” So have a kill switch ready.

— Brian Yin

November 3, 2016