In a recent ThinkLab Clubhouse session, Sascha Wagner, president and CEO of Huntsman Architectural Group, shared this insightful remark about the future of remote work: “We believe in the power of place. This speaks to the idea that space can do more than fulfill functional needs—it helps convey values, bring people together, and empower a sense of cohesion and belonging. What’s more, space can actually become part of the cultural manifest of an organization. So, while the past year has shown us that we can positively embrace remote work, we are confident that group activities, visual and tactical work, and work that relies on an in-person sense of connection will continue to thrive in the built environment.”

His sentiments are supported by a recent study by PWC, which shares that by July 2021, “75 percent of executives anticipate that at least half of office employees will be working in the office.” So, if the future is hybrid work, what will that look like? And how do we balance human connection with function—or, perhaps more accurately, flexibility—that comes with hybrid work? We sat down with Betsy Bula, all-remote evangelist at GitLab, to discuss why hybrid work can be one of the most difficult working arrangements, and to uncover tips on how best to make the transition successful.

Recognize that a hybrid policy is the hardest.

While few companies plan to require all workers back in the office five days per week, and few are ready to continue a fully remote model forever, hybrid is actually the toughest model to balance. Bula shares that hybrid work is that in-between zone that often times blurs the lines and rules of traditional office decorum. It is very easy to prioritize those in the office—to give them more senior leadership exposure, allow them more opportunities for mentorship, and think of them first when you’re looking to handle an impromptu job request.

As she explains, “Hybrid work takes more intentionality to do it well. You must realize that you are responsible for managing different employee experiences, while being cognizant to avoid a two-tier environment where people in the office are considered a different class than people working remote.”

So, to avoid this uneven playing field, Bula shares that asynchronous communication is key to success.

Leveraging asynchronous communication is key.

In telecommunications, asynchronous communication refers to transmitting data intermittently, instead of continuously. Usually, this takes place without the use of an external clock signal. Transitioning that logic to the working world, we liken the external clock signal to the ability to get information from anywhere. In a synchronous-communication work model, a lot of emphasis is placed on working in the same place at the same time. Team members are given information in a team meeting, and then they all break away to do their work.

But in an asynchronous-communication work model, all direction is properly documented so workers can accomplish tasks wherever they are, whenever they are there. In GitLab’s 2021 Remote Work Playbook, it explains asynchronous communication like this: “In a world dictated by calendars and schedules, people are used to working synchronously—meaning that they need to be in the same place (either physically or virtually) at the same time. Another word for synchronous work: ‘meetings.’ Asynchronous communication is the art of eliminating meetings and synchronous work, making it possible to get work done on a flexible schedule.”

And although asynchronous communication allows distributed teams to hand projects off across time zones—a distinct competitive advantage—and reduces disconnects and frustrations, it also takes a lot of intentionality to do so.

Bula explains that it’s important to “try to focus on how work will get done and how your team will work together. When doing so, try to remove the location from the equation as you are thinking through that. That way you will naturally build practices that can be used no matter where your work is getting done on any given day.”

Intentionally define your culture.

Our industry does a great job of defining culture through physical space, but do we ever document our own business culture? According to Bula, combining documentation with intentionality is crucial to a successful approach. She agrees with Wagner that the office is a great place for bringing people together and speaks about the value of a project kickoff or other team bonding experience that unites everyone. Then, when the work is transitioned to a hybrid team, these steps from GitLab can help make it successful:

1. Define a culture that supports equality between remote and in-person work. One of the best ways to do this is to have senior management experience working in the remote model. Do they have communication barriers? What documentation isn’t clear? Are there any access issues?

2. Don’t try to replicate an in-person experience remotely. There are some things that just can’t be done remotely. Hosting meeting after meeting over Zoom is a recipe for Zoom fatigue. Instead, try to be strategic about meetings—if they are needed for hands-on, tactical teamwork, consider coming in to the office. If not, ask yourself if the meeting is really necessary.

3. Place an emphasis on team building. Even teams working 100 percent remotely need to come together to foster team camaraderie. GitLab suggests planning events such as coworking excursions, setting a travel budget for team members to visit one another, and even hosting local coworking days.

The GitLab playbook offers more helpful suggestions. After all, at the end of the day, Bula reminds us that the past year and a half of remote work, while mostly successful, hasn’t been a true representation of authentic hybrid work.

She concludes, “What a lot of people thought they experienced as remote work was really forced working from home due to a global pandemic. Companies that weren’t already working remotely had to transition to a remote work strategy overnight. And while society did an amazing job of adapting, the intentionality and process that takes time to develop wasn’t there. So, as leaders determine what the future of work looks like for their teams, the key to success will be creating, documenting, and iterating on these practices to determine what works best for their organization.”

Adoption of containerization technologies like Docker and Kubernetes has grown rapidly across the industry, and understanding both the benefits and the risks is essential for any DevOps team looking to move workloads into containers successfully.

Why Use Containers?

Containers change the fundamental model of software delivery. A container image bundles application code, runtime, libraries, and configuration into a single, portable artifact. Developers build the image once, test it, validate it, and then deploy it — knowing that what runs in production is byte-for-byte identical to what was tested.

This model provides several concrete advantages over traditional virtual machine (VM)-based deployments:

