This post originally appeared on The New Stack.
In almost any domain, asynchronous collaboration requires two types of tools:
- General-purpose communication tools (e.g. Zoom, Slack, and Trello)
- Role-specific tools for contributing to a work product (e.g. Google Docs for content, Figma for UI/UX design, KNIME and Databricks for data science)
Remember what it was like in the “old days” to be part of a group of stakeholders collaborating on a complex piece of writing? Like, you know, emailing around Microsoft Word attachments with “track changes” enabled?
No one could really be sure if they were working with the most recent file. Conflicts would emerge as teammates edited simultaneously. A missing font or outdated version of Microsoft Office could prevent someone from contributing.
When web-based word processors became the standard, most of these problems magically disappeared. Improved communication tools (better videoconferencing, better chat) couldn’t have had nearly the same impact–users needed a collaboration tool that was created specifically for the task at hand.
Domain-specific tools exist to ensure that every contributor:
- Has the most recent version (and relevant variations) of a work product
- Can trust that a file or document will look and behave the same way regardless of their hardware, operating system, etc.
In other words, teams are guaranteed access and consistency.
Access and consistency are important for any team, but particularly for distributed teams where effective collaboration and communication require extra effort. And a “distributed team” could mean a remote-first company with employees around the globe, a Silicon Valley behemoth where a team is spread throughout a sprawling campus, or a startup that used to share a one-room office but is indefinitely working from home due to a global pandemic.
Access and consistency for cloud native application development
At Garden, our mission is to make it easy for developers and DevOps teams to build, troubleshoot, and test cloud native applications (which we’ll define here as applications composed of loosely coupled, independently developed and deployed services).
While working with our users, we’ve had a chance to observe the software development process at many different organizations. And we think we have a good sense of what access and consistency mean to cloud native development teams.
Access means that every developer knows the current topology of an application and the relationship between different components–including the services they’re not working on. And getting this information doesn’t depend on being friends with the right people or gradually accumulating institutional knowledge that isn’t written down anywhere.
Consistency means that every developer can create testing and preview environments that are identical to those used by their teammates and as similar as possible to production. There’s no collection of cobbled-together local environments that behave differently on every laptop, making it impossible to collaborate coherently.
To make this idea a bit more concrete, let’s talk through access and consistency in a scenario that relies heavily on asynchronous collaboration: onboarding. In software development, “onboarding” can have a few different dimensions, such as:
- Getting a newly hired employee up to speed (we’ve heard from folks that it can take up to six months to fully onboard a developer working on a complex distributed application)
- Working with an existing internal team that’s been newly assigned to build a service that’s part of your application
- Kicking off a project with an external development agency hired to write code, while testing and ongoing operations will be managed internally (a common practice in many larger orgs)
And when we talk about the importance of a good onboarding experience, we’re not only talking about how long it takes for a new team member to be “productive.” A large part of onboarding is about making sure a new teammate feels included, building their confidence as they become familiar with a daunting, multi-layered project.
Yes, providing “access and consistency” as we’ve defined it gives a dev everything they need to do their job from a technical standpoint, but it also signals, “Hey, we’re making an effort to support you and to keep you in the loop about what’s happening on our team.”
Considerations when onboarding a cloud native developer (or team)
What are some of the topics you need to consider if you’re going to provide a developer or team with access and consistency at the start of a project?
- The current state of the application and relationship between different services. If a dev is going to be writing services that are part of an application that already exists, they need to know how every service is built, tested, and deployed. Perhaps this is covered in a bunch of informal READMEs that no one officially owns, and therefore no one proactively updates. Or perhaps this lives only in the heads of “Charlie in the London office” or “Dana from the data team”, and so on.
- Dependencies with adjacent services that a dev needs to be aware of and manage as they develop. Also, who to contact if they have a question or if someone inadvertently breaks their service.
- An understanding of how their services and applications will be tested. Even better, a dev should be able to run the _same _tests that you’ll be running further downstream (including integration tests) throughout their development process, so as to shorten feedback loops.
- How to communicate the application topology and relationship between different services to other members of the team. If a dev is building new services (or built an entire application from scratch), how should they document this and bring the rest of the team up to speed about what they’ve been working on, so that everyone knows how to properly test and troubleshoot in the long term?
- How a dev should share their work so that it can be reviewed by teammates. Some features will need to be tested and reviewed manually. How can a dev share a working version of an application for testing so that it behaves for everyone else the exact same way it behaves for them?
Access and consistency: One possible approach
We didn’t set out to build Garden specifically for this developer onboarding scenario. Rather, we were more generally focused on inefficiencies around testing and troubleshooting that developers had to deal with as applications became more distributed.
But it so happens that the same tooling that makes it easier for a single developer to test and troubleshoot can make it easier for teams to collaborate, too. We’ll give a brief overview here (and our core product is free and open source, so we encourage you to check it out if you’d like to go deeper). And of course, our point of view is just one way to think about access and consistency for devs.
So, the way we approach it:
- Every part of your stack describes how it’s built, tested, and deployed: There’s a Garden configuration file for every part of the stack (container images, Helm charts, functions, etc) rather than one massive, project-wide file. The devs responsible for a given component take care of their config files.
- Garden collects these configuration files and compiles them into a DAG called the Stack Graph. The Stack Graph captures all dependencies between different components and the order in which different parts need to be built and tested. It’s a complete view of the relationship between every part of your stack–like living documentation that can be used to communicate the application topology to anyone working on the project.
- Developers can spin up namespaced testing and preview environments. These environments are based on the Stack Graph, so they’re always up-to-date and reflective of the complete application. Developers can also run an integration test suite with a single command or share a preview environment within the agency or with your team to guarantee a consistent review experience for everyone. Garden can also spin up a testing environment from an existing CI pipeline then run automated tests with every PR.
All developers–whether members of your org or of an external agency–simply need to keep the config files for their services up to date.
Garden is responsible for pulling these files together and providing a big-picture view of the application and the corresponding development and testing environments.
And everyone working on the project is guaranteed access and consistency.
