Cloud Console for Google CloudSQL and AlloyDB — Compute | by Artem Nikulchenko | Google Developer Consultants | Could, 2023

I actually like Google Cloud UI Console. Sure, I do know, to be cool we’re supposed to love and do every thing in a shell (like in motion pictures), however I’ve to confess that I like that I can open Google Cloud Console, go to BigQuery, for instance, see my datasets, tables, and run a question in a pleasant UI.

However there may be one place the place I’ve been lacking it (and had to make use of Cloud Shell) — CloudSQL. There are a number of issues I can see about my DB in Google Cloud Console, however to really run any question — I’ve to make use of Cloud Shell. (At this level, should you utterly disagree with me — you may simply skip the remainder of the article :). And to be honest, I actually like Cloud Shell too for a lot of different use instances.).

So, we thought — why not construct a easy Cloud UI Console for CloudSQL ourselves? And whereas we’re at it — let’s be certain that it can be used for the brand new and funky AlloyDB. And naturally, do it open-source — in order that anybody who shares our ideas can use it too.

And extra importantly, as Ralph Waldo Emerson mentioned — “It’s not the vacation spot, it’s the journey.” Planning on doing such a mission, we realized that we’ve got to make an inventory of architectural selections just like selections we’ve got to make for a lot of different initiatives. So why not convert this course of into posts to share our ideas (and perhaps even be taught the place we have been fallacious)?

This and the next posts will cowl this “journey” and hopefully, arrive on the vacation spot. Be aware: Since it is a Google Cloud collection, we won’t discuss concerning the UI half and can solely deal with the backend.

In case you are right here for the vacation spot (which means that you just truly like the concept of SQL UI Console and wish to use one however don’t want particulars on how it’s constructed) — right here is the hyperlink: Google Cloud SQL Console. Be aware: that is nonetheless a piece in progress 🙂

As for some other mission, we should make the next selections:

  • Compute. Which computing service would we use to run our app?
  • Storage. We’ll most probably have to retailer some information (Customers, Credentials, and so forth.). The place will we retailer them?
  • Safety. Clearly, we would want to guard our app. How will we do it?

Earlier than we are able to make any selections, we have to focus on what we truly need. Listed here are our necessities:

  • Simple to make use of. We wish our UI Console to be very straightforward to make use of (whether it is tougher than embedded Cloud Shell — what’s the level?).
  • Simple to put in. Because it received’t be a normal a part of the Google Cloud Console, we have to construct it in a manner that it will be straightforward to put in for a person.
  • Scaling to 0 (or nearly 0). We assume that this app will solely be used often. It signifies that the infrastructure price to run it needs to be very small when used and even smaller (ideally zero) when idle.
  • Safe. That’s the apparent half.
  • Not limiting. To meet necessities of “Simple to put in” and “Safe” we might want to deploy this app throughout the Google Cloud mission the place CloudSQL is used. In any other case, our choices can be to both open CloudSQL to the general public (which undoubtedly violates “Safe”) or ask the person to make some difficult community configurations (which violates “Simple to put in”). If we plan to put in our app into the person’s mission — we have to ensure that it doesn’t intrude with the rest working there (or perhaps be working sooner or later).

With our primary necessities established, let’s begin to make our selections. First — compute.

Google Cloud provides a number of choices:

  • Google Compute Engine
  • Google Kubernetes Engine
  • Cloud Run
  • Google App Engine Flex
  • Google App Engine Customary
  • Cloud Features

Any of them can truly be used to run the applying we wish to construct. However let’s see which inserts greatest and let’s begin by trying into what doesn’t match.

Google Compute Engine

GCE is a good service and a very simple entry level for these used to pre-cloud VMs. However I don’t suppose it’s the greatest match for our mission as a result of:

  • If we let the GCE machine with our app run on a regular basis, that may violate our “Scale to 0” requirement.
  • If we ask the Consumer to begin and cease the GCE occasion every time the person desires to make use of our app, it violates the “Simple to make use of” requirement.
  • We might have constructed a particular service on Cloud Features, for instance, that robotically begins/stops the VM, however that may in all probability violate the “Simple to put in” requirement.

