Every organization in every part of the world is always looking for ways to amp up productivity, be it of an individual or a team, or a whole department. In this article, I’ll be talking about a particular technology that has been proven to supercharge productivity levels enough times to not be a fluke.
I’m talking about cloud-based desktops or personal cloud PCs. You probably also heard of them by the name “remote workspaces”.
Whatever the moniker, the point is, remote workers report much higher productivity, and cloud PCs/cloud desktops/remote workspaces give employees everything they need to excel while working away from the office.
Plenty has been said about how cloud PCs serve a remote workspace generally, but I’ll be exploring how developers, in particular, can benefit from personal cloud PCs or desktops.
But first, let’s talk about the problems with local development, and why it may be on its way out.
The Problems with Local Development
Inadequate third-party support: I’m sure that, in all your years of development, you’ve come across 3rd-party cloud dependencies that cannot be run locally. You’ve probably had to emulate them by mocking/stubbing 3rd-party APIs, and beat yourself up (metaphorically) over how much work goes into maintaining and updating it.
Even with all that work, you still don’t get to work with the real deal. Let’s say one of your database queries is returned as faulty. How do you even know if you’re not communicating with the real FB instance in the first place?
- Resource usage: You’ll often come across resource-heavy apps that may leave your local device struggling. Examples would be running stress tests to reproduce a memory leak bug. You may have to run 30 replicas of an application to discover a bug, but your laptop conks out and stops responding before you can find what you’re looking for.
Needless to say, this does not bode well for productivity.
Debugging interruptions: Let’s say you have to run a recurring test every few days to identify and resolve a particularly complicated bug. However, you’re local machine suddenly shuts down/sleeps in the middle to preserve its own internal resources, which would require you to start the process from scratch. More road bumps in productivity.
Absence of a single source of truth: With a local machine, you end up using the Docker-compose Method to run a multi-container application. This breaches the “single source of truth” principle as it triggers and maintains multiple representations of your dev environment.
Uncertain integration test results: No matter how sophisticated your script, running integration tests is not the same as integrating code change in a real cloud environment. Integration on your local device may lead to overlooking integration/deployment bugs (network connectivity anomalies, configuration bugs, boot crashes, etc.)
Performance gaps: Building extensive, layered software almost always requires significant computing resources (GPUs, sky-high RAM). To access such resources, devs have to look beyond their laptop to alternatives like desktop towers, spinning up VMs, racked towers, etc. This just piles on extra work when devs are developing locally.
Standardization struggles: Creating and deploying development infra at scale without any dips in speed requires standardization, especially with regard to operational and maintenance protocols. But since dev environments must constantly evolve, standardizations have to keep being updated. In case it isn’t, configuration drifts occur and lead to higher instances of “work on my machine” claims.
You also have to constantly monitor that dev/test/staging environments closely replicate the production environment, including everything from system libraries to deployment models.
Constant optimizations for operational capability: The more complex your environment/infra, the more people you have to hire, onboard, and train. Initial periods of onboarding will be rife with errors, misinterpretations, and configuration fallacies.
Employees in such systems work with different development environments, which include variant code repos running on different requirements. The overhead costs of switching between such wildly varied environment are almost always significant enough to make a dent in your budget.
Source
How cloud PCs accelerate productivity and usability beyond local development environments
Cloud PCs facilitate a cloud-native development experience, which essentially means that every developer is allocated a separate cloud environment. Said environment is a replica (as close as possible) of your desired development and/or production environments.
In this case, the team can use their cloud PCs as they need – testing new features, reproducing and fixing bugs, and experimenting with newer methodologies. And since they get to use an environment similar to prod, they get to work with real-world conditions and develop valid, immediately applicable innovations.
Moreover, these cloud PCs are isolated from each other, so devs can run live, remote debugging exercises without interfering with their teammates’ workspaces. In the event that one of more devs require code review, they can use collaborative coding to achieve the same in real time.
A few standout advantages of using cloud PCs for development:
You can reuse your existing K8s YAML manifests without maintaining duplicate deployment configs.
You can deploy code to the cloud using the same process as deploying to prod, but with the added advantage of isolation.
You no longer have to rely on your local hardware. That means issues stemming from the limited resources of your local device will no longer be a concern.
You can scale cloud resources up and down as required, which is useful if you want to compile large codebases or run resource-intensive tests over the weekend.
Tests launched in a cloud environment won’t be interrupted byyour laptop shutting down or entering sleep mode.
In a cloud environment, you end up using real cloud service APIs instead of mock versions. This lets you monitor for and identify integration bugs as quickly as possible.Cloud PC providers such as Neverinstall provide in-built infrastructure for monitoring, alerting, profiling, tracing, and log aggregation, which go a long way towards simplifying and accelerating development.
No more losing time in running setup scripts since the cloud environment will automatically be primed for development at all times.
Cloud environments can also benefit DevOps personnel or SRE engineers who can run infra configuration changes on their personal environments, without affecting any collective environments used by teammates.
Source
Benefits you can expect from cloud-native environments
Cloud PCs allow devs to access higher CPU and RAM anytime they need it. This speeds up development, build, and testing times across the board.
Cloud desktop providers like Neverinstall allow devs to use internet speeds available in high-speed regions like Europe and the US. This accelerates download times and reduces request latency.
Since cloud PCs can be accessed from any device and any location, it allows your to onboard new users/employees faster. Devs also don’t have to deal with debugging issues on local machines and focus on optimizing their code and/or dev tools.
Again, tools like Neverinstall provide collaborative coding, which lets devs review and contribute to each other’s codebases in real-time. This is also a handy feature when devs have to provide support to customers (for B2B tools).
Since the bulk of development takes place on the cloud, devs’ local devices perform better. These devices no longer have to do the heavy lifting of compiling code, integrating, and testing it. So, you don’t have to deal with common complaints of “Can’t share my screen, server’s running”.
Cloud PCs completely remove the need to supply devs with high-powered laptops with requisite processing power. Don’t forget that such devices have to be upgraded/replaced every couple of years to prevent productivity dips.
With a tool like Neverinstall, you could actually develop end-to-end on a device as basic as a Chromebook. I assume that I don’t have to tell you about the massive cost savings that come with making the transition to the cloud for coding.
- You can automate your cloud environment, and make it reproducible with Infrastructure as Code and GitOps protocols. This will allow you to create/dismantle a cloud environment with a couple of clicks and leaves less room for human error. Source
Summing Up
A quick Google search on the matter will show you the limitations of local development environments. While it does have notable advantages, it comes with barriers to productivity that must be eliminated by teams and companies to stay competitive in an increasingly make-it-or-break-it global marketplace.
Modern applications have only grown in complexity, given the emergence and widespread usage of distributed architectures, more devices to test compatibility with, and event-driven communication (think of app notifications). To develop apps that integrate well with all these architectures, ecosystems, and end-user environments, devs need environments that mirror production environments as closely as possible. Achieving this in a local device is difficult, expensive and has an upper ceiling for scalability.
Cloud PCs automatically eliminate these aforementioned limitations. When an engineer has a cloud PC to work with, they can just log in, initialize the editor they want and start developing. No installations, no configuration, no setup required. Higher productivity, lower performance issues (especially for the local device), and faster delivery of software to customers.
In other words, a win-win-win.
Top comments (0)