Developing in the Cloud vs. Developing in Local
The tech industry has been rapidly embracing trends such as cloud computing, containerization, microservices, and managed services in recent years, and as a result, these technologies have become a part of the everyday responsibilities of software engineers and IT professionals. In today's new era, most modern applications are built with complex and distributed architectures using these technologies and are served in the cloud.
Many applications are made in or modernized to microservices from monolith structures and designed as distributed systems. Development environments, therefore, had to change as cloud technologies became the new standard.
Will the Future of Development Be Remote?
In the past, it was simple to run the same virtual machine on your local machine and interact with it as if it were running in the cloud. Today, however, this is almost impossible if you want a realistic environment.
With the wide adoption of these new technologies, development environments for modern applications can no longer be the same. Because applications are not stand-alone, they rely on infrastructure services such as data stores and queues provided by cloud vendors or external services managed and maintained by other teams or third parties.
Although there are Kubernetes distributions that can run a cluster in your local computer, it gets harder to make tests realistic if you are using managed services in your distributed applications.
When you add managed services and start integrating them into your microservices, it might be problematic to test the resulting behavior before going to production. Doing that locally just isn’t possible anymore because there are too many services, and several of them—as well as the networks between them—are managed by their providers.
What Is the Impact of the Shift?
Developers need to control what they are building; this is a must. For decades, there has been a belief that says the more you develop locally, the more control you will have. This is actually true, but the change in our industry is inevitable.
It’s hard to create development environments that closely mimic production environments while developing distributed microservices in the cloud. Developers are accustomed to working on projects on their personal computers/local environments, even when working on large enterprise projects. This process had almost transformed into a tradition until the rise of distributed applications.
In today’s development environment, however, geography doesn’t equate to control. Control can only be achieved when you understand the systems you’re using, independent of their location.
Mocking or replicating cloud services or managed services in your local environment simply no longer translates to the real environment upon which your application will run during production. This means you are missing the chance to find potential sources of failures and not testing your applications in a realistic manner.
Pros of Developing Locally
Local development is extremely fast, easy, and free. If everything is on your own computer, then you will easily know where to find what you are looking for. Developers don’t have to pay for any resources; even an Internet connection is not required.
You can use logs, and it’s easy to debug code. But it is becoming an increasingly poor option for developers building distributed applications.
Cons of Developing Locally
Although local development is generally a common habit, the downsides might outweigh the benefits in most cases when developing distributed applications.
The development environment is not realistic locally because dependencies cannot be emulated like they can in the real world. There can be small or large differences from production environments.
Additionally, all services have to be set up locally and kept in sync during production. This can potentially be a big burden for developers to handle as applications scale.
Why Not Develop in Remote Environments?
Remote development may be a better choice for developing distributed systems based on managed services. There are tradeoffs between local and remote development, but remote development can be the optimal choice in most cases when developing distributed applications.
A staging environment can be set in the cloud and all dependencies of the service can work there. That being said, remote development still has some downsides.
Pros of Developing Remotely
Remote development is more realistic depending on how much you use it. It becomes more real as the development environment begins to get closer and more similar to the production environment.
It might seem like a drain on your wallet to recreate your local production environment remotely, but it doesn’t have to be. There are several solutions out there that have on-demand pricing, so simply deploying them won’t cost you anything. Furthermore, the load a developer creates when debugging is often negligible.
There is less of a need for mocking external resources and services and a lower risk of differences between development and production environments. Additionally, some of the security, reliability, and scalability responsibilities can be partially outsourced to a cloud vendor in remote development.
Another advantage of remote development is that it’s crash-proof: It does not rely on developers’ hardware, and it’s not limited by the speed of developers’ hardware. It can be even faster and not expensive at all, provided it doesn’t run 24/7 in pre-production.
Lastly, developers can collaborate with each other from the ground up without thinking about security issues. Using a remote development environment can aid your ability to collaborate with your team members in a company, regardless of the company’s size.
Cons of Developing Remotely
It’s not pleasant when the developer’s speed is limited; this is the explicit drawback of remote development. Since code has to be pushed to the cloud every time a change is made, development speed, therefore, decelerates, making it almost impossible to debug distributed complex microservices and cloud applications. These applications are built using cloud services, services provided by other vendors, and even services provided by other teams in the same organization.
It’s difficult for developers to ensure they use these services in a resilient way so that if the application crashes, they can pinpoint the root cause of the problem. Another downside they might encounter is the cost of cloud resources compared to free local development environments.
Luckily, there are third-party services, like Sidekick, that can help you address these obstacles.
Sidekick Open-Source makes debugging possible in the Cloud
Sidekick is created to solve the live debugging issues developers encounter in their remote development environments, especially in production, staging, and testing environments. It combines seamless debugging and tracing capabilities, allowing developers quickly and easily debug remote systems.
Sidekick Open Source is here to allow self-hosting and make live debugging more accessible. Built for everyone who needs extra information from their running applications.
The typical cycle to fix an issue in cloud applications consists of several steps: Create a new build, deploy it to the cloud, and verify the accuracy of the fix. This is a time-consuming and daunting process. Sidekick lets developers get the desired data from running applications without stopping the execution or redeploying code. In this way, developers improve the development cycle, gaining time and productivity.
You can use Sidekick in any stage of your development for your live debugging & logging needs. With Sidekick you can:
- Debug your remote application (monoliths or microservices on Kubernetes, Docker, VMs, or Local) and collect actionable data from your remote application.
- Add logs to your production apps without redeploying or restarting.
- Cut your monitoring costs with on-demand & conditional data collection.
- On-board new developers by showing how your apps work using real-time data.
- Evaluate the impact of an error on applications with integrated distributed tracing.
Sidekick brings almost no overhead (please check out our benchmark blogs). It allows you to troubleshoot issues before they impact your customers. Get started with Sidekick and start debugging at lightning speed!