Virtualisation solutions vendor VMware, has announced its ‘2030 Agenda’, a decade-long commitment to address critical challenges facing the global community.

The company has created 30 measurable goals to achieve by 2030 (30×30) that are focused on three outcomes relevant to its technology and business operations: Trust, Equity and Sustainability. The vendor’s 2030 Agenda builds on VMware’s long-standing commitment to innovate for a better future.

“This year has created an even greater sense of urgency to take action on global and societal challenges so we’ve set bold goals that are core to our business and will have significant impact,” said Pat Gelsinger, Chief Executive Officer, VMware, Inc. “In many ways, Digital Transformation is the backbone to building a better world. It not only creates a resilient global healthcare system, but also helps us overcome the digital divide and decarbonises the planet. At VMware, we’re committed to building technology on a foundation of digital ethics that serves all stakeholders. We will work with our ecosystem to redefine what it means to be a force for good.”

With its technology leadership and expansive global reach, VMware is dedicated to driving tangible, measurable impact focused on three outcomes: Trust, Equity and Sustainability.

Trust: VMware envisions a future where all stakeholders are effectively safeguarded from cyberattacks threatening the digital world. By approaching innovation from a foundation of digital ethics and stewardship, and focusing on intrinsic security, privacy-by-design and transparent business practices, VMware will build and protect trust among our people, customers, partners, shareholders and communities.

Equity: VMware firmly believes that technology will play a critical role in building a digital future that is equitable, accessible and inclusive for all. From the diversity, equity and inclusion commitments to its digital workspace technologies, the company is redefining the workplace of the future. VMware is enabling distributed workforces to empower employees with equal opportunity, inclusive leadership and increased flexibility within our company and beyond. Through partnerships with academic institutions and non-profit partners, VMWare will help close the digital skills gap and make Digital Transformation more accessible for all.

Sustainability: Sustainability is core to VMware’s values and future success. As a global corporate citizen, we have an opportunity and responsibility to innovate for a more resilient world by decarbonising digital infrastructure across the customer ecosystem, value chain and its own operations. Through the collective efforts to drive net-zero emissions in its operations and intrinsic sustainability in its solutions, VMware will inspire the next generation of sustainable digital infrastructure.

“Our 2030 Agenda is transformative because our 30×30 goals are owned by our business leaders and built into everything we do—from the way we develop software and bring our solutions to market, to the way we build a culture of inclusion—and in this way we are aligning our core purpose with doing our part to create a more sustainable, equitable and resilient world,” said Nicola Acutt, Vice President, Environmental, Social and Governance (ESG), VMware. “To demonstrate our commitment, we are setting up an ESG office to partner with our business leaders and help manage our progress.”

At the 2019 DevOps World | Jenkins World conference in San Francisco, CloudBees announced the winners of its annual DevOps World | Jenkins World Awards. Fifteen organizations and individuals were recognized across three award categories: Jenkins Community Awards, CloudBees Innovation Awards, and CloudBees Channel Partner Awards.

The awards span a broad cross-section of the DevOps ecosystem — from individual open source contributors shaping the Jenkins project, to enterprise organizations executing large-scale DevOps transformations, to channel partners driving adoption in the field.

Jenkins Community Awards

The Jenkins Community Awards recognize individuals who have made significant, measurable contributions to the Jenkins open source project. Winners were selected by a panel that included Kohsuke Kawaguchi, founder of Jenkins and Chief Scientist at CloudBees, alongside the Jenkins Ambassadors — a group of annually nominated Jenkins enthusiasts who actively share their technical expertise with the broader community.

“The 2019 Jenkins Community Awards honor the efforts of community members, those who are making significant contributions to advance the Jenkins project in several key areas. The quality of the submissions this year was better than ever, across the board.”

— Kohsuke Kawaguchi, Founder of Jenkins and Chief Scientist, CloudBees

The 2019 Jenkins Community Award winners are:

• Most Valuable Jenkins Contributor — Oliver Gondža
• Jenkins Security MVP — Victor Gazdag
• Most Valuable Jenkins Advocate — Zhao Xiaojie
• Most Innovative Jenkins X Implementation — Vincent Behar

Vincent Behar’s recognition in the Jenkins X category reflects growing interest in Jenkins X, the cloud-native CI/CD solution built on Kubernetes. Behar’s work demonstrated practical continuous delivery implementations in cloud-native environments.

CloudBees Innovation Awards

The CloudBees Innovation Awards recognize organizations that have achieved outstanding results through their DevOps transformations. Winners were selected by a panel comprising Sacha Labourey, CEO and co-founder of CloudBees; Alan Shimel, editor-in-chief and founder of DevOps.com; and Aparna Sinha, Director of Product Management at Google Cloud.

“We’re pleased to have the opportunity to celebrate the outstanding achievement displayed regularly by CloudBees customers. The 2019 CloudBees Innovation Award winners are five examples of outstanding leadership in the DevOps industry.”

— Sacha Labourey, CEO and Co-founder, CloudBees

The 2019 CloudBees Innovation Award winners span organizations of widely varying sizes — from a venture-funded startup to global financial institutions and technology firms:

• DevOps Scalability Achievement — AIG
• DevOps Scalability Achievement — Accenture
• DevOps Automation Excellence — American Express Global Business Travel
• DevOps Automation Excellence — Broadridge Financial Solutions
• DevOps Rising Star (Honorable Mention) — Pinger

Notable achievements among the winners include Accenture enabling a large North American organization to accelerate deployments to production by over 90%, and Broadridge adopting a DevOps approach to rearchitect delivery of business-critical software supporting financial customer transactions. Pinger, a smaller startup, was recognized for using DevOps practices to rapidly launch new products and respond to changing market regulations.

CloudBees Channel Partner Awards

The CloudBees Channel Partner Awards were selected by the CloudBees channel team to recognize partners that demonstrated proven DevOps expertise and excelled within their respective partnership categories. Five partners were honored across regional and functional categories:

