How to Choose a Cloud Development Environment

I remember a financial institution trying to rationalize their development pipeline about 10 years ago, and trying to create what we would today refer to as a platform. They noticed how slow their onboarding times were for new developers, and how inconsistent technology uses could be. They had an architectural board, but that was distant from day-to-day development. Agile methodology informed them that everything should be automated, so they took that approach to their pipeline.

What they were doing was moving towards a Cloud Development Environment, or CDE. There was a vague understanding that if they packed the “best in class” tools altogether, that might provide a good onboarding experience. But one of the problems was working out how to synthesize the different development experiences throughout the organization, and how to avoid losing expertise that might coalesce around a unique environment. Did it make sense to sacrifice expertise in order to gain standardization?

This post is about understanding how the answer to that question hits your team, in the face of all the new CDE options. And it still requires an honest reflection on how your team in your organization operates.

The CDE-WordPress Analogy

You don’t need to think about development to examine cloud experiences. Like many other online publications, The New Stack runs on the WordPress platform. When I write a post, there is a good chance I will want to present a snippet of code that includes angled brackets. If I just plop the snippet straight in as a piece of content, the angled brackets may be interpreted as an instruction, or may be replaced by HTML entities that you are probably all too familiar with: “&lt” and “&gt”. Either way: I have hit a snag in my role as a platform user, a problem with the system. And now the clock starts.

• Will the platform, or at least Google, direct me to a solution?
• Who actually understands the issue? Does the person who understands the issue also have access to the platform?
• How long will the resolution take?
• Should I just avoid the code?

In this situation, the answer involved the excellent internal team recognizing the issue, and quickly giving access to the appropriate WordPress plugin. Time was important, but in no way critical. Ultimately the focus is on the writer expressing themselves as accurately as possible. But if push came to shove, I could correct my post later.

Now imagine your software development team approaching a deadline, and a problematic issue coming up. Does the team have the skills to isolate the problem? Is it more important that quirky developers can express themselves, or that the team preserves a collaborative approach? Answering these questions honestly helps work out how to get into online environments.

On-Demand Computing with CDEs

Today we think of a CDE as an on-demand development environment that comes with all the tools and pre-configured dependencies needed to build and deploy applications — as long as the template exists for the flavor of application you want to build. They normally operate within a known performance band; that is, you have some idea of how much RAM and CPU their containers can spin up. Like most cloud products, you might only be able to access them via the web. In my last article, I looked at the popular online environment Replit running Ghostwriter AI and noticed how easy it was to get started.

The Gitpod CDE whitepaper describes four principal qualities of a CDE: Equity, Consistency, Extensibility and On-demand availability. Anyone can start a session with a development environment, and get the same environment as anyone else. It is more than just spinning up a container and handing it off; a full pipeline must be available to build a complete application from code. Just like Google Docs, a session is available immediately, 24/7. Collaboration is fairly natural.

Self-hosting and Standardization

Daytona has what it calls a Standardized Development Environment (SDE), which is largely about self-hosting CDEs and the need to control these efforts. Coder.com has a slightly different approach to self-hosting.

Many large organizations have built their own cloud environments, citing the need to control cost, security or scalability. SDE recognises the need to create templates to allow developers to use their own tools or access contained resources with AI; to work locally or online.

Self-hosting brings flexibility and control closer to internal users, but clearly favors organizations with the skills to hook everything up.

Some Developers Actually Like Configuration

Some engineers do specifically enjoy working on configurations and infrastructure code. If those skills exist in your team, then it makes sense to exploit them. Conversely, many developers are loathe to fiddle about with a script that doesn’t look like their everyday development code. More to the point, they may never have dug into how systems like Ansible or Chef worked when they were in vogue and may contrive spaghetti-like solutions to fixing platforms.

Are You Onboarding for Standardization or Not?

The most important gain from an environment in a box (Software-as-a-Service, or SaaS) — like GitHub Codespaces — is that it speeds up onboarding massively. The team knowledge about that environment will not have the broad envelope that occurs when everyone has a slightly different experience, because of how they installed it. Any document about getting started is much more likely to be entirely accurate for each user. But there are problems with assuming that because I want an environment, I want one for the same reason as the last person who wanted an environment.

More heterodox onboarding allows everyone into the environment quickly, without assuming you know exactly what they want to do when they get there. A good example is the inquisitive marketing executive who wants to do more than use slides and wants to run a current build. Allowing them to spin up a build makes sense, but not if they have to set up SSH tunnels first. The gains they can make from updating one image resource with the logo of a prospective client — something they can’t do simply from behind a web browser — may be massive. On the other side, someone coming in to quickly assess the project may want to run a range of builds from different times, and may be challenged by not having full control of their familiar tools.

Coding for Innovation vs. Production

The great advantage of shipping containers (or intermodal containers) is that they have a standard size. This has revolutionized cost control in shipping, as container ports can be built in advance with a working template. You might wonder why it took so long (the 1970s) for these to come about. Of course, there were plenty of attempts before this — what has actually standardised are the patterns of international trade. Similarly, you have to look honestly at your team and work out whether their raison d’etre is delivery or inspired skunk works.

Data security has never quite been the issue it is assumed to be. It is more a question of legal geography — where data can be held. Otherwise, data held on your own internal data center is unlikely to be more secure than it is in the data center of a company paid explicitly to mind security. But the term “security” may also mean safety within your own sandbox, or making sure developers don’t have too much code on their laptops. It remains more of a political than a literal issue much of the time.

Start With What Your Team Does

So the bottom line is to make sure you know what your team is really doing, then push in a little future-proofing. AI might be a boon now, but essential later. You may know exactly how big a container you need now, but that might change. You may come to the conclusion that the only thing your team should share is a git repository. Maybe a few containers under Docker. Maybe a full CDE, or maybe something self-hosted. Either way, start with the basics of how the first conflicts would be resolved.