What is application modernization?
That’s officially an FAQ on the Internet. Here at Cockroach Labs, what people frequently ask us is a little more specific:
What does Application Modernization have to do with databases?
Drilling down one more level, the question becomes, “What does Application Modernization have to do with CockroachDB?”
TLDR; Distributed SQL is becoming a major trend just like microservices and containerization. If you’re building modern apps, it’s as important to understand the key capabilities of distributed SQL as it is microservices and containerization.
Application modernization
For starters, let’s define what I’m talking about with respect to applications. From a modernization perspective, I’m discussing application architecture and deployment, not application development.
I would argue that a “modern application” has three key characteristics:
It’s built on a micro-services architecture for scale and resilience.
It’s deployed on a container infrastructure for scale, resilience, and ease of management.
Its transactional data layer is distributed for resilience, scale, data governance, and ease of management.
Towards that last point, we’re starting to see transactional workloads coalesce around distributed SQL as the distributed data layer. Distributed SQL is becoming as big a trend as both microservices and containerization, owing in part to its core (and shared) philosophies of resilience, scale, and ease of management.
How did these key components of modern applications converge? Let’s look at a brief timeline:
Microservices
Microservices started to become a thing in ~2012 with a talk by a the software architect James Lewis, “Microservices — Java, the Unix Way.” Microservices offer numerous advantages, including independent deployment, scalability, fault isolation, and the flexibility to choose the best language or tools for each problem. As software development trends towards decentralization, microservices are going to become an even more popular architecture for building applications.
Containerization
Kubernetes started to become a thing in ~2015 with Kubernetes v1.0, which was launched by Google in the middle of that year. Kubernetes can speed up the development process by making easy, automated deployments, updates (rolling-update) and by managing our apps and services with almost zero downtime. It also provides self-healing. Kubernetes can detect and restart services when a process crashes inside the container. Not every application must be deployed in a container, but the app-dev-world’s a better place with containerization in it.
Distributed SQL
Distributed SQL started to become a thing in ~2018 with the launch of Google Spanner and CockroachDB v2.0. By 2024 when Amazon launched their DSQL service, distributed SQL definitely hit mainstream.
Data Modernization
It’s worth a short tangent to think about data modernization in the context of application modernization.
CockroachDB can modernize your data infrastructure, bridging the gap between traditional data infrastructure and the cloud so you can significantly increase agility, reduce risk, and increase ROI.
Download The Architect’s Guide to SQL Database Modernization to learn more.
Distributed SQL
Distributed SQL exists in comparison to “one large database.” In the past, scaling a database meant buying a bigger server or sharding data across multiple database servers (or both).
Distributed SQL provides ACID consistency with high-horizontal scale for both reads and writes, no single point of failure resilience, built-in data governance, and simplified database operations. These capabilities are all based on the best practices learned about managing databases over the past three decades.
There are four key elements to a distributed SQL database:
Resilience
Scalability
Data governance
Ease of management
Resilience. A distributed SQL cluster has no single point of failure. The database can continue operating if a node, zone, or region fails without compromising availability.
Scalability. The distributed SQL architecture allows a cluster to scale seamlessly as workload increases or decreases. Nodes can be added to a cluster without any manual rebalancing, and performance will scale predictably as the number of nodes increases.
Data governance. Distributed databases allow data to be physically located in specific localities to enhance performance for “localized” applications and to respect data sovereignty requirements. This capability, and the simplicity with which CockroachDB implements data locality, is an area of differentiation between distributed databases.
Ease of management. Distributed SQL leverages our learnings to help make managing databases easier - such as no manual sharding required, no-downtime schema updates, and flexible observability.
The distributed SQL databases, to varying degrees, do all of this while providing the highest practical level of transactional isolation and consistency. Transactions operate independently of each other and, once committed, transactions are guaranteed to be durable and visible to all sessions.
Familiar fundamentals
Distributed SQL is following in the footsteps of both microservices and containerization, and it’s likely that adoption will follow similar patterns. Within the context of application modernization, this makes it critical to understand the fundamental primitives of distributed SQL like resilience, scalability, data governance, and simplified management.
A great way to get started is to put your hands on it! You can do that in two ways.
My first steps were with Cockroach University, where I got some free distributed SQL education and practical experience. These courses are really well-articulated, broken down into easily consumable chunks of both time and brain-power.
Alternatively, you can get started for free with our cloud offering. If you’re already familiar with some of these concepts, but want to deploy an application for real, this is the perfect place to start.
References