• Americas Partner of the Year — Zivra
• Rookie Partner of the Year — ThunderCat
• Channel Marketing Partner of the Year — Fierce Software
• Public Sector Partner of the Year — Fierce Software
• APAC Partner of the Year — TechMatrix

Fierce Software was notably recognized in two categories — Channel Marketing and Public Sector — reflecting strong performance across both marketing execution and government or public-sector deployments.

About the DevOps World | Jenkins World Conference

DevOps World | Jenkins World is CloudBees’ annual flagship conference, bringing together Jenkins users, DevOps practitioners, and software delivery professionals. The event serves as a major gathering point for the Jenkins open source community, as well as enterprise DevOps teams exploring continuous integration, continuous delivery, and application release orchestration (ARO) at scale.

About CloudBees

CloudBees is an enterprise DevOps platform provider focused on continuous software delivery management. The company is built on commercial products as well as open source leadership — CloudBees is the largest contributor to both Jenkins and Jenkins X, and is a founding member of the Continuous Delivery Foundation (CDF).

At the time of this announcement, CloudBees reported serving over 3,500 organizations, including more than 50% of the Fortune 500. The company was founded in 2010 by Sacha Labourey, former CTO of JBoss, and has received backing from Matrix Partners, Lightspeed Venture Partners, Verizon Ventures, Delta-v Capital, Golub Capital, and Unusual Ventures.

Jenkins Turns 15: From a Broken Build to 15.8 Million Developers

In 2004, Kohsuke Kawaguchi was a software engineer at Sun Microsystems with a habit of accidentally breaking builds. Frustrated by colleague callbacks, he asked himself a simple question: could a program catch his mistakes before his colleagues did? That question led him to create the automation server now known as Jenkins — and, in many ways, to help define the modern era of continuous integration.

Fifteen years later, Kawaguchi serves as Chief Scientist at CloudBees, the company that provides commercial support, services, and a growing product portfolio built around Jenkins. At DevOps World | Jenkins World 2019, held in San Francisco, CloudBees marked the anniversary while also making a series of significant product announcements. According to data provided by CloudBees at the event, approximately 15.8 million developers worldwide use Jenkins as part of their DevOps workflows.

What Is Jenkins?

Jenkins is an open-source automation server primarily used to implement continuous integration (CI) and continuous delivery (CD) pipelines. It enables development teams to automatically build, test, and deploy code changes, reducing manual effort and catching integration errors early. Its extensibility through a large plugin ecosystem has made it one of the most widely adopted CI/CD tools in the industry.

CloudBees Flow 9.1 and Accelerator 11.1

Jenkins is foundational to CloudBees, but the company has been expanding well beyond it. At DevOps World, CloudBees announced the 9.1 release of CloudBees Flow, its Application Release Orchestration (ARO) platform. Flow came to CloudBees through its April 2019 acquisition of Electric Cloud, which had developed the product to coordinate complex, multi-team software releases across environments and pipelines.

The same acquisition brought CloudBees Accelerator 11.1, a rebranded version of Electric Cloud’s build and test acceleration product. According to CloudBees CEO and co-founder Sacha Labourey, the tool is designed to compress long build and test cycles:

“The accelerator makes it possible to accelerate build and test from hours to minutes.”

— Sacha Labourey, Co-founder and CEO, CloudBees

Feature Flags via the Rollout Acquisition

In June 2019, CloudBees also acquired Rollout, a DevOps vendor specialising in feature flag management. Feature flags (also called feature toggles) allow teams to enable or disable specific features in production without redeploying code, enabling controlled rollouts, A/B testing, and rapid rollback. The Rollout technology was rebranded and integrated into the broader CloudBees portfolio.

Labourey described the value of the capability in terms of experimentation speed:

“With Rollout, you get to experiment, measure and observe the behavior of what you want to test. And once you’re done, you can switch it off in seconds. Remember, time is acceleration, so it’s important for you to conclude your experiments ASAP.”

— Sacha Labourey, Co-founder and CEO, CloudBees

Software Delivery Management: The Big Reveal

The headline announcement at DevOps World 2019 came on August 14 with the preview of CloudBees’ Software Delivery Management (SDM) platform. The platform aims to give both developers and engineering leadership a unified, contextualised view of the state of software delivery across an organisation — aggregating data from the many disparate tools that modern development teams use every day.

Product Hub: Centralised Visibility

At the core of the SDM platform is a component called Product Hub, described by Ben Williams, Vice President of Product Management at CloudBees, as the central orchestration point for all software delivery activity:

“The Product Hub is the heart of your software delivery efforts. It’s where all of your software delivery activity is visible and orchestrated from.”

— Ben Williams, VP of Product Management, CloudBees

The dashboard ingests data from tools including Jenkins, Jira, GitHub, and observability and monitoring platforms, then presents that data in a single place with contextual organisation. Williams described the goal as consolidating a fragmented toolchain view into a coherent delivery picture for stakeholders at every level.

Efficiency Dashboard and Policy Engine

Beyond visibility, the SDM platform includes an efficiency dashboard paired with a policy engine. The policy engine allows organisations to define and enforce process rules — for example, tracking how long a work item remained idle before progressing. This kind of flow metric is closely aligned with concepts from value stream management, helping teams identify bottlenecks and waste in their delivery pipelines.

Extensibility via an App Framework

The SDM platform is designed to connect to a wide range of DevOps and CI/CD tooling through an open app framework. According to Williams:

“The app framework allows users and partners to be able to create custom integrations, to be able to contribute policies and rules to extend the data model, and to build custom functionality.”

— Ben Williams, VP of Product Management, CloudBees

At the time of the announcement, the SDM platform was available in limited preview, with broader availability and additional integrations planned for subsequent releases.

Key Takeaways

