A to Z of Google Cloud Platform a personal selection — x -’xternal factors
Okay I admit I’m stretching the rules slightly but it is pronounced like this See “xternal” Okay with that excuse out of the way.
Using GCP allows you to scale and be accessible to millions of users from around the world but GCP isn’t responsible for factors outside of it’s infrastructure.
Simply put to communicate via the internet you need a source and destination address and a way to get from the source to destination.
The communication involves end user devices, the applications you build , TCP/IP (I have posted about that too here I admit I like networking 😃 ) , DNS servers, routers, firewalls, cables of various types , ethernet, wifi , 3G/4G and more it’s just fascinating ( well it is to me!).
I know I’m going on about networks again but to understand the external factors that a cloud provider isn’t responsible for a little bit about how the internet works is important to understand . I’ll keep it brief and not dense I promise.
This journey from your end user to your application is complicated. DNS is important and acts as a giant address book. So when you type into chrome for example bbc.com a DNS lookup occurs which provides the IP address of bbc.com ( think of it as a combination of house number and a postcode/ zipcode) ) . From the IP address a path from source to destination can be navigated
Users can be located anywhere in the world that has access to the internet and now it has the address of your target your requesting packet goes off on its journey to ask for a page. This means you’ve got data packets finding its way to bbc.com.
Users can literally be anywhere so that means your packets could literally be moving under water through submarine cables and when the packet hits land changing physical transport until they finally get to their target and then the return trip happens reversing the journey and so on.
Just look at this screenshot I took from the Submarine cable map
To get packets moving across these cables and indeed then moving across land there are routers think of them as signposts which have route tables. These routers use BGP to dynamically advertise routes. In very very simplistic terms the routers because they know what the next hops on the way to the destination is can tell the packet where to go next for further directions . ( I know I haven’t talked about switches but hey this is high level to get a point across!)
[an aside ]I couldn’t resist looking at RIPE’s bgplay widget. This visualises the routes that are advertised . Enter the IP address of your favourite site . Below are the routes advertised for bbc.com. Nuts right!
The internet is pretty amazing and we use it to fill the web with cute dog & cat pictures! Just saying! I don’t mind either but the fact we can send data packets in milliseconds back and forth across the world and we just take it for granted!
Anyway that diversion into a high level look at how a packet physically moves is important as once outside of GCP’s network there are a multitude of things that can affect the transport of packets I’ve barely touched the surface and don’t tempt me to lift the lid else this post will really derail :-)
The main point of my diversion about cables and bgp was to show that data is moving from a to b , it’s physically doing that and where your end user starts their journey from will have an effect on the length of time data travels around the internet. If there’s a problem with one route the packet may get routed via a less direct route . The packet will in many cases still get there just take a little longer . This time lag between the request and response is latency.
GCP has a fast high performance global network and has numerous features to help address the latency issue with more than 70 global network points of presence close to your users.
I’m just going to touch upon some of these features that you can take advantage of to help address latency and some of the things you can do to keep an eye on those external factors.
Use edge caching services to keep static data close to your users so they’re not all pulling data back from the origin You can use GCP’s Cloud CDN .
Take advantage of GCS as that is integrated into the Google front end, a powerful distributed edge routing and caching system that provides incredible performance for serving static content .
Use in memory caching systems like redis or memcached to cache things like lookup tables etc.
Think carefully about your architecture keeping services close together in the same zone and in the same region i.e keep as much traffic within GCP’s network ( It’s pretty awesome after all!)
What about patchy connectivity from your users devices ? Persist data to your end users device and then synch when connectivity is restored. Firebase Google’s mobile platform which is integrated with GCP has a realtime database that syncs data across all clients in realtime, and remains available when your app goes offline.
Make sure you’re monitoring from outside as well as inside. Inside monitoring may be giving the thumbs up that your application is working fine but if none of your users can get to it because of say a dodgy DNS entry or somewhere along the route to you something is timing out then your users are not seeing your application as working as expected even if you are!
You should also undertake due diligence anyway and use an independent third party such as cloudharmony ( Not an endorsement just the first one that popped into my head when writing this)
