What happens when you leave your tech stack unmapped? Time-bombs…
I think our ideal users are engineering teams. It’s not just one person getting value, it’s everyone on the team. For example, if you’re a new hire, OpenContext will help because you would be able to understand from your team’s point of view, what your team does, and what different code repositories they work in. And if you’re working in a monorepo, you’d see the different code paths that you're responsible for. It’s sometimes hard for people to know that! You learn it over time, but it’s seldom explicitly taught when you join a team.
OpenContext makes it easier to onboard a new person on a team, but it also makes things clearer for existing members. It’s rare that someone works on a single team for their entire time at a company. OpenContext also makes it easier to see when the things that you use are moving or changing, even if you’re not directly told by the team that’s changing them. You also really benefit from being able to ask about context when you’re on call or troubleshooting a problem. You don’t have to ask someone else what the codepath or structure is, you can use self-service to see what is affected.
If you can free up brain space or cognitive capacity for people, that brain power can be used to go do something much more innovative and productive than trying to deduce who owns a piece of code.
What can I use OpenContext for?
The main focus of OpenContext is to help people see the whole picture and get an understanding of all the interdependencies of things. Whether we like it or not, our work rubs up against and affects other people’s work. It’s easy to think you’re just working on this one piece of code or single feature, and it won’t affect anything beyond itself. It’s easy to think that, but it’s wrong.
Inevitably that piece of code does affect other people, either upstream or downstream. That’s true whether or not you know it at the time. It’s better if you make changes while being aware of what your changes may affect. That kind of awareness and notification is a given for a big upgrade - we build in notification and alerts for a version-level change. But sometimes, a small change for you can be a big change for someone else. That’s when all kinds of interesting things happen. We’d like to think that we did enough end-to-end and performance testing, but there’s often something we miss because of time constraints. If we knew ahead of time who our code was affecting, we might be able to do better planning.
When we first started OpenContext, we were thinking that people would use it to do modeling and get a broader picture of where they were, but as people really started using it, we realized that auto-discovery was a huge benefit. Auto-discovery gives anyone in the organization the ability to see how their work connects with the rest of the system. That’s especially important when all sorts of individual roles like release manager or QA are getting squished into the developer role. We don’t have people or time dedicated to creating and maintaining a system for explicit system mapping - it needs to be built-in. Every company’s tech stack is different enough that it needs to be mapped, but most companies don’t have the resources to do it as a separate task.
People will only manually map things that they remember. Sadly, most of us don’t remember every tiny detail of our system. Manual mapping is useful, but not sufficient. Auto-discovery starts showing you dependencies that you thought you’d gotten rid of, services that have been running fine for years, so no one actually owns them anymore, that type of thing.
What happens when you leave your tech stack unmapped? Time bombs…
If a service is mature and stable, we tend to not think about it, but then if there’s a hardware failure or something happens to it, you can have an outage of epic proportions because no one knows anything about it or its connections. You lack the context for it, and if you don’t have auto-discovery, it’s really hard to find out what depends on a service that is broken.
Orphaned services may not have a subject matter expert in the organization, and the person who got paged for it needs to be able to find as much information as possible on their own. Is there a runbook? Is the runbook up-to-date? Is it possible you’re intentionally or unintentionally running multiple versions of the same service? That context should be available when you need it, without having to escalate to someone else. Everyone on call should be able to find out basic information about your repository, who owns it, are there past pages for it, is it in the CI/CD pipeline? Most importantly, you should be able to find out who owns it or is likely to know something about it.
GitHub has most of this information. We can see who has contributed to a code repository, and what folders or sub-paths in your repository are getting changed at the same time.That all helps with self-service and faster triage. If I get an alert about a service, I can see exactly where it lives and what it’s connected to. The bigger your codebase is, the more important it is to have pointers to the exact things you need.
Top comments (0)