• Jenkins at 15: The open-source CI/CD server, created in 2004 by Kohsuke Kawaguchi, had reached approximately 15.8 million developers worldwide by mid-2019.
• CloudBees Flow 9.1: Application Release Orchestration platform acquired from Electric Cloud, now integrated into the CloudBees portfolio.
• CloudBees Accelerator 11.1: Build and test acceleration tool, also from the Electric Cloud acquisition, aimed at reducing cycle times from hours to minutes.
• Rollout integration: Feature flag management capability acquired in June 2019, enabling controlled feature rollouts and rapid experimentation.
• Software Delivery Management (SDM): A new cloud-based platform previewed at DevOps World, centred on a Product Hub that aggregates delivery data, an efficiency dashboard, a policy engine, and an extensible app framework.

Original reporting by ITPro Today. Announcements were made at DevOps World | Jenkins World, San Francisco, August 2019.

CloudBees Acquisitions and the Software Delivery Management Vision

When asked about CloudBees’ acquisition strategy, Labourey was measured but confident: “We’re always actively looking at deals that make sense. To be truthful, we’ve set the bar pretty high at the moment. Not only are we focusing hard on executing on those acquisitions, we’re delivering on a vision we’ve laid out for the future in a category we call Software Delivery Management.”

Software Delivery Management (SDM) was CloudBees’ framing at the time for a broader platform vision that extended beyond CI/CD tooling — connecting engineering workflows, business outcomes, and cross-team visibility into a unified layer.

What Labourey Was Looking Forward to at the Conference

For Labourey, the value of DevOps World | Jenkins World was always fundamentally about community: “Always the same: Meeting with great people, hearing about the great innovations in the Jenkins and Jenkins X community, and really, checking out everything all these talented companies are doing. The amount of creativity and innovation we see year after year at DevOps World | Jenkins World is truly amazing.”

Diversity and Inclusion at DevOps World | Jenkins World 2019

Labourey detailed a range of diversity-focused activities CloudBees sponsored at and around the 2019 conference:

“We have supported diversity at DevOps World | Jenkins World for a very long time. We’ve tried to encourage diversity in our recruitment of speakers and in our acceptance of them. Specific to this year’s conference, on Wednesday, August 14, CloudBees is sponsoring a Women in Tech mixer. On Thursday, August 15, we’re sponsoring a Diversity and Inclusion luncheon, where a panel of speakers tackle the topic ‘Connecting Diversity and Inclusion with Business Outcomes.’”

Beyond the conference itself, Labourey outlined several ongoing CloudBees diversity initiatives:

• Hiring benchmarks: CloudBees was benchmarking its workforce diversity against industry peers, with Labourey acknowledging dissatisfaction with the results and a stated commitment to improvement.
• Partnership with PowerToFly: CloudBees was working with PowerToFly to attract more women into technical roles, including hosting a Women in Tech event at its Raleigh office in June 2019.
• Women in DevOps content: CloudBees maintained a blog series focused on Women in DevOps and held dedicated breakout sessions at previous conferences.
• Grace Hopper Conference support: CloudBees supported an internal team of women who applied to speak at the Grace Hopper Celebration, with two accepted.
• Customer Advisory Board: Female representation on the board grew from two to six members out of approximately 30 total.

Labourey was candid about the limitations of these efforts: “As positive as this is, it’s not enough and we are not satisfied with our gains in diversity. We continue to focus on this important area.”

How DevOps World Has Mirrored CloudBees’ Growth

Labourey reflected on the long arc of the industry and CloudBees’ place within it: “We’ve really witnessed it all since 2010 and before. We’ve been part of the first steps of CI, the move to the right and the quest for ever-increasing automation. We’ve seen the fantastic chain reaction where cloud has enabled organizations to do so much more in DevOps and DevOps has returned the favor, opening up so many opportunities for cloud. We are really witnessing the birth of a new tech era. It is a unique privilege for CloudBees to be part of that small group of change agents!”

Labourey’s Personal DevOps Superpower: Open Source

One conference session explored the idea of becoming a “DevOps superhero.” When asked about his own superpower, Labourey didn’t hesitate:

“That’s easy: open source. After years in the JBoss community, at Red Hat and now at CloudBees, where we are the leads on the Jenkins and Jenkins X projects, I still love open source. It is part of our DNA here at CloudBees. There is so much innovation going on in the open source communities, and the developers who are involved are so passionate about what they do. I do think, for the most part, open source developers are among the best in the developer community. They are also inclusive and really have a desire to impact the world.”

Labourey’s background is closely tied to the Jenkins project — CloudBees was co-founded by former members of the Kohsuke Kawaguchi’s extended Jenkins ecosystem — and open source stewardship remained central to the company’s identity heading into 2019.

About DevOps World | Jenkins World 2019

DevOps World | Jenkins World 2019 took place in San Francisco in August 2019. The event served as the flagship annual conference for the Jenkins open source community and the broader CloudBees ecosystem, bringing together practitioners, vendors, and contributors focused on CI/CD and DevOps automation.

CloudBees has announced the first release of the CloudBees Jenkins X Distribution — a preconfigured, commercially supported package of Jenkins X designed for enterprise teams that need a stable, predictable foundation for their Kubernetes-native CI/CD pipelines. The release comes with CloudBees-backed support plans, curated documentation, and a defined release cadence intended to shield organizations from the pace of change inherent in a fast-moving open-source project.

What Is the CloudBees Jenkins X Distribution?

Jenkins X is an open-source CI/CD solution built for Kubernetes. It automates the creation of pipelines, preview environments, and GitOps-based promotion workflows. Because it evolves rapidly, new features and fixes land frequently — but so do breaking changes and experimental behaviour that may not be suitable for production use in regulated or risk-averse organisations.

The CloudBees Jenkins X Distribution addresses this tension. Rather than tracking the bleeding edge of the OSS project, it selects the most mature and proven components, packages them into a tested and documented bundle, and releases updates on a monthly cadence. CloudBees commits to:

