Adopting remote development is a significant decision for any company. At JetBrains, we talk to many customers about this shift. While we see growing demand, we also encounter many misconceptions about what remote development with cloud development environments (CDEs) can and cannot do.
1. What problems can you solve with remote development
Before diving into whether CDEs make sense for your business, let’s identify the core problems that remote development helps to solve:
Non-productive time Much development time is wasted on setting up development environments (e.g. when onboarding new staff or dealing with “works on my machine” issues), switching branches for small tasks (IDEs need to reindex the codebase, rebuild the project, etc.), and waiting for builds to complete. This time could be better spent on actual development work. CDEs can help minimize these delays by providing standardized, ready-to-use environments for each task.
Security risks For industries like finance, healthcare, or companies that use contractors, local development poses numerous security risks: Company code is more vulnerable when stored on local machines, and the possibility of policy violations or data breaches is greater. With CDEs, code and sensitive data are stored in the cloud, with strict access control and monitoring.
Local machine limitations Developers often face hardware constraints, such as insufficient RAM, CPU, or GPUs for heavy machine learning tasks. CDEs scale with your needs, providing the necessary resources on demand to eliminate these limitations.
However, the simple fact that you’re facing these challenges doesn’t automatically mean that remote development is the right solution for your team. Whether it’s worth adopting remote development depends on various factors, such as the scale of your team, your development workflows and infrastructure, and many others. This post will guide you through these considerations in the form of a questionnaire. We’ll explore key areas like:
Organization scale: How the size and distribution of your team affect the need for remote development.
Development process: The type of projects you work on and your development workflows can heavily influence how beneficial CDEs will be for your team.
Security and compliance: How remote development environments can help you meet security and compliance requirements.
Infrastructure and resources: How your current infrastructure and internet connection may impact the usage of CDEs.
Additional considerations: Other factors like software licensing and disaster recovery that might affect your decision.
JetBrains CodeCanvas
In September 2024, we announced the release of CodeCanvas, our solution for remote development. CodeCanvas is a CDE orchestration tool that can help you centralize the configuration of dev environments for specific projects, manage the CDE lifecycle (from creation to deletion), and benefit from the support of the majority of JetBrains IDEs and VS Code. For more details, check out our announcement blog post and watch the overview video.
2. Organization scale
a. Number of developers in your company
0–30 developers For smaller teams, traditional local development may still be a cost-effective solution. The overhead of managing cloud infrastructure, setting up CDEs, and maintaining cloud resources might not justify the benefits of CDEs.
Recommendation: Stick to local development unless you need CDEs for other reasons, such as enhanced security, standardized environments, etc.
30+ developers At this scale, managing multiple development environments can become a challenge, especially when different projects require different configurations. Here, remote environments can simplify onboarding and make transitions between projects easier. With tools like CodeCanvas, setting up and managing these environments at scale becomes more efficient.
Recommendation: Consider hybrid solutions, where some environments are remote and others are local.
100+ developers Managing local development at scale can be highly inefficient. As your team grows, CDEs simplify scaling by enabling centralized management, enforcing security, and minimizing local machine setup.
Recommendation: CDEs are highly recommended at this scale.
b. Number of projects and project complexity
It’s challenging to provide a definitive answer based solely on the number of projects your company is developing. The impact of multiple projects on your development process depends on several key factors.
Key considerations:
Project complexity: Even a single project in development may require complex configuration: multiple modules, numerous dependencies, specialized hardware requirements (like GPUs for AI/ML tasks), and so on. These complexities are also constantly evolving, with updates to dependencies, frameworks, or hardware demands that each developer must keep up with. CDEs overcome these challenges by providing standardized and ready-to-use environments for all developers.
Developer workload and context switching: Consider how many projects a single developer works on and how frequently they switch between them. Frequent switching can lead to significant downtime due to a need to configure different local setups in the same local environment. CDEs eliminate the need to switch contexts in the same environment by providing pre-configured environments for each project.
Environment consistency: The more projects your team handles, the harder it is to ensure that all developers are working with the same environment configuration. Variations in local setups can result in the “works on my machine” problem. CDEs centralize environment configuration, ensuring every developer works with consistent setups across all projects.
Recommendation:
Few projects, low complexity: If your company develops a small number of simple projects, CDEs might not offer significant benefits, as the overhead of local environment management remains manageable.
Multiple projects, high complexity: CDEs are highly beneficial for companies managing multiple and/or complex projects – especially those involving AI/ML workflows. They reduce setup time, improve consistency, and help scale GPU resources efficiently.
c. Geographical distribution of your team
When considering CDEs, latency is the critical factor that can make or break the experience. Latency is recommended to stay under 100 ms for a smooth and responsive development workflow.
All your developers are in one location If your entire team is located in one place with fast and stable access to nearby cloud services, maintaining low network latency is simpler.
You have distributed teams across the globe Network latency can have a more noticeable impact on globally distributed teams. Latency greater than 100 ms can disrupt the responsiveness of CDEs, causing developers to experience delays while coding. To mitigate this, you must deploy dev environment clusters as close to your developers as possible, often in different regions. This reduces latency but introduces additional operational costs for setup and maintenance.
Recommendations:
Assess network conditions: Evaluate the latency between your developers’ locations and the cloud regions where CDEs can be hosted. Keep latency below 100 ms to ensure a smooth development experience.
Regional deployments: If feasible, deploy dev environment clusters in each region where your developers are located. This setup reduces latency but requires more operational overhead.
Hybrid approach: Consider a hybrid model where developers in regions with low latency to cloud data centers use CDEs while others continue with local dev environments.
d. Growth rate of your team
You have a stable team size If your development team is stable or only slowly growing, local environments or a traditional development setup might still be manageable. However, adopting CDEs can still provide significant benefits, like standardized environments, improved developer productivity, and better security. Other sections of this blog post address all these benefits.
You have a rapidly growing team For rapidly growing development teams, adopting CDEs is not just a benefit – it’s almost essential for managing scale, streamlining onboarding, and controlling infrastructure costs:
Resource scaling: As your team grows, managing individual machines and scaling hardware can quickly become overwhelming. CDEs can dynamically allocate the necessary compute resources for your team.
Onboarding efficiency: Onboarding new developers quickly is essential in a fast-growing team. Case studies show that new hires can jump straight into development with pre-configured environments, reducing onboarding time from days to minutes.
Cost efficiency: CDEs prevent overspending on idle resources by scaling down when not in use, allowing infrastructure to grow in line with team size.
3. Development process
a. Type of developed applications
Understanding the nature of the applications your team develops is crucial in determining whether CDEs are suitable for your workflow.
Server-side applications (web apps, backends, APIs) CDEs are well-suited for server-side development, which typically doesn’t require a graphical user interface (GUI) or specialized hardware. CDEs support port forwarding, allowing developers to run their applications remotely and access them through the web browser on their local machine.
Recommendation: CDEs are a great fit.
Client-side web applications As with server-side apps, if a client-side app doesn’t require a native GUI, CDEs can effectively replace local machines.
Recommendation: CDEs are a great fit.
Mobile applications (iOS and Android)
iOS apps: CDEs have limitations for iOS development because of Apple’s ecosystem requirements. Xcode (the essential tool for iOS development) doesn’t currently support remote development.
Android apps: Android development is supported in CDEs. However, there may be challenges running the Android Emulator, which is a separate resource-intensive application.
Recommendation: Remote development isn’t fully available to mobile devices yet. For iOS development, using local macOS machines or VDI solutions is the only viable option. For Android development, CDEs are supported, though there may be some nuances to consider.
Desktop applications CDEs are typically Linux-based (like CodeCanvas). You can use VNCto access desktop windows, which allows you to visually interact with applications. However, there are limitations, especially if you are developing for other operating systems. Even if you’re building cross-platform apps, testing and building for macOS or Windows still require their own respective environments.
Recommendation: CDEs are a good fit for Linux apps but not for macOS and Windows.
Game development Game development with engines like Unity or Unreal Engine requires running the engine application alongside your IDE. This means the engine window must be somehow shared between the remote dev environment and a local machine. Though this can be done via VNC, the problem here is that both Unity and Unreal Engine require GPUs for real-time rendering and other tasks. However, VNC doesn’t support hardware-accelerated rendering, meaning that while you can use VNC to view the remote desktop, it won’t perform well with these game engines.
Recommendation: Developing games in CDEs is not recommended at this point.
Specialized applications (embedded systems, IoT, hardware integration) Developing and testing applications for embedded systems, IoT devices, and hardware-integrated solutions often requires direct access to hardware, such as microcontrollers, sensors, and other external peripherals.
Recommendation: Stick to local environments unless you need CDEs for other reasons, such as enhanced security, standardized environments, etc.
b. Branching strategies
Branching strategies play a significant role in your development workflow and can influence the benefits of CDEs for your team.
Your team uses flows with feature branches If your team utilizes a branching strategy that involves creating feature branches for new features, bug fixes, or experiments (e.g. GitFlow, GitHub Flow, or others), CDEs can offer substantial advantages:
Isolated environments: Developers can easily create a dedicated CDE for each feature branch, ensuring that changes are isolated and do not interfere with other work.
Quick context switching: Developers can switch between different tasks or features by simply launching the corresponding CDEs. This means there are no overheads like those associated with changing branches locally, which often requires rebuilding indexes, fetching dependencies, and waiting for the environment to be ready.
Consistent setups: Each CDE is a fresh environment based on the branch’s code, reducing issues caused by leftover artifacts or configurations from previous work.
For example, a developer is assigned to fix a bug while already working on a new feature. Instead of stashing changes or juggling branches locally, they can:
Keep the CDE for the new feature runningю
Run a new CDE for the bug fix on the appropriate branch.
Switch between CDEs instantly, maintaining productivity and reducing context-switching costs.
Recommendation: Adopting CDEs can significantly speed up the development.
Your team uses flows without feature branches If your team employs trunk-based development or ad hoc commits to main, CDEs can still provide some benefits:
Fresh environments for each task: When starting a new task in the morning, developers must fetch the latest changes from the main branch. On large projects, this could mean pulling in 100+ commits each day. After fetching, the IDE needs to rebuild indexes and dependencies, which can take up to 30 minutes or more. With CDEs, the warmup feature automatically builds and prepares all the data overnight, meaning the developers can start their work almost immediately.
Reduced local setup overhead: CDEs eliminate the need to manage local environments, reducing issues related to configuration drift or dependency conflicts.
Task isolation: Even without branches, using separate CDEs for different tasks can help isolate work and prevent unintended interactions between changes.
Recommendation: Even without branches, CDEs can help maintain a clean working state and reduce setup time.
c. Code reviews and merge requests
Your team uses code reviews and merge requests Code reviews and merge requests that require approval are essential practices for maintaining high code quality. If your workflow includes these practices, CDEs can greatly enhance their efficiency:
Instant environment setup: Very few developers are willing to switch their entire local project to a review branch, as this can result in hours of setup – especially when new dependencies are introduced during the review. With CDEs, reviewers can quickly spin up a dedicated dev environment with a specific branch or commit under review.
In-depth analysis and experimentation: With a CDE, reviewers can open the reviewed code in a full-featured IDE, allowing them to navigate the codebase, understand the context, and even run/debug the code. Moreover, they can test proposed changes without affecting their local setup.
Your team doesn’t use code reviews and merge requests Without these practices, the benefits of CDEs in this context may be insignificant. However, we strongly recommend implementing code reviews and merge requests, at least for critical parts of your codebase, as they can greatly enhance code quality and collaboration.
Recommendation: If you rely on code reviews and merge requests, CDEs will perfectly fit into your workflow.
d. Onboarding of new developers
The complexity of your development environment can greatly impact the time it takes for new hires to become effective team members.
Quick onboarding (less than a day) If your current setup allows new developers to install and configure their local environments in just a few hours, CDEs may offer limited additional value.
Recommendation: Stick with local development unless you need CDEs for other reasons, such as enhanced security, standardized environments, etc.
Complex onboarding (several days or more) During onboarding, setting up a development environment with complex configurations, access setup, multiple dependencies, or large codebases can take days or weeks.
Recommendation: Adopt CDEs, such as CodeCanvas, to significantly reduce onboarding time. Pre-configured environments allow developers to avoid the time-consuming task of local setup and start working right away.
Frequent onboarding (rapid growth or high turnover)
If your company is rapidly expanding or experiencing high turnover, the cumulative time spent on onboarding becomes significant. Ensuring each new developer has a consistent environment is critical to maintaining productivity and reducing errors.
Recommendation: Regardless of how long onboarding takes in your company, CDEs will help you greatly improve this process.
e. Internal tools
Your company has platform teams building internal developer tools
In large organizations, platform teams often create specialized tools for developers, such as custom authentication mechanisms, CLI tools for managing cloud resources, and others. The challenge lies in delivering and configuring this tooling consistently across all developer machines.
With the centralized management of CDEs, this becomes much easier. Platform teams can ensure that all required tools, configurations, and updates are included in the standard CDE templates – all developers will work in properly configured environments without needing to install or update the tools themselves manually.
Recommendation: CDEs can significantly simplify tool adoption.
Your company doesn’t have such teams
Recommendation: Stick to local environments unless you need CDEs for other reasons, such as enhanced security, standardized environments, etc.
4. Security and compliance
a. Strict security or compliance requirements
You have significant compliance needs (e.g. fintech, healthcare) If your organization operates in industries with stringent security or compliance mandates – such as finance, healthcare, or government – CDEs can offer several security advantages:
Data isolation: With CDEs, your source code remains within the secure cloud infrastructure, reducing the risk of local device vulnerabilities or leaks. Of course, users can still retrieve the data from a remote environment if they really need to, and you can minimize this risk further with third-party solutions, such as data loss prevention (DLP) or monitoring tools.
Centralized control and role-based access (RBAC):Tools like CodeCanvas make it easier to enforce access controls, track activity, and comply with strict regulations like SOC 2 or HIPAA. Built-in RBAC ensures that only authorized personnel can access specific data, adding an extra layer of security.
Recommendation: CDEs are a valuable tool for meeting stringent industry regulations.
You have standard security measures For organizations without strict compliance requirements, CDEs still offer better security than local machines, simply “by design”. Code and data are housed in secure cloud environments, preventing the risks associated with local storage.
Recommendation: Evaluate CDEs for additional security benefits.
b. Use of contractors or third-party developers
Your team works with contractors or third-party developers When working with external teams, security is the main concern, and CDEs can be a great solution:
Fast onboarding via provisioning pre-configured dev environments.
Limited accesswith role-based access control (RBAC): Contractors have access only to the specific dev environments they need. Once a contractor completes their work, CDEs allow you to swiftly revoke access.
Recommendation: CDEs are highly beneficial.
Your team doesn’t work with contractors or third-party developers Even if contractors or third-party developers are not part of your workflow, CDEs may still offer benefits in terms of team management and security.
Recommendation: Evaluate CDEs for additional security benefits.
c. Need for audit trails and activity logs
Your team requires audit trails and activity logs CDEs can track key actions related to development environments, such as when a CDE is created, modified, or run for a specific project. This allows for transparent tracking of who accessed what and when, a critical requirement for security reviews and audits.
Recommendation: CDEs are recommended for teams requiring centralized tracking of environment-related actions: creation, usage, changes to configuration templates, and so on.
Your team doesn’t need audit trails or detailed logs Even if audit trails and detailed logging aren’t critical to your organization, CDEs may still offer benefits in terms of team management and security.
Recommendation: Evaluate CDEs for additional security benefits.
5. Infrastructure and resources
a. Infrastructure setup
Your team uses local machines only The truth about remote development is that using local machines will always be cheaper in terms of pure infrastructure costs. However, the benefits of CDEs lead to indirect savings:
Reduced non-productive time (NPT): Remote development reduces the time developers spend setting up environments, switching branches, or waiting for indexing. These tasks, often seen as downtime, are greatly minimized.
Lower hardware costs: With CDEs, developers no longer need powerful machines, as heavy computing tasks happen in the cloud. This approach significantly reduces the need to provide high-end hardware for every developer. If developers occasionally need more powerful hardware, they can access it through the cloud without needing a dedicated machine.
Your team uses virtual machines for development If you’re already using VMs, adopting CDEs with orchestration tools like CodeCanvas can further optimize your costs:
Scalable resources:CDEs offer dynamic scaling, ensuring that you only use resources as needed, preventing over-provisioning or leaving VMs idle.
Auto-shutdown:Automatically shutting down environments when they’re not in use helps reduce costs and avoids wasting resources.
Cheaper storage: Tools like CodeCanvas can automatically move data of inactive dev environments to more cost-effective storage, further reducing infrastructure expenses.
Auto cleanup: Unused or abandoned CDEs can be automatically deleted, freeing up pricy cloud storage.
Your team has some infrastructure in the cloud (AWS, Azure, Google Cloud) For companies already using cloud infrastructure, integrating CDEs into the existing setup can be a smoother and potentially more cost-effective process:
Existing expertise: Your cloud experts can easily set up and maintain an orchestration tool like CodeCanvas.
Access to cloud resources: CDEs have built-in access to the resources hosted in the same cloud (via Kubernetes service accounts).
Cost benefits through scale: By moving the local development to the cloud, you might see cost advantages through bulk usage or negotiated discounts with cloud providers.
Recommendation: Be prepared for remote development to be more expensive in terms of infrastructure costs, but you may save indirectly through improved productivity, reduced expenses on local hardware, and optimized resource management. The actual savings depend on factors like team size and project duration – the more developers you have and the longer the time frame, the more you save.
b. Internet connection reliability
Remote development heavily depends on fast and stable internet connections.
Your team has strong, reliable internet If your internet is reliable and provides low latency (under 100 ms) to major cloud service providers (AWS, Google Cloud, Azure), then CDEs are a suitable option for you.
Your team experiences intermittent internet issues or has slower bandwidth With remote development, no internet means no development. Slow or unreliable internet can significantly impact productivity. Latency greater than 100 ms can make interactions with the remote IDE frustrating, causing delays during typing.
Recommendation: If you want to adopt CDEs, ensure your latency to cloud providers is consistently below 100 ms. Additionally, it’s vital to have a backup internet plan. Without the internet, you won’t be able to access your dev environments or code, so ensure you have a second provider, among other backup options.
6. Additional considerations
a. Software licensing and compliance
IDE licensing: When using CDEs, IDE licenses (e.g. for JetBrains IDEs) function as they would locally. Developers are required to have valid licenses to use their chosen IDE within the cloud environment, as CDEs do not manage or provide these licenses automatically.
Licensing for additional tools and dependencies: Licensing may be more complex for specialized development tools, frameworks, or dependencies. Some tools may have specific licensing models for cloud usage, such as geographic restrictions or limits on the number of users. Before deploying these tools in CDEs, it’s essential to verify whether additional steps are needed to comply with licensing terms.
License management: CDEs do not offer centralized management for software licenses. If you’re using multiple third-party tools, managing these licenses (e.g. tracking usage, renewals, and compliance) may require an external license management system to prevent over-deployment or violations.
b. Disaster recovery and business continuity
Recovery time: In traditional local setups, recovery time depends heavily on your ability to restore hardware, retrieve backups, and reconfigure environments. In CDEs, recovery times can be significantly reduced as dev environments are created on demand from pre-configured templates.
Internet dependency: Since CDEs depend on constant internet access, a failure in connectivity could result in a total development halt. It’s critical to have a backup internet connection in place or alternative local environments that can be activated in the case of extended internet outages.
Cost and complexity: Implementing a fail-safe infrastructure in CDEs can increase both the cost and complexity of your setup. However, the trade-off is enhanced resilience and potentially reduced downtime.
c. CDEs and AI development
AI and autonomous developers: As we move toward a future where AI-autonomous developers become a reality, CDEs will play a crucial role. Remote development offers the infrastructure and scalability necessary for AI agents to run. AI models can use CDEs to perform code generation, testing, and deployment autonomously.
