How to reach on premise resources with Serverless products ?

Published in

Google Cloud - Community

8 min readJul 31, 2019

Serverless is awesome. You pay only when they run and they scale automatically. Serverless solves a lot of problem. Do have a micro-batch to run daily ? Use the resource only when required ! Do you have an event to handle ? Plug it to your code and process it.

When you begin to play with serverless, like AppEngine, Cloud Functions or Cloud Run, you want to use it everywhere and anytime, even for your on-premise workload. However, there is a major issue: your workload has to use on-premise data and data can’t be moved to the cloud because other on-premise workloads use them.

Connect OnPrem data to the Cloud

For using securely the on-premise data in the cloud, you have to secure the connexion, mainly without exposing public IP and by encrypting data in transit.

The cheaper solution is the VPN. The bandwidth is limited but it offers a good starting point with low investment for a secure channel to your on-premise environment

The ultimate level is the interconnect solution, which offers a direct connection between your on-premise environment and Google fiber network. Extremely fast (from 10 to 100Gbits/s), with high SLA and thus… expensive.

Finally, the intermediate level is the Partner interconnect. A tier company has a direct connect subscription with Google, and resell smaller bandwidths. The SLA are lower than with direct interconnect, but the price is more accessible for small and medium company.

In production environment, don’t forget to, at least, backup each link for avoiding SPOF (single point of failure)

I’m not expert in network and I can’t discuss about the best hybrid connectivity solution. There is a lot of great articles and examples here.

So, to connect your on-premise environment is time consuming, more or less expensive, and you have to double all for reliability. And, thereby, you don’t want to reproduce this work in all your project.

The solution is to connect all other projects to this “on-premise entry-point” project and thereby to re-routed other projects flows to the on-premise environment. Here is the purpose the VPC peering solution.

Now you have the right product for connecting your on-premise environment to all your GCP projects, in a secure way and with mutualized costs and efforts!

Serverless to VPC connexion

Serverless means without infrastructure to manage. Thereby, a design issue seems occur

How to connect not managed servers and networks to a specific and managed VPC ?

Hopefully, a beta feature helps us in this task: serverless VPC connector. Today available only for Cloud Functions and AppEngine; the team works hard to offer this capability to other products like Cloud Run.

The principle is simple:

Define an IP range (CIDR /28) for the serverless service
Define a name
Define a location

Then attach this connector to your serverless product and its network flow will enter in the VPC network with one of IP defined in the range. The 2 worlds are unified!

How to proceed

Now, we have all the pieces of the puzzle, let’s have a look how to proceed step by step.

I will name “project-onpremise” the project with the VPC connected to on-premise environment, and “project-function”, the project where the Cloud Functions is deployed and has to reach Oracle DB on the on-premise environment.

Cloud Function to on-premise through hybrid connectivity, VPC Peering and Serverless VPC Connector

Create the VPC peering

In this part, I suppose that the connexion with your on-premise environment exists (VPN or interconnect). If you want to create a dummy VPN connection, this Qwiklab is well documented

For creating a VPC peering, you have to create a peer connexion in each project. Let’s start with the project-onpremise:

Go to Network, then VPC network Peering

Click on Create Connection, then Continue
Fill the name of the connection, select the VPC that you want to use in the current project (here the default)
Choose In another project, then fill the projectId (not the name!) and the VPC name into the target project
Don’t forget to click on Exchange custom routes and select Export custom route for exporting hybrid connectivity route to the peering.
Click on Create

If you prefer command lines

gcloud beta compute networks peerings create peer-project-function \
    --network=default \
    --peer-project project-function \
    --peer-network default \
    --export-custom-routes

Perform the exact same mirrored thing in the project-function.

Switch project, go to Network, then VPC network peering
Click on Create Connection, then Continue
Fill the name of the connection, select the VPC that you want to use in the current project (here the default)
Choose In another project, then fill the projectId (not the name!) and the VPC name into the target project
Don’t forget to click on Exchange custom routes and select Import custom route for importing hybrid connectivity route from the peering.
Click on Create

If you prefer command lines

gcloud beta compute networks peerings create peer-project-onpremise\
    --network=default \
    --peer-project project-onpremise \
    --peer-network default \
    --import-custom-routes

Great, now your peering should be green in the 2 projects.