• Validating every release before it ships
• Publishing clear documentation for each supported feature
• Communicating upcoming changes in advance so teams can plan upgrades
• Preventing unannounced breaking changes from reaching users
• Offering commercial support plans for teams that need a vendor to escalate to

The goal is to give enterprises the confidence to commit to Jenkins X as a long-term platform choice, rather than treating it as an experimental tool.

What Is Included — and What Is Not?

The distribution deliberately does not replicate every feature available in the upstream Jenkins X project. It captures the subset of functionality that CloudBees considers ready for production use and documents it thoroughly.

At the time of the initial release, the CloudBees Jenkins X Distribution included support for:

• Google Kubernetes Engine (GKE) — the primary supported Kubernetes platform at launch
• Preview environments — ephemeral environments automatically created for pull requests

Features not yet supported in the first release included:

• Amazon Elastic Kubernetes Service (EKS) — planned for a future release
• DevPods — developer-in-a-pod workflow support, also planned for later releases

CloudBees stated that new features would be added monthly, with each addition going through testing and documentation before inclusion. Teams that need capabilities not yet in the distribution can continue to use the upstream OSS project, which remains fully available and accepts contributions.

How the Distribution Relates to Jenkins X Open Source

CloudBees positioned the distribution as complementary to — not competitive with — the Jenkins X open-source project. The company framed its reasoning around a pattern familiar from other successful open-source ecosystems: a commercially supported downstream distribution lowers the barrier to enterprise adoption, which in turn drives more real-world usage, more bug reports, more contributors, and ultimately a healthier upstream project.

From this perspective, organisations running the CloudBees Jenkins X Distribution are still running Jenkins X workloads. Their operational experience feeds back into the community’s understanding of what patterns work at scale, which strategic directions are worth pursuing, and which rough edges need the most attention. CloudBees described this as a way of growing the Jenkins X ecosystem, not fragmenting it — drawing a parallel to how Jenkins itself has been sustained by community participation over more than a decade.

For teams comfortable tracking the OSS project directly, nothing changes. The upstream Jenkins X project continues to develop at its own pace, with experimental features available as soon as they land. The distribution simply provides an on-ramp for teams that cannot — or do not want to — maintain that level of engagement with a fast-moving open-source project.

Support and Commercial Options

CloudBees offered paid support plans for organisations adopting the distribution. Support contracts provide access to CloudBees engineers when teams encounter issues, as well as SLA-backed response times that the OSS community alone cannot guarantee. This makes the distribution a viable option for organisations with procurement requirements around vendor accountability, security response, or regulated-industry compliance frameworks that mandate supported software.

Summary

The CloudBees Jenkins X Distribution occupies a familiar position in the open-source software landscape: a commercially curated and supported downstream release of a rapidly evolving community project. For DevOps teams evaluating Kubernetes-native CI/CD tooling, it represents a lower-risk path to adopting Jenkins X — one with defined release windows, documented feature sets, and a commercial support safety net. Teams that want the latest innovations should stay close to the upstream OSS project; teams that need stability and accountability have a clear alternative.

Note: This article is based on the original CloudBees announcement from August 2019. Product availability, supported platforms, and commercial terms may have changed significantly since then. Consult current CloudBees documentation for up-to-date information.

DevOps World | Jenkins World is widely regarded as one of the premier annual conferences for DevOps practitioners and Jenkins users. Every year it brings together thousands of engineers, architects, and leaders for sessions, hands-on training, keynotes, and networking. But knowing you want to attend is only half the battle—you still need to get your manager on board with the budget and travel approval.

Below are six concrete arguments you can bring to that conversation, framed around the measurable value the conference delivers—to you and to your organization.

1. You Can Pursue Recognized DevOps Leadership Certification

DevOps is as much a cultural discipline as it is a technical one, and organizations consistently struggle to find people who can champion that culture internally. The conference offers structured courses—including a DevOps Leader track—designed to equip attendees with the skills needed to sit the DevOps Leader certification exam.

Beyond that single certification path, training sessions at the event have historically covered DevSecOps practices, Continuous Delivery with Jenkins X, and operational best practices for CloudBees Core. Attending puts you on a credentialed path that benefits you professionally and gives your team a recognized internal subject-matter expert.

Talking point for your manager: A certified DevOps leader on the team reduces reliance on external consultants and accelerates adoption of mature DevOps practices across projects.

2. You’ll Return with Sharper Automation and CI/CD Skills

If your organization uses Jenkins, practical expertise in pipeline design, administration, and troubleshooting directly affects delivery speed and reliability. The conference runs introductory through intermediate sessions on Jenkins administration and Jenkins Pipeline that are explicitly structured to build on one another—so learners leave with a coherent, progressive skill set rather than isolated tips.

The training curriculum has also been aligned with the Certified Jenkins Engineer (CJE) exam, meaning attendance can be a direct step toward a formal credential. Additional sessions typically cover automated release orchestration and widely adopted DevOps toolchains, giving you cross-tool perspective you can apply immediately.

Talking point for your manager: Skills acquired at the conference can be applied on day one back at the office—reducing pipeline failures, improving build reliability, and shortening onboarding time for new team members.

3. You’ll Learn Directly from Industry Leaders and Jenkins Core Contributors

Reading documentation or watching recorded talks is useful, but it is a fundamentally different experience from hearing an expert speak live and being able to ask a question afterward. DevOps World | Jenkins World has featured keynotes and sessions from notable figures including Jenkins creator Kohsuke Kawaguchi, CloudBees CEO Sacha Labourey, and analysts such as James Governor of RedMonk.

The access to primary voices in the ecosystem—people who are actively shaping the direction of Jenkins and the broader DevOps toolchain—is difficult to replicate through any other channel. Insights from those conversations often provide early signals on where the ecosystem is heading, giving your team a strategic advantage in tooling decisions.

Talking point for your manager: First-hand access to ecosystem leaders surfaces roadmap signals and emerging best practices that inform better architectural decisions at your organization.

4. You’ll Gain a Broader Perspective on DevOps in Practice

