Planning infrastructure requirements and costs
When you configured your server-side tagging endpoint with the automatic provisioning option, Tag Manager:
- Created a Google Cloud project for you
- Set up a server running on Cloud Run infrastructure
These Cloud Run deployment settings are intended for testing and setting up your server container. While proofing your setup, you will most likely stay within the free usage limits. However, to handle live traffic from a website, you need to upgrade your infrastructure.
Once you are ready to upgrade your environment, you need to consider a number of things:
- Stability: How much computing power do you need to run your server-side tagging environment? How much does your annual traffic fluctuate during high vs. low season or during high volume campaigns?
- Cost: How much budget do you have for running the environment? If you have insufficient funds to handle the full traffic load, you might have to consider throttling the traffic so that only a subset of the events are handled by the server container.
- Maintenance: Cloud Run requires some knowledge about the Google Cloud Platform. Do you have this experience in-house, or will you need to hire someone to support you?
- Organization policies: If your company already has a Google Cloud Platform account (or organization), there might be policies in place which require review before upgrading the server-side environment. It's a good idea to walk through the upgrade with your IT or DevOps people.
- Domain Name Service (DNS): It's a good idea to move your tracking into first-party context with your website(s). Work with your IT and DevOps people to update DNS zones accordingly.
Next, we will look at estimating how many instances you'll need. If you are already proficient with infrastructure design, you can skip ahead to the upgrade process.
Costs and estimations - Cloud Billing
The cost structure of a Cloud Run setup with server-side tagging depends on how much computation power and storage you need, and how much network traffic gets generated.
You can use the Google Cloud pricing calculator to estimate your monthly billing charges, but this can be difficult to use, especially because a typical website will have traffic fluctuation which might impact all three of the cost types listed above.
To roughly estimate your costs with a Cloud Run deployment, you need to look at these factors:
| Cost type | Impact on billing | Notes |
|---|---|---|
| Computation (instances) | High – fixed | Your minimum cost is the minimum number of instances you configured multiplied with the cost per server. To account for scaling your servers and getting a more realistic price range: Multiply the maximum instances you've configured with the cost per server. The price is approximately USD 50 per instance per month. |
| Network (egress) | Moderate – fluctuates | Egress is calculated for all outgoing network data from the server container. This includes requests dispatched by your clients and tags and HTTP responses from the server container back to the user's browser. Network egress can become a cost factor if your server-side tagging endpoint serves larger resources or JavaScript libraries. |
| Storage (logs) | Varies | Once you collect enough requests to surpass the free tier of Cloud Logging, the cost of storing logs can become substantial. To lower logging cost, filter out the incoming requests or to include only a sample of log entries. |
Alternatively, you can follow your Google Cloud Platform Billing reports closely, set appropriate budgets, and cooperate with your organization's DevOps team to figure out the best approach to scaling up your server-side tagging environment.
What to consider when designing the infrastructure
In case you want even more control over the deployment, familiarize yourself with the checklist below. While Cloud Run makes running and maintaining your servers as simple as possible, it's useful to understand the technical context in which your server operates to make informed decisions.
| Topic | Description | Considerations |
|---|---|---|
| Cold boot time | When your traffic spikes enough to trigger Cloud Run to create a new
instance, it needs to boot and set up your tagging environment. This might take some time and lead to increased latency while your infrastructure adapts. |
Make sure you have enough minimum instances
configured to account for regular fluctuation in your traffic. When you know you're entering a high traffic season, update the Cloud Run deployment settings and configure a higher number of minimum instances. |
| Blue/green deployment | When you need to update the Docker image, you need to re-deploy your Cloud Run server. While Cloud Run configures the new server version (status is blue), traffic still flows to the old version. Once the new version is ready (status is green), traffic will be automatically diverted to it and the old version is deactivated. | During this update, you might see more than one version of your application deployed. This is normal. Setting up the new version and diverting traffic to it will be handled automatically for you. |
| Health checks | You might see periodic requests to /healthz
in your Cloud Run logs. These are health checks generated by the deployment. If these requests ever fail, it means that your deployment is unhealthy and there will be an automatic redeployment of your environment. |
Even though the requests to /healthz are
very small in size and take up very little space in your log storage, you might want to exclude them from your Cloud Logging logs to make it easier to parse only the relevant log entries. |
| Custom domain support | Custom domain support allows you to run your tagging setup in a
first-party context. Google Cloud Run offers an integration to quickly set up a custom domain mapping using a global external Application Load Balancer. |
You can deploy more than one custom domain to your
server-side tagging environment when using the Google Cloud Platform. If you want to deploy in Cloud Run, be aware of the current limitations of domain mappings depending on which region you deploy the service in. In many cases, using a load balancer is the best option, even though it adds cost and complexity to your setup. |
| Cloud region | The automatic provisioning setup of your server container creates a Cloud Run application in region us-central1. In order to change the region, you must create a new service with the new region in the Cloud Run user interface, and delete the existing service. | If you want your server-side tagging environment to service from multiple different regions, you can set up more than one service in Google Cloud Run and place them all behind a load balancer, which distributes the traffic based on the user's geographical location. |
Resources:
Summary
After reading this chapter, you might have a better idea how you want to set up your servers. If you're still not sure, consult with your IT department or ask one of our Tag Manager Partners.
Are you ready to upgrade your servers? Start the next chapter!