DEV Community

Cover image for How containers promote equity in tech
Rizèl Scarlett for GitHub

Posted on • Updated on

How containers promote equity in tech

In the tech industry, we often talk a lot about diversity, equity, and inclusion. Sometimes, we mention belonging. But, if we’re being honest very little improvements have been made to the state of diversity in our field. During the peak of the Black Lives Matter movement, companies made commitments to amplify diversity. Initiatives like renaming default branches from master to main were undertaken, but their true impact warrants scrutiny. The insights from Built In's State of Diversity 2022 Report illustrate my point: ¼ of the surveyed companies were over 70 percent white, with 73 percent acknowledging the absence of Black leaders in executive positions. Additionally, the report highlighted that 39 percent of women and BIPOC employees felt their voices and perspectives were ignored in the decision-making process. Today, we’re also seeing that DEI roles are slowly disappearing.

Part of the issue is that we’re laser-focused on the wrong things. We often build products and companies that fine-tune the lives of those who already have a head start. For example: we have multiple platforms that make sharing documents easier or share code. We’re using artificial intelligence to accelerate developer productivity. However, we are missing technological breakthroughs that address fundamental human predicaments such as hunger, homelessness, and the glaring lack of diversity in the tech sphere. I’m not naive. I acknowledge that this is because these problems take more effort to solve. Perhap, it doesn’t have to be such a heavy lift. The tools we’ve developed to solve first-world problems have the potential to uplift those marginalized by circumstance. Specifically, I believe that while container technology streamlines software deployment, it also shatters barriers, paving the way for a more equitable landscape. In this blog post, we’ll explore the powerful synergy between containerization and equity in the tech industry.

We’ll break this down by understanding the definitions of:

  • Privilege
  • Equality
  • Equity

Then, we will take a look at:

  • Why we use containers
  • The history of container technology
  • And how they promote equity in our industry

Privilege

Privilege is a good thing, but the word can sometimes evoke unintended negative reactions. The term “privilege” is often misconstrued as “you didn’t work for your achievements.” However, privilege refers to the fact that you have access to something that other people may not have. It's a universal truth: everyone holds some form of privilege. There are different types of privilege including, but not limited to: race, education, sexuality, gender, class, language, ethnicity, ability, and age.

A prime example of someone who doesn’t always acknowledge his privilege is Drake.

While his song "Started from the Bottom" chronicles his path to stardom, it sometimes obscures the fact that he had a head start due to his acting career as a child star on Degrassi: The Next Generation. Since becoming a rapper, he’s amassed over:

  • 5 Grammys
  • 7 studio albums
  • 3 compilation albums
  • 4 extended plays
  • 7 mixtapes
  • 140 singles
  • 84 music videos

This is not to diminish his accomplishments, but rather to highlight how privilege plays a role. He worked hard to be one of the few Canadian rappers who are popular in the United States.

On a more personal note, my own life is full of disadvantages—living in homeless shelters, being an immigrant, a woman, and Black. But amid these experiences, I acknowledge the privileges I hold— a supportive family, access to education, a role at GitHub, and a public platform as a Developer Advocate.

The important thing is that we use our privileges to uplift others.

Equity vs. Equality

Equity and equality are terms that are often used interchangeably, but they have different meanings.

Equality means each individual or group of people is given the same resources or opportunities. Equity recognizes that each person has different circumstances and allocates the exact resources and opportunities needed to reach an equal outcome.

What is a container?

According to the official Docker website, “A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another”

The way I think of it is: a container holds code for the app, other tools that it depends on, and settings that make sure it works consistently across different computers. In this way, the application will behave the same regardless of whether it resides on your computer, production, or your uncle's 2015 Dell machine. Containers enable software engineers to program in a consistent environment. Your dev environment mirrors production with the same operating system, configurations, and dependencies. This ensures bugs and features behave the same across all environments.

Why containers?

