What Is a Next-Gen WAF and Why Does It Matter for DevOps?

Traditional Web Application Firewalls (WAFs) were designed primarily as perimeter defenses—statically configured rule sets that inspect HTTP traffic and block suspicious requests. While effective in narrow scenarios, legacy WAFs are often criticized for being opaque “black boxes” that block requests without surfacing contextual information about why a request was flagged. This lack of visibility is a poor fit for modern DevOps practices, where speed, feedback loops, and observability are foundational principles.

A next-generation WAF addresses these shortcomings by operating as an integrated security data layer rather than a standalone gate. Instead of just blocking traffic, it collects Layer 7 (application-layer) telemetry, exposes that data through APIs and integrations, and feeds actionable intelligence back into the tools that development, security, and operations teams already use.

Security Visibility at Every Stage of the DevOps Lifecycle

The DevOps lifecycle is typically broken into continuous stages: Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor. A next-gen WAF can contribute meaningful security signal at each of these stages—not just at the perimeter in production. The sections below outline where and how that value is delivered.

Code: Surface Real-World Vulnerabilities for Developers

Static analysis and code review catch many issues before deployment, but they cannot fully replicate the conditions of production traffic. A next-gen WAF observes how attackers actually attempt to exploit your running application and can surface patterns that indicate high-value security bugs—such as injection attempts repeatedly targeting a specific endpoint. This gives developers a prioritized, evidence-based list of vulnerabilities to address in the next sprint rather than relying solely on theoretical threat models.

Build: Visibility Into Cloud-Native Attack Surfaces

Modern cloud-native applications—deployed across microservices, containers, and managed platforms—introduce web-layer attack surfaces that traditional network controls do not adequately cover. Cloud providers offer robust infrastructure security, but application-layer visibility is typically the team’s own responsibility. A next-gen WAF deployed alongside cloud-native workloads provides that missing layer of context, enabling security and platform teams to understand the real-world threat landscape their architecture faces before a vulnerability becomes an incident.

Release: Protection Without Code Changes on Every Deployment

DevOps teams release frequently—often multiple times per day. Requiring a manual security review or configuration change on every release is a bottleneck that directly conflicts with continuous delivery. A next-gen WAF solves this by decoupling application security from the release artifact itself. Whether deployed as a sidecar agent, a reverse proxy, or a cloud-delivered WAF service, protection travels with the infrastructure configuration rather than the application code. Teams can release confidently knowing their WAF policy follows the deployment automatically.

Operate: Production Monitoring on Key Application Metrics

Operations teams are responsible for availability, performance, and reliability. Security events—such as a volumetric request flood or a spike in invalid authentication attempts—directly threaten these objectives. A next-gen WAF contributes to operational observability by exposing security-relevant metrics alongside standard application performance indicators. When operations teams can see attack patterns and application health in a unified view, they can respond faster and make more informed decisions about scaling, rate-limiting, or incident escalation.

Monitor: Real-Time Alerting and Integration With Your Toolchain

After deployment, continuous monitoring is essential. A next-gen WAF integrates with the broader security and DevOps toolchain—sending alerts and telemetry to SIEM platforms, incident management systems, messaging tools like Slack or PagerDuty, and monitoring dashboards—so that security signals appear in the same places where teams are already working. This removes the need to context-switch into a separate security console to understand what is happening in production.

Next-Gen WAF as a Force Multiplier for Security and DevOps Teams

Security and DevOps teams are almost universally resource-constrained. A next-gen WAF can operate in two complementary modes that reflect different team maturity levels:

• Automated protection mode: Teams that need immediate coverage without deep customization can rely on the WAF’s automated detection and blocking capabilities. This allows smaller teams to maintain a strong security posture without dedicating significant engineering time to rule tuning.
• Intelligence and KPI mode: More mature teams can treat the WAF as a security data source, using its management console and API to extract KPIs, analyze attacker behavior, and feed that intelligence back into their development and security processes. This produces compounding improvements in application security over time.

Key Capabilities to Look for in a Next-Gen WAF

When evaluating next-gen WAF solutions for a DevOps environment, prioritize the following capabilities:

• API-first architecture: Security data should be accessible programmatically so it can be integrated into pipelines, dashboards, and automation workflows.
• Flexible deployment models: Support for agent-based deployment, reverse proxy, and cloud-delivered WAF ensures the solution fits different infrastructure topologies.
• Contextual blocking decisions: Every block or flag should include enough context for a developer or analyst to understand and act on the decision.
• Native integrations with DevOps tooling: Pre-built integrations with CI/CD platforms, monitoring systems, SIEM tools, and communication platforms reduce integration effort.
• Low false-positive rate: In a continuous delivery environment, a WAF that generates excessive false positives will be bypassed or disabled. Accuracy is a prerequisite for adoption.
• Support for modern traffic patterns: The solution should handle REST APIs, GraphQL, gRPC, and other contemporary application protocols in addition to traditional web traffic.

Summary

