Illustration Image

Cassandra.Link

The best knowledge base on Apache Cassandra®

Helping platform leaders, architects, engineers, and operators build scalable real time data platforms.

1/12/2021

Reading time:5 min

Moving to cloud-native applications and data with Kubernetes and Apache Cassandra - JAXenter

by John Doe




 What's next? Moving to cloud-native applications and data with Kubernetes and Apache Cassandra November 4, 2020 Patrick McFadin #apache cassandra #cloud #kubernetes © Shutterstock / issaro prakalung Over the past twenty years, there have been several big trends in distributed computing. Today, we have more developers using microservices designs to decompose applications into smaller and more manageable units. Apache Cassandra was built for cloud data and is now becoming the choice of developers for cloud native applications. Moving your applications to run in the cloud is attractive to developers. Who doesn’t like the idea of being able to easily scale out and have someone else worry about the hardware? However, making use of cloud-native methodologies to design your applications is more than migrating them to a cloud platform, or using cloud services.What does this mean in practice? It involves understanding the role that containers and orchestration tools play in automating your applications, how to use APIs effectively and how other elements like data are affected by dynamic changes to your application infrastructure. More specifically, it means running your application using virtually unlimited compute and storage in the cloud alongside a move to distributed data. Apache Cassandra was built for cloud data and is now becoming the choice of developers for cloud native applications.SEE ALSO: Practical Implications for Adopting a Multi-Cluster, Multi-Cloud Kubernetes StrategyHow did we get here?Let’s look at how we got to today. Over the past twenty years, there have been several big trends in distributed computing. Reliable scale networking was the big area of focus in the 2000s, which enabled the linking of multiple locations and services together so that they could function at the velocity and volume the Internet demanded. This was followed in the 2010s by moving compute and storage to the cloud, which used the power of that distributed network to link application infrastructure together on-demand with elasticity. That works well for the application itself, but it does not change how we have been managing data.Managing a distributed database like Cassandra can be complex. To manage transactions across multiple servers, it takes some understanding of the tradeoffs presented in Brewer’s Theorem which covers Consistency, Availability and Partition Tolerance (CAP): how a database can manage data across nodes; the availability of that data; and what happens across different locations respectively. More importantly, how does the database react when non-ideal conditions are present. The inevitable failures that happen in a system with multiple parts.Not only does your database have to manage failure cases, it also has to do this while maintaining data consistency, availability and partition tolerance across multiple locations. This is exactly what Cassandra was built to do and has proven itself in just those tough conditions. Being rooted in a distributed foundation, has given Cassandra the ability to do hybrid cloud, multi-cloud or geographically distributed environments from the beginning. As applications have been built to withstand failures and scalability problems, Cassandra has been the database of choice for developers. 



 





 


NEXT GENERATION DEVOPS: VALUE STREAM MANAGEMENT

Helen Beal (DevOps Institute.)







HOW TO GROW YOUR SERVERLESS TEAM

Sheen Brisals (The LEGO Group)






MLOPS: CONTINUOUS DELIVERY OF MACHINE LEARNING SYSTEMS

Hauke Brammer (finpair GmbH)





DevOpsCon Program »






  What’s next?Today, we have more developers using microservices designs to decompose applications into smaller and more manageable units. Each unit fulfills a specific purpose which can scale independently using containers. To manage these container instances, the container orchestration tool Kubernetes has become the de-facto choice.Kubernetes can handle creating new container instances as needed, which can help scale the amount of compute power available for the application. Similarly, Kubernetes dynamically tracks the health of running containers – if a container goes down, Kubernetes handles restarting it, and can schedule its container replacement on other hardware. You can rapidly build microservice-powered applications and ensure they run as designed across any Kubernetes platform. For an application to run continuously and avoid downtime, even while things are going wrong, are powerful attributes.In order to run Kubernetes together with Apache Cassandra, you will need to use a Cassandra Operator within your Kubernetes cluster. This allows Cassandra nodes to run on top of your existing Kubernetes cluster as a service. Operators provide an interface between Kubernetes and more complex processes like Cassandra to allow them to be managed together. Starting a Cassandra cluster, scaling it and dealing with failures are handled via the Kubernetes Operator in a way that Cassandra understands.Since Cassandra nodes are considered stateful services you will need to provision additional parts of your Kubernetes cluster. Storage requirements needed by Cassandra can be satisfied by using PersistentVolumes and StatefulSets to guarantee that data volumes are attached to the same running nodes between any restart event. Containers for Cassandra nodes are built with the idea of external volumes and are a key element in the success of a cluster deployment. When properly configured, a single YAML file can deploy both the application and data tiers in a consistent fashion across a variety of environments.SEE ALSO: Successful Containerized, Multi-Cloud Strategy: Tips for Avoiding FOMOPlanning aheadAs you look at adopting microservices and using application containers, you can take advantage of fully distributed computing to help scale out. However, to really take advantage of this, you need to include distributed data in your planning. While Kubernetes can make it easier to automate and manage cloud-native applications, using Cassandra can complete the picture.Bringing together Apache Cassandra and Kubernetes can make it easier to scale out applications. Planning this process involves understanding how distributed compute and distributed data can work together, in order to take advantage of what cloud-native applications can really deliver. Be the first to share this article with your network! Author Patrick McFadin Patrick McFadin is the vice president of developer relations at DataStax, where he leads a team devoted to making users of DataStax products successful. He has also worked as chief evangelist for Apache Cassandra and consultant for DataStax, where he helped build some of the largest deployments in production. Previous to DataStax, he was chief architect at Hobsons and an Oracle DBA/developer for over 15 years. Recommended For You “Start at the edge, typically with an API gateway, and work inwards” Adopting a multi-cloud strategy? 5 reasons why your enterprise should