If you’re a developer, and you’ve ever said the words, “It works on my machine”, you know the pain and embarrassment of working tirelessly on a project, but you’re unable to show the fruit of your labor to your coworkers because it doesn’t work on their computers or on a different environment. Because of this, the software industry has spent years in pursuit of a solution to running and shipping software automatically and reliably from one environment to another.

It was an incremental climb to developing a solution.

A brief history on container technology

Chroot

We started trying to solve this problem in the 1970s with chroot, which stands for “Change root.” It allows developers to change the root directory for a running process and its children. Developers can use chroot to create a new isolated environment with its own root directory. Creating isolated environments to build and test software helps developers ensure that software can run in specific environments and avoids potential conflicts with system libraries and dependencies.

Cgroups

In the 2000s, the industry created Cgroups, also known as control groups. They fairly manage and divide resources like CPU, memory, and storage among processes or groups of processes. This way each application isn’t fighting for resources. Cgroups are one of the building blocks of containerization because they help containers ensure they are receiving a fair share of resources.

Docker

Then, in March 2013, folks like Solomon Hykes popularized the use of containers. Docker, an open source platform, introduced a suite of management and packaging tools for containerization. It enables developers to create, deploy, and manage applications within containers. Overall, it made containers more accessible for technologists.

How container technology promotes equity

The reason that software development teams are not diverse is not because of a lack of interest from people of diverse and even underprivileged backgrounds. Common factors for a lack of diversity at a tech company are:

  • Barriers to Entry: Many potential talents face difficulties accessing the field in the first place.
  • Stunted Growth and Inclusivity: Even when they manage to enter, they often encounter challenges in advancing and feeling valued and included within their teams. After years of feeling stuck or excluded, disenfranchised people may feel more tempted to quit.

Barriers to entry exist for many reasons, including the following:

  • Limited access to computers or limited access to devices with strong computing power
  • Lack of knowledge on how to initiate their journey into software development.

Access

Container technology ushered in the emergence of other tools like Replit, GitPod, and GitHub Codespaces, which empower people with low computing power or limited computing resources to code even on devices like their phones or iPads. These tools run in your browser, which means that you consume less of your machine's resources, so you don’t need heavy computing power.

Time-to-start

Whether you are joining a team, contributing to an open source, or you’re just trying to learn how to code, setting up your environment as a new developer is an overwhelming task. For companies, project configurations can be automated, ensuring that any developer contributing to the codebase can effortlessly set up and run projects. If you’re a single developer, trying to learn a new programming language or framework, you can leverage GitHub Codespace Templates. We have templates for frameworks and languages like, Next.js, Ruby, Django with boilerplate code. This immediate access circumvents the time-consuming setup phase.

Stunted Growth and Inclusivity

From onboarding to deployment, minorities don’t always get the mentorship and sponsorship they deserve, which can lead to feeling stuck in your career and excluded.

Onboarding

Navigating outdated documentation during onboarding can be frustrating, underscoring the value of tools like GitHub Codespaces.

Getting help

Collaborating on remote teams can pose challenges in sharing local environments with coworkers. GitHub Codespaces provides solutions through features like port forwarding and liveshare, facilitating seamless collaboration and troubleshooting.

Deployment

Leveraging container technology like GitHub Codespaces minimizes the risk of discrepancies between local, staging, and production environments. This ensures a more consistent and reliable development experience.

The hard part

I work at GitHub, so I’ll focus on one tool I know most intimately: GitHub Codespaces. Although GitHub Codespaces streamlines the onboarding process, it uses configuration-as-code to establish a consistent development environment.

In some of my past blog posts, I outline how to set up a development container in GitHub Codespaces for a:

The TLDR, to make GitHub Codespaces install and run your project, you should provide your devcontainer with the following:

  • Installation commands like npm install
  • Execution commands npm run dev
  • The port you want the project to run on like [forwardPort: 3000]
  • And Codespace lifecycle properties like [postCreateCommand] - These control when the commands you provided should run.

Below are examples of two devcontainer.json files that I created for specific projects.