• Lower resource overhead: Containers share the host operating system kernel rather than running a full guest OS, so they consume significantly less CPU, memory, and storage than VMs. This allows more workloads to run on the same underlying hardware.
• Portability: A container image runs the same way on a developer’s laptop, a CI server, and a cloud provider’s managed Kubernetes cluster — eliminating the “works on my machine” problem.
• Consistent delivery pipeline: The same container image can be used at every stage of the pipeline — build, test, staging, and production — removing environment-specific surprises.
• Faster deployments and scaling: Containers start in seconds, not minutes, and container orchestrators like Kubernetes can spin up or tear down replicas automatically in response to load.
• Support for modernization: Teams can incrementally containerize legacy monolithic applications while simultaneously building new cloud-native microservices alongside them.

These qualities make containers especially valuable in hybrid and multi-cloud environments, where workloads need to move across different infrastructure providers without requiring application changes.

Containers Add Value — But Also Introduce Risk

It is important to be clear about what containers do not solve. They eliminate environment-drift problems, but they do not make software immune to bugs, outages, or security vulnerabilities.

Security Vulnerabilities in Base Images

Container images are built on top of base images — typically minimal Linux distributions — and those base images frequently contain unpatched vulnerabilities. Security research from Snyk has found that widely used public Docker images commonly carry dozens of known vulnerabilities, particularly when they have not been recently updated. Any container built on an outdated base image inherits all of those vulnerabilities.

Practical mitigations include:

• Regularly scanning images with tools such as Trivy, Snyk Container, or AWS ECR image scanning before pushing to a registry.
• Rebuilding and republishing images whenever base image updates are available.
• Using minimal base images (e.g., Alpine or distroless images) to reduce the attack surface.
• Enforcing image provenance policies so that only images from trusted, scanned registries can be deployed.

The Uniformity Risk

Containers solve the mixed-environment problem by ensuring identical software runs everywhere. This is both their greatest strength and a significant risk amplifier. If a vulnerability or misconfiguration is baked into an image, every replica instantiated from that image is equally vulnerable. An exploit that works against one container works against all of them simultaneously.

This makes rigorous image validation before deployment — not after — essential. Vulnerability scanning, image signing, and admission controllers in Kubernetes (such as OPA/Gatekeeper or Kyverno) can help enforce policy gates that prevent vulnerable images from reaching production.

The Cost of Downtime

Application outages carry real economic impact regardless of whether the underlying infrastructure uses containers or VMs. Organizations should not assume that containerization alone reduces their operational risk; it shifts the risk profile rather than eliminating it. Proper testing, observability, and incident response processes remain essential.

A Better Approach to Testing Containerized Applications

Moving to containers requires a corresponding evolution in how QA and testing are done. Simply lifting an existing testing approach and applying it to containerized apps is insufficient.

• Test under production-like conditions: Containers can behave differently depending on CPU limits, memory constraints, network policies, and storage configurations. QA environments should mirror production resource settings as closely as possible.
• Integrate security scanning into CI/CD: Vulnerability scanning should happen automatically at image build time, not as a one-off manual check. Block pipeline progression if critical vulnerabilities are detected.
• Test network behavior: Microservices running in containers communicate over the network. Test for latency, timeouts, partial failures, and retry logic — not just happy-path flows.
• Use chaos engineering: Tools like Chaos Monkey or Litmus can deliberately introduce failures (container crashes, network partitions) to verify that the system degrades gracefully and recovers correctly.
• Validate container orchestration configuration: Kubernetes manifests, Helm charts, resource quotas, and network policies are all part of the deployable artifact. Lint and test them as part of the pipeline.

Key Practices for Successfully Running Containers in Production

Beyond testing, several operational practices distinguish teams that run containers reliably in production from those that struggle:

• Run containers as non-root: Avoid running processes inside containers as the root user. Use a dedicated, low-privilege user in your Dockerfile.
• Set resource limits: Always define CPU and memory requests and limits in Kubernetes pod specs to prevent a single noisy container from starving others on the same node.
• Use health checks: Define liveness and readiness probes so that the orchestrator knows when to restart a failed container or stop routing traffic to one that is not yet ready.
• Store configuration externally: Use environment variables, ConfigMaps, or secrets management tools (such as HashiCorp Vault or Kubernetes Secrets) rather than baking configuration into images.
• Implement centralized logging and monitoring: Container logs are ephemeral. Ship them to a centralized system (e.g., ELK stack, Datadog, or CloudWatch) and instrument applications with metrics and distributed tracing.
• Maintain an image registry hygiene policy: Delete old, unused image tags regularly. Old images are security liabilities and inflate storage costs.

Containers Are Powerful — But Not a Silver Bullet

Containers genuinely improve developer productivity, deployment consistency, and infrastructure efficiency. They are one of the most impactful operational shifts a software team can make. However, they introduce their own failure modes and security considerations that teams must plan for explicitly.

The teams that get the most value from containers are those that treat image security, testing fidelity, and orchestration configuration with the same rigor they apply to application code. Containers used thoughtfully — with proper scanning, testing, resource management, and observability — enable faster, safer software delivery. Containers used carelessly can propagate vulnerabilities and misconfigurations at scale.

Invest the time to understand the risks, build the right tooling into your pipeline, and containers will become one of the most reliable parts of your infrastructure.