Why Your Local Workstation Can’t Mimic the Cloud

If there is one thing developers love, it’s the control. This makes sense if you build something as complex as a software system, you need to understand what’s happening at every level. But absolute control can be a liability when it becomes the main goal of the development process.

Many developers go to great lengths to get the same system replicated locally that they run on a remote server with the hope of catching every error before it’s deployed. This is a pipedream. Getting your local machine to resemble the remote system is nearly impossible and the goal when creating software should be to get fast iteration times between releases. If you lose sight of that goal, it’s easy to get caught up in micromanagement.

In this article, we’ll discuss why development so often fails in staging environments and the benefits of developing and testing directly on the cloud services you’re running your production on.

How the Cloud Differs from Local Environments

Cloud providers offer different services. Some services, like virtual machines or containers, might resemble your own machine, while others might be entirely different systems. Understanding how cloud services differ from your local environment can help you improve your development and debugging processes.

Multiple Servers

First, a local machine is often just that: one machine. And there are cloud services that are also just a single computer. Every cloud provider will offer to rent you a virtual machine (VM), and often you can run the same software on it as you do on your local computer.

Even if you only build your app on VMs, you can quickly end up with multiple of them-one for your application servers, one for your database, and so on. Working on multiple VMs means you’ll run into distributed system problems you can’t accurately model on your one, local machine, because the latency between machines is now considerably greater.

Geographically Distributed Deployments

You may also find that all of your VMs are running in different geographical locations. It’s easier to manage three VMs close to each other in one network than if they are spread across an entire continent. Network problems are more common when deployments are far apart, and you can quickly find yourself running in timeouts.

To keep latency in your application to a minimum, you’ll want your servers to be close to your clients. But if you have users in the U.S. and Australia, you have no choice but to deploy servers for each continent, making internal communication between these servers harder.

You can try to run multiple VMs on your own machine, and even simulate potential problems by injecting network issues and latency. But models can only go so far. A real deployment in the cloud will yield more accurate results. If this process is well planned, and you start your application with a cloud-based development process, such a test deployment could be quick and easy.

Managed Services

The cloud also offers managed services, which are usually built on top of VMs but don’t give you access to them.

Managed services are higher-level services like authentication or artificial intelligence. They give you an API and keep their inner workings to themselves. This lets you build systems faster than if you had to install everything you need to work on a blank VM.

If you try to mock managed services on your local machine you will likely end up with an incomplete clone, leaving room for errors from behavior that you forgot to replicate.

Shared Services

Many cloud services are virtual, meaning you don’t rent physical hardware. Instead you pay for an instance of a system that shares physical hardware with other instances, either of your own or that of other customers of that service.

This can lead to unexpected behavior if your application expects to have the whole system to itself. The other applications running on the same hardware could be badly optimized and can inadvertently leach resources from your application.

Implicit Assumptions

Software development is full of implicit assumptions that are rarely consciously considered. These can be related to distributed systems theory or implementation details. For example, if you send a request that is too big the API might time out. If you have too much delay between two requests that belong together, the API may not be able to consolidate them.

Even if you’ve done everything according to the documentation, and it worked when you tried it locally, it can still fail in the cloud. If you’d tested your assumptions with the real cloud service, however, you would have been able to catch these problems from the start.

Debugging Locally Is Only Faster If It Works

If you don’t have a cloud development environment at hand, you can lose a lot of time setting up an ad-hoc remote environment. Debugging locally is only faster than reproducing an error in a cloud environment if you can reproduce the error in your local environment.

If you get to the point where most errors are best reproduced remotely, there won’t be a benefit in continuing to use a local environment. That nice, low latency debugging won’t feel so good once you realize it doesn’t provide great results.

Deployment Code Is Part of Your System

The deployment process is a part of your software; infrastructure as code and deployment scripts are code after all. Though they’re often executed just once per release, that doesn’t mean they can’t be buggy or lead to bugs inside the deployed code of your software through faulty configured linters, code generators, or other deployment related tools.

Setting up a remote debugging environment will allow you to debug the deployment part of your software and keep things in line, even for code that doesn’t belong directly to your application.

Summary

Debugging isn’t easy and working from a local environment can provide a sense of security. But that doesn’t make it the best approach. Sure, running a script locally is quicker than deploying it in the cloud, and setting up ad-hoc environments in the cloud to test and debug your system costs time. But identifying bugs related to cloud-specific behavior may take a much longer time if you can’t catch them before deployment.

Managed cloud services aren’t cheap because they cost fewer dollars per hour to rent than hardware. They save you time and money in maintenance and setup costs. Debugging in the cloud can be slower in terms of latency and runtime while still giving you faster iterations for new releases.

Control is good, but controlling irrelevant things won’t help you achieve quick iteration cycles. Instead, these goals can be met with tools like Thundra Sidekick, which integrates with your local IDE to make online debugging second nature. Get started today.

Originally published at https://blog.thundra.io.