With more than 100 sessions available across a typical conference program, attendees can move well beyond their existing focus area. Topics have ranged from DevOps culture theory versus practice, to DevOps adoption in the public sector, to machine learning in continuous delivery environments. Case studies from organizations in different industries—automotive, telecommunications, financial services—provide concrete examples of how real teams have solved problems similar to yours.

This breadth of perspective is hard to find in any single book, course, or internal training session. Exposure to how other industries and organizations approach the same challenges frequently surfaces ideas that are directly transferable to your context.

Talking point for your manager: You can return and run an internal knowledge-sharing session, turning conference attendance into a multiplier for the whole team rather than a benefit to a single individual.

5. You’ll Build a Professional Network That Benefits Your Organization

Concentrating thousands of DevOps practitioners in one venue creates networking density you cannot replicate online. Attendees share war stories, debate tooling choices, and swap contact information. That network has practical organizational value: the next time your team hits a difficult problem—a tricky Jenkins configuration, an edge case in a pipeline framework, a staffing gap—you may have a direct line to someone who has already solved it.

Professional relationships built at conferences also tend to be stickier than LinkedIn connections because they are rooted in shared, in-person experience. Those contacts become long-term resources: people who will respond to a direct message, share internal documentation, or point you toward a solution faster than a support ticket will.

Talking point for your manager: A strong peer network reduces time-to-resolution on complex technical problems and can surface candidate referrals when you are hiring for specialized roles.

6. You Can Structure Your Attendance to Generate Direct ROI

The most persuasive argument for any conference investment is a plan that ties specific sessions and goals to specific organizational pain points. Before you approach your manager, do the work: identify the top two or three challenges your team is facing—whether that is slow release cycles, pipeline reliability, security integration in CI/CD, or something else—and map those to sessions on the conference schedule.

Come to the conversation with a brief written plan: here are our current pain points, here are the sessions and training tracks I intend to attend, here is how I plan to share what I learn when I return. That framing transforms the trip from a personal benefit into an organizational investment, which is a much easier approval to get.

Talking point for your manager: A clearly scoped attendance plan with defined learning objectives and a post-conference knowledge transfer session demonstrates accountability and turns conference spend into a team-level asset.

Putting It All Together

No single argument on this list is likely to secure approval on its own—but together they build a coherent case that addresses the concerns most managers raise: cost, time away, and uncertain return on investment. Lead with the certification and skills story, reinforce it with the knowledge-transfer plan, and close with the networking value. That combination covers technical, operational, and strategic angles, and gives your manager concrete justification to approve the trip.

Why Kubernetes Has Become Central to Multi-Cloud Strategy

Kubernetes has moved well beyond experimental status. IT leaders across industries are deploying it in mainstream production environments, using it to bridge on-premises infrastructure with public cloud platforms. A significant driver of this adoption is that major cloud providers — AWS (Amazon EKS), Microsoft Azure (AKS), and Google Cloud (GKE) — have all embraced Kubernetes and offer it as a managed service. This lowers the barrier to entry, allowing teams to experiment incrementally and scale consumption on a pay-as-you-go basis.

The result is a growing ecosystem of tooling, community knowledge, and integrations that continues to accelerate enterprise digitalization. But with opportunity comes complexity. As Kubernetes use cases expand, three considerations stand out for teams operating in multi-cloud environments.

1. Evolving IT and Developer Roles Demand a New Operating Model

The shift to multi-cloud and multi-cluster Kubernetes environments has fundamentally changed what IT operations teams manage. Applications are increasingly decomposed into microservices and packaged as containers — but not all workloads are ready for containerization at the same pace. This means IT teams often manage hybrid environments where containerized and non-containerized workloads coexist, sometimes across multiple clusters and clouds simultaneously.

For application developers, Kubernetes introduces genuine workload portability. Because it operates as a consistent abstraction layer across public and private cloud infrastructure, developers can target Kubernetes APIs regardless of the underlying provider. Combined with a large open-source community, rich documentation, and widely available tutorials, this portability increases developer velocity and reduces friction when moving workloads between environments.

The practical implication: both operators and developers need to upskill. Platform engineers need to understand multi-cluster networking, policy management, and federated workload scheduling. Developers need enough operational awareness to write applications that take advantage of Kubernetes primitives — health checks, resource limits, rolling deployments, and service discovery — from the start.

2. The Network Security Surface Area Is Expanding

Running containers in production — especially on bare metal — pushes the boundaries of what traditional networking and security tooling was designed to handle. Container workloads are ephemeral, horizontally scaled, and communicate extensively over internal service meshes. Each microservice boundary is a potential attack surface, and in large deployments those surfaces multiply rapidly.

Kubernetes is designed for continuous delivery, zero-downtime deployments, and high availability. These are valuable operational properties, but they also mean the environment is in constant flux — pods spin up and down, IP addresses change, and network policies need to reflect the current state of the cluster at all times. Static, perimeter-based security models are inadequate in this context.

Security teams working with Kubernetes environments should focus on several layers:

• Pod security: Use Pod Security Admission (or equivalent policies) to restrict what containers can do at runtime.
• Network policies: Define explicit ingress and egress rules between namespaces and services using Kubernetes NetworkPolicy resources or a CNI plugin that supports fine-grained policy (e.g., Calico, Cilium).
• Image security: Scan container images for known CVEs before they reach production. Implement admission controllers to block non-compliant images.
• Secrets management: Avoid storing secrets in environment variables or ConfigMaps. Use a dedicated secrets manager and integrate it with the cluster via a CSI driver or sidecar.
• Audit logging: Enable Kubernetes API audit logs and ship them to a central SIEM for anomaly detection.

As microservice architectures grow, mutual TLS (mTLS) between services — often implemented via a service mesh such as Istio or Linkerd — becomes an important defense-in-depth measure, encrypting and authenticating east-west traffic inside the cluster.

3. DevOps Adoption Is Accelerating — and Kubernetes Is a Catalyst