A next-generation WAF is not simply a more powerful version of a legacy firewall. When properly integrated into the DevOps lifecycle, it becomes a source of continuous security intelligence that informs coding decisions, validates builds, protects releases, supports operations, and feeds monitoring workflows. For teams practicing continuous delivery, the ability to decouple application security from the release artifact—while maintaining full observability of the production threat landscape—is a meaningful operational advantage.

If you are evaluating next-gen WAF options for your organization, focus on solutions that expose their data through open APIs, integrate with the tools your teams already use, and are designed from the ground up for cloud-native and containerized environments.

The following sections walk through each phase of a typical DevOps lifecycle and explain how real-time messaging adds value at each step.

1. Plan

Your messaging platform is the system of record for team conversations related to planning new products and features. Teams collaborate on ideas, debate technical approaches, and reach decisions — all within a searchable, persistent history that keeps stakeholders informed and aligned.

• Document sharing: Roadmaps, diagrams, and presentations can be shared directly in a channel, reducing context-switching to email or file servers.
• Threaded conversations: Threaded replies keep planning discussions organized and easy to reference later.
• Planning tool integrations: Integrations with tools such as Jira let teams surface issue details, create tickets, and update statuses without leaving the messaging interface.
• Video conferencing: When a text conversation needs to become a voice call, integrations with platforms such as Zoom or Webex make it simple to start a meeting from within the channel and return to the chat thread afterwards.

2. Code

As developers write code, they naturally turn to each other for collaboration and support. Whether the team is co-located or fully remote, a shared virtual workspace enables real-time problem-solving and peer review.

• Code snippet sharing: A messaging platform with language syntax highlighting lets developers paste a code block directly into a conversation and see it rendered with correct formatting, making reviews faster and clearer.
• Source control integration: Integrations with platforms such as GitLab or GitHub allow developers to receive pull request notifications, review diffs, and merge code without leaving their messaging workspace.
• Async collaboration: Persistent message history means remote team members working across time zones can pick up a conversation exactly where it left off.

3. Build

Integrating your messaging platform with your build system makes the build process transparent and actionable without requiring engineers to switch between tools.

• Slash commands: Custom slash commands let team members trigger a build, check its status, or retrieve artifact information directly from the messaging UI.
• CI tool plugins: Plugins for tools such as Jenkins expose job status, build logs, and failure alerts inside the team channel, so engineers are notified immediately when a build breaks.
• Automated notifications: Build success or failure messages posted to a dedicated channel ensure the right people are informed without manual follow-up.

4. Test

The testing phase requires close collaboration as teams validate new releases, identify defects, and fix bugs under time pressure. A well-integrated messaging platform can serve as a centralized testing hub.

• Webhooks: Use webhooks to connect CI pipelines and bug-tracking tools to your messaging platform, automatically posting test results, failure alerts, and bug reports to the appropriate channel.
• Triggered test runs: Teams can trigger automated test suites from within the messaging interface using bot commands or slash commands, removing the need to access a separate CI dashboard.
• Real-time visibility: Everyone involved — developers, QA engineers, and product managers — can watch test results appear in real time, reducing the communication lag between finding and fixing a defect.

5. Release

At release time, the messaging platform acts as a real-time broadcaster, ensuring that developers, operations engineers, and business stakeholders all know when a build has shipped and whether it was successful.

• Automated release notifications: Integrating release packaging tools such as Jenkins into your release workflow enables automatic notifications to the right channels when a release is packaged and ready.
• Cross-team transparency: Developers can accelerate follow-on work knowing a release has landed, while ops engineers can prepare for the incoming deployment without waiting for a manual handoff message.
• Audit trail: The persistent message history creates an informal audit trail of who was notified and when, which can be useful during post-release reviews.

6. Deploy

Following code to its final destination in production, the DevOps team needs visibility into which servers received the deployment and any relevant metrics, so they can troubleshoot issues quickly.

• Deployment tool integrations: Whether your team deploys using Puppet, Kubernetes, AWS services, or another solution, your messaging platform can receive automated deployment event notifications and surface them in a dedicated deployment channel.
• Rollout tracking: Automated messages can report the progress of a rolling deployment — for example, how many nodes have received the update — giving the team real-time confidence in the rollout.
• Rapid incident response: If a deployment triggers an error, the alert can surface immediately in the same channel where the deployment was announced, collapsing the gap between detection and response.

7. Monitor

Monitoring is where real-time messaging arguably delivers its greatest operational value. Posting alerts, health metrics, and incident updates directly into a messaging channel transforms how teams respond to production issues.

• Monitoring tool integrations: Tools such as Nagios, Datadog, or PagerDuty can be configured to post alerts and performance data directly to designated channels, making application health visible across the organization — not just to the on-call engineer.
• Incident response channels: When an outage occurs, a dedicated incident channel can be created instantly to bring together the right engineers, share diagnostic data, and coordinate a resolution — all with a preserved log of the incident conversation for the post-mortem.
• Historical data: Posting periodic metric summaries to a channel gives both engineers and business stakeholders a shared view of system health trends without requiring access to a separate monitoring dashboard.

Choosing the Right Integrations

