Eliminating The Fallacies Of Distributed Computing

In the first of our new technical blogs, Solution Architect Cameron Parry explains how network and cloud architects can effectively use Console Connect within their hybrid and multi-cloud environments.

More than 20 years ago, Peter Deutsch and James Gosling outlined the eight fallacies of distributed computing. They are probably as relevant to businesses today as they were back then:

1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn’t change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous

With the exception of number 6, all these fallacies focus on networking and they are worth bearing in mind when we look at hybrid and multi-cloud environments.

The problem with most hybrid and multi-cloud solutions is that your organisation’s traffic will still be travelling over the public internet – and whether you secure that with VPNs or not, it is still constrained by an internet that many no longer see as fit for purpose.

With platforms like Console Connect, it is now possible to have the best of both worlds by accessing these private and public clouds using a private dedicated network.

Our hybrid cloud architecture 

In this blog, I’m going to explain how we’ve set-up our own hybrid cloud architecture and why. I’ll also show you some of the big advantages of using Console Connect in this architecture.

We use the open-source container-orchestration system Kubernetes. This enables us to have a multi-cloud solution that could be in two or more regions from one cloud provider. Or it could be in two regions from different cloud providers. Or even on-premise with two cloud providers.

Although it does let us break free from the infamous vendor lock-in and at the same time improves geo redundancy, you still have to weigh up the pros and cons of Kubernetes - and whether your applications actually fit into the micro-services architecture or big data architectures.

Or even whether it is a good cultural fit for your organisation. Jumping headfirst into a new technology when your organisation isn’t ready for that change or isn’t mature enough is a whole separate article.

Anyway, back to our setup… we have four Kubernetes clusters. One of those is on-premise in London with 4 BareMetal nodes, running cilium 1.8, with MetalLB for L4 load balancing and HAProxy setup for L4-L7 Load balancing (there are lots of blog posts on BareMetal load balancing and why this has to be done, so I won’t go deeper into this).

The other clusters we have are in Google Cloud Platform (GCP): One for Rancher management on top of GKE; another utilising GKE for any big data, Prometheus monitoring with Thanos, back-up, logging and centralised reporting; and another on-premise cluster in Hong Kong running 6 BareMetal nodes, similar to the one in London.

Here is a screenshot from Rancher and a high-level diagram of what our set-up looks like (Note: there isn't a cluster in LA yet - this is just an alternate back-up route in case some of the other routes go down).

Now, the cynic in me would say that plenty has already been written on multi-cluster Kubernetes federation - so what’s new here?  

This is where I do a shameless plug for our Console Connect product. Except, with the right use cases, I genuinely think this could help a lot of companies.

Making the most of a private MPLS network 

For example, the set-up above has allowed me to connect my on-premise Kubernetes clusters in London and Hong Kong to my GKE clusters in GCP Hong Kong.

This set-up uses the Console Connect network to go from London to Hong Kong, which is a private MPLS network that not only offers the best latency but also ensures I won’t incur egress charges by Google for going between regions.

Using this private MPLS network, I can get from London to Hong Kong with a latency of 175ms. I also have a redundant VLAN interconnect in Hong Kong straight into GCP at a bandwidth of 100Mb.

With this set-up, all my data from both on-premise clusters can go into BigQuery for analytics and querying, while my monitoring and logging gets sent to my Thanos and Elasticsearch clusters.

If I need more bandwidth, I can also easily scale this up and down using the Console Connect platform. It is very simple to sign-up and start connecting your on-premise or clouds together.

Using Console Connect’s Pricing Calculator, I can see that connection between London and Hong Kong is going to cost me roughly $388/month for 100Mbps.

I have also now eliminated most of Peter Deutsch and James Gosling’s fallacies, as:

•       The network is private.
•       Latency is protected by SLA guarantees.
•       Bandwidth is known and can scale.
•       The network is private and secure.
•       Topology of my connection is known to a degree of the endpoints.
•       I have known costs for transport (yes, I still need to pay small egress charges to Google, but we have eliminated most of the risks/caveats associated with operating a global scale operation with multiple Kubernetes clusters, either in multiple clouds or hybrid clouds).

Exploring the power of Console Connect

In the coming weeks, I will look to deploy a cluster in AWS and set-up a direct connect so that I can explore the best of breed toolset from AWS. That’s when we can really start to explore the power of using a private network with hybrid clouds. 

Some possible investigations will look into how the new AWS private link works to access AWS Lambda, which would give the power of running Lambda, without having the infrastructure to run that sort of workload on premise. 

Then we can move back to GCP and look into their specialisation of big data. We can utilise Dataproc, Dataflow and Data Studio to analyse and report on the data to get the information my customers and business users need.

As we have the power of a global network (as do you if you use Console Connect), we can also look to explore utilising tools like GCP Vision, to deploy Vision API to the edge of the network, but these are topics that I will cover further in this blog in the months ahead. 

If you would like to explore any of these concepts further or understand more on how to better utilise Console Connect, I’d love to chat: consoleconnect@pccwglobal.com