Comparing Developer Environments: An Introduction
What are Developer Environments?
Developer experience can be massively improved with the right developer environments and broader Platform Engineering strategy. A developer environment refers to the integrated set of developer tools, configurations, and resources that empower software developers to create, test, and debug code efficiently. This could include developer tools found in integrated development environments (IDEs). A developer environment may be accessible via an Internal Developer Platform (IDP). IDPs and Developer Environments are frequently conflated and so we will briefly touch on both even though they are distinct.
IDPs vs Developer Environments
These software development environments serve as the virtual workspaces where developers bring their ideas to life, collaborating seamlessly with diverse frameworks, languages, and platforms. From a local development environment tailored to individual preferences to complex cloud-based ecosystems supporting collaborative projects, a software development environment encompasses a spectrum of possibilities, influencing productivity, code quality, and the overall software development lifecycle. As the Kubernetes and Cloud Native technological ecosystem continues to evolve, the need for robust and adaptable dev environments becomes increasingly crucial. The better your software development environments, the faster your iteration time.
Developer Environment importance
Developer environments are rocketing up in importance primarily because of an increasing focus on engineering efficiency, but also a recognition that microservices-oriented development creates a host of discoverability and maintenance problems. How do I test my tiny microservice in my dev environment when it depends on hundreds of other services? How do I know that a datastore service is even available when I’m getting started? These problems arise because distributed agile teams developing independent services tend to bury information into nooks and crannies within the organization without realizing it.
Why Developer Environments are confusing
A developer environment can come in many shapes with radically different technical approaches and tradeoffs. It’s probably not practical for most teams to “build a developer test environment” or a complete “developer platform” without specifying what it’s for. There are simply too many developer tools and philosophies on offer.
The right way to approach the problem is analyze where your engineering process slowdowns are and pick targeted best of breed solutions for those problems. The wrong way to approach the problem is to have your platform engineering team build a portal and stuff it full of interesting new technology that confuses everyone and has no specific purpose. Pick something smaller like adding preview environments to your build pipeline or implementing some basic traffic replay testing. These two example starting points are taken from our real world experience with large enterprises and how they begin.
Ensuring performance: how major retailers leverage
User traffic to validate code changes
How do developer environments compare?
Currently, this is a fairly new space so there’s a lot of marketing thrash. This table combines different terms into buckets of similar offerings.
|
Types of Developer Environments |
Internal Developer Platform |
– Test Containers – Preview Environments – Environments as a Service (EaaS) – Ephemeral Environments |
Release Environments |
Traffic Replay & Traffic Mirroring |
|
How it works |
A specialized web app that resembles a Wiki but is tailored for engineering use cases. Usually has templates for common tasks like Spring Boot deployment. |
Pre-loaded containers curated by your organization, ready for deployment at a moment’s notice. It’s Docker after years of working out at the IaaC gym. |
Simulates user requests and backend systems with real data from production environments. Works at the network level so no databases or “real” 3rd-party APIs need to be stood up. |
|
|
Main problem it solves |
Onboarding, Service Discovery and Standardization for big teams |
Expensive cloud environments only cost money during active testing. |
“Almost Production” testing by creating mirrored, different environments. |
Removes the need for custom curated test data. This is a critical challenge in all other approaches. |
|
Popular tools |
Do-It-Yourself |
|||
|
Benefits |
* Onboarding new engineers * Service discovery across the org * Automated code documentation * Documentation of “known good” paths |
– Lets devs test without hitting production server/databases – Decouples work so engineers can test independently – Greatly speeds up peer review because code can be run live with little effort (in preview) |
– Allows experimentation in staging environment – Allows regression test suites to run |
– Realistic tests with no scripting – Removes need to build service mocks or stand up back end systems (because they are simulated at the network level) |
|
Challenges |
* Falls out of date easily * Requires maintenance and commitment * Fixes process problems but people incorrectly view it as mainly a tool |
– Test data is always out of date, limiting usefulness. – Requires even more effort than a static staging server “Release Environment” because you need to add the code, the test data and now IaaC. |
– “Almost Production” is never close enough. Data is always out of date. – Slow feedback loop. Looks like waterfall development because it is waterfall development. – Copying data from production is arduous |
The Platform Eng, DevOps or Security needs to be bought in if you want to record from production. |
|
Best suited for |
Big organizations with lots of teams or high churn that need to keep devs on the same page. |
Anyone wanting to “virtualize” the dependencies surrounding their service. |
Complex apps built before cloud apps became mainstream. Use this when you simply cannot automate environment creation. |
Testing of all kinds (regression, performance or chaos). |
|
Can replace |
Internal Wiki |
Release Environments |
No testing at all |
Integration testing and moving test data between environments (however they are provisioned). |
|
Where to start |
Start small, don’t boil the ocean. Remember, you have to maintain it. |
Add a preview environment to your MR build pipeline. Start with something easy like your documentation. Add more complexity and support for additional services as you go along. |
Don’t do this in 2023 |
Record traffic from your local machine and replay it for local debugging. When you get serious, deploy a collector to production to eliminate the need for most integration testing. |
|
Does it really work? |
Yes, but only if you are willing to put in the effort. |
Only when used for local development environment use cases and not as an integration testing alternative. The lack of realistic data limits this approach to mainly MR review and super-charged unit tests. It isn’t a substitute for integration tests as some tools promise. |
Sort of, but it’s easy to fall into re-branded waterfall processes. Don’t make big testing suites and process gates. Design these environments as tools used in a continuous fashion. |
Yes, but it works best for established services. It works for new services but gets more valuable the more mature your services are. |
What to know before you start
Some basic advice when starting to increase developer productivity:
Evolutions from Cloud Native
Test Containers/Preview Environments are the Cloud Native evolution of Release Environments. As with most things Cloud Native, they are designed to be short lived and just in time. In other words, we treat them like a herd of cattle instead of individual treasured pets. But Kelsey Hightower’s warning about treating infrastructure as cattle applies just as much in this situation. Populating those test containers with meaningful data is in some ways harder than just having a staging environment and dealing with the chaos.
Unlocking value with IDPs
Internal Developer Platforms are (mostly) process improvement systems. If you need them, they are absolutely necessary. However, you’ll still need a solution for Developer Environments. Also, someone will be complaining about updating the docs/templates/cave drawings next year so make sure it’s worth it. Some of the folks who helped build Backstage say it starts being worth it once you have 500 engineers and 2-3 people to dedicate to keeping it up to date.
Enhancing with traffic replay
Traffic replay fits within any Developer Environment strategy because it brings the real world production environment data anywhere you specify. You can make a traditional testing environment much more useful by adding a realistic database without scripting. The same applies for preview/ephemeral environments, etc.
Unraveling the different discussions around a Dev Environment can get confusing. As this space is evolving rapidly, there are still big improvements ahead.
Conclusion
The best way to accelerate development tasks in the development lifecycle is to streamline your dev environments for the different types of tasks software developers will encounter during the software development process. In summary, optimizing developer environments is about strategically aligning your tools and processes to address specific engineering bottlenecks and challenges, ultimately enhancing productivity and software quality.