The tools mentioned above — Jira, GitLab, Jenkins, Puppet, Kubernetes, Nagios, Zoom — are illustrative examples of a broader ecosystem. When evaluating a messaging platform for your DevOps environment, prioritize the following capabilities:

• A rich integration marketplace or support for custom webhooks and slash commands
• Persistent, searchable message history
• Granular channel and notification controls to prevent alert fatigue
• Support for code syntax highlighting
• Enterprise-grade security and compliance features appropriate for your industry

When a messaging platform is woven into every stage of the DevOps lifecycle, it becomes far more than a chat application. It becomes the connective tissue that keeps distributed teams aligned, accelerates incident response, and provides the transparency that continuous delivery demands.

Originally sourced from sdtimes.com (2019).

Why DevSecOps Is a Cultural Challenge First

A common mistake enterprises make when starting a DevSecOps initiative is treating it as a tooling problem. Teams rush to procure security scanners and vulnerability management platforms, only to find that adoption stalls because no one has changed how people think about security. DevSecOps is fundamentally a cultural and mindset shift before it is a technology change.

Developers frequently acknowledge that security matters but feel they lack the time or knowledge to address it within tight delivery schedules. Business leaders, meanwhile, have historically optimised for speed-to-market, sometimes treating security as a gate at the end of the pipeline rather than a continuous thread running through it. Bridging these perspectives is the first real challenge of DevSecOps adoption.

Successful DevSecOps programmes sell the concept to stakeholders at every level—executive sponsors, product owners, developers, testers, and operations engineers—before a single tool is procured. Only when everyone understands that functionality and security are not competing outcomes can implementation begin in earnest.

Step 1: Adopt a Security-First Mindset Across the Organisation

A security-first mindset means every person involved in the application lifecycle considers the security implications of their decisions, not just the dedicated security team. This applies to:

• Developers — trained to assess the security consequences of each line of code they write.
• Product owners — expected to capture security requirements in every user story alongside functional requirements.
• Operations engineers — equipped to recognise infrastructure anomalies as potential security breaches rather than routine misconfiguration.
• Business teams — empowered to adjust timelines when security work demands it, understanding that a single exploitable vulnerability can cause significant financial and reputational damage.

Achieving this requires structured training programmes, clear communication from leadership, and time allocated for up-skilling existing staff. In some cases, enterprises will also need to hire experienced security engineers who can act as internal advocates and coaches.

Step 2: Secure Applications by Design

Application security must start before a single line of code is written—sometimes called Day 0 security. Design-time decisions, such as how data is stored, which trust boundaries exist between services, and how authentication flows work, have lasting consequences that are expensive to fix post-deployment.

Key practices for secure application design include:

• Threat modelling — systematically identifying and prioritising potential threats to an application before design is finalised.
• Shift-left security — moving security considerations earlier in the SDLC, including into planning and architecture phases, not just development.
• Identifying core security pillars — defining confidentiality, integrity, and availability requirements specific to the application context.
• Security test planning — defining what security testing will occur, at which pipeline stages, and using which tools, before coding begins.
• Incident response planning — preparing procedures for detecting, containing, and recovering from a security breach while the application is still in design.

Step 3: Apply Secure Coding Standards

Even well-designed applications can accumulate vulnerabilities at the code level. The Open Web Application Security Project (OWASP) provides a widely adopted set of secure coding guidelines that give developers a practical reference for common vulnerability categories. The OWASP Secure Coding Practices guide covers areas including:

• Input Validation
• Output Encoding
• Authentication and Password Management
• Session Management
• Access Control
• Cryptographic Practices
• Error Handling and Logging
• Data Protection
• Communication Security
• System Configuration
• Database Security
• File Management
• Memory Management
• General Coding Practices

Most developers have some familiarity with the OWASP Top 10 list of critical web application risks, but the broader secure coding guide serves as a useful reference when developers want to verify their approach to a specific vulnerability class. Coupling these standards with structured peer code review reduces the volume of security defects that reach the release gate.

Step 4: Integrate Automated Security Testing Early in the Pipeline

Automated security testing tools allow teams to catch vulnerabilities continuously rather than in a single, high-stakes audit before release. There are two primary categories to integrate into a DevSecOps pipeline:

Static Application Security Testing (SAST)

SAST tools analyse source code, bytecode, or binaries without executing the application. When integrated into the build or commit stage of a CI/CD pipeline, they can flag insecure code patterns before a pull request is merged into the main branch. This is one of the most effective ways to prevent vulnerable code from advancing through the pipeline.

Dynamic Application Security Testing (DAST)

DAST tools test a running application by simulating external attacks against its APIs, web services, databases, and network interfaces. Many organisations only run DAST against production environments, which means vulnerabilities are first discovered when real user data is already at risk. A better DevSecOps approach is to run DAST against a pre-production environment that closely mirrors production, shifting vulnerability discovery left without exposing live systems.

Combining SAST and DAST in the pipeline creates overlapping layers of automated protection and embeds security controls throughout the SDLC rather than appending them at the end.

Step 5: Establish Governance, Feedback Loops, and Continuous Improvement

