Business applications need computational resources such as servers, networks, and storage. Traditionally, businesses owned private data centers which meant that companies had capital expenditures (CapEx) for physical assets. In addition, they also had recurrent operating expenditures (OpEx) to maintain the data center and to pay the operations staff.
Public clouds eliminate the need for a data center and operations staff and let companies focus on their business.
There are cloud providers such as Google, Amazon Web Services and Microsoft, that work continuously on improving their services.
Regions and zones
Cloud services are commonly available in locations across North America, South America, Europe, Asia, and Australia. These locations are divided into regions and zones (the exact terms can vary between cloud providers). Cloud users choose where to locate their applications to meet their performance and availability requirements.
Regions are independent geographic areas that consist of zones, and a zone is a deployment area for cloud resources within a region.
When it comes to business requirements, it is common to find terms like high availability, global accessibility and max performance within them.
In order to deploy applications with high availability, cloud users should deploy their applications across multiple zones in a region to help protect against unexpected failures. In addition, multi-region deployments are essential if these applications need to handle global accessibility or availability requirements.
Designing and deploying multi-region architectures can be tricky to cloud engineers even if they based the whole system on public cloud services. Replication, resilience or disaster recovery are conditions hard to meet so companies end up needing dedicated engineering teams.
Why we should go serverless
Serverless is one step further in this direction towards “no-ops” (or no operations). It does not mean that the software that you run does not run on a virtual machine with computational resources. It means that cloud providers manage it for you.
Almost any big area of the cloud providers portfolio includes serverless options (managed databases, networking services, platform-as-a-service tools, continuous integration services and more).
Google Cloud offers state-of-the-art serverless services that allow us to build and run applications globally with confidence.
Solution Design
Let’s design a solution for applications whose users are located in three regions: California (US), Germany (Europe), and India (Asia). Minimum latency is required and apps should keep running even if a whole region goes down.
A VPC (Virtual Private Cloud) will be the foundations of the system. VPCs are global resources on Google Cloud. This means that physically separated compute resources are reachable as long as they are in the same VPC. This is a big advantage compared to other big cloud providers where VPCs are usually attached to regions.
A single Google Cloud VPC can span multiple regions without communicating across the public Internet. For on-premises scenarios, you can share a connection between VPC and on-premises resources with all regions in a single VPC. We don’t need a connection in every region.
To run our applications we will choose GKE (Google Kubernetes Engine) as a compute technology service. Thanks to GKE, our solution can meet replication and high availability requirements.
Finally, we will also make use of the HTTP(S) Global Load Balancer that allows us to route user traffic to the closest server thanks to the Premium Network Tier.
Setting up a GCP Global VPC
Let’s start creating a brand new VPC in Custom Mode with subnets in each region (us-west2, eu-west3 y asia-south1).
It is important to check how firewalls work in this scenario. By default, custom mode VPCs do not create firewall rules more than a couple of implied rules.
Creating GKE Regional Clusters
GKE Clusters can be deployed using a zonal or regional configuration. In this case, it’s required to have duplicated resources across zones so we have to create them as regional clusters. This setup of 5-node-pool regional cluster actually results in 15 nodes in total, 5 per zone.
The Load Balancing check should be enabled so GKE preinstalls the required ingress controllers that allow us to use ingress resources for routing and load balancing.
Setting up an HTTP(S) Global Load Balancer with GKE Ingress
HTTP(S) Load Balancing provides global load balancing for HTTP(S) requests destined for our instances.
Global load balancing requires that we use the Premium Tier of Network Service Tiers.
Premium Tier delivers GCP traffic over Google’s well-provisioned, low latency, highly reliable global network. This network consists of an extensive global private fiber network with over 100 points of presence (POPs) across the globe. By this measure, Google’s network is the largest of any public cloud provider.
Network Premium Tier
With the Network Premium Tier, requests destined for our instances will enter the Google Network at the closest PoP.
HTTP(S) L7 Global Load Balancer
Using the Global Load Balancer, we can configure URL rules that route some URLs to one set of instances and route other URLs to other instances. Requests are always routed to the instance group that is closest to the user always ensuring that this group has enough capacity to handle the request. If the closest group does not have enough capacity, the request is sent to the closest group that does have capacity.
At this point, we have the VPC, subnets and clusters up and running. In addition, we have also seen why the Network Premium Tier is required so we can make use of the Global Load Balancer.
In this context, the backends required for a Load Balancers are actually Kubernetes services. These services are abstract entities that point to Kubernetes Pods running on the existing clusters. We could have multiple instances of our apps running as Pods on Nodes (zones) and replicated across clusters (regions).
According to the official docs, these services have to be created following a NodePort Service setup and they have to expose on the same NodePort.
With that done, the Global Load Balancer will expose a globally accessible single IP that will route traffic to the closest and healthiest instance group.
Extra Step One – Using Cloud CDN with the same HTTP(S) Global Load Balancer
The HTTP(S) GLB also accepts backend buckets as endpoints for its routing configuration.
We can have the same anycast IP pointed from our DNS provider and routes traffic to instances or bucket binaries just changing the URI in our requests.
Extra Step Two – Protecting your infrastructure from malicious attacks using Cloud Armor
Cloud Armor delivers defense at scale against infrastructure and application Distributed Denial of Service (DDoS) attacks using Google’s global infrastructure and security systems.
With Cloud Armor, we can define an IP blacklist and it prevents malicious attacks at the network level. Thanks to Cloud armor our infrastructure will never be reached from external attacks from these sources.
—–
In this article, we’ve seen how easily we can create global VPCs to deploys multi-zone and multi-region infrastructures in the cloud. Furthermore, thanks to the Network Premium Tier and the HTTP(S) Load Balancer we can build global, replicated and high-available applications making use of serverless services.
Interested in Google Cloud? Stay tuned to upcoming posts in the Keepler’s blog because we will continue posting interesting articles about GCP.
References:
Imagen: unsplash | @topfivebuzztravelmagazine
Leave A Comment