Why Remote Development Might Be a Better Option Than Local Development – InApps 2022

Cloud computing has been on the rise for over a decade and much of the software industry has shifted to renting their IT resources instead of buying them. It has been a long journey from on-premise to the cloud, but today, VMs, containerization, microservices, managed services, and serverless technology are common parts of software services.

The switch from monolithic applications to microservices also converted many apps to distributed systems. With this wide adoption of cloud technologies, development environments have had to change.

Why the Shift to Remote Development?

Historically, you could simply run a virtual machine on your local computer and interact with it as if it were running in the cloud. But this approach has become harder to maintain. Today many cloud services are more than just VMs where you install whatever software you want. These services are specialized and provide higher-level features. While there are Kubernetes distributions that run a cluster locally, the more managed services you include in your system — and you will include them because they save time and money — the fewer options you have to test them locally.

Cloud providers have dedicated teams that maintain their services, so the services themselves are rarely a source of bugs. With microservices, problems arise when you start integrating services. Doing that locally just isn’t possible anymore, because there are too many services and many of them — as well as the networks between them — are managed by the providers.

How Does the Shift to the Cloud Affect Developers?

When building a system, developers want as much control as they can get. This leads many to believe that the more local their development, the more control they’ll have. After all, this is how it’s been for decades.

In today’s development environment, though, geography doesn’t equal control. Control is achieved when you understand the systems you’re using, independent of their location.

If you replicate a cloud service partially on your local machine, you might get better performance for debugging and testing. But you aren’t really testing the system; everything missing from the original service that runs in the cloud is a potential source of errors that you’re neglecting.

The Advantages of Local Development

Local development is high speed, and not just in terms of latency. If everything is stored on your own hard drives, you know where to search for logs and source code files. You feel at home, and that familiarity can be a huge advantage. Developing on the machine you set up yourself, with all the software you prefer, can contribute to developer motivation.

Additionally, a local machine is usually already paid for; this means developing locally avoids the fees associated with managed services.

The Downside of Local Development

While there are upsides to local development, they may be short-sighted — especially if you’re building distributed systems based on managed services. Faster iteration speed of developing locally doesn’t help if it’s invested in the wrong work, such as mocking managed services incompletely for local testing.

Being tied to familiar methods can also stymie innovation. By focusing on optimizing your local development, you might miss out on services that are better suited to your needs. At a certain point, you run the risk of perfecting your system for yourself rather than your users.

Remote Development Provides an Opportunity

Local development has its place, but remote development might be a better choice for developing distributed systems based on managed services.

With the help of infrastructure as code (IaC) tools, it’s easier than ever to replicate production deployments for development purposes. Even parts of the production data can often be copied to such a development environment.

That said, as with any tool, remote development has both benefits and drawbacks.

The Advantages of Remote Development

Remote development is a more realistic option than you may think. Recreating your local production environment remotely might seem too expensive, but it doesn’t have to be. Serverless solutions have on-demand pricing, so just deploying them doesn’t cost you anything. Furthermore, the load a developer creates when debugging is often negligible.

Working in a remote environment ameliorates the need for mocking external resources and services, and it reduces the risk of differences between development and production environments. Additionally, some security, reliability and scalability responsibilities can be partially outsourced to the remote development cloud vendor.

Another advantage of remote development is that it’s crashproof. It doesn’t rely on a developer’s hardware; and service reliability is the cloud provider’s responsibility. You also aren’t limited by hardware when you deploy in the cloud — your deployment can be as fast as you like. If you don’t own it and it doesn’t run 24/7, this may be even less expensive than buying a developer a high-end machine.

Lastly, developers can collaborate from the ground up without thinking about security issues. No one can complain: “But it runs on my machine.” Everyone can share their development environments in the cloud.

The Downside of Remote Development

Limited development speed is an undeniable drawback of remote development. Because the code has to be pushed to the cloud every time a change is made, development speed decelerates. This is both because of the actual time it takes — some cloud services take half an hour to deploy — and because if there’s an error, you may have to tear down the whole system and deploy from scratch.

Additionally, it’s hard to debug complex, distributed microservices and cloud applications. These applications are managed by other vendors or by other teams in your organization. Often, a developer can’t be sure they’ll be able to pinpoint the root cause of the problem when their application crashes.

Luckily, there are third-party services — such as our Thundra Sidekick — that can help you address these obstacles. Thundra Sidekick has an IntelliJ IDEA Plugin, which aims to ease the debugging of remote applications with non-breaking tracepoints and distributed tracing integrated. Non-breaking tracepoints take a snapshot of the code execution while code is being executed. Integrated with Thundra’s distributed tracing engine, Sidekick connects the tracepoints in several services in the same distributed transaction.

In Summary

Modern applications have gotten more and more complex with the advent of distributed architectures and event-driven communications. Although there are numerous advantages of running such architectures, the biggest downside is not being able to replicate the production environment to the local during development. For this reason, application teams are adapting remote development practices more and more. However, debugging remote applications is not as straightforward as debugging local applications. Our product, Thundra Sidekick, introduces a new way of debugging remote applications with tracepoints integrating non-breaking breakpoints and distributed tracing. It’s provided under our private beta program for now. You can start your journey here.

Feature image via Pixabay.