DevSecOps is not a project with a finish line—it is an ongoing practice. The final step is to build the governance structures and feedback mechanisms that sustain security improvements over time:

• Security champions — designate security-aware individuals within each development team who act as a first point of contact for security questions and help maintain standards without bottlenecking every decision through a central security team.
• Metrics and dashboards — track meaningful indicators such as mean time to remediate vulnerabilities, the volume of findings at each pipeline stage, and the percentage of builds passing security gates. Make these visible to engineering leadership.
• Post-incident reviews — treat every security incident or near-miss as a learning opportunity. Update threat models, coding standards, and test coverage based on findings.
• Regular training updates — the threat landscape evolves. Refresh security training at least annually and whenever significant new vulnerability classes or tooling changes emerge.
• Pipeline policy enforcement — codify security requirements as policy-as-code where possible, so that non-compliant builds are blocked automatically rather than relying on manual review.

Summary

Integrating DevSecOps in an enterprise is a multi-dimensional effort that spans culture, process, and tooling. The five steps—adopting a security-first mindset, securing applications by design, applying secure coding standards, integrating automated security testing early, and establishing continuous governance—provide a structured path forward. None of these steps can succeed in isolation: they reinforce each other, and sustainable DevSecOps adoption requires commitment at every level of the organisation.

Original source attribution: itproportal.com

This article breaks down who is likely to resist a DevOps adoption, why they resist, and the practical steps leadership can take to address each group’s concerns.

What DevOps Implementation Actually Demands

Before addressing resistance, it helps to be honest about what DevOps asks of an organisation. The benefits are real—faster infrastructure provisioning, reliable CI/CD pipelines, continuous testing that catches defects earlier, and better alignment between test and production environments. But reaching those benefits requires genuine change across multiple teams:

• Process changes: Waterfall or siloed handoff models give way to continuous collaboration between development, QA, and operations.
• Tooling changes: Teams must adopt containerisation (e.g., Docker), infrastructure as code (IaC), CI/CD pipelines (e.g., Jenkins, GitLab CI), version control practices, and cloud platforms.
• Cultural changes: Shared ownership of delivery outcomes replaces the classic “throw it over the wall” mentality.

Every one of these changes disrupts existing comfort zones. The stakeholders most affected each have their own legitimate concerns—understanding those concerns is the first step to resolving them.

Resistance from Project Managers

Why Project Managers Resist

Project managers (PMs) are typically the first to feel the impact of a DevOps transition. Their resistance tends to stem from an expanded scope of responsibility rather than simple reluctance to change:

• They must now actively champion DevOps to development, QA, and operations teams—a persuasion role they may not have played before.
• They are expected to facilitate continuous collaboration across teams that previously worked in separate phases.
• They need working familiarity with DevOps tooling—CI/CD pipelines, continuous monitoring, version control systems—and with cloud platforms such as AWS, Azure, or Google Cloud.

How to Overcome It

The CIO or transformation sponsor should invest in structured DevOps training for PMs before the rollout begins. This training should cover:

• Core DevOps principles and the business case behind the transition.
• Practical exposure to the tools the teams will use (containerisation, IaC, CI/CD).
• Cross-functional team management—specifically how to coordinate development, QA, and operations working in parallel rather than in sequence.

A well-prepared PM becomes a DevOps evangelist rather than an obstacle. Because PMs interact with every other stakeholder group, their buy-in has a multiplying effect on overall adoption.

Resistance from Developers

Why Developers Resist

Developers frequently resist DevOps not because they oppose automation or faster releases, but because the model changes their day-to-day responsibilities in uncomfortable ways:

• They are now expected to engage with infrastructure concerns—deployments, environment configuration, on-call incidents—that previously belonged to operations.
• They must coordinate their technology choices with operations and QA rather than selecting tools that suit their preferences alone.
• Closer collaboration with less experienced infrastructure staff can feel like a drag on productivity.

How to Overcome It

PMs must apply genuine facilitation skills to build mutual respect between developers and infrastructure engineers. Concrete steps include:

• Ensuring infrastructure engineers receive training on the specific tools the development team uses—Docker, Jenkins, Git workflows, and so on—so developers are not carrying colleagues who cannot keep up.
• Framing DevOps as removing friction for developers (fewer environment mismatches, faster feedback loops) rather than adding responsibility.
• Establishing clear ownership boundaries so developers understand precisely which operational concerns are theirs and which remain with the operations team.

Resistance from QA Teams

Why QA Teams Resist

QA engineers often feel squeezed by DevOps. A faster SDLC means less calendar time for manual testing, and the shift to continuous testing requires skills many test engineers do not yet have:

• Automated functional and regression testing frameworks (e.g., Selenium, Appium).
• API and performance testing tools (e.g., JMeter, Postman).
• Integration of test execution into CI/CD pipelines so that tests run automatically on every code commit.

The fear is understandable: asking a manual tester to own automated test suites overnight is a significant professional leap.

How to Overcome It

QA managers and PMs should work together to reframe the transition as a skills upgrade, not a threat. Practical tactics:

