

Distributed systems are hard. Developing in and with distributed systems is even harder.
What’s so hard? Well, first off we’re dealing with two aspects here:
The second distinction we have to make is that of local vs. remote, from the point of view of the developer. Local means: runs on my machine. Remote means: runs somewhere in The Cloud© (or yeah, in your datacenter, welcome to 2017 ;)
Let’s walk through the four fundamental options now:
Both CL and DE are local. Examples are K8S minikube, DC/OS Vagrant and Docker Compose.
From the developer’s POV the pros of this approach are:
And the cons:
CL and DE are located where one would expect it. The CL is made available to the DE via proxy or VPN. One example is DC/OS Tunnel.
From the developer’s POV the pros of this approach are:
And the cons:
Same as CLASS II in terms of separation but in order to test a service one needs to actually deploy it in the CL. This is the usual setup found in many environments, with or without a CI/CD pipeline in place.
From the developer’s POV the pros of this approach are:
And the cons:
Both CL and DE are remote. Call it Chromebook-based development or whatever, but essentially nothing runs your machine, really, in this setup. And while I’ve written about this topic many years ago I think by and large we’re still not there yet. Examples of this category are Google Cloud Shell and Cloud9.
From the developer’s POV the pros of this approach are:
And the cons:
What to choose? I don’t know your preferences, your use case, your team size, your industry, your regulatory requirements, your budget, … you get it. Personally, I believe we’ll be transitioning to CLASS IV within the next 5 to 10 years. Currently, I mostly use a CLASS II setup: it combines the authenticity of the distributed system with the (necessary) iteration speed, and if you like you can have a look at a concrete example here.
Create your free account to unlock your custom reading experience.