Python


// For format details, see https://aka.ms/devcontainer.json. For config options, see the

// README at: https://github.com/devcontainers/templates/tree/main/src/python

{

  "name": "Python 3",

  // Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile

  "image": "mcr.microsoft.com/devcontainers/python:0-3.11-bullseye",

  "features": {

    "ghcr.io/devcontainers-contrib/features/coverage-py:2": {}

  }

  // Features to add to the dev container. More info: https://containers.dev/features.

  // "features": {},

  // Use 'forwardPorts' to make a list of ports inside the container available locally.

  "forwardPorts": [5003],

  // Use 'postCreateCommand' to run commands after the container is created.

  "postCreateCommand": "pip install -r requirements.txt",

  "postAttachCommand": ".devcontainer/addcodespacename.sh && python main.py",

 // Configure tool-specific properties.

  "customizations": {

        "codespaces": {

            "openFiles": [

                ".well-known/ai-plugin.json",

                "openapi.yaml"

            ]

        }

    }

}

  // Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.

  // "remoteUser": "root"

}

Enter fullscreen mode Exit fullscreen mode

Next.js/TypeScript

// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/typescript-node
{
    "name": "Node.js & TypeScript",
    "image": "mcr.microsoft.com/devcontainers/typescript-node:0-18",
    "waitFor": "onCreateCommand",
    "updateContentCommand": "pnpm install",
    "postAttachCommand": "pnpm dev",
    "customizations": {
        "vscode": {
            "extensions": [
                "streetsidesoftware.code-spell-checker",
                "dbaeumer.vscode-eslint",
                "esbenp.prettier-vscode",
                "DavidAnson.vscode-markdownlint",
                "ms-vscode-remote.remote-containers"
            ]
        }
    },
    "portsAttributes": {
        "3000": {
            "label": "Application",
            "onAutoForward": "openPreview"
        }
    },
    "forwardPorts": [3000]
}
Enter fullscreen mode Exit fullscreen mode

This is only a start

Containers help you standardize environments and use less of your local machine's resources. This lowers the barriers for folks with:

  • Low computing power
  • Low access to coding education
  • A tough onboarding process

Looking forward, I hope that we can invest more time and effort into the following technological advancements:

  • Bridging the digital divide by improving internet access for folks in more underdeveloped countries or rural areas
  • Introduce coding to underrepresented folks at an early stage
  • Prioritize accessibility for developers with visible and non-visible disabilities

I’ll leave you with these thoughts: rather than ignoring the value of DEI, how can our industry build upon already existing technologies to drive impactful change for DEI? And what issues do you hope our industry addresses in the near future?

Top comments (2)

Collapse
 
nitya profile image
Nitya Narasimhan, Ph.D

Love the discussion on thinking on building tools and technologies that can level the playing field so that less privileged communities get the same development environment as those who have more resources and access.

I think a lot about developer onboarding experience as a measure of success here. If you spend more time in having to work around/through limitations to just set up your environment, while your peers take that step for granted and are already into the development stages - then you are automatically starting at a disadvantage.

It also made me now think about how Codespaces could be used to also do the reverse - which is to allow people in privileged regions to experience what it feels like to develop/deploy/use applications in more constrained environments. If I could keep 2 container profiles (one resource-rich, one resource-poor) and spend one day a week switching to the less resourceful one - chances are I would think twice about every extra byte of data, content and code that I add into my development workflow.

Anyway - great article and gave me something to think about.

Collapse
 
freddyhm profile image
Freddy Hidalgo-Monchez • Edited

Super interesting post. I hadn't thought of containerization or onboarding with that perspective in mind. Sometimes I feel like it's an uphill battle to show engineers the multiplying effect of good documentation, onboarding, and culture building.

Too often I see the belief that if the code is good enough, the rest is not important. Issues like knowledge hoarding, high employee turnover, and poor communication are addressed with a shrug.

How would you promote the value of inclusivity to a team who is not yet sold on its benefits?