DevOps aims to unify application development and operations across the full software lifecycle: planning, coding, building, testing, releasing, deploying, operating, and monitoring. Kubernetes contributes directly to this goal by providing a common substrate that both developers and operators can target, removing the “it works on my machine” problem at the infrastructure level.

Practically, this means developers can use the same Kubernetes manifests or Helm charts across local development environments, CI pipelines, staging clusters, and production — reducing environment drift and accelerating release cycles. Operators, in turn, gain standardized interfaces for observability, scaling, and rollback rather than managing bespoke deployment scripts per application.

The growing Kubernetes ecosystem reinforces this collaboration. Tools like Argo CD and Flux bring GitOps workflows to cluster management. Prometheus and Grafana provide a consistent monitoring stack. Tekton and other Kubernetes-native CI systems let teams define pipelines as code in the same repositories as their applications. This convergence gives DevOps teams a coherent, auditable, and repeatable delivery pipeline from code commit to production.

Looking Ahead: Kubernetes as Enterprise Infrastructure

Kubernetes is no longer a cutting-edge experiment — for many enterprises it is foundational infrastructure. As adoption matures, the ecosystem of tools, managed services, and community knowledge will continue to expand, making it easier for organizations at every stage of the journey to adopt and operate it effectively.

For IT leaders planning their multi-cloud strategies, the three considerations above are not one-time checkboxes. They require ongoing attention as cluster scale grows, as new workloads are onboarded, and as the threat landscape evolves. Organizations that invest in the operational discipline to manage Kubernetes well — across roles, security, and DevOps culture — will be better positioned to deliver software faster and more reliably across both private and public cloud environments.

Google Bets Big on Business Intelligence

Despite heavy investment and continued product innovation, Google Cloud has long trailed Amazon Web Services and Microsoft Azure for market share, sitting at a distant third place. When Thomas Kurian took over leadership of Google Cloud, one of his earliest and most aggressive moves was acquiring Looker — a deal reportedly valued at $2.6 billion, making it one of the largest acquisitions in Google’s history.

“It’s a very smart deal for Google,” said Jake Stein, SVP of Stitch at Talend at the time of the announcement. “It’s a great indicator and testament to the value of technologies embracing a multi-cloud future.”

What Looker Built — and Why It Mattered

Founded in 2011, Looker set out to solve a problem that was becoming critical for data-driven organizations: as businesses accumulated massive volumes of data from enterprise applications, social networks, and IoT devices, extracting actionable, real-time insights remained painfully difficult. Fragmented IT infrastructure and poorly integrated tools often produced what practitioners called “Frankenstacks” — brittle, hard-to-maintain data pipelines that slowed decision-making.

Looker’s response was a next-generation Business Intelligence (BI) platform built around two core design decisions:

• In-database architecture: Rather than extracting and loading data into a proprietary datastore, Looker connects directly to cloud data warehouses — including Amazon Redshift, Snowflake, Google BigQuery, and Microsoft SQL-based platforms — querying data where it already lives.
• LookML: Looker created its own modeling language, LookML, which abstracts complex SQL into reusable, version-controlled business logic. This lowered the barrier for analysts who lacked deep SQL expertise while giving data engineers a consistent way to define metrics.

By the time of the acquisition, Looker had grown to more than 1,700 customers — a strong commercial footprint that Google was, in part, buying along with the technology.

Why the Deal Made Strategic Sense for Google

Looker and Google shared meaningful common ground before any deal was signed. Both companies operated cloud-native architectures, and the two reportedly had approximately 350 customers in common — including major media and marketing organizations like WPP, Hearst, and BuzzFeed.

The strategic upside extended beyond the existing customer overlap. Google’s AI and machine learning capabilities — embedded across products like BigQuery ML and Vertex AI — represented a natural integration path with Looker’s analytics layer. Combining Looker’s semantic modeling with Google’s ML infrastructure could allow organizations to move from descriptive reporting to predictive and prescriptive analytics within a single platform.

“The pace and scale at which analytics workloads are moving to the cloud has been unrelenting, and the size of Google Cloud’s acquisition of Looker is a prime example of this market shift,” said Adam Wilson, then-CEO of Trifacta. “The early days of cloud computing were driven by developers building and hosting applications on the cloud, but today’s growth opportunities in cloud are focused on analytics, machine learning, and AI.”

Industry Disruption: A Signal for Tableau, Qlik, and Others

Many industry observers interpreted the acquisition as a signal that the era of standalone visualization tools was ending. Traditional BI vendors built their businesses on desktop-centric, on-premises deployments. The Google-Looker combination represented a different model entirely: cloud-first, API-driven, and deeply integrated with data infrastructure.

“Google’s acquisition of Looker is validation that the age of pure-play visualization tools is over,” said Ajeet Singh, co-founder and executive chairman of ThoughtSpot. “Businesses need agility to compete in a digital world, and the older generation of tools like Tableau and Qlik are holding them back.”

It is worth noting that Tableau was itself acquired by Salesforce shortly after the Looker deal was announced — an indication of how rapidly the BI consolidation wave was moving across the industry at the time.

The Risks: What Could Go Wrong

Large acquisitions frequently stumble, and the Google-Looker deal came with a meaningful list of risks that analysts and practitioners flagged at the time.

Vendor Lock-In Concerns

One of Looker’s key selling points had always been its multi-cloud, warehouse-agnostic approach. Existing customers running Redshift or Snowflake had legitimate concerns that Google might gradually optimize Looker for BigQuery, limiting feature access or performance for non-Google data warehouses. Preserving Looker’s neutrality would be critical to retaining customers who were not already Google Cloud customers.

Regulatory Scrutiny

At the time of the announcement, Google was already facing scrutiny from U.S. regulators exploring potential antitrust investigations into major technology platforms. Regulatory approval of large acquisitions — particularly in sectors involving data — was no longer a formality, and the deal required careful navigation of that environment.