• Provide structured training in test automation and API testing tools before the team is expected to use them in production pipelines.
• Highlight the professional benefit: test engineers who can write and maintain automated test suites are more marketable and command broader responsibilities than manual-only testers.
• Introduce automation incrementally—starting with a subset of high-value regression tests—rather than replacing all manual testing at once.

Resistance from Infrastructure Department Managers

Why Infrastructure Managers Resist

Before DevOps, the infrastructure department manager controlled the design, configuration, and delivery of environments for development, test, and production. Infrastructure as Code (IaC) and self-service provisioning models can make it feel as though that control is being handed to developers—which is a genuine identity challenge for someone whose authority has long rested on gatekeeping infrastructure.

At the same time, the role actually expands: the infrastructure manager must now run their department as a competency centre, ensuring that every project team has the right mix of qualified engineers.

How to Overcome It

The CIO must communicate the new role clearly and early. Key messages:

• The infrastructure manager is not losing control—they are shifting from hands-on gatekeeping to strategic oversight and quality assurance of how infrastructure is provisioned and governed across projects.
• Their new mandate is to proactively identify and resolve skills gaps within project teams before those gaps cause delays, rather than reacting after problems emerge.
• They become an enabler of speed rather than a bottleneck, which is a more influential position in a DevOps organisation.

Resistance from Operations Engineers

Why Operations Engineers Resist

Operations engineers are accustomed to working at the end of the delivery pipeline—receiving a finished build and deploying it. DevOps pulls them into the process from day one, requiring:

• Continuous coordination with developers and QA throughout the project, not just at release time.
• Regular reporting to the PM on task status—a level of visibility that can feel like micromanagement to those not used to it.
• Fluency in automation and version control tooling: configuration management tools (Chef, Puppet, Ansible), version control systems (Git), and deployment automation platforms.
• A new obligation to communicate infrastructure status to both business and technical stakeholders.

How to Overcome It

The infrastructure department manager should own the technical upskilling of the operations team, delivering or arranging training on the specific tools the organisation has adopted. The PM should focus on the cultural side—building genuine working relationships between operations, development, and QA so that cross-team collaboration feels productive rather than intrusive.

It also helps to give operations engineers a voice in tooling decisions early. When engineers help choose the tools they will use, adoption resistance drops considerably.

Resistance from End Users

Why End Users Resist

It may seem counterintuitive that the people who benefit most from faster, more reliable software updates would push back. But end users often raise two specific objections:

• Less time for acceptance testing: A compressed SDLC leaves a shorter window for user acceptance testing (UAT), which can feel like their concerns are being rushed past.
• Distrust of automated testing: End users who have historically relied on their own exploratory testing during UAT cycles may not trust that automated test suites cover the scenarios that matter to them.

How to Overcome It

PMs should maintain consistent, transparent communication with end users throughout the delivery cycle. Specific actions that build confidence:

• Show end users which critical workflows are covered by automated tests and explain the coverage strategy.
• Share test results and defect metrics openly so end users can see that quality gates are functioning.
• Involve end users in defining acceptance criteria that feed directly into automated test cases, giving them genuine ownership over what gets tested.

A Unified Approach: What the CIO Must Drive

Addressing resistance stakeholder by stakeholder requires a coordinated strategy from the top. The CIO or executive sponsor should:

• Communicate openly and early. Every affected team should understand what is changing, why it is changing, and what their new responsibilities will look like—before the transition begins, not during it.
• Invest in targeted training. Generic “DevOps awareness” sessions rarely move the needle. Training should be role-specific: PMs need cross-functional management skills; QA engineers need test automation tools; operations engineers need IaC and configuration management; developers may need exposure to deployment and monitoring practices.
• Listen to concerns. Resistance is often a signal that a legitimate problem has not been addressed. Creating feedback channels—retrospectives, open Q&A sessions, anonymous surveys—helps surface issues before they become blockers.
• Measure and share progress. Demonstrating early wins (faster deployments, reduced incident rates, shorter feedback loops) builds momentum and makes the value of the transition concrete for everyone involved.

Summary

DevOps resistance is not irrational—it reflects real concerns about changing roles, new skill requirements, and unfamiliar ways of working. Each stakeholder group has a different source of friction:

Overcoming this resistance is as much a leadership and communication challenge as a technical one. Organisations that address the human dimension of DevOps adoption with the same rigour they apply to tooling selection consistently achieve faster, more durable transformations.

MLflow 1.0 Delivered Docker and Windows Support

When MLflow reached its 1.0 milestone in June 2019, it shipped two significant capabilities: Windows support and an experimental CLI command for building Docker images capable of serving MLflow models. Both had been stated targets for the 1.0 release by Databricks co-founder and chief technologist Matei Zaharia, who had previously identified Kubernetes and Windows support as key goals for that milestone.

Windows support arrived as promised. Kubernetes support, however, was not explicitly included in the 1.0 release — though the new Docker image tooling laid important groundwork for it.

Kubernetes Support: Two Distinct Problems

Speaking to Devclass following the 1.0 release, Clemens Mewald, Databricks Director of Product Management, described Kubernetes support as “a top item for the community” and broke the challenge into two distinct dimensions:

