VMware is buying Mesh7. The virtualization giant’s latest acquisition secures cloud-native applications and microservices by monitoring application behavior at the API layer.
The acquisition is part of VMware‘s efforts to make modern applications more secure. Once the deal closes, the Mesh7 technology will enable VMware to bring visibility, discovery and better security to APIs.

Mesh7 API Security Mesh provides application and API layer visibility to remove any blind spots within distributed and cloud-native application environments. It does so in a frictionless manner while being agnostic to the platform, cloud, environment and workload type.

VMware isn’t disclosing financial details of the transaction.

More Value for VMware Partners
Tom Gillis is senior vice president and general manager of VMware’s networking and security business unit.
“The value partners bring to customers is in helping them drive their app and cloud transformations,” he said. “This means having access to a modern set of capabilities for connecting and protecting modern apps that span multicloud environments.”

VMware is building a set of modern application connectivity services, Gillis said. That allows partners to bring more value to customers.

In time, partners will be able to offer the combination of Tanzu Service Mesh and Mesh7 to give developers and security teams a better understanding of when, where and how APIs are communicating. That’s even across multicloud environments, enabling better DevSecOps.

“VMware is continually working to help partners capture the customer opportunity for multicloud and app modernization,” Gillis said. “This is guided by the belief that a better developer experience leads to more secure operations. After close, the tight integration of Mesh7’s contextual API behavior security solution with Tanzu Service Mesh will deliver high-fidelity understanding of which applications components are talking to which APIs.”

In time, VMware plans to roll out an overall API solution, he said. It will make the developer experience for APIs more secure by default and easy to operate.

Upon close of the acquisition, the Mesh7 team will join VMware and help deliver the overall API solution, Gillis said.

GitLab Patches Nine Bugs in Rapid Follow-Up Release

GitLab shipped a patch update shortly after its 11.11.2 release to address nine regressions and bugs affecting both the Community Edition (CE) and Enterprise Edition (EE). The rapid turnaround underscores GitLab’s practice of pushing fixes quickly rather than bundling them into the next monthly release cycle.

What Was Fixed

• GitHub project import failure: A problem with recommended settings was causing imports of GitHub projects to fail. The patch corrects the misconfigured defaults responsible for the breakage.
• OpenID Connect 404 errors: Two related issues with OpenID Connect were triggering 404 errors whenever a name argument was absent from the request. Both problems were resolved in this update.
• Broken “Create Merge Request” button (CE): In the Community Edition, the button to create a merge request from the group and project security dashboards was non-functional. This fix restores expected behavior for teams relying on the security dashboard workflow.

All nine fixes apply across both editions unless otherwise noted, making the update relevant to the full GitLab user base regardless of licensing tier.

GitLab Ultimate Comes to the AWS Marketplace

Alongside the patch release, GitLab announced that GitLab Ultimate is now available for purchase directly through the AWS Marketplace. The listing gives AWS customers a convenient billing path: the cost of GitLab licenses can be consolidated into their existing monthly AWS bill rather than managed through a separate vendor relationship.

Customers who opt into the AWS Marketplace Product Support Connection program can also receive support directly from GitLab through that channel, streamlining the support experience for teams already invested in the AWS ecosystem.

What GitLab Ultimate Includes

GitLab Ultimate sits at the top of GitLab’s commercial tier, adding a range of advanced capabilities on top of the Premium plan. Security-focused features are a major differentiator at this tier, including:

• Container scanning – identifies vulnerabilities in Docker images as part of the CI pipeline.
• Dependency scanning – checks project dependencies for known security issues.
• Security dashboards – aggregated views of vulnerability findings across groups and projects.
• Advanced Epics – enhanced planning features for managing large bodies of work across multiple teams and milestones.

License Scope and Larger Deployments

The initial AWS Marketplace listing covers up to five licenses, designed to let smaller teams or new adopters get started quickly without a lengthy procurement process. Organizations that need to deploy GitLab Ultimate at larger scale are directed to contact the GitLab sales team directly for volume licensing discussions.

The Strategic Context: GitLab, AWS, and the CI/CD Landscape

The AWS Marketplace listing is a practical business move, but it also highlights the nuanced position DevOps tooling vendors occupy when partnering with major cloud providers. AWS has the technical capability to build deeply integrated CI/CD offerings of its own — and its closest hyperscaler rival, Microsoft Azure, already does exactly that with Azure DevOps, backed by its ownership of GitHub.

For GitLab, distribution through AWS Marketplace lowers the barrier to adoption for cloud-native teams while preserving GitLab’s identity as a multi-cloud, platform-agnostic DevOps solution. The partnership extends GitLab’s reach without ceding control of the product roadmap or customer relationship — a balance many independent software vendors must carefully manage as cloud provider influence grows.

Upgrade Recommendations

If you are running GitLab 11.11.1 or 11.11.2, applying the latest patch release is recommended to resolve the GitHub import, OpenID Connect, and security dashboard issues documented above. Refer to the official GitLab release page for upgrade instructions specific to your installation type (Omnibus, source, or Helm chart).

Background: Why a Separate Technical Conference?

The Agile movement has firmly taken hold in software development. Standups, user stories, and sprints are now standard vocabulary across most engineering teams. Yet over roughly four years, the flagship Agile Alliance conference — which grew from around 900 to 1,500 attendees during that period — steadily reduced its technical content. The DevOps track continued to grow, but sessions on programming and testing drew smaller audiences. Fewer technical practitioners attended, fewer attended technical sessions, and organizers responded by scheduling fewer technical talks the following year — a self-reinforcing cycle.