Integration Execution

M&A integration is notoriously difficult. Engineering culture, product roadmap alignment, and go-to-market coordination all need to work in practice — and large acquirers have a mixed track record of preserving the qualities that made an acquired product successful in the first place.

The Open-Source Opportunity

The acquisition also opened a conversation about open-source alternatives to proprietary BI tooling. If Looker became more tightly coupled to the Google ecosystem, organizations prioritizing data independence might look elsewhere.

“Overall we believe that anyone should be able to make sense of data without having to write complex business queries,” said Danielle Morrill, then-General Manager of Meltano at GitLab. “With the acquisition of Looker, there is a lot of conversation about the open-source data analytics space. As Looker is proprietary, we believe this is the right time to develop an open-source alternative that helps users define reusable business logic to allow everyday people to consume data for business purposes.”

Projects like Meltano, Apache Superset, and Metabase were among the open-source tools that gained attention in this context — though their maturity and enterprise readiness varied significantly at the time.

Key Takeaways for BI and Data Engineering Teams

• Cloud-native BI is the direction of travel. The deal underscored that modern BI platforms are expected to connect directly to cloud data warehouses rather than maintaining separate data stores.
• Semantic layers matter. LookML’s approach — defining reusable, version-controlled business logic — influenced how the broader data community thinks about metric consistency and governed analytics.
• Multi-cloud neutrality is a competitive differentiator. For Looker, its warehouse-agnostic design was central to its appeal. How Google managed that positioning post-acquisition was a key thing to watch.
• Consolidation creates opportunity for alternatives. Every major BI acquisition historically has shifted some portion of the market toward open-source or independent vendors.

This article covers the state of the Google-Looker deal as reported at the time of the June 2019 announcement. Post-acquisition product developments are not covered here.

Innovation in tech is not always about chasing the newest framework or the hottest cloud service. Sometimes it comes from questioning a long-standing workflow, hiring differently, or applying a familiar pattern — such as continuous delivery — to an unexpected domain like hardware. Leaders at nine Chicago-based tech companies explained how they keep their teams sharp, what engineering practices they rely on, and which trends they were watching heading into the 2020s.

1. Guaranteed Rate — Continuous Improvement of Core Product

Company focus: Digital mortgage origination and processing.

Founder and CEO Victor Ciardelli said Guaranteed Rate has invested heavily in proprietary technology since its founding in 2000. In 2015 the company launched what it described as the first online lock-to-close mortgage processing engine. Rather than treating that launch as a finish line, the engineering team continued iterating on speed and usability.

“We’re always working to make our existing technology better and exploring new tech to make us more efficient and ahead of the curve. It’s all about changing the future of homebuying.”

— Victor Ciardelli, Founder & CEO, Guaranteed Rate

Key takeaway: First-mover advantage means little without sustained iteration. Guaranteed Rate’s approach treats the initial launch as a baseline and treats every subsequent release as an opportunity to close the gap between what customers tolerate and what they actually want.

2. IMC Trading — Bringing Software CI/CD Practices to Hardware

Company focus: Technology-driven trading across 100+ regulated international platforms.

Hardware Engineering Team Lead Rob (last name not provided in the source) described a deliberate effort to apply software-world release discipline — verification automation, integration testing, and fast feedback loops — to the FPGA (field-programmable gate array) development process, which traditionally moves far more slowly than software delivery.

“We heavily invest in verification, release and integration automation in ways that you just don’t see in the larger hardware world yet.”

— Rob, Hardware Engineering Team Lead, IMC Trading

The team was also evaluating Bazel, Google’s open-source build system, to accelerate FPGA build caching and iteration cycles.

Key takeaway: DevOps principles — automated testing, incremental releases, fast feedback — are not exclusive to software. Trading firms and other latency-sensitive hardware shops are beginning to apply the same discipline to HDL development pipelines.

3. HealthJoy — Microservices, the Strangler Pattern, and Distributed Team Tooling

Company focus: Employee healthcare benefits guidance platform.

VP of Engineering Sajal Dam outlined a three-layer approach to staying current: architectural patterns, DevOps practice, and culture.

• Strangler pattern: Rather than risky big-bang rewrites, HealthJoy incrementally replaces legacy components by routing traffic to new microservices while keeping the old system in place until it can be safely retired.
• Technical debt cadence: Agile planning explicitly budgets time for paying down debt alongside feature work.
• CI/CD pipeline improvements: Dam was evaluating new plugins to improve build, test, and deploy stages.
• Container orchestration: The team was analyzing multiple Docker orchestration tools to handle dynamic scaling, service discovery, monitoring, and maintenance of their SaaS platform.
• Collaboration tooling: New development tools were being evaluated specifically for distributed engineering teams.

“Using DevOps best practices, we minimize the risks in regularly upgrading and deploying new technologies.”

— Sajal Dam, VP of Engineering, HealthJoy

Key takeaway: The strangler pattern and microservices architecture give teams a safe path to modernisation. Pairing that with rigorous CI/CD and explicit debt-reduction sprints reduces the accumulation of risk over time.

4. Kin Insurance — Talent First, Technology Second

Company focus: Data-driven home insurance platform.

Co-founder and CTO Lucas Ward argued that the most important engineering decision a company makes is a hiring decision, not a technology decision.

“We don’t chase trends, we chase talent. Your tech is only as good as the people implementing it.”

— Lucas Ward, Co-founder & CTO, Kin Insurance

Once strong people are in place, Ward said, tools like Looker (analytics) and Segment (customer data infrastructure) give operational teams the insight to iterate on customer-facing workflows without blocking core engineering from building complex, domain-specific systems such as Kin’s own policy administration system — the internal platform handling underwriting, rating, billing, and accounting.

The team was also exploring machine learning for catastrophic risk prediction, and anticipated that smart-home data would eventually feed into more granular insurance products.