Illustration Image
What's next?

Moving to cloud-native applications and data with Kubernetes and Apache Cassandra

Patrick McFadin
cloud
© Shutterstock / issaro prakalung

Over the past twenty years, there have been several big trends in distributed computing. Today, we have more developers using microservices designs to decompose applications into smaller and more manageable units. Apache Cassandra was built for cloud data and is now becoming the choice of developers for cloud native applications.

Moving your applications to run in the cloud is attractive to developers. Who doesn’t like the idea of being able to easily scale out and have someone else worry about the hardware? However, making use of cloud-native methodologies to design your applications is more than migrating them to a cloud platform, or using cloud services.

What does this mean in practice? It involves understanding the role that containers and orchestration tools play in automating your applications, how to use APIs effectively and how other elements like data are affected by dynamic changes to your application infrastructure. More specifically, it means running your application using virtually unlimited compute and storage in the cloud alongside a move to distributed data. Apache Cassandra was built for cloud data and is now becoming the choice of developers for cloud native applications.

SEE ALSO: Practical Implications for Adopting a Multi-Cluster, Multi-Cloud Kubernetes Strategy

How did we get here?

Let’s look at how we got to today. Over the past twenty years, there have been several big trends in distributed computing. Reliable scale networking was the big area of focus in the 2000s, which enabled the linking of multiple locations and services together so that they could function at the velocity and volume the Internet demanded. This was followed in the 2010s by moving compute and storage to the cloud, which used the power of that distributed network to link application infrastructure together on-demand with elasticity. That works well for the application itself, but it does not change how we have been managing data.

Managing a distributed database like Cassandra can be complex. To manage transactions across multiple servers, it takes some understanding of the tradeoffs presented in Brewer’s Theorem which covers Consistency, Availability and Partition Tolerance (CAP): how a database can manage data across nodes; the availability of that data; and what happens across different locations respectively. More importantly, how does the database react when non-ideal conditions are present. The inevitable failures that happen in a system with multiple parts.

Not only does your database have to manage failure cases, it also has to do this while maintaining data consistency, availability and partition tolerance across multiple locations. This is exactly what Cassandra was built to do and has proven itself in just those tough conditions. Being rooted in a distributed foundation, has given Cassandra the ability to do hybrid cloud, multi-cloud or geographically distributed environments from the beginning. As applications have been built to withstand failures and scalability problems, Cassandra has been the database of choice for developers.

JAX London 2019

 

What’s next?

Today, we have more developers using microservices designs to decompose applications into smaller and more manageable units. Each unit fulfills a specific purpose which can scale independently using containers. To manage these container instances, the container orchestration tool Kubernetes has become the de-facto choice.

Kubernetes can handle creating new container instances as needed, which can help scale the amount of compute power available for the application. Similarly, Kubernetes dynamically tracks the health of running containers – if a container goes down, Kubernetes handles restarting it, and can schedule its container replacement on other hardware. You can rapidly build microservice-powered applications and ensure they run as designed across any Kubernetes platform. For an application to run continuously and avoid downtime, even while things are going wrong, are powerful attributes.

In order to run Kubernetes together with Apache Cassandra, you will need to use a Cassandra Operator within your Kubernetes cluster. This allows Cassandra nodes to run on top of your existing Kubernetes cluster as a service. Operators provide an interface between Kubernetes and more complex processes like Cassandra to allow them to be managed together. Starting a Cassandra cluster, scaling it and dealing with failures are handled via the Kubernetes Operator in a way that Cassandra understands.

Since Cassandra nodes are considered stateful services you will need to provision additional parts of your Kubernetes cluster. Storage requirements needed by Cassandra can be satisfied by using PersistentVolumes and StatefulSets to guarantee that data volumes are attached to the same running nodes between any restart event. Containers for Cassandra nodes are built with the idea of external volumes and are a key element in the success of a cluster deployment. When properly configured, a single YAML file can deploy both the application and data tiers in a consistent fashion across a variety of environments.

SEE ALSO: Successful Containerized, Multi-Cloud Strategy: Tips for Avoiding FOMO

Planning ahead

As you look at adopting microservices and using application containers, you can take advantage of fully distributed computing to help scale out. However, to really take advantage of this, you need to include distributed data in your planning. While Kubernetes can make it easier to automate and manage cloud-native applications, using Cassandra can complete the picture.

Bringing together Apache Cassandra and Kubernetes can make it easier to scale out applications. Planning this process involves understanding how distributed compute and distributed data can work together, in order to take advantage of what cloud-native applications can really deliver.

Author

Patrick McFadin

Patrick McFadin is the vice president of developer relations at DataStax, where he leads a team devoted to making users of DataStax products successful. He has also worked as chief evangelist for Apache Cassandra and consultant for DataStax, where he helped build some of the largest deployments in production. Previous to DataStax, he was chief architect at Hobsons and an Oracle DBA/developer for over 15 years.


Related Articles

migration
cassandra
kubernetes

How to Migrate Your Cassandra Database to Kubernetes with Zero Downtime

DataStax

11/15/2023

cassandra
kubernetes

Checkout Planet Cassandra

Claim Your Free Planet Cassandra Contributor T-shirt!

Make your contribution and score a FREE Planet Cassandra Contributor T-Shirt! 
We value our incredible Cassandra community, and we want to express our gratitude by sending an exclusive Planet Cassandra Contributor T-Shirt you can wear with pride.

Join Our Newsletter!

Sign up below to receive email updates and see what's going on with our company

Explore Related Topics

AllKafkaSparkScyllaSStableKubernetesApiGithubGraphQl

Explore Further

cassandra