Let’s see what our different choices are.

Cloud Features

Leaping to the opposite a part of the specter — Cloud Features.

Once more, that is doable however Cloud Features have been designed for even-driven workflows whereas the person maintains a session with our app (it received’t be good to ask for credentials every time the person runs a question). Let’s skip this for now.

Google Kubernetes Engine

We love GKE and it’s utilized in all our initiatives and if there’s a GKE cluster working in a mission already, including yet another pod with SQL Console could be an excellent choice.

Nonetheless, if GKE isn’t utilized in a mission, this method received’t work as a result of:

  • Beginning and managing GKE cluster for a person that by no means used it could’t be thought of “straightforward to put in”.
  • Because of the administration payment, it received’t “scale to 0”. (Technically, there’s a free tier that gives $74.40 in month-to-month credit per billing account that applies to zonal and Autopilot clusters. However that solely covers one cluster.)

Due to that, we should always skip GKE for now however add yet another nice-to-have requirement: be capable of deploy SQL Console into the GKE cluster (this could be utilized by customers who’ve GKE clusters which might be already working). We will name it “Containerization”.

Now we’re down to a few contestants…

Google App Engine Customary

Google App Engine Customary was the primary (and solely at the moment) service accessible on Google Cloud and principally began Google Cloud as a platform. It was designed to permit constructing scalable net apps fast and straightforward and it nonetheless serves the identical goal.

Be aware: GAE didn’t achieve reputation at its time, however in my private viewpoint, that was because of the solely storage accessible at the moment — Datastore. Datastore had eventual consistency, which restricted the set of apps that might be constructed utilizing it and required new approaches.

Nonetheless, Google App Engine Customary comes with the next limitations:

  • It’s important to construct an app particularly for GAE Customary, which suggests it received’t be doable to take the identical app and later deploy it to GKE.
  • The checklist of supported languages is proscribed. In our case, we needed to make use of .NET, which isn’t supported.

So, now we’re down to 2 and we’re on the closing spherical!

Google App Engine Flex and Cloud Run

GAE Flex and Cloud Run even have extra in frequent than variations. Each enable to deploy and run the container-based app whereas caring for scalability, availability, redundancy, underlying infrastructure, and so forth.

Be aware: The underlying know-how and historical past of these companies are literally slightly totally different. App Engine Flex was initially constructed as an extension of App Engine Customary to resolve for limitation it had, whereas Cloud Run was constructed primarily based on an open-source knative mission.

Since our app can be container-based, it additionally signifies that we are able to later transfer the identical app to GKE with out altering the code.

Since each companies require constructing the app precisely the identical manner — we truly don’t have to make the ultimate alternative — we are able to construct our app and let the person determine. Our choice, nonetheless, could be Cloud Run.

BTW, App Engine Flex doesn’t assist scalability to 0 and all the time retains at the least one occasion working. Cloud Run, nonetheless, will take down all pods if the service isn’t used. 1–0 for Cloud Run!

Let’s declare Cloud Run a winner!

Let’s see how Cloud Run matches our necessities:

  • Simple to make use of. Utilizing Cloud Run would enable us to entry our app utilizing the browser.
  • Simple to put in. Deploying an app in Cloud Run is definitely slightly straightforward (so long as you know the way to construct a container, which is a “should have” in twenty first century…). Nonetheless, we would want to make sure that our CloudRun-based app can connect with the CloudSQL particular community configuration. Fortunately it’s effectively documented.
  • Scaling to 0 (or nearly 0). All OK right here — Cloud Run can scale to 0.
  • Safe. Cloud Run provides us sufficient management over safety (extra on that later).
  • Not limiting. Customers can have a number of Cloud Run companies throughout the identical Google Cloud mission, which suggests our SQL Console received’t battle with different companies.
  • Containerization. Cloud Run permits deploying containerized apps, so every thing is okay right here.

Seems to be like every thing checks our and we are able to transfer to our subsequent downside — storage.

Leave a Reply

Your email address will not be published. Required fields are marked *