Transit Gateways are one of the latest features to be released in IBM Cloud and they fulfil an important role in providing simple click-based connectivity between different infrastrucure environments.
As a user of Virtual Private Cloud (VPC), you'll notice that each individual VPC is isolated from one another. It's also isolated from Classic infrastructure environments within your account too. This is great from a security point of view - a VPC is a
private cloud after all - but there are occasions when you might want to join them up. I suppose you could do that by going out over the internet but that's inefficient and if you want to keep your traffic flows on a private network, unworkable too.
Consider this example. You have an application which has been deployed in VPC and stores data within a database that you have created and manage. It's simple to create a highly available application with VPC by load balancing applications across the zones and you can create a replica database in another zone too. But what if you needed to replicate the data to a standby in another region or even, what if another application deployed using Classic Infrastructure could use some of the data?
VPCs sit in regions, so to replicate to another region would mean having another VPC and VPCs are not natively connected on the private network. The application on Classic Infrastructure is in another environment entirely, which again, is not natively connected to VPC. So how do you easily allow them to communicate without going out and back in via the Internet? We use Transit Gateways.
What's a Transit Gateway?
A Transit Gateway is a simple service that provides connectivity across IBM to different environments, running across the private network. They can be used to provide connectivity between different Virtual Private Clouds, as well as connectivity between VPC and Classic Infrastructure. Since the connectivity is across the private network, there is no need to go 'out and in' across the internet from one environment to another.
There are two types of Transit Gateway - Local Routing and Global Routing and they are aptly named. In all cases, Transit Gateways are provisioned in a particular region of your choice.
A Local Routing Transit Gateway can provide access to all VPC and Classic resources within the Transit Gateway's provisioned region. For Local Routing Transit Gateways, all data transfer is free.
A Global Routing Transit Gateway on the other hand, can provide access to all VPC resources in all IBM Cloud Multi-Zone Regions as well as Classic resources. There is a free monthly data transfer allotment of 1TB and after that is used, there's then a small per GB fee for further transfers.
When you create a Transit Gateway of any type, you still have control over what's connected to what. So, creating the gateway doesn't mean that everything is suddenly connected, you still have control and need to specify the VPCs that are connected to the Transit Gateway, as well as if Classic Infrastructure should be connected. Don't worry though, the GUI is really simple to use.
Sounds interesting, what do I need to know?
A couple of things that I've noted when using Transit Gateways for the first time.
To start with, if you are looking to connect in your Classic Infrastructure, you must have virtual routing and forwarding (VRF) enabled on your account. If you don't have this enabled, it's a very simple process that is carried out by IBM Cloud Support, though it does involve a few minutes of downtime across your account, which can be scheduled. If you want to know more about this process, click here.
Secondly, you need to plan your subnets so that they do not have overlapping addresses. For example, if you are connecting two VPCs that both feature subnets in the address range 10.10.0.0/24, they won't route because of the overlap. My suggestion here is that you plan your VPCs out so that they each have unique address ranges, so there is no overlapping.
Thirdly, carefully consider where you place your Transit Gateway, if you are using Global Routing. Because the Transit Gateway resides in a region, resources placed outside that region will need to communicate across regions with the Gateway, which adds latency. So a good tip is to place the Transit Gateway in the region from where most of the traffic will originate.
Conclusion and More Information
So Transit Gateways are a great way to connect environments. As an experiment, I created a very simple Wordpress web application, that featured a couple of web servers and a separate MySQL database, on VSIs in a VPC in London. I decided that I wanted to reuse that same database instance for other Wordpress applications that I created in VPCs in Frankfurt and in Washington and I achieved that easily using a Global Routing Transit Gateway - I just pointed each Wordpress instance to the MySQL host in London. I then created another VPC in Tokyo and used that to create a standby instance of my MySQL database, which is automatically kept in step with the version in London.
In terms of access speed, well, there's a slight one second lag when the Washington instances are hitting the London-based MySQL instance but baring in mind the database hasn't been tuned and isn't sitting on a particularly powerful VSI - the site is still more that usable and that's not bad, and to be honest, you wouldn't normally host an application that uses a database several thousand miles away!
So that's Transient Gateways at a really high level. A really fast and efficient way to connect up your VPCs and Classic Infrastructure, using the IBM Cloud Private network! Find out more by provisioning your first Transit Gateway in IBM Cloud or of course you can check out the documentation too.