• Model deployment on Kubernetes: The most common pattern at the time was to package a trained model into a Docker container and deploy that container onto a Kubernetes cluster. Mewald noted that the new Docker image build feature added in 1.0 directly addressed this use case: “The feature we added to easily build a Docker container from an MLflow model addresses that request.”
• Hosting MLflow itself on Kubernetes: The second dimension involved deploying the MLflow tracking server, the UI, and its supporting components onto a Kubernetes cluster. This was the more substantial piece of work still in progress at the time of the interview.

Community-Driven Pull Request Under Review

Mewald indicated that Databricks was actively collaborating with community contributors on a significant pull request intended to enable full MLflow-on-Kubernetes hosting. “We’re basically reviewing and deciding that the design decisions are sound,” he said, adding that the work was expected to land within the following quarter. He noted that once a contribution is merged to the GitHub repository it becomes immediately available, but is only formally packaged when included in an official release.

Model Registry: The Next Major Priority

Alongside Kubernetes, Mewald identified a model registry as “the most important and biggest piece” the team was prioritising for the following quarter. The motivation was clear: some Databricks customers were already managing hundreds or thousands of models, creating a real operational challenge.

The planned registry would give teams the ability to:

• Register models with human-readable names
• Version models automatically
• Manage the full lifecycle of a model from experimentation through to production
• Integrate with CI/CD systems and enforce approval gates before promoting a model to a new lifecycle stage

“The model registry allows our users to manage the lifecycle and in some cases we’ve seen companies apply as much rigour to this process” as they would to software releases, Mewald explained, citing the integration of approval workflows with CI/CD pipelines as a concrete example.

Multi-Step Workflows on the Longer-Term Roadmap

Looking further ahead, Mewald described plans for expressing multi-step ML workflows natively in MLflow — a capability the company had recently demonstrated. Real-world ML training pipelines are rarely a single step: they typically involve data transformation, model training, evaluation, and potentially further post-processing stages. Databricks intended to give users a structured way to define and orchestrate these steps within MLflow itself. Mewald described this feature as “farther out” and likely to arrive later in 2019.

Context: Why This Mattered for MLOps Practitioners

At the time of this reporting, Kubernetes had already established itself as the dominant platform for containerised workloads, and machine learning teams were increasingly looking to run inference services alongside their other microservices on shared Kubernetes infrastructure. The gap between MLflow’s experiment-tracking capabilities and the operational requirements of production ML deployment was a live pain point. The combination of Docker image tooling, planned Kubernetes hosting support, and a model registry represented a coherent attempt to close that gap — and to position MLflow as a full MLOps platform rather than purely an experiment-tracking tool.

Note: This article reflects the state of MLflow and Databricks’ roadmap as of June 2019. Features described as planned or in-progress may have since been released, modified, or superseded. Refer to the official MLflow documentation and GitHub repository for current capabilities.

The Orchestration Problem: Many Tools, No Conductor

A realistic CD pipeline is rarely a single, unified system. It is a patchwork of best-of-breed tools: source code management, CI servers, test frameworks, artifact repositories, ticketing systems, provisioning tools, and deployment platforms. Each tool solves its own problem well, but none of them inherently knows what the others are doing.

Without something to tie these tools together, several problems emerge:

• Manual handoffs persist. Even in a heavily automated environment, transitions between stages are often managed through spreadsheets, emails, or manually created documents tracking who is responsible for what and when.
• Visibility gaps appear. Business owners, compliance teams, and support staff have no direct window into the release process. They must interrupt engineers to get status updates, ask about upcoming features, or answer security and audit questions.
• Audit trails are incomplete. Point-to-point integrations between tools rarely produce a coherent, queryable record of what happened, when, and why.

Think of your individual tools as talented musicians. A CI server, a test suite, a deployment engine—each is excellent at its specific role. But without a conductor, the result is noise rather than music. Release orchestration software is that conductor. It keeps track of every moving part, coordinates contributions from each tool, and ensures the whole ensemble delivers something coherent.

Why Building Your Own Integration Layer Is a Bad Idea

Faced with a fragmented toolchain, many teams are tempted to write custom scripts or build internal integration platforms to glue everything together. This approach has serious drawbacks that compound over time:

• Maintenance burden. Every time a tool is upgraded, a process changes, or a new team joins, scripts must be updated. The codebase for these integrations grows quickly and becomes a product in its own right—one that delivers no direct business value.
• Poor scalability. Shell scripts and point integrations that work for a small team become unmanageable at enterprise scale. Adding environments, teams, or release tracks multiplies the complexity non-linearly.
• No built-in reporting. Home-grown integrations rarely produce the dashboards, metrics, and audit logs that security, compliance, and management stakeholders need.
• Opportunity cost. Engineers who build and maintain an internal orchestration platform are not building the core product. This is a significant and often underestimated cost.

Building a robust, secure, and auditable release integration framework from scratch is an ambitious undertaking. For most organisations, it is neither the best use of engineering time nor likely to produce a result as capable as a dedicated solution.

What Release Orchestration Software Actually Does

