Business Platform Team

The Apache Cassandra database has gained popularity because it offers scalability and high availability without compromising performance. Many applications running today were built using relational database technology, however, this technology doesn’t offer the scalability or availability that Cassandra does. This is why many people are considering the switch to Switch to Cassandra. In this post, we will cover everything you need to know about switching from a relational database to Cassandra.

​Our team is passionate about Realtime Business Platforms, especially ones we help build using our standard framework of Cassandra, Spark, and Kafka. We built this site because we needed a site like it. One place to know what’s going in the Apache Cassandra community from all the different viewpoints. Since there are now different commercially backed variants of Apache Cassandra such as Datastax, DDACS, Scylla, Yugabyte, Elassandra, and Microsoft’s CosmosDB, we felt that out of self-interest none of those folks were going to come together to make a resource like the one we craved.

Once a new distributed platform is implemented, any growing organization needs to be able to properly scale the system. Scaling a system for the sake of scaling it doesn’t make sense because cloud resources cost money. The best way to see when and how to scale is to properly monitor the software.

Thus far we’ve discussed how Cassandra, Spark, Kafka, Docker, and Kubernetes can be useful to build a global data platform. These components are powerful in their own right and managing them is a little simpler if we decide to use commercial components from DataStax and Confluent.

There are other tools and services we can use to further accelerate our timeline to deliver a world-class global data and analytics platform. Although bringing up a distributed data (Cassandra), distributed computing (Spark), and distributed communication (Kafka) is a great start for a framework, it still needs a few more components to make it a “Platform” which allows quick creation and delivery of services that an enterprise can use.

It’s much easier to iterate your platform on containers before deciding to use more “traditional” computing systems in Staging or Production. It’s not a requirement to use Docker or Kubernetes, but even if the system is using containers all the way up to Production, many of the DevOps cycles can be done more quickly because of how quickly environments can be refreshed.