DataStax sponsored this podcast.

A little over 10 years ago the tech industry rejected the single relational database for all jobs, and demanded a way to scale — at scale — with distributed systems. This movement saw the birth of the NoSQL movement with React, Cassandra, MongoDB, Tokyo Cabinet, and many others, all to better manage distributed databases.

“All those databases that grew from: ‘Hey, we have a scaled data problem and this single relational database is not solving it.’ And I think that was the first time we really had to solve scale problems and use distributed technology to make it work,” said Patrick McFadin, chief evangelist for Apache Cassandra and vice president of developer relations at DataStax.


Self-Serve Architectures, The K8S Operator for Cassandra on DataStax

Also available on Apple Podcasts, Google Podcasts, Overcast, PlayerFM, Pocket Casts, Spotify, Stitcher, TuneIn

McFadin was joined by colleague Kathryn Erickson, head of strategy and product at DataStax, for this episode of InApps Makers podcast. They sat down with Founder and Publisher of InApps, Alex Williams, to reflect on how the industry has seen a sudden explosion of scale and how that’s now guiding the next steps toward fully self-service architecture.

After NoSQL came the applications tiers, component tiers — APIs, containers and microservices and a new application stack, McFadin continued. Then either domain-driven design drove DevOps or the DevOps movement drove DDD. After all, there would no longer be room for silos when things started moving this fast. Operations had to get on board with the speed of agile software development. And tech had to be aligned with business.

Read More:   Update Rackspace, Microsoft and the Game to Make Cassandra Accessible to the Mainstream

This all led to the perhaps-inevitable domination of Kubernetes, which he says finally satisfied the need for scaled architecture in a distributed nature.

Erickson sees Kubernetes orchestration as sharing an open source, cloud native future with the hosted and managed Cassandra database. They both scale-out distributed applications with the same use cases, the same users and similar environments.

“Ensuring that there’s a long-term story for Cassandra and Kubernetes is really important,” Erickson said. “These cloud native developers, the first thing they want after easily built scalable apps is an easily built scalable backend.”

She says that it’s up to the Kubernetes-Cassandra duo to delight developers to write the applications they want and how they want them, without having to worry about the database.

McFadin pointed to UK telecom giant Sky, which is combining Kubernetes and Cassandra in a hybrid cloud, building out architectures that are spanning multiple clouds and on-premise.

“It’s being fueled by this microservices thing that, you know, where we could distribute our APIs anywhere, and then persist that data and have stateful data everywhere we go,” he said.

And then that future? Certainly moving away from the infrastructure and databases being overwhelming challenges to work with. Or, as McFadin puts it: “The ability to get more lazy.” Data simply has to be simpler for developers to work with. No more steep learning curves or barriers to entry.

He continued that “The thing that’s exciting for me is when databases become less of a cognitive burden for developers, they’re just using data. And they’re using data effectively.”

This belief in self-serve architectures allows for the use of data in fresh and unique ways. And that’s where DataStax comes in, Erickson said, providing the guide for Cassandra through its new Kubernetes operator. This new operator abstracts the database layers that developers simply don’t need to worry about.

Read More:   Paving a Path to Continuous Delivery – InApps 2022

Now developers can just focus on doing what they do best.

At this time, InApps does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: [email protected].