Release orchestration—often implemented through Application Release Automation (ARA) platforms—provides a structured layer above your existing toolchain. It does not replace your individual tools; it coordinates them. Key capabilities typically include:

• Pipeline modelling. You define your release process as a sequence of phases and steps. These models can be saved as reusable templates and composed in different configurations for different products or environments.
• Tool integration via plugins. Rather than brittle custom API calls, a plugin architecture provides pre-built, maintained connectors to CI servers like Jenkins, issue trackers like JIRA, test platforms, and deployment targets. This produces a single coherent interface across tools that would otherwise speak different languages.
• End-to-end visibility. All stakeholders—engineers, product owners, security teams, and support staff—can see exactly where a release is in the pipeline, what risks are present, what has passed, and what has failed. This reduces interruptions to development teams and speeds up decision-making.
• Audit trails and compliance. Because every action is recorded through a single orchestration layer, producing an audit log or demonstrating compliance with a security policy becomes a query rather than a manual investigation.
• Reporting and intelligence. Dashboards and metrics expose bottlenecks, failure patterns, and opportunities for further automation. Non-technical stakeholders can access the data relevant to them without requiring engineering support.
• Manual step management. Where manual approvals or interventions are genuinely required, the orchestrator tracks them explicitly rather than leaving them as undocumented gaps between automated stages.

The Business Case for Release Orchestration

The argument for release orchestration is not purely technical. There is a direct business impact:

• Faster, more reliable releases. A fully orchestrated pipeline can be triggered with confidence. Fewer manual handoffs mean fewer delays and fewer human errors.
• Reduced risk. Consistent, templated release processes reduce the chance of a step being skipped or executed out of order. Visibility into what is happening in real time means problems are caught earlier.
• Scalability without proportional headcount growth. Orchestration allows an organisation to increase release frequency and the number of products or services being released without a corresponding increase in coordination overhead.
• Better compliance posture. Automated audit trails and policy enforcement reduce the effort required to satisfy internal governance or external regulatory requirements.

Where Release Orchestration Fits in a CD Pipeline

Release orchestration does not compete with the specialised tools in your pipeline. It sits above them as a coordination and visibility layer. A typical integrated pipeline might look like this:

1. A developer commits code to source control.
2. The orchestrator detects the commit and triggers a CI build in Jenkins.
3. On a successful build, the orchestrator triggers automated tests in the configured test framework.
4. Test results are reported back to the orchestrator’s dashboard.
5. If a manual approval gate is required (for example, a compliance sign-off), the orchestrator creates or updates a ticket in JIRA and waits for confirmation.
6. On approval, the orchestrator triggers deployment to the target environment using the appropriate provisioning or deployment tool.
7. All steps, results, timings, and approvals are logged in a single audit trail accessible to technical and non-technical stakeholders alike.

At every stage, the release orchestration layer provides the conductor’s-eye view: what is happening, who is responsible, what the risks are, and what needs attention.

Summary

Automation is necessary but not sufficient for Continuous Delivery success. As toolchains grow in complexity, the coordination overhead between tools becomes a bottleneck in its own right. Release orchestration—through dedicated Application Release Automation platforms—provides the missing layer: a conductor that ties your tools together, makes the entire pipeline visible to all stakeholders, enforces consistency, and produces the audit trails that governance and security demand. For organisations serious about scaling their CD practice, release orchestration is not optional infrastructure; it is a core enabler.

Visual Studio 2017 Officially Released on March 7

After a series of release candidates, Microsoft officially launched Visual Studio 2017 on March 7, 2017. The date was deliberately chosen to coincide with the 20th anniversary of the original Visual Studio release in 1997 — a version that shipped with tools including Visual J++, Visual FoxPro, Visual InterDev, and Visual C++.

The release represented a major milestone not just in terms of age, but in the scope of changes Microsoft made to modernize the IDE, improve startup and solution-load performance, and expand support for modern development workflows including containers, cloud, and cross-platform .NET development.

What the Final Release Candidate Introduced

The last release candidate before the formal launch (build 26206, released February 7, 2017) focused primarily on stability and bug fixes, but it did include two notable feature additions:

• dotnet new Templating Engine (.NET Core): The final RC included integration of the new dotnet new templating engine for .NET Core projects. This allowed developers to scaffold new projects from a wider range of templates directly from the command line, improving the CLI-based development experience.
• Redgate SQL Prompt: Microsoft bundled the Redgate SQL Prompt into the release, providing IntelliSense-style code completion for SQL queries and scripts. This was a notable addition for developers working with SQL Server databases directly inside the IDE.

Bug Fixes in Build 26206

Beyond new features, the final RC addressed a range of bugs across several areas:

VSIX and Extension Projects

Developers building or maintaining Visual Studio extensions (VSIX projects) received targeted fixes in this build. Issues affecting debugging and build pipelines for extension projects were resolved, making it more reliable to develop and test extensions against the new VS2017 host.

.NET Core and ASP.NET Core

Several bugs affecting .NET Core and ASP.NET Core project workflows were fixed, including:

• Problems saving project files correctly
• NuGet package restore and resolution issues
• Bugs in the .NET Core command-line tooling integration

