The main aspect of my role here at Couchbase, is educating people in different areas of the Couchbase portfolio. Then, working closely with customers to build resilient, performant solutions for their specific application needs. Couchbase Cloud became generally available around the same time I joined the company and has become one of my main topics of conversation with customers. Like most new things, especially when it comes to people’s data, people want to fully understand what they are working with before considering adopting the technology.

There are a number of questions that come my way around the new offering. However, the majority of these questions seem to focus on the initial stages of evaluating the product and whether it is fit for purpose. What? Why? When? How?

I thought it would be a good idea to answer a few of these questions in a format which could be transferable and reusable. What better place than a shiny new blog post to get started on your Fully Managed NoSQL adventure.

So, whether you have already heard about the solution and want to get started, or whether this is the first you’re hearing about it. This blog post is set out to answer some of those key burning questions, that both new users and I, encounter on a regular basis.

What is Couchbase Cloud?

Couchbase Cloud takes a 360 approach to your NoSQL Couchbase Server deployments including ALL of your Cloud Service Providers. Whether you deploy On-Prem, private or public cloud, all of your Couchbase clusters should be seen as equal entities with the same level of capabilities and manageability from a single pane of glass.

Couchbase Cloud clusters take full advantage of our Autonomous Operator and allows deployments in the cloud to become fully managed clusters. Deployment, operations, and upgrades are no longer a task of a database administrator, these tasks are all automated and managed through the operator, removing the burden and time-consuming resource from your database teams. We incorporate Multi-factor authentication (MFA), as well as Role-Based Acess Control (RBAC), with data encrypted at rest and in flight, to fully secure the information in all instances at any point.

Caching, Sources of truth, Systems of records in single or multi-node deployments with either hourly or volume-based payment methods, allows full flexibility in not only the direction of the internal infrastructure but also the cost that comes with each individual use case. All of these capabilities, whilst providing high availability and resiliency, with full fault tolerance and self-healing properties throughout application interaction and maintaining the highest possible level of performance.

There is a lot of information to take in there, but there is a lot of functionality that we have been able to achieve with this latest offering which we see everybody moving towards in the near future. Below is a diagram which itself can look a little complicated, but will give you a little understanding of how Couchbase and the Autonomous operator sit inside customers VPC and talk to this central pane of glass.

Avoiding Vendor Lock-In

Now as with most cloud technologies we face a common problem, picking the right Cloud Service Provider to deploy our service on. There are a number of big competitors in the cloud computing space, all fighting for the right prices and machine sizes, in an attempt to become the main provider of cloud services for the world. In reality, is there really only going to be one?

Couchbase Cloud was designed on the basis that nobody truly knows what the cloud market space is going to look like in the future. There isn’t going to be a single platform to provide all the answers, but more of a complex architecture which may take the best parts from all of them. Some consumers may have their favourites and choose to deploy everything in the same place, others may have this mixture of multiple vendors. Either way, we wanted our database to be completely heterogeneous with its deployment strategy.

Like our diverse infrastructure, Couchbase Cloud clusters can be deployed in any main Cloud Service Provider, with the ability to communicate and run alongside another cluster in a different provider. Replication and High Availability across multiple platforms with all the information and metrics viewable from a centralized location. This flexibility and adaptability are aimed to remove people’s concerns of the future which we spoke about at the start. People shouldn’t be concerned about what the future may look like, purely because we understand nobody knows what the answer is yet.

What is so different?

There was careful deliberation around how Couchbase Cloud would work, with a focus on what’s best for our customers. Despite not being first to market with a Fully Managed NoSQL solution, it allowed us to look at what was currently out there, and see where we found the most common pitfalls. What could we do better?

One of the main topics of discussion comes around cost. Now we are taking a lot of the operational responsibility onto ourselves, instead of in the hand of our customer, how much do we value that time? Unfortunately, there is no fixed value for this sort of measurement, every use case is different, and it would be hard to calculate. So we started to look at other things. One of the problems that we saw were the costs that other solutions charged.

Now, being first to market means that you can set whatever price you want on your solution, however most of the time this comes at a cost higher than it should be. Competitors’ technologies provide fully managed offerings on hosted environments. Which essentially means that, the company will rent out machines and then sell those machines packaged with the technology and stamp a price on the side, most of the time they will be increasing the price they are paying on the machine, Upselling.

We wanted to avoid this pricing model, why should a company be paying any more money than we would for renting those servers?
Couchbase Cloud is there to provide a NoSQL technology, that’s what you should be paying for, nothing else.

So, this is where the ‘Deploy in your VPC’ approach came along. We will work side by side with your current Cloud Service Provider, to spin up the correct infrastructure and deployment of the Couchbase NoSQL Database, allowing you to be fully in control of the cost. No upsold machines or increased prices, you receive them at the exact price you would pay for them yourselves, we just focus on the licensing of the database. Pay for what you run, nothing more.

So where do you begin?

Like most technologies, personally I feel the best way to experience this new solution and understand the benefits that come with it, is to simply try it out. This is achievable in a few steps but it’s worth explaining them briefly.

1. Register on cloud.couchbase.com

This is the entry point for the solution, the control plane. From here you can login and control all of your Cloud providers and NoSQL clusters which reside on them. Think of this as a 360 overview of your NoSQL portfolio.

2. Connect a Cloud Service Provider

In order for Couchbase to be deployed within your CSP you will need to log into the desired service and accept permissions which allows Couchbase to kick off and manage the deployment within your VPC.

If you want to read a full breakdown of the explicit permissions required, then head to the documentation for a breakdown. https://docs.couchbase.com/cloud/clouds/cloud-providers.html

3. Deploy a Trial cluster

There is a full list of customizable deployments to suit your use case’s need. However, for those who are wanting to spin things up quickly, then this can be done through an evaluation cluster. Those of you who have any prior experience of Couchbase will know that this deployment colocates all features between three nodes, not optimized in any way for performance, so this should be strictly considered for evaluation purposes only.

4. What to start with

A good starting point would be to look around the control plane and get some familiarisation with the technology, see how it looks and feels. Look into the different users and project hierarchy, how could this solution fit into your current deployments? Who would be responsible for the top-level administration?. Then you should play around with connecting an SDK to the cluster and interacting with it through an application. understanding the similarities it shares with an on-prem or virtual cluster, for those with previous experience.

5. Finally… production clusters and migration

Once you have been hooked on the idea of autonomous maintainability, then you’re likely going to want to get your journey started. I would try and get in contact with a representative from Couchbase to have a proper discussion of any further questions that you may still have, then we can also help you build the best database for your specific needs. Once we have a production cluster up and running, you should be ready to go. If you have an existing cluster and wish to move to the new fully managed offering then you can you would need to migrate your existing information over to the platform. Fortunately, Couchbase works well with any other deployment, whether that be a private cloud, public cloud, containerized, virtual machines, or even bare metal. Tools like Cross Data Centre Replication will allow you to stream your data to your new environment, hassle-free.

What the future holds

Although Couchbase Cloud is already supporting a number of clusters and use cases, in our eyes, the journey has only just begun. Theres a number of things currently in the roadmap and to finish off I’m going to list a few interesting ones that I’m looking forward to, so I know you will too

• Private Networking
• Cloud API’s
• AWS + Azure Region expansion
• Data Migration Enhancements
• Cluster Hibernation