The Journey to Hybrid Cloud with DataStax Enterprise
Introduction
Hybrid and multi-cloud computing environments incorporate infrastructure from multiple platforms and data centers and are typically a combination of on-premises resources and resources offered by one or more cloud service providers.
Hybrid and multi-cloud offer many benefits, and DataStax Enterprise (DSE) can be an important component in achieving those benefits. This paper discusses a number of success patterns for moving to a hybrid or multi-cloud environment, and the role that DSE can play in each pattern.
Hybrid and Multi-Cloud Use Cases
There are many reasons to adopt hybrid or multi-cloud. For example, an organization may want to avoid being locked into a specific cloud vendor for financial or strategic business reasons. They may also want to ensure that they avoid entire cloud outages.
An organization may also want increased agility in their development cycle. For example, they could partition their application in the cloud based on the application lifecycle. In this case, the organization would utilize services in a public cloud such as Google Cloud Platform (GCP), Microsoft Azure, or Amazon Web Services (AWS) during their development and test cycles. For production, they would then deploy their application to local on-premises infrastructure and turn off those used in the public cloud, resulting in cost savings and reduced time to market.
Hybrid cloud also enables enterprises to choose where to place workloads and data based on compliance, policy, and/ or security requirements. For example, an enterprise may want to keep certain data assets on premises. Security policies could require user authentication and authorization data to be stored and accessed via on-premises servers while the content
is managed via a public cloud provider, as is the case for Sony, which runs databases for individual PlayStation games in the cloud but takes care of user authentication on premises.
Accordingly, hybrid cloud allows you to put the data closer to additional cloud services an enterprise may want to leverage. Perhaps the enterprise wants to use Microsoft Azure Cognitive Services, Google Cloud Machine Learning, or both. Machine learning requires a lot of data and processing; moving the data sets from one cloud to the next isn’t typically a straightforward process.
However, DSE provides the flexibility needed to seamlessly share data across disparate resources. Because of this, enterprises use DSE not only as the database of record to collect data for training purposes when building their AI models, but also as a way to store features for continued use by data science and engineering teams in both development and production.
How to Achieve Hybrid Cloud Success
Over 60% of DataStax customers leverage resources from cloud service providers. In helping our users achieve their hybrid cloud objectives, we see common patterns for achieving a successful outcome.
These include:
- Using a distributed database management system (DBMS) that spans multiple clouds
- Eliminating single points of failure
- Creating a data management strategy
- Creating a security strategy
- Monitoring the database via a single view
In the following sections, we’ll explore these keys to success and how DataStax addresses them.
Use a Distributed DBMS That Spans Multiple Clouds
If you have multiple database management systems in multiple clouds, then you likely have many different applications and APIs in place to access and update them. This creates an overly complex environment to use and maintain.
With DSE, you can deploy a single distributed database (one schema) spanning multiple clouds and accessed through
one or more microservices. The microservices do not need to know that there are multiple clouds in place, just that they utilize a single API. In fact, the microservice could be architected for a single cloud and then later an additional cloud could be added without a major rewrite of the microservice. In other words, it’s easy to add an additional cloud service provider.
Eliminate Single Points of Failure
An active everywhere architecture such as the masterless architecture of DSE is a distributed database that has no single point of failure. It utilizes a peer-to-peer design and can include multiple data centers in a hybrid cloud.
This matters because, rather than relying on a typical master/slave architecture common with relational databases and most NoSQL databases, an active everywhere architecture has no master point that services write traffic. In master/slave environments, if the master is not available, a new master needs to be elected and write requests will be temporarily suspended while this happens.
With a peer-to-peer architecture, requests can go to any one of the database nodes. If a server disappears, requests will simply not be sent to that node. If an entire data center is not available, perhaps due to a cloud outage, requests automatically go to another data center.
It’s also important to remember that having a distributed database architected to avoid single points of failure does not guarantee protection. There are still entire cloud outages and/or hardware configurations configured with a single point of failure built in. For example, a single network connection between a microservice and an application that uses that microservice could cause an outage if the connection
isn’t available.
The architecture must ensure that there are always multiple paths for connections between microservices, applications, and data. In the case of cloud outages, if your microservices are deployed in only one cloud, they will not be available during the outage. In a similar fashion, if your business logic is dependent on a specific management service that is only available through your cloud provider, then that management service is not likely going to be available in another cloud. (Note: In some cases, companies decide to accept that risk in order to take advantage of a great service provided by the specific public cloud.)