These fixes were important given that .NET Core support was one of the headline features of VS2017 and was still maturing at the time of release.

How to Get Visual Studio 2017

At the time of the release candidate, Microsoft offered two upgrade paths for developers:

1. In-place update: Developers already running an earlier VS2017 RC could update directly from within the IDE using the built-in update notification.
2. Fresh installer download: A standalone installer was available from Microsoft’s official website for clean installations.

VS2017 introduced a new modular installer that replaced the monolithic setup experience of previous versions, allowing teams to install only the workloads and components they actually needed — significantly reducing install size and time.

Why VS2017 Mattered for DevOps Teams

For DevOps and platform engineering teams, Visual Studio 2017 was significant for several reasons:

• Faster startup and load times: Microsoft made substantial performance investments, reducing the time to open the IDE and load large solutions.
• Improved .NET Core tooling: With .NET Core becoming the primary target for cross-platform and containerized workloads, better tooling integration mattered for CI/CD pipeline reliability.
• Docker and container support: VS2017 improved integration with Docker tooling, making it easier to develop and debug containerized ASP.NET Core applications locally.
• Live Unit Testing: Introduced in the Enterprise edition, this feature ran unit tests automatically in the background as code was edited, shortening the feedback loop without leaving the editor.

Further Reading

Full release notes for VS2017 RC build 26206 were published by Microsoft and detail every change included in that build. Developers evaluating the release or maintaining extensions should consult the official Microsoft documentation for the authoritative list of breaking changes and API updates.

The 3×3 Release Challenge

LinkedIn operates on what it calls a 3×3 mobile release schedule: three releases per day, with a goal of never allowing code to sit uncommitted for more than three hours. At the scale LinkedIn operates, that cadence demands that every stage of the pipeline — including automated testing — runs fast, reliably, and without human bottlenecks.

For most engineering teams, continuous integration pipelines already feel stretched when pushing one release per day. Tripling that frequency requires rethinking not just deployment, but every upstream gate, particularly automated UI testing on mobile.

Where iOS UI Testing Became the Bottleneck

Automated iOS UI testing is notoriously slow. Running a full UI test suite sequentially on a single simulator can take far longer than the three-hour window LinkedIn had set for its release cycle. Off-the-shelf solutions available at the time could not adequately parallelize iOS simulator runs to fit within that window, and LinkedIn’s engineering team found themselves at a wall: without faster test execution, the 3×3 schedule simply was not achievable.

The options were limited. Compromise the release cadence, accept reduced test coverage, or build something new.

The Solution: Bluepill — An Open-Source Parallel iOS Test Runner

LinkedIn’s engineering team chose to build their own tool. Named Bluepill — a nod to The Matrix — it is an open-source iOS test runner designed to execute tests across multiple simulators in parallel. Key capabilities include:

• Parallel simulator execution: Bluepill spawns multiple iOS simulators simultaneously, distributing the test suite across them to cut overall wall-clock execution time.
• Intelligent test packing: Tests are grouped into balanced batches so that simulators finish at roughly the same time, avoiding idle resources waiting on a slow final batch.
• JUnit report output: After each run, Bluepill produces a standard JUnit XML report, making it straightforward to integrate with existing CI dashboards and reporting tools.

LinkedIn open-sourced Bluepill in January 2017. Full details are available on the LinkedIn Engineering Blog.

How Long Did It Take to Build?

LinkedIn engineer Oscar Bonilla described the development timeline directly:

“The first commit happened on Aug. 12 and we had it working on the LinkedIn Continuous Integration system by Nov. 1. From there we continued to polish the project and address a few bugs. So in total it took about 10 weeks to build Bluepill and another 10 to refine it.”

— Oscar Bonilla, LinkedIn Engineering

That is roughly five months from initial commit to a production-hardened open-source release — a reasonable timeline for a tool that reportedly saved LinkedIn thousands of developer hours.

Lessons for DevOps and Mobile Engineering Teams

The Bluepill story illustrates several principles relevant to any team dealing with CI bottlenecks at scale:

• Identify the constraint precisely. LinkedIn did not try to speed up their entire pipeline at once. They identified iOS UI testing as the specific gate blocking their release cadence and focused engineering effort there.
• Evaluate build-vs-buy honestly. Off-the-shelf tools failed to meet the requirement. Rather than forcing an inadequate tool into production, the team invested roughly ten weeks to build a fit-for-purpose solution.
• Parallelisation is often the right lever for test speed. Distributing a test suite across multiple simulators or machines is frequently more practical than trying to make individual tests faster.
• Open-sourcing internal tooling creates compounding value. By releasing Bluepill publicly, LinkedIn benefited from external contributions and bug reports while giving the broader iOS community a tool to address a common pain point.
• Standard output formats matter. JUnit XML is a lingua franca for CI test results. Tools that produce it integrate immediately with Jenkins, CircleCI, GitHub Actions, and most other CI systems without custom parsing.

Further Reading

For the full technical details of Bluepill’s architecture and configuration options, see the original announcement on the LinkedIn Engineering Blog.