Cloud SQL as we just mentioned is a default choice for those OLTP or Online Transaction Processing workloads on Google Cloud. Let's dive a little bit deeper. Cloud SQL is an easy-to-use service that delivers fully manage relational databases, Cloud SQL lets you hand off to Google all those mundane but necessary and time-consuming DBA tasks, like applying patches and software updates, managing your backups and configuring replications. So you can put your focus on building your great application and not being a DBA. Cloud SQL is Google's managed service for third-party RDBMSs or Relational Database Management Systems. It has MySQL, recently added PostgresSQL and Microsoft SQL server in there as well, we'll continue to add additional RDBMSs over time. What this means is that we provide a compute engine instance that already has that database like MySQL already installed, we'll manage the instance on your behalf. We'll do the backups, we'll do security updates, update the minor versions of the software, so you don't have to worry about that. In other words, Google Cloud manages the database to the point where you can treat it as a service. We even do DBA-like things, you can tell us to add a failover replica for your database, we'll manage it for you, and you'll have a 99.95 availability SLA. Another benefit of cloud SQL instances is that they're accessible by other gcp services as you saw with our Federated query from BigQuery to Cloud SQL, I love that demo. You can also use Cloud SQL with app engine, using standard drivers like connector J for Java and MySQLdb for Python. You can authorize compute engine instances to access Cloud SQL instances, configure the cloud SQL instance to be in the same zone as your virtual machine. Cloud SQL also supports other applications and tools that you might already be familiar with, for example, if you're using MySQL, MySQL Workbench, Toad and other external applications using those standard MySQL drivers. One of the advantages of Google managing your database is that you get the benefits of Google grade security. Cloud SQL's customer data is encrypted when on Google's internal networks, and when stored in database tables temporary files in those backups that we mentioned earlier. Every Cloud SQL instance includes a network firewall allowing you to control network access to your database instance by granting a revoking access. Cloud SQL is easy to use, it doesn't require any software installation or maintenance, and Google manages the backups. It takes care of the securely storing your backup data and then it makes it easy for you to restore from a backup at a point in time and perform that recovery to a specific state of that instance. Cloud SQL retains up to 7 backups for each instance, which is included automatically in the cost of your instance. You can vertically scale Cloud SQL, just increase the size of your machine, you can scale it up to 64 processor cores and more than a hundred gigabytes of RAM. Horizontally, you can quickly scale out read replicas, Google Cloud SQL supports 3 read replica scenarios. The first, Google Cloud SQL instance is replicating from a Cloud SQL Master instance, replicas are other instances in the same project and location as a master instance. Second, Cloud SQL instance is replicating from an external Master instance, therefore the master instance is external to Google Cloud SQL. For example, it can be outside the Google Network or in a Google compute engine instance, you can use this for backing up an on-premise SQL instance. Third, external SQL instances replicating from a Cloud SQL Master instance or replicas that are in a hosting environment that's outside of Cloud SQL. And keep in mind, if you need a horizontal read and write scaling, consider the use of Cloud Spanner. For the special case of failover, Cloud SQL does support this, Cloud SQL instances can be configured with a failover replica in a different zone within the same region. Then, Cloud SQL data is replicated across zones within a region for durability. In an unlikely event of a complete data center outage, a Cloud SQL instance will automatically become available in another zone. All changes made to the data on the Master are then replicated to a failover. If the Master instances zone has an outage, Cloud SQL automatically fails over to the replica. If the Master has issues not caused by his own outage, failover doesn't occur, you can however initiate that failover and get those benefits manually. Now, there are a few caveats, note that the failure of a replica is charged as a separate instance. And when a zonal outage occurs and your master fails over to your failover, replica any existing connections to that instance are closed. However, your application can reconnect using the same connection string or IP address. You don't need to update your application after a failover. After a failover occurs, the replica becomes the Master, and Cloud SQL automatically creates a new failover replica in another zone. If you located your Cloud SQL instance to be near other resources, such as a compute engine instance, you can relocate your Cloud SQL instance back to its original zone when that zone becomes online again, otherwise, there's no need to relocate your instance after a failover. You can use the failover replica as a read replica to offload read operations from the master to help avoid those bottlenecks. For more details on failover replicas, check those docs that I'll provide on high availability. We kept saying that cloud SQL is fully managed. You might also seen us use the word serverless to describe like BigQuery. For example, what's the difference between fully managed and serverless? By fully managed, we mean that the service runs on a hardware that you can control, you can SSH into a Cloud SQL instance for example. That said, Google does help you manage that instance by automating backups and setting over those failover instances that we just talked about. Serverless is the next step up, you can treat a serverless product that's just like an API that you're calling, sure you pay for using the product, but you don't have to worry about or manage any of the servers, for all you know, it could be completely manual behind the scenes, you just get the benefits of the output. BigQuery is serverless, as is cloud pub/sub for asynchronous messaging and data flow for parallel data processing, you can think of cloud storage as being serverless as well. Sure cloud storage uses discs, but you never actually have to interact with any of the hardware. One of the unique things about Google Cloud is that you can build a data processing pipeline on well design components all of which fully is serverless. Dataproc on the other hand is fully managed, meaning it'll help you run Spark and Hadoop workloads, without having to worry about the setup, you can get to those servers if you wanted to. Given the choice between doing a brand new project on BigQuery or data flow which are serverless or Dataproc which is fully managed, which one should you choose? Well it really depends on your use case, but all things being equal, if it's easy enough to get your data into either, you want to choose this serverless product.
