This headline is kind of the whole idea of Cloud computing. It is not necessarily cheaper than On-Prem hosting if you only count the hardware and platform costs while in operation. However if you're not a company whos main business IS operations then why build up platforms and competence in this area? It's going to cost you lots and lots of money to do so, and even more to maintain the quality of what you've built up.

You just want to sell your services, right?

So, understanding that you need 3rd party solutions of various sorts, like databases and caches, with great uptime and security and also knowing the pain in configuring and maintaining these products GCP, like all other decent Cloud providers, offer managed solutions of the most common and beloved products. This means that you don't need to handle or understand complicated setups and high availability configurations. There is a built-in solution!

In the first part of learning to integrate our own GKE services with managed GCP services we will make use of Cloud SQL. Cloud SQL comes with three different SQL service solutions;

• MySQL
• PostgreSQL
• SQL Server (beta)

We will use PostgreSQL in this example, but obviously the only difference is the configuration of our services (using a PostgreSQL connector rather than a MySQL or SQL Server one) and to some extent the provider differences when it comes to specifying the schemas etc.

Use the web based Cloud console and go to the SQL section using the menu. What we're going to achieve looks like the following:

So go ahead and click "Create instance" to get started. When prompted to select type of database click "Choose PostgreSQL" (you'll get to choose version soon).

You'll reach a screen when you're asked to fill in some info.

You can really choose any name you like for the database but why not pingpong-database as in the example picture?

For this showcase the provided config/setup expects the password to be postgres (for the user postgres). This is bad practice for production usage but it keeps things simple for us right now.

Choose region europe-west3 and zone europe-west3-a. This is where our cluster is so it will give us low latency.

Go ahead and choose PostgreSQL 11.

Click the link Show configuration options to see available config parameters. Some are of interest, some are not.

Choose Private IP, associate it with your pingpong-site1-net, choose automatically allocated IP and then click the button to Allocate and Connect. This will take some time...

Make sure you have the smallest (and cheapest) available machine type. This should be default.

Turn off backups and make sure you do not use high availability. In a real world example both of these are most likely a must have, but for the sake of this showcase it's just extra costs...

Once done with all of the above, go ahead and create the instance. It will take some time, a couple of minutes, to allocate the database and to configure your network to access it. When all is done you should return to the instance overview page, as in the picture above, and you should see your database.

Now we're going to abandon the old pingpong-service-simple that we've played around with so far and instead navigate into the pingpong-service-postgres folder of the project.

Let's spend a few seconds on explaining how the pingpong-service-postgres works.

First of all, when the service starts it will connect to a database and create a very simple schema into which it loads a list of memes. The framework used to do this is called Flyway and it has a very tight integration with Spring Boot making it easy to use. The actual SQL files that are loaded upon service startup are located in the src/main/resources/db/migration folder if you want to check them out.

Then, in the API, this version of pingpong-service accepts a request parameter called meme which makes the service return a random meme on each request when you set it to true. The memes are retrieved from the database.

As with the public IP, that your pingpong-service will receive when exposed to the Internet, it is impossible to predict the Private IP that your database will obtain upon being created. Therefore you need to set it properly yourself.

The k8s folder contains two other folders:

-rw-r--r--  1 user  group  161 Feb 23 21:54 kustomization.yaml
drwxr-xr-x  5 user  group  160 Feb 23 21:53 managed-postgres
-rw-r--r--  1 user  group   57 Feb 15 16:36 namespace.yaml
drwxr-xr-x  5 user  group  160 Feb 23 21:38 single-exposed-deployment

Go into the managed-postgres folder and open the file called endpoints.yaml. In there you find the following:

kind: Endpoints
apiVersion: v1
metadata:
  name: pingpong-database-service
subsets:
  - addresses:
      - ip: <YOUR-IP>
    ports:
      - port: 5432

Yeah, you've guessed it! <YOUR-IP> is not gonna work! Replace that with the Private IP of your database.

The endpoint object allows us to abstract the IP of the SQL service and combined with a service object we can use a meaningful name in our own service configurations. If we need to update the IP we just update the endpoints object, no need to change any service config. This won’t even require a restart.

Do study the different kustomize- and yaml-files for a while to get a feeling of how they add up to what we want.

Once the change is done you can just go back to the k8s folder and run kustomize in that folder as per usual and the service should start up.

Check your public IP with a get services query to see your public IP and then in your browser navigate to:

http://<YOUR-LOADBALANCER-IP>:8080/ping?name=John&meme=true

You should see something similar to this:

This is of course hilarious so go ahead and spend the rest of the evening exhausting the memes. When you get tired of that we're going to look at caching the memes so that your database gets a relief from all those requests of yours. That's the next chapter.