Key takeaway: Separating operational tooling (off-the-shelf analytics and data pipelines) from domain-specific engineering (proprietary insurance systems) lets talented generalists move fast in one layer while specialists go deep in another.

5. CityBase — Hackathons, Conferences, and Canary Deployments

Company focus: Digital payment and engagement services for government agencies and utilities.

Director of Engineering Mike Awine emphasised that sustainable innovation requires diverse input, not a single visionary. Concrete practices CityBase uses include:

• A multi-day, companywide hackathon to surface ideas from across the organisation.
• Sponsoring engineers to attend conferences such as ElixirConf.
• Open sharing of articles and conference talks internally.
• Transparency around company goals so individuals can make well-informed decisions.

On the engineering side, the team was building toward canary deployments — releasing changes to a small subset of traffic before full rollout — supported by improved monitoring and instrumentation in their CI/CD pipeline.

“Navigating a perpetually changing business and technology landscape requires the diversity of thought of many people, not just a single person.”

— Mike Awine, Director of Engineering, CityBase

Key takeaway: Canary deployments require investment in observability before they deliver value. CityBase’s path — improve monitoring first, then enable progressive delivery — reflects a pragmatic sequencing of DevOps maturity.

6. Narrative Science — Revenue Operations and Conversational Marketing

Company focus: Natural language generation platform that converts structured data into plain-English narratives.

COO Nick Beil highlighted an organisational innovation alongside the technical one: merging marketing, sales, and customer success into a unified revenue operations function so that the customer journey is handled with a single coherent strategy rather than handoffs between siloed teams.

On the product side, the company deployed its own NLG technology internally — a tool called Lexio that converted Salesforce pipeline data into plain-English stories delivered by email, enabling non-technical staff to understand sales performance without querying dashboards.

“Our entire team gets stories emailed to them from Lexio as if an analyst was sending them in real time. It’s spurred a continuous internal dialogue about our business performance.”

— Nick Beil, COO, Narrative Science

Key takeaway: Dogfooding your own product is one of the most credible forms of product validation. It also forces the product team to experience the friction that external customers face.

7. Foxtrot — Build vs. Buy Discipline in a Fast-Growing Startup

Company focus: Tech-enabled retail and delivery service for food, beverages, and goods (Built In Chicago profile).

CTO and co-founder Taylor Bloom described a pragmatic framework for technology decision-making: understand popular trends and tools thoroughly, but resist the temptation to adopt them unless they are genuinely the best fit for the problem at hand.

“It’s important to be able to understand if it’s worth actually building something, or if we can adapt a tool off the shelf to meet our needs and save time.”

— Taylor Bloom, CTO & Co-founder, Foxtrot

The engineering team was applying machine learning to two specific problems: personalised product recommendations and courier fleet routing — both areas where proprietary models can produce a measurable competitive advantage over generic solutions.

Key takeaway: The build-vs-buy question has no universal answer. In fast-moving startups, off-the-shelf tools preserve engineering capacity for the problems that genuinely differentiate the product. ML for routing and recommendations is one area where custom models can outperform generic SaaS, making it a reasonable candidate for in-house development.

8. Builtout — Early-Career Internships and Bottom-Up Technology Adoption

Company focus: Marketing and communications platform for commercial real estate operators.

Director of Engineering Alan Spadoni shared two unconventional practices. First, rather than targeting junior or senior university students for internships, Builtout recruits freshmen and sophomores — the reasoning being that the pace of self-directed learning has outpaced the traditional degree timeline, and early recruitment builds loyalty before larger companies can compete.

Second, technology adoption is driven bottom-up: individual engineers investigate frameworks and present findings to the wider team. The article cites an engineer-led evaluation of Vue and React for the front end, and exploration of adding Elixir to the backend stack.

“We encourage people to learn, try things out and teach the rest of the team.”

— Alan Spadoni, Director of Engineering, Builtout

Key takeaway: Bottom-up technology evaluation distributes the cognitive load of staying current across the whole team. It also increases buy-in — engineers who championed a technology are more likely to use it well.

9. Avail — Mobile-First Design Driven by Observed User Behaviour

Company focus: Property management and rental platform for landlords and tenants (Built In Chicago profile).

Co-founder and CEO Ryan Coon described a shift in product strategy driven entirely by observed usage data rather than assumption. When analytics showed that landlords continued using the platform on desktop while renters had moved predominantly to mobile devices, the team split the product approach: desktop-first for the landlord-facing interface (designed to shrink to mobile), and mobile-first for the renter-facing interface (designed to expand to desktop).

“We stay ahead of the curve by keeping the customer at the center of every decision we make.”

— Ryan Coon, Co-founder & CEO, Avail

Looking ahead, the team was exploring how gig-economy on-demand workforce models could be applied to property maintenance — one of the highest-friction pain points in the rental cycle.

Key takeaway: Different user personas within the same product can have radically different device preferences. Treating the platform as a single responsive interface can produce a mediocre experience for everyone. Segmenting by persona and designing intentionally for each is more work but produces significantly better outcomes.

Common Themes Across All Nine Companies

Despite operating in very different domains — fintech, trading, healthcare, insurance, government services, NLG, retail, real estate, and proptech — these Chicago engineering leaders converged on several recurring principles:

• People over tools: Multiple leaders stated explicitly that hiring the right people matters more than selecting the right technology stack.
• Incremental modernisation: Patterns like the strangler pattern, canary deployments, and continuous delivery were preferred over big-bang rewrites.
• Machine learning for domain-specific problems: ML appeared in use cases ranging from risk modelling and fleet routing to product recommendations and workflow automation — always applied to a specific business problem rather than adopted speculatively.
• DevOps as a cultural practice: CI/CD, observability, and automation were treated as ongoing disciplines rather than one-time implementations.
• Bottom-up innovation: Hackathons, conference sponsorships, and engineer-led technology evaluations were used to distribute responsibility for staying current across the organisation.

Original interviews sourced from Built In Chicago. Company details reflect the state of each organisation as of mid-2019.