Be careful, if you use the default VPC networks created automatically in the projects, it won’t work because IP range are overlapped. Indeed, the peering import all the subnet of the VPC from the target project. This builds a logical super VPC with the subnets of all the peered projects.

Thereby, I recommend you to create a custom VPC, or to turn to custom the default VPC and change/replace the current ranges in both projects for avoiding any overlapping.

Now, have a look on network routes in the projects.

project-onpremise with peering routes of project-function and the vpc-tunnel route

project-function with default route (own VPC) and the peering routes, including the custom-vpc route to VPN

As you can see, the custom VPC route for the VPN has been exported to the peer project and correctly imported in the project-function.

The routes between the projects are up. Let’s continue with the VPC Connector.

Create the VPC Connector

The serverless VPC Connector builds a bridge between the serverless “wild” world (not or few customizable) and your “in-house” VPC (fully customizable). Let’s set up one in the project-function:

Go to Network, then Serverless VPC Connector
Enable the API if asked
Click on Create connector (Until now, the GUI allows to create a connector only in the us-central1 region. us-east1 and europe-west1 are only available in command lines)
Fill in the name, (can’t select the region), the VPC network and the IP Range (here an example, choose the right one in your context). Here again, the IP range has not to overlap an existing range.
(Optionally, you can change the min/max throughput, this will impact the billing)
Click on Create

If you prefer command lines (here an example with europe-west1 region)

gcloud beta compute networks vpc-access connectors \
      create function-to-fusion \
      --network default \
      --region europe-west1 \
      --range 172.16.16.240/28

Great, that works !

Don’t forget to update your routing rules on your on-premise equipments for sending back the response to the defined serverless VPC Connector range

Create the Cloud Functions

Now, the final piece. But before creating the Cloud Functions, roles has to be granted to the “Cloud Function Service Agent” for allowing the Cloud Function to use the serverless VPC connector

You can add them manually in the IAM console:

Add project viewer role
Add compute network user role

Or use the command lines

PROJECT_NUM=$(gcloud projects describe project-function \
      --format="value(projectNumber)")gcloud projects add-iam-policy-binding project-function \
      --member=serviceAccount:service-${PROJECT_NUM}@gcf-admin-robot.iam.gserviceaccount.com \
      --role=roles/viewergcloud projects add-iam-policy-binding project-function \
      --member=serviceAccount:service-${PROJECT_NUM}@gcf-admin-robot.iam.gserviceaccount.com \
      --role=roles/compute.networkUser

Now, let’s deploy a simple test connexion Cloud Function in Go for testing the opened port on-premise. (In my case, I would like to reach a Oracle database, port 1521)

Go to Cloud Function, clic on Create function
Name your function, select the runtime Go 1.11
In the function.go paste this code snippet

package pimport (  
    "fmt"
    "net"
    "time"
    "net/http"
)func Ping(w http.ResponseWriter, r *http.Request) {  
    conn, err := net.DialTimeout("tcp", "10.1.2.2:1521",   time.Duration(10)*time.Second)
    defer conn.Close()    if err != nil {
        // Log or report the error here
        http.Error(w, err.Error(), http.StatusNotFound)
        return
    }
    fmt.Fprint(w, "Connexion OK")
}

Change the function to execute to Ping

Deploy the section Environment variables, networking, timeouts and more
Select the Region of your VPC connector and your VPC Connector in the drop down list
Then clic on Create

If you prefer to deploy with command lines (in the directory where you have created the files function.go)

gcloud beta functions deploy test-onpremise \
      --vpc-connector projects/project-function/locations/us-central1/connectors/function-connector
      --runtime go111
      --trigger-http

Now, it’s time to test your function and the whole connectivity.

In the console, simply click on Test the function

Or with command line

gcloud function call test-onpremise
# result: Connexion OK

Boom, that works !

Summary

In few clicks, or few command lines, we simply:

Create a VPC peering to be connected to a mutualized project which act as entry-point to the on premise environment
Set up a bridge between the serverless world and the VPC network with the serverless VPC connector
Deploy a Cloud Function which reaches securely on premise server without exposing any public IP. This work also with AppEngine, and soon with Cloud Run

This capability is very useful for starting a migration process with no critical workload and with few data to process, especially with VPN. Indeed, the network latency and the connection availability avoid all mission critical workloads.

Serverless VPC Connector is also useful for allowing your serverless components to reach services only deployed on VPC, like Memorystore or VM only available in a VPC (without external IP).

Happy testing!