Something had to change. In 2016, the Agile Alliance launched the Agile Alliance Technical Conference (AATC) as a dedicated venue for practitioners who wanted to go deep on engineering craft rather than process or management frameworks.

What Happened at AATC 2017?

The 2017 edition was held in Boston and drew approximately 300 attendees. The opening keynote was delivered by Ron Jeffries and Chet Hendrickson, two of the original signatories of the Agile Manifesto and long-time advocates of Extreme Programming (XP). They performed the bowling game kata — a form of deliberate practice in which a programmer (or pair) solves a well-defined problem repeatedly to build muscle memory for a specific skill.

In this case, the skill was test-driven development (TDD). Along the way, the two discussed code quality, sustainable pace, pair programming, and what “modern” Agile engineering looks like in practice. Because Jeffries and Hendrickson bring fresh nuance to the kata each time they perform it — despite having done it for over a decade — it still resonated as genuinely new material with the audience.

Other sessions at AATC 2017 covered:

• A keynote on Extreme Programming, celebrating its twentieth year as a methodology
• Fundamentals of test-driven development
• Practical refactoring techniques
• Writing and maintaining clean code

Notably absent from the three-day agenda: stories, standups, sprints, or discussions of trendy infrastructure tooling. The conference was deliberately focused on coding craft.

The Technical Renaissance: Are Agile Engineering Practices Going Mainstream?

At first glance, the fact that a technical conference needs to re-teach TDD and refactoring — practices that have existed for twenty-plus years — can look like a failure. It could be read as evidence that the industry is “post-Agile” in the worst sense: teams adopted the ceremonies while abandoning the hard technical disciplines.

But there is a more optimistic interpretation. Linda Cook, an Agile Alliance board member, explained the conference’s intent the evening before it opened: the AATC was designed to reach a different audience — practitioners who were not plugged into the conference circuit, who had not been exposed to XP or TDD through the usual channels, but who were hungry to learn and improve their craft.

Filling a hotel ballroom in Boston with developers eager to learn TDD and refactoring suggests something important: Agile technical practices may finally be reaching the mainstream, rather than remaining the province of a small community of early adopters.

The Diffusion of Innovation Lens

Sociologist Everett Rogers’ diffusion of innovation model describes how new ideas spread through a population across five groups:

• Innovators — create and experiment with new ideas
• Early Adopters — willing to try things with minimal evidence
• Early Majority — adopt after seeing others succeed
• Late Majority — adopt once a practice is well established, often under peer pressure
• Laggards — adopt only when the old approach is no longer viable, or not at all

Viewed through this model, the AATC audience looked like the early and late majority arriving for Agile engineering practices. These were not the innovators who invented TDD in the 1990s, nor the early adopters who championed XP in the 2000s. They were developers at mainstream organizations who had heard about these practices, sensed they were falling behind, and wanted structured help getting started.

Seeing 300 peers — all at different stages of the same journey — in one room is a powerful signal. It validates that the struggle is common, and that the practices are learnable. That is precisely the environment in which a late majority adopts a new approach.

Proto-Agile, Agile, and Post-Agile: Where Does the Industry Stand?

Each morning at AATC, a small group gathered for Lean Coffee — an open-agenda conversational format where participants propose topics, vote on priority, and then discuss in time-boxed rounds. One recurring theme was the state of technical practices: specifically, “Is Extreme Programming dead?”

Woody Zuill, a well-known practitioner and pioneer of Mob Programming, offered a useful three-stage framework at the table:

• Proto-Agile: “We know what we had before isn’t working, and we are discovering new things.”
• Agile: “We actually understand these modern methods and do them well.”
• Post-Agile: Continuing to innovate beyond established Agile practice — not abandoning it.

Zuill’s position was direct: XP cannot be dead, because he uses it every day. “Post-Agile” in the healthy sense means teams have internalized the core practices so deeply that they no longer need to label them — not that they have abandoned them in favor of stand-up theater.

What This Means for Engineering Teams

The signal from AATC 2017 is nuanced but important for anyone leading or working on a software engineering team:

• TDD, refactoring, and clean code are not niche or outdated — they are skills that a large segment of the industry is actively trying to acquire right now.
• The gap between process adoption and technical discipline is real. Many teams run sprints but do not practice continuous integration, TDD, or refactoring. Closing that gap is one of the highest-leverage investments an engineering organization can make.
• Deliberate practice works. Katas, pair programming exercises, and structured code review are how these skills transfer — not just by reading about them.
• “Post-Agile” is not an excuse to stop improving. If your team has abandoned technical practices in the name of pragmatism, the AATC data suggests you are likely in the early or late majority who have adopted Agile ceremonies without the engineering foundation that makes them effective.

Conclusion

The Agile Alliance Technical Conference 2017 offered a clear-eyed snapshot of where the industry stands: technical practices like TDD, refactoring, and clean code are no longer strange or radical ideas, but they are also not yet universal. They are in the process of diffusing from their innovative origins into the mainstream — and a growing number of developers are actively seeking to learn them.

For DevOps practitioners, this matters directly. The feedback loops that make continuous delivery reliable — fast automated tests, small refactored functions, clean interfaces — depend on exactly these skills. The infrastructure may be ready; the question is whether the engineering practices are keeping pace.