Infoworks DataFoundry Now Available as a Free Trial on Google Cloud Marketplace

Infoworks.io has announced a free trial program for Infoworks DataFoundry on the Google Cloud Marketplace. The trial introduces an updated version of DataFoundry featuring an interactive assistant designed to guide users through data onboarding to Google Cloud and the development of advanced analytics use cases.

DataFoundry had previously been made available on the Google Cloud Marketplace the prior fall. This free trial expands access and lowers the barrier to entry for Google Cloud customers looking to automate data operations at scale.

What Is Infoworks DataFoundry?

DataFoundry is Infoworks’ flagship platform for Enterprise Data Operations and Orchestration (EDO2). It is designed to automate and accelerate the deployment and orchestration of analytics projects, removing the need for manual coding or deep infrastructure management. Key characteristics include:

• No-code automation: Data engineers, scientists, analysts, and business users can build data pipelines without writing custom code.
• Scalable data onboarding: Automates ingestion and preparation of enterprise data at scale.
• Multi-environment support: Works across cloud, hybrid, multi-cloud, and on-premises environments.
• Rapid time-to-value: Enables organizations to deploy analytics projects to production within days rather than months.

What the Free Trial Includes

The DataFoundry free trial runs natively on Google Cloud and is optimized to leverage Google Cloud’s underlying infrastructure. The trial package includes:

• An interactive assistant providing step-by-step guidance for building data onboarding and analytics use cases.
• Integration with Google Cloud’s advanced analytics services, including BigQuery and TensorFlow.
• Support for third-party AI and machine learning solutions available on Google Cloud.
• Access to DataFoundry’s full pipeline orchestration and automation capabilities.

Why This Matters for Data Engineering Teams

One of the persistent challenges for enterprises migrating to or expanding on cloud platforms is the complexity of data operations — ingesting, transforming, governing, and operationalizing data at scale. This work typically consumes significant data engineering time and specialized talent.

Russ Barck, Vice President of Strategic Alliances at Infoworks, framed the value proposition directly:

“Infoworks DataFoundry frees data engineers, scientists, analysts and even business users to focus on leveraging Google Cloud in delivering use cases that drive digital transformation. Our unique automated, no-code offering means the major time and talent sink of dealing with underlying data operations and orchestration complexity is no longer an issue.”

— Russ Barck, VP Strategic Alliances, Infoworks

Manvinder Singh, Director of Partnerships at Google Cloud, also commented on the partnership:

“Businesses today need to derive more insights and greater value from their data. We’re delighted that Infoworks will make its enhanced DataFoundry capabilities available via Google Cloud Marketplace, helping customers more seamlessly bring their data to Google Cloud.”

— Manvinder Singh, Director of Partnerships, Google Cloud

Supported Industries and Customer Base

According to Infoworks, DataFoundry is already deployed by some of the world’s largest enterprises across a range of industries, including:

• Financial services
• Retail
• Technology
• Healthcare
• Oil and gas
• Manufacturing

How to Access the Free Trial

The DataFoundry free trial can be accessed directly through the Google Cloud Marketplace or via the Infoworks website at infoworks.io.

About Infoworks

Infoworks offers an Enterprise Data Operations and Orchestration (EDO2) platform that automates the full lifecycle of analytics project deployment — from data ingestion and preparation through to production operationalization. The platform supports cloud, hybrid, multi-cloud, and on-premises deployments. More information is available at infoworks.io.

What Is Datadog Incident Management?

Datadog announced the general availability of Incident Management, a product designed to consolidate on-call response workflows for DevOps and security teams. Rather than juggling multiple disconnected tools for alerting, communication, tracking, and investigation, engineers can now work from a single, unified interface that brings together alerting data, documentation, and real-time collaboration.

The goal is straightforward: reduce the time wasted querying disparate systems during an active incident, and make it easier to onboard additional responders quickly when an outage escalates.

The Problem: Fragmented Tooling During Incidents

When a performance or security incident occurs, every minute of downtime increases the number of affected users and transactions — and the potential revenue and reputational damage to the business. Yet on-call engineers have historically had to coordinate across a patchwork of tools:

• Alerting platforms to detect the issue
• Chat tools (such as Slack) to coordinate the response team
• Ticketing systems to track tasks and ownership
• Wikis or runbooks for documentation and procedures
• Monitoring dashboards to investigate root cause

Context-switching between these tools slows the mean time to resolution (MTTR) and complicates post-incident review, since relevant data is scattered across systems.

“Managing incidents across disparate tools for alerting, communicating, tracking, and investigating makes it difficult to both solve a problem while it’s happening and conduct a post-mortem to prevent it from happening again.”

Marc Weisman, Vice President of Product, Datadog

Core Capabilities of Datadog Incident Management

Datadog Incident Management centralizes the incident lifecycle in one place. Key capabilities at launch included:

Incident Declaration from Alerts and Graphs

Engineers can collect signals from across Datadog data sources and declare an incident directly from an anomalous graph or a triggered alert. This eliminates the manual step of copying context into a separate incident tracking tool.

Incident Timeline and Task Tracking

Responders can document a chronological timeline of events as the incident unfolds, and log follow-up tasks within the same interface. This structured record becomes the foundation for post-mortem analysis once the incident is resolved.

Incident History for Post-Mortems

All collaboration and data associated with an incident is automatically saved in an incident history. Teams can return to this record to conduct thorough post-mortem reviews and identify patterns that could prevent future occurrences.

Companion Features Released Alongside Incident Management

Datadog released several additional capabilities to complement the Incident Management workflow:

Mobile App (Android and iOS)

A native mobile application — reaching general availability at the same time — allows engineers to interact with Datadog monitors and dashboards from their phones. This is particularly valuable for on-call engineers who need situational awareness outside of normal working hours.

Slack ChatBot Integration

A Datadog ChatBot for Slack allows teams to manage incidents and query Datadog data without leaving their primary communication channel. This supports chat-driven incident response workflows that many DevOps teams already rely on.

Collaborative Notebooks

Datadog Notebooks received updates enabling real-time collaboration, including presence detection (showing who else is viewing or editing the document) and live content updates without requiring a page refresh. This makes notebooks a viable tool for live incident documentation shared across a distributed response team.

Customer and Partner Perspectives

“At Olo it’s critical to always have our finger on the pulse of our systems in order to keep restaurants up and running. While Datadog is already an important part of that, the release of integrated Incident Management can further improve our team’s ability to respond quickly and effectively, in those times it matters most.”

Greg Shackles, Vice President of Technology, Olo

“effx provides users the context and contributing factors of an incident in real-time. We’re excited to partner with Datadog for Incident Management to provide further insight into managing incidents that can potentially impact just one or thousands of microservices.”

Joey Parsons, Founder & CEO, effx

Why Incident Management Matters for DevOps Teams

Incident management is not just a reactive capability — it directly affects business outcomes. A unified incident platform supports several DevOps best practices:

• Reduced MTTR: Faster access to correlated data means engineers spend less time hunting for information and more time fixing the problem.
• Better post-mortems: An automatically generated incident timeline provides an accurate record of events, reducing the effort required to reconstruct what happened.
• Scalable collaboration: New team members joining a live incident can quickly get up to speed from a single pane of glass rather than being briefed across multiple tools.
• Continuous improvement: Structured incident histories enable teams to identify recurring failure modes and prioritize reliability investments accordingly.

Industry Context

The launch coincided with a period of significantly increased pressure on digital infrastructure. As organizations accelerated their shift to digital channels, the business impact of performance incidents grew accordingly. Analyst firm 451 Research noted at the time that businesses would increasingly rely on monitoring, incident management, and collaboration tools to resolve performance problems before they cause customer and revenue loss.

Datadog Incident Management positions the company to serve as a more complete operational platform — moving beyond observability into the workflow layer that determines how quickly teams can act on what they observe.

Summary

Datadog Incident Management centralizes alerting signals, documentation, timelines, and team collaboration into a single platform, reducing the friction of multi-tool incident response. Combined with a mobile app, a Slack ChatBot, and collaborative notebooks, the product suite addresses the full lifecycle of a DevOps incident — from detection through resolution and post-mortem review.

For DevOps teams operating under SLA pressure with distributed on-call rotations, consolidating this workflow can meaningfully reduce both MTTR and the cognitive overhead of incident response.

1. Source Code Management (SCM) Tools

Source code management is the foundation of any repeatable software delivery process. A well-configured SCM system gives every member of a distributed engineering team a single source of truth for application code, configuration files, and infrastructure definitions.

Key capabilities to look for in an enterprise SCM tool include:

• Branching and merging strategies — support for Git Flow, trunk-based development, or feature-flag workflows so teams can work in parallel without conflicts.
• Version history and rollback — the ability to compare any two commits and revert to a known-good state reduces the blast radius of bad releases.
• Access controls and audit logs — fine-grained permissions protect sensitive code and satisfy compliance requirements by tracking who changed what and when.
• Repository hosting and mirroring — self-hosted or cloud-hosted options (GitHub Enterprise, GitLab, Bitbucket Data Center) that integrate with the rest of the toolchain.

When SCM is tightly integrated with CI/CD pipelines and code review workflows, it becomes the control plane for the entire software delivery lifecycle rather than just a backup mechanism.

2. Containerization Platforms

Containers solve one of the oldest enterprise software problems: environmental inconsistency between development, staging, and production. By packaging an application together with all of its dependencies into a portable, immutable image, containers make "it works on my machine" arguments largely irrelevant.

Two tools dominate this space:

• Docker — the de facto standard for building and running container images locally and in CI pipelines.
• Kubernetes — the leading container orchestration platform for scheduling, scaling, and managing containerized workloads across clusters in production.

Adopting containers also facilitates a microservices architecture. Large monolithic applications can be decomposed into independently deployable services, each versioned and scaled on its own schedule. Before committing to an orchestration platform, evaluate your team’s operational maturity, your existing infrastructure (on-premises vs. cloud), and whether managed Kubernetes offerings from your cloud provider (EKS, GKE, AKS) reduce the operational overhead.

3. Structured Logging Libraries

Log files are among the most valuable diagnostic assets an engineering team produces — and among the most frequently misused. Traditional log output is free-form text, which is easy for humans to read line by line but difficult for machines to parse, aggregate, or alert on at scale.

Structured logging solves this by emitting log entries as key-value pairs or JSON objects, making every log event immediately queryable by your observability platform. A concrete example is Logrus, a popular structured logging library for Go that is API-compatible with the standard log package. Teams can add fields such as request ID, user ID, service name, and severity level to every log entry without changing the consuming code.

Practical benefits of structured logging at the enterprise scale include:

• Faster root-cause analysis because log data can be filtered and grouped without grep pipelines.
• Integration with log aggregation platforms (Elasticsearch/OpenSearch, Splunk, Datadog) that index structured fields natively.
• Consistent log schemas across services, which is critical when dozens of teams contribute to a shared observability stack.
• Support for correlation IDs that trace a single request across multiple microservices.

Most modern languages have mature structured logging libraries. Investing time in a shared logging standard early pays dividends when debugging production incidents under pressure.

4. Advanced Monitoring and Observability Systems

Monitoring tells you that something is wrong. Observability — the combination of metrics, logs, and distributed traces — tells you why. As DevOps enterprises scale, reactive alerting on a handful of server metrics is no longer sufficient.

A mature monitoring stack typically includes:

• Metrics collection and time-series storage — tools like Prometheus scrape application and infrastructure metrics at high resolution and store them for alerting and dashboards.
• Visualization — Grafana or equivalent dashboards surface real-time performance data to on-call engineers and leadership alike.
• Distributed tracing — OpenTelemetry-instrumented services emit trace spans that reveal latency bottlenecks across microservice call chains.
• Alerting and incident management — alert rules fire when SLO thresholds are breached, routing notifications to PagerDuty, Opsgenie, or Slack.
• SaaS alternatives — platforms like Datadog, New Relic, and Dynatrace bundle all of the above with minimal infrastructure overhead, which is valuable for teams without dedicated platform engineering resources.

Monitoring containerized workloads requires tooling that understands ephemeral, dynamically scheduled pods rather than static host addresses. Ensure any solution you adopt has first-class Kubernetes support.

5. CI/CD Servers and Pipelines

Continuous integration and continuous delivery (CI/CD) is the automation backbone of a DevOps practice. CI/CD pipelines encode the steps required to take code from a developer’s commit to a production deployment as a repeatable, auditable process.

A well-designed enterprise CI/CD pipeline typically handles:

• Build automation — compiling code, resolving dependencies, and producing versioned artifacts on every commit.
• Automated testing — unit, integration, contract, and end-to-end tests run in parallel to catch regressions before they reach production.
• Security scanning — static analysis (SAST), dependency vulnerability scanning, and container image scanning integrated directly into the pipeline gate.
• Deployment orchestration — progressive delivery strategies such as canary releases, blue/green deployments, and feature flags reduce the risk of each release.
• Distributed execution — agents or runners distributed across multiple nodes reduce pipeline queue times as team size grows.

Popular CI/CD platforms include Jenkins, GitLab CI/CD, GitHub Actions, CircleCI, and Tekton (for Kubernetes-native pipelines). The right choice depends on your existing SCM platform, cloud provider relationships, and whether your team prefers self-hosted control or managed convenience.

Putting It All Together

These five technology categories are not independent silos — they reinforce each other. SCM events trigger CI/CD pipelines. Pipelines build and push container images. Running containers emit structured logs and metrics. Monitoring systems alert on those signals and trace failures back to specific commits in the SCM history. Investing in all five creates a closed feedback loop that shortens the time between writing code and learning from it in production.

For enterprises earlier in the DevOps journey, the highest-leverage starting point is usually source code management and CI/CD — both deliver immediate, visible improvements to delivery speed and code quality before you invest in the more advanced observability and containerization layers.

Five Years in the Making: Ansible for DevOps, 2nd Edition

After five years of continuous development, 834 commits, and 24 major revisions, Jeff Geerling published the 2nd edition of Ansible for DevOps. The book has sold over 60,000 copies and served as the foundation for a free Ansible 101 video series on YouTube. The 2nd edition marks the start of the 2.x revision series.

The book covers a broad range of infrastructure automation topics:

• Managing Linux servers with Ansible basics
• Continuous integration pipelines
• Application deployments
• Container image management
• Kubernetes cluster management with Ansible

The Problem with Traditional Edition-Based Publishing

Geerling’s original commitment was simple: ebook updates would be free, forever. He has published at least one new revision per quarter since the first release (version 0.42 on LeanPub in 2014). However, selling through Amazon introduced friction: Amazon follows the traditional publishing convention of “editions,” where any substantive update beyond minor corrections requires a new edition — complete with a new ISBN and a new product listing.

This model made sense in the era of print, but it creates a poor experience for readers of digital technical books. Anyone who has owned outdated print books on Python 2, PHP 5, or legacy Linux distributions understands the problem. Technology moves faster than print publishing cycles, and readers who buy digital copies deserve to benefit from an author’s ongoing improvements.

What an Evergreen Technical Book Looks Like in Practice

Keeping a technical book genuinely current requires more than occasional edits. Geerling’s approach to maintaining Ansible for DevOps as an evergreen resource included:

• Quarterly revisions to reflect new Ansible releases, deprecation cycles, and evolving best practices.
• Chapter rewrites when underlying architecture shifted significantly enough to make older guidance misleading.
• A companion GitHub repository containing all code examples from the book, with CI tests that run on a weekly schedule to catch bit rot — examples that silently break as dependencies, APIs, or Ansible modules change.
• An open issue tracker where readers can report broken or confusing examples, and submit patches directly.

The CI testing approach is particularly notable for a book project. Rather than relying solely on manual review, automated weekly test runs surface problems proactively, before readers encounter them.

The Financial Case for Self-Publishing Technical Books

Geerling is candid about the economics. Over five years, Ansible for DevOps earned him nearly $200,000 in royalties — after platform fees of 30–70% from Amazon, Apple Books, and LeanPub (LeanPub being the most author-generous of the three).

For context, a comparable deal with a traditional publisher might have yielded:

• A few thousand dollars as an advance
• Roughly a 5% royalty rate on net sales
• No royalties until the advance was earned out
• An estimated total return of under $50,000 for the same sales volume

Self-publishing platforms like LeanPub typically return 70–80% of the sale price to the author. Amazon’s cut varies by price tier and format. The gap in author earnings between self-publishing and traditional publishing is substantial, and for a successful title it can represent a difference of four times or more in total income.

“Self-publish, don’t write for a publisher.” — Jeff Geerling

Honest Advice: Don’t Quit Your Day Job

Despite Ansible for DevOps being a genuinely successful technical book — one of the more successful self-published DevOps titles available — Geerling is direct: $200,000 over five years averages $40,000 per year. That is meaningful supplemental income, but it does not replace the salary a skilled DevOps engineer or software architect can command.

His conclusion for anyone considering writing a technical book:

• If you have deep, practical expertise in a cloud or infrastructure topic, your salary as a practitioner will likely exceed your maximum book revenue by a factor of five or more.
• Write the book as a practitioner, not as a full-time author. The best technical books come from people solving real problems in production environments, not from authors who write to fill a publisher’s catalog.
• “Fluff” tech books — written by light users of a tool or by serial authors without hands-on depth — are immediately apparent to experienced readers and rarely offer the small, high-value tips that justify the purchase price.

LeanPub and the Lean Publishing Model

One of the practical enablers of Geerling’s approach is LeanPub, a publishing platform designed for iterative, in-progress book writing. Key properties that make it well-suited for technical authors:

• You can publish and sell a partial, in-progress manuscript immediately.
• Readers who buy early can engage with the content and provide feedback while the book is still being written.
• Updates to buyers are automatic and free — no new purchase required.
• Author royalty rates are significantly higher than traditional publishers or even most major retail platforms.

This model validates demand early, reduces the risk of spending months writing a book nobody wants, and aligns author incentives with reader experience over the long term.

What This Means for DevOps Engineers Considering Writing

If you are a DevOps or platform engineering practitioner with genuine depth on a specific tool or workflow, self-publishing a technical book is a viable way to build credibility, contribute to the community, and earn supplemental income. The key takeaways from Geerling’s experience:

• Start lean. Publish early on a platform like LeanPub and iterate publicly.
• Automate quality assurance. Treat code examples like production code — use CI to test them on a regular schedule.
• Commit to maintenance. A technical book that goes stale within a year damages your reputation more than not writing one at all.
• Self-publish first. Traditional publishing deals rarely make financial sense for technical authors with the motivation to self-publish.
• Keep your day job. Even a successful technical book is unlikely to match your engineering salary.

About the Books

Ansible for DevOps, 2nd Edition is available on Amazon, LeanPub, and Apple Books. Jeff Geerling is also writing Ansible for Kubernetes, a deeper dive into Kubernetes and container automation with Ansible, available in progress on LeanPub with the same free-updates-forever commitment.

For more from Jeff Geerling, see jeffgeerling.com.

Nutanix Clusters Land on Amazon EC2 Bare-Metal

Nutanix announced in August 2020 that Nutanix Clusters are now available on bare-metal instances of Amazon Elastic Compute Cloud (Amazon EC2), marking the company’s first major step into public-cloud-hosted hyperconverged infrastructure (HCI). The move allows enterprises already running Nutanix on-premises to extend those environments into AWS without rearchitecting their workloads.

What Is Nutanix Clusters on AWS?

Nutanix Clusters brings the company’s HCI software stack — which converges compute, storage, and networking management — to AWS EC2 bare-metal instances. Because these instances expose the underlying hardware directly rather than through a hypervisor layer, Nutanix can run its own hypervisor and storage fabric on top, replicating the on-premises experience inside AWS data centers.

Manoj Agarwal, then Senior Vice President of Engineering at Nutanix, described the value proposition clearly: AWS does not natively offer HCI capabilities based on the Nutanix virtual machine stack, so Nutanix Clusters fills a gap for organizations that want HCI-style infrastructure management in the public cloud.

Key Capabilities and Benefits

No Workload Refactoring Required

One of the primary selling points is that IT organizations can lift and shift existing on-premises Nutanix clusters to AWS without refactoring applications. Because the underlying platform is identical, VMs and workloads behave the same way in the cloud as they do on-premises.

Unified Management via Nutanix Prism

IT teams can provision and manage Nutanix Clusters on AWS using Nutanix Prism — the same management console used for on-premises deployments. This single management plane eliminates the need to learn cloud-native tooling or maintain separate operational workflows for cloud and on-premises environments.

Access to the Full Nutanix Add-On Ecosystem

Running Nutanix on AWS also unlocks the broader suite of Nutanix add-on services, including:

• Nutanix Files — unstructured data management and file services
• Nutanix Calm — application orchestration and automation
• Nutanix Era — database lifecycle management and provisioning

These services function consistently whether the underlying cluster is in an on-premises data center or on AWS, reinforcing the goal of a single operational model across environments.

The Hybrid Cloud Context: Why This Matters

The announcement arrived during a period of significant disruption. The economic pressures of the COVID-19 pandemic accelerated hybrid cloud adoption as IT teams looked for ways to reduce total cost of ownership and increase operational flexibility. Many organizations had historically managed cloud and on-premises environments as completely separate silos — each with its own tooling, processes, and operational teams.

Nutanix Clusters on AWS directly addresses this fragmentation. Rather than forcing IT teams to choose between a dedicated on-premises HCI platform and native cloud services, it allows them to span both using a common infrastructure and management layer.

Avoiding Cloud Lock-In

Agarwal also positioned Nutanix Clusters as a hedge against cloud vendor lock-in. By deploying a consistent HCI platform across on-premises and cloud environments — and potentially across multiple clouds — IT organizations can move workloads more freely without being tightly coupled to any single cloud provider’s proprietary services.

Notably, at the time of the announcement, Nutanix declined to confirm whether Clusters support would be extended to other public cloud platforms beyond AWS. The multi-cloud angle remained aspirational rather than immediately actionable for non-AWS environments.

How Nutanix Competes in the Hybrid Cloud Management Race

Nutanix is not the only vendor pursuing the role of a unified hybrid cloud management plane. Cloud providers themselves have moved in the opposite direction — making managed, on-premises versions of their cloud platforms available (for example, AWS Outposts, Google Anthos, and Azure Arc). These offerings let cloud vendors manage on-premises infrastructure on behalf of customers.

Nutanix’s approach differs in a meaningful way: IT teams retain direct control of their infrastructure and operational model. Rather than delegating management to a cloud provider, organizations use Nutanix tooling to automate hybrid cloud operations themselves. This resonates particularly with enterprises that have regulatory, data sovereignty, or operational reasons to maintain direct infrastructure control.

Summary

Nutanix Clusters on AWS represents a significant milestone for enterprise HCI in the public cloud. By running on EC2 bare-metal instances and integrating with the existing Nutanix Prism management layer, it gives IT teams a credible, low-disruption path to hybrid cloud — extending familiar on-premises infrastructure into AWS without sacrificing consistency, tooling, or control. Whether this approach becomes a dominant hybrid cloud model will depend on how quickly organizations can consolidate fragmented cloud and on-premises operations under a single management framework.

From IT Stack to Data Infrastructure

The concept of the “IT stack” has evolved significantly. Where once it described software running across a mix of hardware resources — tied together by analytics tools, network topology controls, and data channels — organizations now talk about data infrastructure as a first-class architectural concern. Investment in data infrastructure has become a strategic conversation at every level of the business, not just within engineering teams.

It is in this context that Looker, the business intelligence (BI) and analytics platform acquired by and now part of Google Cloud, has shipped a release focused on what the company describes as foundational optimisation. The update targets application builders and developer services specifically, with upgrades spanning the development environment, marketing analytics integrations, and a new data discovery tool.

Looker Blocks for Google Marketing Platform

One of the headline additions is a set of new Looker Blocks for Google Marketing Platform. Looker Blocks are pre-built data models and dashboards designed to accelerate analytics development by providing a reusable, shareable foundation.

These new Blocks are purpose-built for Google Marketing Platform advertising and web data, and include:

• Interactive data exploration capabilities out of the box.
• Light machine learning (ML) predictions baked into the data models, enabling marketers to surface predictive insights without building custom ML pipelines.
• Direct links back to Google Marketing Platform, allowing analysts to act on insights by adjusting campaigns without leaving their analytics workflow.
• Paths for pushing insights back into Google Marketing Platform, enabling a feedback loop between analysis and campaign execution.

Colin Zima, head of Looker analytics and strategy at Google Cloud, has highlighted the ability to “customize data experiences” as central to this release, with deeper Google Cloud integration enabling solutions that were not previously practical.

Redesigned IDE for Model Developers

Looker’s built-in Integrated Development Environment (IDE) — used for authoring LookML data models — has been redesigned to improve developer workflows. Key improvements include:

• More intuitive workflows with advanced controls surfaced in a cleaner interface.
• An object browser that simplifies navigation across a project, making it easier to find, track, and reuse existing LookML objects such as views, explores, and dimensions.
• A single shared repository that can be shared across Looker instances, enabling teams to collaborate on model development without duplicating work.
• Project folders to improve organisation and make collaboration across large LookML projects more manageable.

Together, these changes aim to reduce the friction involved in building and maintaining complex LookML models, particularly in enterprise environments where multiple teams share a single Looker instance.

Developer Data Dictionary

Available through the Looker Marketplace, the new Data Dictionary is an application built using Looker’s extension framework. It provides a dedicated, purpose-built user interface that helps business users locate the fields and metrics they need for analysis — reducing their dependence on developers or data engineers for routine discovery tasks.

From a developer and governance perspective, the Data Dictionary also provides:

• The ability to audit all LookML fields across a project quickly.
• Visualisation of relationships between datasets and explores, helping teams understand data lineage and dependencies.
• Insight into which explores are used most frequently and which are redundant or duplicative — useful for maintaining a lean, well-governed LookML project.

Extension Framework Now Generally Available

Perhaps the most significant long-term development is the general availability of Looker’s extension framework. First announced in November as part of the Looker 7 release, the framework allows developers to build fully custom data experiences within Looker and embed those experiences into existing enterprise applications and workflows.

This positions Looker not just as a standalone BI tool but as a data platform and application development environment. Teams can build bespoke internal tools — dashboards, data explorers, self-service reporting apps — powered by Looker’s semantic layer and embedded directly into the products their users already use.

The Data Dictionary described above is itself an example of an application built on this framework, demonstrating the kind of tooling that becomes possible when analytics infrastructure is treated as a developer platform.

Key Takeaways for DevOps and Data Engineering Teams

• The redesigned LookML IDE reduces development friction for teams managing large or complex data models.
• Looker Blocks for Google Marketing Platform offer a reusable analytics foundation for organisations already invested in the Google advertising ecosystem.
• The Data Dictionary app improves data governance and self-service discovery, reducing analyst dependence on engineering teams.
• The generally available extension framework opens the door to treating Looker as an embedded analytics platform, not just a reporting tool.
• Shared repositories across instances are a meaningful improvement for organisations running multi-instance Looker deployments.

The Growing Need for DevOps in Healthcare

Healthcare IT teams are operating under significant pressure. Smaller budgets, staffing shortages, and the explosive growth of telehealth services have combined to make standardized processes and automation no longer optional — they are operational necessities. According to research from Redgate, the COVID-19 pandemic acted as a forcing function, compelling healthcare organizations to rapidly build and deliver telehealth platforms while simultaneously managing secure access to electronic health records (EHRs) and other sensitive patient data.

These conditions have accelerated interest in both application-level DevOps and — critically — database DevOps, an extension of DevOps principles into the database development and deployment lifecycle.

“We know that the healthcare sector is facing unprecedented demands from the pandemic and other regulatory struggles, and DevOps is the best way to tackle these issues. By then extending those practices into the database, the healthcare sector can not only improve the quality and efficiency of these systems, but ensure patient data remains secure and maintain compliance practices.”

— Kendra Little, DevOps Advocate, Redgate

Key Findings: Database DevOps Adoption in Healthcare

Redgate’s research surfaced several notable trends specific to the healthcare sector. The figures below are drawn from the published survey data and should be interpreted as directional indicators rather than definitive benchmarks.

1. Overall DevOps Adoption Is Ahead of Other Sectors

Seventy percent of healthcare respondents reported that they have adopted DevOps across all or some projects, or have at least a Proof of Concept (PoC) in place. This compares favorably to a 68% average across all sectors surveyed. More significantly, 41% of healthcare respondents have moved beyond the PoC stage into active adoption — compared to 36% in sectors such as government and financial services. This suggests that healthcare organizations, despite their compliance complexity, are not lagging behind in DevOps maturity.

2. Automation Adoption Is a Competitive Differentiator

Healthcare is outpacing other industries when it comes to adopting automation throughout the database development process. Survey respondents cited three primary motivators for automation investment:

• Free up developer time — cited by 27% of respondents
• Increase speed of delivery — cited by 22%
• Reduce the risk of data loss — cited by 13%

The prominence of data-loss risk reduction as a driver is particularly telling. In healthcare, a database error is not merely a technical inconvenience — it can directly impact patient safety and regulatory standing. Automation reduces the manual touchpoints where errors are most likely to occur.

3. Cloud Migration Is Underway but Not Yet Dominant

Forty-two percent of healthcare respondents reported using the cloud in some capacity for their database workloads. While this reflects significant progress, healthcare has historically been cautious about cloud adoption due to HIPAA and other regulatory requirements around data residency and security. The expectation at the time of this research was that cloud adoption would accelerate as remote work and telehealth services increased reliance on scalable, cloud-native infrastructure.

4. Version Control Is Being Used as a Compliance Foundation

Fifty-eight percent of healthcare respondents reported having version control measures in place for their database code, enabling automated builds and deployments. This is a meaningful compliance enabler: version control creates an auditable, repeatable development process that reduces the risk of unauthorized or unintended changes reaching production databases containing protected health information (PHI). For regulated industries, the ability to demonstrate that every change was reviewed, approved, and traceable is central to audit readiness.

5. Database Deployment Frequency Is Rising Sharply

One of the most concrete indicators of DevOps maturity is deployment frequency. In the 2020 data, 51% of healthcare respondents reported deploying database changes daily or weekly — a significant jump over prior years. Among North American respondents specifically, 55% reported deploying database changes daily, weekly, or on demand.

“What’s surprising this year is the way North American respondents are surging ahead, with 55% saying that they deploy database changes daily, weekly or even on demand. This indicates that they’re embracing Agile practices to better meet the needs of doctors, patients and remote services like telehealth that rely on these databases each day.”

— Kendra Little, DevOps Advocate, Redgate

Why Database DevOps Matters in Healthcare Specifically

Traditional DevOps conversations in healthcare tend to focus on application code — the APIs, front-end portals, and integration layers that connect systems. But databases are where the most sensitive and operationally critical data lives. EHR systems, claims databases, lab result repositories, and prescription management platforms all depend on the integrity and availability of their underlying databases.

Database DevOps addresses several healthcare-specific challenges:

• Compliance and auditability: Automated pipelines with version-controlled database changes provide the audit trail that HIPAA and other regulations require.
• Reducing human error in production: Manual database changes are a leading cause of outages and data integrity issues. Automated, tested deployments reduce this risk.
• Faster response to clinical requirements: Telehealth platforms and patient portals need to evolve quickly. Database DevOps removes bottlenecks that slow down schema changes and data migrations.
• Consistent environments: Development, staging, and production parity — a core DevOps principle — is especially important when debugging issues that involve patient data.

Takeaways for Healthcare Engineering Teams

If your organization is still treating database changes as a separate, manually-managed process outside your CI/CD pipeline, the data above suggests you are behind where your peers are heading. Practical first steps include:

1. Bring database scripts into version control alongside application code. Tools like Redgate SQL Source Control, Liquibase, and Flyway make this tractable for most database platforms.
2. Integrate database changes into your CI pipeline so that schema migrations are tested automatically on every pull request.
3. Automate compliance checks — static analysis and policy enforcement can flag changes that would introduce risk before they reach production.
4. Track deployment frequency as a metric. If your team cannot deploy database changes at least weekly without a manual change-control process that spans days, that is a signal to examine your pipeline.

The healthcare sector’s DevOps journey is accelerating. For database teams still operating in isolation from their application counterparts, the window to modernize — before compliance requirements or competitive pressures force a reactive overhaul — is narrowing.

Oracle Cloud’s newly launched VMware service takes an architectural approach that puts the channel front and center in selling, implementation and management, Ross Brown, vice president for go-to-market at Oracle Cloud Infrastructure, told CRN.

The market has been flooded with hyperscalers offering their versions of hosted VMware environments in recent years. But Oracle VMware Cloud Solution is unique in its ability to seamlessly operate alongside all types of workloads while empowering partners with full operational control, said Brown, a former VMware channel chief.

“In cloud, I have to serve all my IT: VMware workloads, VDI, cloud-native stuff. All those things have to work there, and those things are by definition partner integrated and delivered,” Brown said.

[Related: Oracle Cloud Preparing To Introduce Nvidia’s New A100s]

Oracle VMware Cloud Solution launched Thursday in all of Oracle’s global cloud regions, as well as through its on-premises cloud solution, Dedicated Region Cloud@Customer. The service, unveiled before last year’s Oracle OpenWorld conference, had previously been available only to beta customers through a limited release.

Oracle’s approach to delivering a native VMware service was grounded in the belief that hybrid and multi-cloud will become the norm for most enterprises, and the granular workings of hosted VMware environments should be entirely accessible and seamlessly interoperable with other workloads.

In recent years, VMware has forged alliances with the public cloud providers it once competed with, starting with Amazon Web Services and then moving on to Microsoft Azure and Google Cloud Platform.

Oracle didn’t want to emulate any of those plays, Brown said.

Instead, the Redwood Shores, Calif.-based tech giant focused on the question: “How do you build a more performant cloud that actually allows partners to engage on their workloads and go run them?” Brown said.

Microsoft Azure and Google Cloud offer dedicated hardware to run VMware that customers can connect to the rest of their cloud instances. And VMware Cloud on AWS also stands apart from the native AWS environment, Brown said.

“AWS doesn’t offer VMware. VMware offers VMware on AWS. You can build a connection back to your AWS tenancy, but it’s still separate,” he told CRN.

Oracle took a different tack, integrating the full VMware stack—vSphere, NSX network virtualization, vSAN storage virtualization, vRealize management—directly into the same bare-metal clusters that comprise the rest of the customer’s cloud tenancy.

The comprehensive integration of OCI with the VMware Cloud Foundation stack and VMware tools was an endeavor that Oracle product and engineering teams worked on for two years.

“VMware is a pretty detailed infrastructure environment,” Brown said. “It maximizes the hardware. It’s definitely not a lightweight tool, and it operates at a very thin layer.”

That approach, while technically challenging, delivers certain advantages—especially to the channel.

For starters, all VMware and third-party tools that partners currently use to manage on-premises VMware environments will work just the same in Oracle’s cloud.

“They operate identically because we’re running the same physical infrastructure, just as a cloud service,” Brown said.

With granular control over nearly all infrastructure operations, VMware partners can offer a complete catalog of managed services, just as they would if they stood up vSphere in their own data centers. Oracle allows them to create a VMware region and offer their customers shared tenancy, then use the complete set of MSP tools that VMware distributes through its VMware Cloud Provider Program.

“The notion of moving on-premises hardware into a cloud environment, still have everything work the same way, and have all management contracts go along with it, is pretty powerful,” Brown said.

Oracle also is the first cloud to allow customers to select a version of the ESX hypervisor, which is useful for those with apps certified for specific ESX releases.

“If I want to get under the hypervisor and do things with vCloud Director, we’re the only cloud that can do that,” he said.

Oracle’s partnership with VMware reflects its larger philosophy of cloud being an approach, not a place, Brown said.

But Oracle certainly hasn’t yet built a reputation as a VMware provider—the companies are better known for a longstanding rivalry predating their cloud transformations.

That’s another reason Oracle set out to build an offering that empowers the channel, Brown said, as it needs partners to be the trusted advisers that bring the service to enterprise customers.

“I‘m glad to see more native support from Oracle on their customers’ platforms of choice,” said David Klee, founder and chief architect at VMware partner Heraflux.

A native VMware platform on Oracle Cloud will further encourage the channel to migrate Oracle databases out of on-premises data centers and into the cloud, Klee told CRN.

“I‘m eager to see how this cloud platform continues to evolve and expand, and what other service offerings they will add in the future to complement this big shift in their model,” he said.

The product that appears to be stimulating the most customer interest for Oracle VMware Cloud Solution is Dedicated Region Cloud@Customer, Brown said. The on-premises infrastructure unveiled in June offers the same array of services, SLAs and pricing models as Oracle’s public cloud.

On-premises Exadata hardware running cloud-native apps built with Kubernetes and legacy ones built on VMware is a compelling offer to many large Oracle customers, Brown told CRN.

Oracle Executive Chairman and CTO Larry Ellison praised the solution last September in an OpenWorld keynote.

“We have a very important relationship with VMware,” Ellison said. ”The VMware stack you‘re running on-premises, you really can lift and shift it intact to the Oracle Cloud.”

Background: Why Dockerize at All?

One advantage of working for an application management vendor is broad visibility into how development and operations teams architect, build, and deploy software. After absorbing those patterns across many customers, the site reliability team at Instana decided to share their own experience dockerizing the one remaining application in their portfolio that was still running outside of Docker.

Instana operated two distinct delivery models: a SaaS platform and a self-hosted, on-premises version of its back-end management servers. The SaaS side was already containerized; the on-premises version was packaged as RPM and DEB binaries stitched together by a Chef cookbook that had grown organically to cover every edge case discovered over time. The goal was to close that gap and give on-premises customers the same quality, cadence, and ease of operation enjoyed by SaaS customers.

Should You Dockerize? Three Questions to Answer First

Before committing to a containerization effort, the team framed the decision around three specific questions:

1. Should you re-architect your application to use containers? — Containers are not the right answer for every workload. Evaluate whether your application’s operational pain points — inconsistent environments, slow releases, complex dependency management — are problems containers actually solve.
2. Is Docker the right container technology? — Docker has broad enterprise adoption, and the Open Container Initiative (OCI) standard means images built today remain compatible with emerging runtimes such as CRI-O. That longevity matters when you are making a multi-year infrastructure commitment.
3. Is now the right time? — Timing a migration requires honest assessment of team bandwidth, release schedule risk, and customer impact. Instana’s trigger was that the lag between SaaS and on-premises releases was actively growing, customer interviews confirmed frustration, and the SaaS artifacts were already containerized — meaning the raw material for the migration already existed.

The Architecture Before Dockerization

The legacy delivery pipeline packaged SaaS binaries into RPM/DEB packages to support multiple Linux distributions. A Chef cookbook wired the components together and handled configuration. Over time, the cookbook accumulated logic to handle:

• Multiple Linux distribution variants
• Multi-host deployment topologies (beyond the original single-host model)
• Multiple cloud environments: AWS, Google Cloud Platform, Microsoft Azure, and private data centers

This complexity created unpredictable release cycles, slowed QA qualification, and meant on-premises customers always lagged behind SaaS customers in getting new capabilities.

Choosing and Implementing Docker

Because the SaaS platform already used Docker images (orchestrated by Nomad and Kubernetes), the core application containers were ready. The main work involved creating containers for third-party infrastructure components — including ClickHouse, Cassandra, and other databases — and integrating them into the release pipeline.

The team’s key architectural insight: creating a database container is not the hard part — managing its configuration in a repeatable, trackable way is.

Their solution was to use a host-mounted volume (mount point) for all configuration files. This approach:

• Keeps configuration changes outside the container, on the host file system
• Makes every change auditable and version-controllable
• Allows debug bundles to be collected from the host without exec-ing into a running container
• Simplifies the docker run directive because the container itself does not encode environment-specific state

Originally adopted out of necessity for database containers, this mount-point pattern turned out to be repeatable across all containers in the stack, creating an unexpected but valuable layer of standardization.

Lessons Learned: Practical Gotchas When Dockerizing

Despite a largely smooth migration, three specific issues surfaced that are worth knowing before you start your own containerization project.

1. ulimits on CentOS Are Lower Than You Expect

During the first CentOS rollout, ClickHouse failed to write to disk as expected. The initial assumption was a database misconfiguration, but the root cause was the system’s default ulimits — specifically the open-file-descriptor limit, which is set surprisingly low in some CentOS configurations.

The team considered modifying the ulimit on the host but recognized that each customer environment could configure ulimits differently, making that approach fragile. The better solution: use Docker’s --ulimit flag when launching the container.

docker run --ulimit nofile=65536:65536 my-clickhouse-image

The --ulimit flag sits at the top of Docker’s override hierarchy, so it reliably enforces the required limit regardless of what the host OS or customer configuration specifies.

2. Eliminate Docker Network Overhead with Host Networking

Network overhead introduced by Docker’s default bridge networking was a legitimate concern, especially for latency-sensitive inter-component communication. Because the deployment model is single-host (all components on one machine), the team used Docker’s host network mode:

docker run --network host my-service-image

This removes the virtual network interface layer entirely, giving containers direct access to the host network stack and eliminating potential throughput or latency bottlenecks from the Docker networking layer. Note that this trade-off is appropriate for a single-host model; multi-host or multi-tenant deployments require a different approach.

3. Bind Systemd Services to docker.service

Once customers saw the reliability of the new platform, their automated maintenance tools began issuing system updates — reboots, patch cycles — without Docker-aware sequencing. Docker’s own restart policy (--restart always or --restart unless-stopped) is not sufficient to guarantee that containers start in the correct order after a host reboot or a forced service restart triggered by an external automation tool.

The fix was to define explicit systemd unit files for each container service and bind them to docker.service using After= and Requires= directives. This ensures that no application container attempts to start before the Docker daemon is fully up, and that startup ordering between dependent services is enforced by the init system rather than left to timing luck.

[Unit]
Description=My Application Container
After=docker.service
Requires=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/docker run --name my-app my-app-image
ExecStop=/usr/bin/docker stop my-app

[Install]
WantedBy=multi-user.target

Results After Six Months in Production

According to the team, the outcomes exceeded their original goals:

• SaaS and self-hosted releases now ship simultaneously — a goal that was not even stated at the start of the project.
• QA qualification cycles are shorter, particularly for operating system compatibility testing, because a validated container image behaves consistently across distributions.
• Release cycles are more predictable — the variability introduced by the Chef cookbook’s edge-case logic is gone.
• Support complexity dropped significantly — because the team no longer needs to reason about version skew between SaaS and on-premises deployments.
• All customers receive new capabilities at release time, not weeks or months later.

What Comes Next: Kubernetes for Self-Hosted

With Docker packaging standardized across the product, the team’s stated next step is scalability: extending the self-hosted platform to support Kubernetes-based deployment, bringing it into full alignment with the SaaS architecture already running on Nomad and Kubernetes.

Key Takeaways

• If your SaaS artifacts are already containers, you have most of the raw material needed for an on-premises containerization project.
• Use host-mounted configuration volumes to keep container images environment-agnostic and configuration changes auditable.
• Do not rely on Docker’s restart policy alone for production startup ordering — use systemd unit bindings.
• Check ulimits early, especially on CentOS and RHEL-family hosts; use Docker’s --ulimit flag to enforce the values your workload actually needs.
• For single-host deployments, --network host eliminates an entire category of networking overhead concerns.
• Even organizations without containerized workloads in production often permit vendor-supplied Dockerized installations — OCI adoption has made Docker a broadly acceptable delivery format.

What Was Azure Stack ‘Fiji’?

According to reporting by ZDNet in August 2020, Microsoft was working on a new hybrid cloud product internally codenamed Azure Stack ‘Fiji’. The goal: give customers a rack of Microsoft-supplied servers, installed on-premises or in a colocation facility, but fully managed through the Azure public cloud — much like Amazon’s AWS Outposts model.

If accurate, Fiji would represent a significant evolution in Microsoft’s hybrid strategy, moving away from partner-delivered appliances toward Microsoft-owned and Microsoft-managed hardware infrastructure delivered directly to customers.

The Competitive Context: AWS Outposts and Google Anthos

Microsoft was actually an early mover in hybrid cloud, beginning to sell Azure Stack in July 2017. However, competitor offerings that followed raised the bar:

• AWS Outposts — Made generally available in December 2019, Outposts extends AWS infrastructure, APIs, and services directly into customer datacenters or colocation facilities. AWS positions it as a fully managed service for workloads requiring low latency, local data processing, or local data storage.
• Google Cloud Anthos — A managed application platform that runs on-premises (on Google-provided or customer hardware) and across multiple clouds, with centralized management from Google Cloud.

Azure Stack Fiji was reportedly aimed squarely at matching the AWS Outposts model: rack-scale hardware supplied by the cloud vendor, managed entirely through the provider’s public cloud fabric rather than by the customer’s own operations team.

How Fiji Would Differ from Existing Azure Stack Products

At the time of the report, Microsoft’s hybrid portfolio already included several distinct products. Understanding where Fiji would fit requires knowing the landscape:

The key distinction for Fiji would be who manages the hardware. Azure Stack Hub relies on partner-certified hardware and places operational responsibility on the customer. Fiji, like AWS Outposts, would shift that management burden back to the cloud provider.

The Role of Azure Arc

The ZDNet report speculated that Fiji’s management plane would be Azure Arc, Microsoft’s control-plane service for managing resources across on-premises, multi-cloud, and edge environments from a single Azure portal. Arc already allows operators to project Kubernetes clusters, servers, and data services running outside Azure into Azure Resource Manager for unified governance, policy enforcement, and monitoring.

Using Arc as the management fabric for Fiji-class hardware would be a logical extension — giving enterprises a consistent operational experience whether their workloads run in an Azure region or in their own datacenter on Microsoft-owned infrastructure.

Engineering Challenges Microsoft Would Need to Solve

The ZDNet report noted that delivering a product like Fiji is technically non-trivial. Microsoft would need to address:

• Service architecture changes — Azure services built to run at global-region scale must be adapted to run on a much smaller hardware footprint inside a customer facility.
• Security model adjustments — Hardware sitting in a third-party datacenter requires a revised trust boundary, hardware attestation approach, and physical security model compared to hardware inside Microsoft’s own facilities.
• Hardware configuration and supply chain — Microsoft would need to manage logistics, racking, cabling, and lifecycle operations for hardware it owns but that lives on customer premises at scale.
• Connectivity requirements — Fiji instances would need reliable, low-latency connectivity back to Azure for management plane operations, similar to the connectivity requirements AWS imposes on Outposts deployments.

Microsoft’s Official Response

When ZDNet asked Microsoft for comment on the Fiji project, a spokesperson responded that “Microsoft has nothing to share.” No further public confirmation or denial was offered at the time of the original report.

Why This Matters for DevOps and Platform Engineers

For teams evaluating hybrid cloud architecture, the direction signaled by projects like Fiji has practical implications:

• Reduced operational overhead — If the cloud provider manages the hardware, your team focuses on workloads and configuration, not firmware updates, drive replacements, or capacity planning at the hardware layer.
• Consistent APIs — Running on the same hardware and software stack as the public cloud means the same SDKs, CLI tools, and IaC templates (ARM, Bicep, Terraform) apply without significant modification.
• Data residency and latency — Regulated industries or latency-sensitive applications can keep data on-premises while still consuming managed cloud services and tooling.
• Hybrid GitOps workflows — Azure Arc-managed infrastructure enables GitOps-style deployment and policy enforcement across both cloud and on-premises environments from a single control plane.

Current Status

This reporting dates from August 2020. Since then, Microsoft has continued to evolve Azure Arc and the broader Azure Stack portfolio. Whether the internal ‘Fiji’ project shipped under that name, was folded into another product, or was cancelled is not confirmed in the original source. Readers should consult current Microsoft documentation and announcements for the latest on Azure’s hybrid offerings.

The Problem: Secrets Leaking into Public Repositories

GitHub is central to modern software development, giving teams a shared platform to collaborate on code and publish open-source projects. But the same openness that makes it powerful also creates a persistent security risk: developers occasionally commit sensitive material — API tokens, database passwords, private keys, and cloud credentials — directly into repositories without realising it.

Once a secret is pushed to a public repository, it can be indexed, cached, or harvested by automated scanners within minutes. Even a brief exposure can result in account takeovers, data breaches, or unauthorised cloud spending. At enterprise scale, where hundreds or thousands of developers are committing code daily, the probability of at least one accidental exposure climbs significantly.

What Is xGitGuard?

Researchers at Comcast developed xGitGuard, an AI-powered tool designed to detect credentials and other private information that has been inadvertently posted to GitHub. The tool was publicly demonstrated during an Arsenal session at the Black Hat USA 2020 virtual conference on August 7, 2020.

According to Bahman Rashidi, senior cybersecurity researcher and system architect at Comcast, the tool is deliberately lean and fast — two properties that matter enormously when scanning a platform as large as GitHub, which hosts more than 30 million repositories.

“xGitGuard is an AI-based tool designed to detect if and when private information is improperly posted on GitHub (such as passwords or credentials). Comcast technologists developed the tool to address a challenge common in software development environments where large numbers of developers are using GitHub on a daily basis.”

— Bahman Rashidi, Comcast, speaking to The Daily Swig

How xGitGuard Works

The core innovation in xGitGuard is its text-processing algorithm, which analyses not just whether a string looks like a secret, but also the surrounding context within a file. This contextual awareness is what allows the tool to achieve a high detection accuracy while keeping false-positive rates low — a key weakness of simpler pattern-matching approaches.

Key Capabilities

• Context-aware detection: The algorithm inspects the text surrounding a candidate secret, not just the token string itself, improving precision.
• Low false-positive rate: By combining machine learning with efficient text processing, xGitGuard reduces noise compared to regex-only tools.
• Enterprise scalability: The tool is architected to operate at the scale of large organisations, where many repositories and contributors must be monitored continuously.
• Smart use of the GitHub Search API: Rather than brute-forcing every repository, xGitGuard introduces a targeted query-generation approach that works within GitHub’s API rate limits while still covering a broad search surface.

“GitHub contains more than 30 million repositories and with API limitations, it is challenging to find secrets in a timely manner. xGitGuard introduces a new search approach that can utilize the existing GitHub search API and review search results at scale.”

— Bahman Rashidi, Comcast

Why Existing Tools Fall Short

Secret-scanning is not a new problem, and several tools — both open-source and commercial — already exist to address it. Common approaches rely on regular expressions to flag strings that match known secret formats (for example, AWS access key prefixes or GitHub personal access token patterns). While effective at catching obvious cases, pure regex matching suffers from two well-known weaknesses:

• High false-positive rates: Placeholder values, test fixtures, and example credentials in documentation frequently match secret patterns without actually being secrets.
• API rate limiting: Naively querying GitHub’s search API at scale quickly exhausts rate limits, making comprehensive scanning slow or impractical.

Comcast’s claim is that xGitGuard’s ML-driven, context-aware approach directly addresses both of these limitations — though independent benchmarks comparing it against alternatives such as truffleHog, gitleaks, or GitHub’s own secret-scanning feature were not published as part of the Black Hat presentation.

Practical Implications for DevOps and Security Teams

For DevOps and platform-security teams, the inadvertent exposure of secrets in source control remains one of the most common and most avoidable classes of security incident. Tools like xGitGuard are most useful as part of a layered defence that also includes:

• Pre-commit hooks that block secrets from being committed in the first place (e.g., git-secrets, detect-secrets).
• CI/CD pipeline scanning that checks each pull request for credential patterns before code is merged.
• Repository-wide periodic scans to catch secrets that slipped through earlier controls — the problem xGitGuard is specifically designed to solve.
• Secrets management platforms (HashiCorp Vault, AWS Secrets Manager, etc.) to eliminate the need to store credentials in code at all.

A continuous scanning tool that monitors an organisation’s GitHub presence for leaked secrets — especially one tuned to minimise alert fatigue through low false-positive rates — fills a genuine gap in the above stack.

Availability

xGitGuard was presented as an open-source tool at Black Hat 2020’s Arsenal track. Readers interested in the tool should search for the Comcast xGitGuard repository on GitHub and consult the project’s own documentation for up-to-date installation and usage instructions, as project status may have changed since the 2020 release.

Summary

xGitGuard represents Comcast’s practical response to a problem every large engineering organisation faces: keeping secrets out of public code repositories when hundreds of developers are pushing code every day. By combining a context-aware ML algorithm with a smarter approach to the GitHub Search API, the tool aims to deliver faster, more accurate detection than traditional pattern-matching solutions — and to do so at enterprise scale.

What Is SNMP and Why Does Monitoring It Matter?

Simple Network Management Protocol (SNMP) is one of the most widely deployed protocols for monitoring and managing network infrastructure. Defined in a series of IETF RFCs, SNMP allows management systems to collect performance data, receive alerts, and in some cases reconfigure devices — all over a standardised UDP-based interface (port 161 for queries, port 162 for traps).

SNMP is supported by virtually every enterprise-grade router, switch, firewall, server, UPS, and storage device, making it a foundational layer of network observability. Even in environments that have adopted modern telemetry protocols such as gNMI or OpenTelemetry, SNMP often remains the only option for older or embedded hardware.

Core SNMP Architecture Components

Understanding what SNMP monitoring tools actually manage requires familiarity with the four main architectural components that any tool in this space must handle:

• SNMP Manager — The central management station (or software process) that sends queries (GET, GETNEXT, GETBULK) to devices and receives trap notifications. This is the engine of any SNMP monitoring tool.
• SNMP Agent — Software running on the managed device (router, server, printer, etc.) that listens for manager requests, reads the relevant counters or state variables, and returns responses. Agents also proactively send traps when threshold events occur.
• Managed Devices — The physical or virtual infrastructure being monitored: network switches, routers, firewalls, servers, storage arrays, environmental sensors, and any other SNMP-capable endpoint.
• Management Information Base (MIB) — A hierarchical, tree-structured schema that defines every object an agent can expose. Each object has a unique Object Identifier (OID). Vendors publish proprietary MIBs alongside the standard MIBs defined by the IETF (e.g., MIB-II, IF-MIB).

A capable SNMP monitoring tool must be able to parse and walk MIBs, poll agents on configurable intervals, correlate traps to known thresholds, and visualise or alert on the resulting data.

SNMP Versions: v1, v2c, and v3

Most tools on the market support all three SNMP versions, but the choice matters for security:

• SNMPv1 — The original 1988 specification. Community-string authentication only; data sent in plain text. Avoid in production where possible.
• SNMPv2c — Adds GETBULK for efficient bulk retrieval and 64-bit counters (critical for high-speed interfaces). Still uses plain-text community strings.
• SNMPv3 — Introduces authentication (MD5 or SHA) and optional encryption (DES or AES). The only version suitable for environments with security or compliance requirements. Many organisations still run v2c internally due to device or tooling limitations.

Key Vendors in the SNMP Monitoring Tool Space

The market research report cited Cisco Systems, Nagios Enterprises, Microsoft, OpenNMS Group, HCL, and Zoho as notable players. Here is a brief, factual description of each vendor’s known position in this space:

Cisco Systems

Cisco is both a major producer of SNMP-capable devices and a vendor of network management platforms. Products such as Cisco Prime Infrastructure and Cisco DNA Center include built-in SNMP polling and MIB management for Cisco hardware.

Nagios Enterprises

Nagios is one of the most widely known open-source-rooted monitoring platforms. The core Nagios engine, along with Nagios XI (the commercial product), supports SNMP polling and trap handling through a rich ecosystem of community and commercial plugins. Nagios XI ships with built-in MIB management and trap translation.

Microsoft

Microsoft’s System Center Operations Manager (SCOM) includes network device discovery and SNMP-based monitoring. Windows Server also ships with an optional SNMP service that can expose Windows performance counters to external managers. Microsoft’s position in pure-play SNMP tooling is secondary to its role as a managed-device platform.

OpenNMS Group

OpenNMS is an open-source enterprise network management platform with strong SNMP capabilities including auto-discovery, SNMP data collection, MIB compiler, and trap daemon. The OpenNMS Group offers commercial support and the Horizon and Meridian distributions.

HCL Technologies

HCL has network and infrastructure management offerings, including tools that incorporate SNMP monitoring as part of broader IT operations management suites.

Zoho (ManageEngine)

Zoho’s ManageEngine division produces OpManager, a widely deployed network monitoring platform that supports SNMP v1/v2c/v3 polling, MIB browsing, and trap processing. ManageEngine also offers dedicated tools such as MibBrowser Free Tool and OpUtils.

Other Widely Used SNMP Monitoring Tools

The vendor list above is not exhaustive. Other tools with strong SNMP support that DevOps and network teams commonly deploy include:

• PRTG Network Monitor (Paessler) — Sensor-based model; dedicated SNMP sensors for standard and custom OIDs.
• Zabbix — Open-source; supports SNMP polling and traps natively with flexible MIB-based item discovery.
• LibreNMS — Open-source auto-discovering network monitoring system built on SNMP, with a large community MIB library.
• SolarWinds Network Performance Monitor — Commercial platform with deep SNMP integration and automated MIB compilation.
• Checkmk — Combines agent-based and SNMP-based monitoring with automated device discovery.

Typical Application Areas

SNMP monitoring tools are used across a range of operational scenarios:

• Network performance monitoring — Interface utilisation, error rates, packet loss, and latency on routers and switches.
• Hardware health monitoring — CPU and memory usage, fan speeds, temperature sensors, and power supply status on servers and appliances.
• Availability monitoring — Up/down detection via SNMP reachability and trap-based alerts.
• Capacity planning — Long-term trending of bandwidth, storage, and resource utilisation data collected via SNMP.
• Compliance and auditing — Verifying device configurations and software versions across a managed fleet.

Geographic Market Distribution

SNMP monitoring tool adoption is global, reflecting the ubiquity of enterprise networking. The market research report identified the following major regions as relevant to the analysis:

• North America (United States, Canada, Mexico)
• Europe (Germany, UK, France, Russia, Italy, Turkey, and others)
• Asia-Pacific (China, Japan, India, Australia, South Korea, Vietnam, Malaysia, Thailand, Philippines, Indonesia)
• South America (Brazil and others)
• Middle East and Africa (GCC countries and Egypt)

North America and Europe have historically represented the largest markets for enterprise network monitoring software, driven by large financial services, healthcare, and telecommunications sectors with complex infrastructure requirements.

Evaluating an SNMP Monitoring Tool: Key Criteria

When assessing tools for your environment, consider the following criteria:

• MIB support and compiler — Can the tool import vendor-specific MIBs and translate OIDs into human-readable names?
• SNMPv3 support — Is SNMPv3 with AES encryption fully supported, not just documented?
• Trap handling — Can the tool receive, parse, deduplicate, and alert on SNMP traps in addition to active polling?
• Scalability — How many devices and polling intervals can the system handle before performance degrades? Distributed pollers matter at scale.
• Discovery — Does the tool auto-discover devices using SNMP, CDP, LLDP, or network range scanning?
• Integration — Does it integrate with alerting systems (PagerDuty, Opsgenie), ITSM platforms (ServiceNow, Jira), or observability stacks (Grafana, Prometheus)?
• Licensing model — Per-device, per-interface, per-sensor, or subscription-based pricing has significant budget implications at enterprise scale.

SNMP in the Context of Modern Observability

SNMP coexists with — rather than being replaced by — modern observability tooling. Streaming telemetry protocols (gNMI/gRPC) offer lower latency and better scalability for high-end platforms, but SNMP remains the only supported management interface for a large proportion of installed network equipment. Most mature monitoring platforms support both, allowing teams to use streaming telemetry where available and fall back to SNMP elsewhere.

The practical approach for most organisations is to treat SNMP as a required baseline capability, layer modern telemetry on top for supported devices, and centralise all data into a unified observability platform.

Using Work Item Templates

Azure Boards is excellent for tracking work, but if your team creates dozens of similar Work Items each day — each requiring the same description, priority level, or custom field values — that repetition adds up fast. Work Item templates solve this by letting you pre-fill a defined set of fields with saved values.

Creating a Template

1. Open an existing Work Item that already has the field values you want to reuse.
2. Click the ellipsis (…) in the top-right area of the Work Item form.
3. Select Templates → Capture.
4. On the Capture Template page, click Remove unmodified fields to strip out any fields you did not intentionally set. This keeps the template focused and prevents accidental overwrites.
5. Give the template a descriptive name, verify the field-value pairs, and save.

Applying a Template

1. Open a new, blank Work Item of the same type.
2. Click the ellipsis (…) and choose Templates.
3. Select the template you created. All pre-defined fields are populated instantly.

Templates are scoped to a specific Work Item type (Task, Bug, User Story, etc.), so a Task template will not appear when you open a Bug, keeping the list clean and relevant.

Tagging Work Items Effectively

Tags are free-text labels you attach to any Work Item. Adding a tag takes seconds, but the real value emerges only when the team agrees on a consistent tagging taxonomy and then uses those tags inside queries and dashboards.

A few practical guidelines:

• Agree on a naming convention up front. For example, use ProjectX rather than project-x, projectX, or Project X. Inconsistent casing creates separate tags that behave differently in filters.
• Limit the total number of tags. A long, unmanaged tag list is as useless as no tags at all.
• Assign tag governance to a specific role — typically the person building reports and dashboards — so the list stays meaningful over time.

Harnessing the Power of Queries

Queries are the engine behind Azure DevOps reporting. Every widget on a dashboard, every emailed status update, and every backlog filter can be driven by a saved query. Investing a little time in building well-structured queries pays dividends every sprint.

Building a Query

1. Navigate to Boards → Queries.
2. Add field conditions using the query editor. For example: Work Item Type = Task AND State = Active AND Tags contains ProjectX.
3. Use Add new clause to combine multiple conditions.
4. Click Run query to preview results in the panel below the editor.

Saving and Sharing Queries

Once a query returns the data you need, save it. You have two save locations:

• My Queries — visible only to you.
• Shared Queries — visible to all team members with access to the project. Dashboard widgets can only reference queries saved in Shared Queries or My Queries belonging to the dashboard owner.

Sending Emails Directly from Azure DevOps

Sharing a query result or Work Item status via email used to mean taking screenshots, pasting them into an email client, and hoping the formatting survived. Azure DevOps removes that friction with a built-in email action.

Look for the mail icon or Send email option on query result pages and individual Work Items. Clicking it opens a compose view where you can:

• Search for recipients by name within your Azure DevOps organization.
• Add a personal note or context.
• Include the query results or Work Item details automatically in the message body.

This is particularly useful during daily stand-ups or sprint reviews when stakeholders need a quick snapshot without logging into Azure DevOps themselves.

Building Dashboards for a Single Pane of Glass

Dashboards aggregate the information from your tags, queries, and Work Item fields into a visual overview. A well-built dashboard lets a team lead check project health in under a minute.

Getting Started

1. Expand Overview in the left navigation and click Dashboards.
2. Click Add a widget or Edit on an existing dashboard.
3. Search the widget catalog for the widget you want and click Add.

Recommended Widgets

Adding Conditional Formatting to Query Tile

The Query Tile widget supports color-coded thresholds, making it easy to spot problems at a glance. In the widget’s Configuration panel you can define rules such as:

• Green when the count is fewer than 5
• Blue when the count is between 5 and 10
• Red when the count exceeds 10

Both the Query Tile and Query Results widgets can point to the same underlying saved query, so your count and your detailed list always reflect identical data.

When you are satisfied with the layout, click Done Editing to save the dashboard.

Keyboard Shortcuts

Azure DevOps includes a set of keyboard shortcuts that speed up navigation and common actions without reaching for the mouse. To view them:

• Click the ellipsis (…) on any Work Item and select Keyboard shortcuts for a concise reference.
• Click Full list of keyboard shortcuts at the bottom of that panel to see every available shortcut across Boards, Repos, Pipelines, and more.

Shortcuts are particularly valuable for keyboard-first users who move quickly between backlogs, sprint boards, and individual Work Items.

Putting It All Together

Each of these features delivers incremental value on its own, but the compounding effect is where the real productivity gain lives:

• Templates eliminate repetitive data entry when creating Work Items.
• Tags provide a flexible cross-cutting classification system.
• Queries turn tags and field values into filterable, shareable data sets.
• Dashboards surface query results as visual KPIs and task lists.
• Email integration gets query results to stakeholders without leaving Azure DevOps.
• Keyboard shortcuts reduce navigation overhead for power users.

Azure DevOps is a constantly evolving platform. The features described here represent a foundation — there is considerably more to explore in areas like Pipeline YAML templates, branch policies, artifact feeds, and test plan management. Treat these tips as a starting point and build from there as your team’s maturity with the platform grows.

Overview: What Changed and Why It Matters

In August 2020, Microsoft executed a notable internal reorganization that reshuffled responsibilities across its Windows + Devices and Azure business units. Unlike the smaller round of layoffs the company made earlier that summer, this restructuring was not primarily a headcount reduction—it was a strategic realignment of teams, leadership roles, and product ownership.

The headline move: Microsoft brought parts of its Azure organization, specifically the COSINE team, into the Experiences and Devices (E+D) organization led by Panos Panay. The goal was to help Windows and Surface teams build more cohesive, end-to-end user experiences and to give the Surface hardware team stronger software and services alignment.

Key Leadership Changes in Windows + Devices

The most significant individual change was Michael Fortin joining Panos Panay’s Experiences and Devices organization. His expanded role combines services teams from COSINE and 365 Experiences and Services into a single new team.

Several COSINE team leads also moved into Panay’s org, including:

• Kevin Gallo
• Mark Alcazar
• Kristian Andaker

This move is particularly notable for developers: because Kevin Gallo was closely associated with Project Reunion (now known as the Windows App SDK), his transfer to the Windows org likely means Project Reunion moved under Windows leadership—widely considered a more natural home for the initiative than Azure.

Additional Windows + Devices org changes included:

• Jeff Johnson leading a newly formed Windows, Developer, and Experiences engineering team.
• Linda Averett joining Windows + Devices to lead a new Windows, Developers, and Experiences PM team.

Leadership positions that remained stable:

• Ralf Groene continuing to lead the Design Team.
• Stevie Bathiche continuing to lead the Applied Sciences Group.
• Robin Seiler now leading the Devices Portfolio and Operations (DPO) team.

Key Changes on the Azure Side

The reorganization was not limited to Windows. Azure also saw structural changes designed to consolidate infrastructure services and prepare for emerging markets.

New Azure Core Team

A new Azure Core team was formed by consolidating Compute, Networking, and Storage services under a single umbrella, spanning both PM and engineering. Girish Bablani was tapped to lead this team.

Azure Edge + Platform

The legacy COSINE team was reorganized by merging services from ASME, PIE, and the remaining COSINE components to create a new team: Azure Edge + Platform. Henry Sanders was appointed to a newly created role of CTO of Azure Edge + Platform.

Azure for Operators: 5G and Virtual Networking

A new Azure for Operators organization was established to pursue opportunities in 5G and virtual networking. This team brought together leadership from two recent Microsoft acquisitions:

• Anand Krishnamurthy, CEO of Affirmed Networks.
• Martin Lund, CEO of Metaswitch.

The formation of Azure for Operators signals Microsoft’s intention to compete in the carrier and telecommunications infrastructure market, an area where cloud vendors see significant growth potential.

Strategic Pillars for Windows + Devices

To understand the thinking behind the Windows + Devices reorganization, Microsoft articulated three strategic pillars guiding the org’s product decisions:

1. Deliver iconic experiences across Microsoft, enabling both modern work and personal use cases.
2. Grow the Windows and Surface business by delivering the best of Microsoft and creating end-user demand.
3. Lead the industry through innovation and technology, enabling the partner ecosystem to thrive.

Context: Surface Business Momentum

The restructuring came on the heels of strong Surface hardware sales in Microsoft’s fiscal year 2020. One significant shift noted at the time: while Microsoft had historically maintained roughly a 50/50 split between consumer and commercial Surface sales, the end of FY20 saw that balance tilt heavily toward commercial customers—likely driven by enterprise remote-work purchasing during the COVID-19 pandemic.

The new organizational structure was designed to build on that commercial momentum by better integrating cloud services with the hardware and software experience.

What This Means for DevOps and Developer Teams

For engineering and DevOps teams that build on Microsoft’s platform, a few implications are worth watching:

• Project Reunion / Windows App SDK ownership moving to Windows leadership could accelerate delivery of a unified Windows development model, reducing fragmentation between Win32 and UWP application models.
• Azure Core consolidation of Compute, Networking, and Storage under a single leadership team may eventually improve cross-service consistency and integration for infrastructure teams.
• Azure for Operators signals a serious push into 5G and edge networking infrastructure, which is relevant to teams building latency-sensitive or distributed applications.
• New organizational boundaries always create transition periods—expect some turbulence in roadmap communication and team contacts while the new structure stabilizes.

All changes described above were reported as effective immediately as of the original publication date in August 2020. Given how quickly Microsoft’s organizational structure evolves, current team names and leadership assignments should be verified against up-to-date Microsoft sources.

Infostretch, a leader in digital engineering services, has announced that it has achieved the status of Advanced Consulting Partner in the Amazon Web Services (AWS) Partner Network (APN). To achieve this certification, Digital Engineering Services (DES) firm Infostretch had to undergo a meticulous approval process to demonstrate the company’s knowledge, experience and customer success with AWS. The AWS partnership comes as Infostretch continues to expand and strengthen its global strategic partner network, having recently announced a partnership with continuous testing leader Tricentis.

To help enterprise delivery teams accelerate their digital initiatives on the AWS cloud, Infostretch has developed sixteen AWS solution packages. These “accelerators” and “enablers” draw upon the company’s competencies in cloud engineering, data analytics, DevOps and IoT to allow its customers to benefit from the capabilities of the AWS at an accelerated pace. These include data engineering and IoT accelerators as well as enablers for the data pipeline, DevOps and Microservices.

Recommended AI News: Bright Pattern Contact Center Chosen By Everise

Infostretch has also developed solutions for specific industries to use with AWS. This includes Healthcare Data Analytics Platform (HDAP), a new data accelerator built on AWS for companies in the healthcare ecosystem to harness their healthcare data assets more effectively. By integrating and collaborating with AWS, Infostretch has built a unique set of AWS experiences for its customers, designed to reduce resource requirements, cost, time and project risk.

Headquartered in Silicon Valley, Infostretch has over 70 AWS Certified Experts among its ranks and has already delivered many AWS cloud enablement projects for its customers including Westhill. The company’s ‘Go, Be, Evolve’ digital approach aims to help clients at any stage in their digital maturity journey from strategy, planning, migration, and execution to production scaling and automation.

Recommended AI News: UiPath Named A Leader In The 2020 Gartner Magic Quadrant For Robotic Process Automation

“We were creating a first-of-its-kind, extremely complex platform ecosystem, leading with speed and security of data,” commented Larry Parker, Chief Product Officer & Founder of Westhill. “Infostretch had the proven experience and scale to deliver on our vision. They designed a robust architecture, fully mapped to AWS, which is already paying dividends for our business. Our customers highlight efficiencies in our solution every week, and that’s a testament to the technology.”

“With Advanced Consulting Partner status, Infostretch is now among the elite of cloud enablement partners globally,” said Rutesh Shah, Infostretch Chief Executive Officer and Co-Founder. “But we’re not stopping there. To extract the most value out of AWS and set up digital initiatives for long-term success requires deep expertise, which we’ve developed over the years. We’ve crystallized this expertise into accelerators and enablers that will fundamentally improve the AWS experience for our clients – and deliver better results for them at speed.”

Google Cloud recently announced that it will now be the cloud provider for Wipro Limited’s enterprise-wide systems applications and products in data processing (SAP) footprint.

The partnership will bring SAP applications and workloads to the cloud to support over 180,000 of Wipro’s employees.

Specializing in global information technology, Wipro will modernize and transform its enterprise resource planning (ERP) system to SAP’s flagship, which is the company’s leading product.

Dig Deeper
Google Cloud, Orange Partner to Boost AI, Edge Computing Services
Google, Box Extend Partnership to Transform Work in the Cloud
Google Cloud Launches Multi-Cloud Solution to Help Orgs Analyze Data
Wipro will then relocate SAP workloads onto Google Cloud Platform (GCP), Google officials said.

“Wipro is embracing digital transformation at speed and scale. By modernizing their core systems and technologies with Google Cloud, they have a powerful and scalable foundation to accelerate their strategic enterprise priorities and build for the future,” Thomas Kurian, CEO, Google Cloud, said in the announcement.

As part of the collaboration, Wipro will leverage G Suite for some of its employees as a workplace productivity platform. Wipro believes that G Suite has strong interoperability and security controls and features that allow for real-time collaboration, even in remote work environments.

“As a provider of digital transformation services to some of the world’s most impactful businesses, it is critical that our own core systems and technologies are running on intelligent and modern platforms that encompass the needs of the future,” said Bhanumurthy B.M, president and chief operating officer, Wipro Limited.

“This transformation program will help us to run our most business-critical workloads and applications with speed and agility, and to support our customers more effectively.”

Wipro’s industry-focused solutions, with Google Cloud technologies, enable enterprises to future-proof their IT investments, Google officials said. And Wipro’s Google Cloud practice also helps transform businesses and healthcare organizations as well.

This transformation includes application modernization, data analytics, artificial intelligence, SAP workload migration, and industrialized cloud migrations at scale.

Additionally, Wipro integrated Anthos, Google’s open platform for managing applications, into its services offerings to enable hybrid cloud deployments for customers.

Back in April 2019, Google launched Anthos, a platform to allow providers to run applications, unmodified, on existing hardware investments or in the public cloud.

Anthos allows healthcare organizations to manage workloads running on third-party clouds like AWS and Azure, to deploy, run, and manage applications on the cloud, without requiring administrators to learn different environments and APIs, Google officials said.

And in mid-July of this year, Google launched BigQuery Omni, a multi-cloud analytics platform designed to help customers to bring the power of BigQuery to data stored in Google Cloud, Amazon Web Services (AWS), and Microsoft Azure.

Through Anthos, BigQuery Omni aims to support enterprises with breaking down silos and creating actionable business insights at an affordable price.

“The ability to run the same database on multiple cloud/data center environments is an important consideration when selecting a new data platform,” said Matt Aslett, research director, data, AI and analytics, 451 Research, in a statement.

“As hybrid and multi-cloud adoption has become the norm, enterprises are increasingly looking for data products that provide a consistent experience and lower complexity of using multiple clouds, while enabling the ongoing use of existing infrastructure investments,” he added.

This article examines ten practical ways AI is accelerating DevOps today, drawing on published industry data and practitioner perspectives.

Industry Context

Several market signals underscore why AI adoption in DevOps is accelerating:

• Startups offering AI-powered software development tools raised $704 million over the twelve months ending September 2019, according to a Deloitte report published in 2020.
• IDC forecast the global market for custom application development services to grow from $47 billion in 2018 to more than $61 billion in 2023, a 5.3% CAGR.
• Poor software quality cost US organizations an estimated $319 billion in 2019, according to the Consortium for IT Software Quality.
• Gartner predicted that 40% of DevOps teams would be using application and infrastructure monitoring tools with integrated AIOps capabilities by 2023.

These numbers frame a clear business case: AI investment in DevOps is driven by the twin pressures of accelerating delivery speed and reducing the cost of defects.

1. AI-Powered Code Completion and Autosuggestion

One of the highest-impact AI applications in DevOps is real-time code autosuggestion. Tools trained on large code corpora use supervised machine learning to predict the next logical code segment as a developer types, reducing keystrokes, lookup time, and context switching.

Early implementations were inconsistent, but improvements in supervised ML models—particularly around how quickly models adapt to a team’s specific codebase and style—have made suggestions significantly more accurate. Microsoft’s Visual Studio IntelliCode is a widely adopted example in this category. DevOps practitioners in enterprise CRM, supply chain, and social media companies have cited AI code autosuggestion as the single most productivity-positive AI capability they have adopted.

2. Streamlining Requirements Management

Managing requirements documents is one of the most time-consuming non-coding tasks DevOps teams face. Requirements go through multiple iterations, involve stakeholders with varying levels of technical literacy, and must remain tightly aligned with the evolving codebase.

AI—and specifically Natural Language Processing (NLP)—is being applied to assist with drafting, editing, validating, and cross-referencing requirements. NLP models can flag ambiguous language, identify contradictions between requirements, and suggest standardized phrasing. Teams adopting AI-based requirements management tools have reported requirements review time reductions of more than 50%, allowing engineers to redirect effort toward coding and design. Atlassian’s Jira Software is widely used as a foundation for structured requirements workflows in enterprise DevOps environments.

3. AI-Assisted Bug Detection and Code Remediation

Static analysis has long been part of code review pipelines, but AI is taking defect detection further by predicting where bugs are likely to occur and suggesting remediation steps before a human reviewer encounters the issue.

Facebook has publicly described a bug detection system that predicts defects and suggests remedies with approximately 80% accuracy. GitHub’s CodeQL (originally developed by Semmle) is a widely used tool in this space; it allows teams to query their codebase for known vulnerability patterns and logical variants across the entire repository. Microsoft’s security response team has used CodeQL to find variants of critical vulnerabilities, enabling faster response and reducing the blast radius of discovered flaws.

4. Prioritizing and Triaging Security Vulnerabilities

Security scanners can generate thousands of findings per scan. Without intelligent triage, teams waste significant time on false positives or low-risk issues while genuinely critical vulnerabilities wait in the queue.

ML models trained on historical vulnerability data and developer remediation patterns can score and rank findings by their likelihood of being true positives and by their actual exploitability in context. Maty Siman, CTO of Checkmarx, has described this challenge and the ML-based solution clearly: models learn which vulnerability types have a statistically higher rate of being genuine threats, allowing AppSec and development teams to focus remediation effort where it matters most. Siman notes that the security landscape evolves continuously, and ML systems that adapt at the same pace are essential for teams that cannot manually review every alert.

5. Automated Test Case Generation and Optimization

Writing and maintaining test cases is a specialized skill that sits at the intersection of deep product knowledge and software engineering. As codebases grow, test suites become difficult to maintain: coverage gaps emerge, redundant tests accumulate, and skilled testers are perpetually backlogged.

AI-based testing tools address this by auto-generating test cases based on analysis of code structure, user flows, and historical defect patterns. These tools can also identify overlapping test coverage, remove redundant cases, and shift the focus from reactive defect detection to proactive defect prevention—predicting which code paths are most likely to fail under specific load or input conditions before tests are run manually.

6. Managing Complex Module Dependencies

Large enterprise applications consist of dozens or hundreds of interdependent modules. A change in one area can produce unexpected failures in others, and mapping these dependencies manually is error-prone and time-consuming.

AI-based development platforms can automatically map and monitor inter-module dependencies, flagging high-risk change propagation paths before a release. This improves overall product quality and gives release managers better information about which components need additional testing when a given module is modified.

7. Post-Release Defect Prediction and Root Cause Analysis

Even with rigorous pre-release QA, defects emerge in production. The cost of identifying, diagnosing, and fixing production defects is significantly higher than catching the same issue during development. AI is being applied to predict which areas of a released application are most likely to fail in specific customer environments before they actually do.

Beyond prediction, AI tools assist with root cause analysis—correlating logs, traces, and metrics to pinpoint the origin of a failure faster than manual investigation allows. One enterprise CRM team reported a 72% reduction in time-to-restore in customer environments after adopting AI-assisted root cause analysis. Other teams have used AI to auto-configure application settings to optimize performance for specific deployment profiles.

8. Anomaly Detection and Real-Time Security Monitoring

ML models can establish a statistical baseline of normal behavior across application performance metrics, code commit patterns, API call volumes, and infrastructure telemetry. Deviations from that baseline—anomalies—are flagged in real time for human review.

Checkmarx’s Maty Siman has described this approach: given a baseline of normal developer and application activity, ML can identify and surface anomalies that indicate either a security threat or an emerging performance issue before it affects end users. This kind of continuous, automated vigilance is not achievable at scale through manual monitoring alone.

9. Cross-System Analytics for Process Improvement

Advanced DevOps teams are applying AI not just to code, but to the development process itself. By aggregating data from version control systems, CI/CD pipelines, APM platforms, issue trackers, and release management tools, ML models can surface patterns that explain why some projects deliver on time with high quality while others fall into prolonged review and rework cycles.

Enterprise DevOps teams in supply chain management have used supervised ML to identify these patterns and build genuinely data-driven engineering cultures. The goal is to move from anecdotal postmortems to quantitative, predictive process improvement—understanding what leading indicators predict a troubled sprint before the sprint ends.

10. Improving Traceability and Cross-Team Collaboration

In distributed teams spanning multiple geographies, keeping requirements, code changes, test outcomes, and release decisions aligned is a persistent challenge. AI-driven traceability tools help maintain clear links between user requirements, implemented features, test coverage, and shipped releases—making it possible to identify exactly where a gap in collaboration or data integration caused a quality or schedule problem.

AI-driven insights also help distributed teams understand how shared specifications need to account for localization requirements, region-specific performance constraints, and unique customer configurations—surfacing these gaps earlier in the cycle rather than at release time.

Building a Framework for AI-Driven DevOps

Adopting individual AI tools is only part of the opportunity. The teams seeing the greatest gains are those that have integrated AI capabilities into a coherent DevOps strategy—one that embeds security into every development phase (DevSecOps), incorporates quality assurance throughout the pipeline rather than as a gate at the end, and uses analytics to drive continuous improvement.

Frameworks that help enterprises operationalize this integration—connecting AI capabilities across planning, development, testing, security, release, and operations—are an active area of vendor development. The core principle is consistent: AI delivers the most value in DevOps when it is woven into the workflow rather than bolted on as a separate tool.

Conclusion

AI is accelerating DevOps across every phase of the SDLC—not by replacing engineers, but by handling the repetitive, time-consuming tasks that take them away from high-value work. Code autosuggestion, intelligent test generation, ML-based vulnerability triage, anomaly detection, and cross-system process analytics are all delivering measurable improvements in speed, quality, and security today.

The teams realizing the greatest benefit are those treating AI adoption as a strategic, integrated initiative rather than a series of point-tool experiments. As the underlying models improve and more SDLC data becomes available to train them, the gap between AI-augmented DevOps teams and those operating without these capabilities will continue to widen.

Cloud Computing Revenues Hit New Highs in Q2 2020

The world’s leading cloud computing providers reported another strong quarter in Q2 2020, driven largely by an accelerating global shift toward remote working triggered by the COVID-19 pandemic. Both Google Cloud and Amazon Web Services (AWS) posted significant year-on-year revenue growth, reinforcing the position of cloud infrastructure as one of the technology sector’s most resilient and fastest-growing segments.

AWS: $10.81 Billion in Q2 Revenue Despite Pandemic Headwinds

Amazon Web Services reported Q2 2020 revenues of $10.81 billion, representing year-on-year growth of 29%. While impressive in absolute terms, this marked the first time AWS growth had slipped below the 30% threshold, down from 33% recorded in Q1 2020.

Amazon acknowledged that the coronavirus pandemic had disrupted certain enterprise partnerships and affected consumption patterns among some of its largest customers. Nevertheless, AWS revenue accounted for approximately 12% of Amazon’s total revenue for the quarter, underlining the division’s strategic importance to the parent company’s overall financial performance.

Despite the pandemic-related friction, AWS expanded or deepened partnerships with high-profile organisations during the quarter, including video conferencing platform Zoom, workplace messaging tool Slack, and Formula 1, reflecting continued enterprise and media-sector appetite for scalable cloud infrastructure.

Google Cloud: 43% Year-on-Year Growth to $3.007 Billion

Google Cloud posted Q2 2020 revenues of $3.007 billion, up 43% year-on-year from $2.1 billion in Q2 2019, and up from $2.77 billion in the previous quarter. The growth rate was slightly below the 52% year-on-year increase recorded in Q1 2019, but represented a continued strong trajectory for the division.

Google CFO Ruth Porat commented on the results:

“GCP maintained the strong level of revenue growth it delivered in the first quarter, and its revenue growth was again meaningfully above cloud overall.”

Porat also addressed the slightly moderated growth rate in G Suite (now Google Workspace), attributing it to a pricing comparison effect:

“Overall, the lower Google Cloud revenue growth in the second quarter relative to the first quarter reflects the fact that G Suite lapped a price increase that was introduced in April last year. G Suite maintained healthy growth in average revenue per seat as well as in seat growth, which does not include customers who took advantage of our free trials as they shifted their employees to work-from-home.”

Google Cloud: A Bright Spot for Alphabet

Google Cloud’s strong performance was a notable bright point in an otherwise difficult quarter for parent company Alphabet. Q2 2020 marked the first quarterly revenue decline since Alphabet went public, with total revenue of $31.6 billion — a marginal drop from $31.7 billion recorded in the same period the previous year. The decline was driven primarily by a contraction in advertising revenue as businesses cut marketing budgets during the pandemic.

In this context, the cloud division’s double-digit growth served as a significant counterbalance, and analysts took note of its growing contribution to Alphabet’s overall revenue mix.

Microsoft Azure Also Surges 27% Year-on-Year

The strong results from Google Cloud and AWS were mirrored by the third member of the major cloud triad: Microsoft Azure. Azure revenues grew 27% year-on-year in Microsoft’s equivalent reporting period, driven by soaring demand for remote collaboration tools and cloud-hosted infrastructure. Microsoft’s Teams platform saw explosive adoption over the same period, further reinforcing Azure’s position as a full-stack enterprise cloud solution.

What This Means for the Cloud Market

The Q2 2020 results across all three hyperscalers point to several important trends for DevOps and infrastructure engineering teams:

• Remote work as a demand catalyst: The rapid shift to distributed teams pushed organisations to accelerate cloud migrations that might otherwise have taken years.
• Resilience of cloud revenue models: Even as overall corporate revenues contracted across many sectors, cloud infrastructure spending proved relatively insulated.
• Competitive dynamics remain tight: AWS retains the largest market share, but Google Cloud’s higher growth rate suggests it is closing the gap, at least in percentage terms. Azure’s enterprise positioning gives it a distinct advantage in regulated industries.
• SaaS integration matters: Google’s G Suite and Microsoft’s Teams/Office 365 ecosystem demonstrate how bundling productivity software with cloud infrastructure can drive seat-based recurring revenue.

For engineering teams evaluating cloud strategy, the financial health of these providers is a relevant signal: continued investment in infrastructure, tooling, and regional expansion is more likely when revenue growth remains strong.

Video: Cloud Computing Context

The Core Problem: Service Account Sprawl in DevOps Environments

Modern DevOps pipelines rely heavily on automation, infrastructure-as-code, and elastic cloud environments. One persistent security friction point in these pipelines is the management of privileged credentials for workloads and services—the non-human accounts that applications use to authenticate to databases, APIs, vaults, and other services.

Traditional approaches to this problem, often called Application-to-Application Password Management (AAPM), improved on hardcoded credentials by moving secrets into a vault. However, they introduced a new operational burden: each application or service still required its own dedicated service account in the vault, complete with a credential and a rotation schedule. In large enterprises, this can mean managing hundreds or thousands of service accounts—slowing down DevOps teams and creating a wide attack surface for adversaries to exploit.

Password vaults were originally designed to manage human administrative logins to servers. Applying them to machine-to-machine authentication at scale creates bottlenecks that developers resent and security teams struggle to govern in fast-moving CI/CD environments.

What Centrify Announced: Delegated Machine Credentials (DMC)

On July 28, 2020, Centrify announced Delegated Machine Credentials (DMC) as part of the Centrify Privileged Access Service (PAS). The feature is designed to address service account sprawl by shifting the unit of identity from the individual application or service to the machine on which those workloads run.

How DMC Works

• Machine enrollment: The Centrify Client enrolls the host machine into the Centrify Platform, giving it a unique machine identity and credential.
• Role-based permissions: The Centrify Platform automatically assigns role-based permissions to the machine and defines which vault APIs that machine is permitted to call.
• Credential delegation: Workloads, applications, containers, and services running on that machine can then delegate the machine’s identity to authenticate to target resources—without needing their own separate service accounts in the vault.
• Scoped, time-limited tokens: Rather than issuing long-lived shared credentials, DMC issues short-lived access tokens scoped to a specific resource and period of time, limiting the window of exposure if a token is compromised.

The result is that one machine identity can serve all the workloads running on it, rather than requiring a separate vault service account for every application, microservice, or container.

The “Federation for Machine Identities” Analogy

Garrett Bekker, principal security analyst at 451 Research (part of S&P Global Market Intelligence), offered a useful conceptual frame for understanding DMC:

“Conceptually, delegated machine credentials can be thought of as ‘federation for machine identities,’ in the sense that rather than applications sharing passwords or secrets directly, the Centrify client can broker a temporary access token between Centrify’s PAS and target resources – applications, service accounts, containers, and APIs. DMC creates a machine identity and issues a scoped token that is only valid for a defined period of time, in lieu of using many service accounts with long-lived credentials that present a greater attack window.”

— Garrett Bekker, Principal Security Analyst, 451 Research / S&P Global Market Intelligence

This federation analogy is instructive for DevSecOps practitioners already familiar with identity federation concepts in human-user SSO: instead of each application managing its own trust relationship with a vault, the machine acts as an intermediary trust anchor, and the Centrify Platform brokers access on its behalf.

Why This Matters for DevSecOps Pipelines

The announcement positions DMC specifically as an enabler of “PAM as a first-class citizen in the CI/CD pipeline.” The practical implications for DevSecOps teams include:

• Reduced manual processes: Eliminating per-application service account creation removes a recurring operational task from already-stretched Ops teams.
• Smaller attack surface: Fewer service accounts with long-lived static credentials means fewer potential entry points for attackers exploiting privileged credential abuse.
• Infrastructure-as-code compatibility: Machine enrollment and permission assignment can be automated, allowing PAM configuration to be managed alongside other infrastructure definitions in tools like Terraform or Ansible—without requiring developers to manually provision vault credentials for each new service.
• Improved developer agility: Developers are no longer required to integrate vault client code into every application that needs to retrieve a credential, reducing friction in the development workflow.

DMC vs. Traditional AAPM: A Comparison

Centrify’s Broader Identity-Centric PAM Position

DMC is part of Centrify’s broader strategy of Identity-Centric Privileged Access Management—a model that emphasizes verifying who (or what) is requesting access, the context of that request, and the risk of the environment, rather than simply managing passwords in a vault. The approach applies least-privilege and just-in-time access principles to both human and machine identities across hybrid and multi-cloud environments.

David McNeely, Chief Strategy Officer at Centrify, summarized the security rationale at the time of the announcement:

“The explosive growth of machine and service accounts in the enterprise is creating a wealth of opportunity for cyber-attackers to sneak into the enterprise. Our infrastructure-as-code approach makes PAM a ‘first class citizen’ in the CI/CD pipeline, eliminating the need for thousands of potential exposure points while increasing agility.”

— David McNeely, Chief Strategy Officer, Centrify

Key Takeaways for DevSecOps Engineers

• If your organization is managing a large number of vault service accounts for automated workloads, DMC-style approaches (whether from Centrify or other vendors) are worth evaluating as a way to reduce that account sprawl.
• Short-lived, scoped tokens are a security improvement over long-lived static credentials for machine-to-machine authentication—a principle also reflected in cloud-native approaches like AWS IAM roles for EC2 instances or Kubernetes service account tokens.
• Embedding PAM tooling into your infrastructure-as-code workflows (rather than bolting it on afterward) reduces the likelihood of credentials being hardcoded or manually managed outside of governance controls.
• Evaluate whether your current AAPM approach requires per-service vault accounts and, if so, what the operational and security cost of that sprawl is at your current scale.

Note: Centrify has undergone corporate changes since this announcement. Readers evaluating Centrify products should verify current product availability and naming directly with the vendor.

Microsoft Confirms CyberX Acquisition

Microsoft officially confirmed its acquisition of CyberX, an industrial IoT (IIoT) cybersecurity startup based in Waltham, Massachusetts. The announcement came more than a month after Israeli media outlets first reported that the two companies were in the final stages of a deal. While Microsoft did not publicly disclose the purchase price, multiple reports — including one from TechCrunch — placed the deal at approximately $165 million.

The acquisition was announced in a blog post co-authored by Microsoft executives Michal Braverman-Blumenstyk (CTO, Microsoft Security) and Sam George (VP, Azure IoT), who outlined how CyberX would be integrated into Microsoft’s existing Azure cloud security portfolio.

Why CyberX? Filling the Industrial IoT Security Gap

Microsoft’s Azure platform already offered multi-layer IoT security and monitoring capabilities prior to this acquisition. However, CyberX addresses a specific and growing challenge: securing devices in industrial IoT (IIoT), operational technology (OT), and critical infrastructure environments — settings where traditional IT security tools often fall short.

Many industrial environments run legacy equipment — programmable logic controllers (PLCs), SCADA systems, industrial sensors — that cannot run security agents. These unmanaged devices present significant blind spots for security teams. CyberX’s platform is designed specifically for this problem.

What CyberX Brings to the Table

Founded in 2013, CyberX had raised $48 million across five funding rounds and employed approximately 163 people at the time of the acquisition. Its most recent round — $18 million closed in April 2019 — was led by Qualcomm Ventures and Inven Capital.

CyberX’s core product is an agentless cybersecurity platform built for industrial environments. Key capabilities include:

• Passive asset discovery: Automatically identifies and inventories unmanaged IIoT and OT devices without requiring agents or active scanning that could disrupt sensitive industrial equipment.
• Continuous network monitoring: Monitors OT networks in real time for anomalous behavior, unauthorized changes, and indicators of compromise.
• Vulnerability management: Profiles each discovered device — including firmware version, open ports, and known CVEs — to help operators understand their attack surface.
• Threat intelligence: Applies threat intelligence specific to industrial control systems (ICS) to identify attack patterns relevant to OT environments.
• Digital asset mapping: Produces a visual map of thousands of devices across a factory floor or facility, showing asset relationships and communication paths.

The platform’s XSense product line focuses specifically on anomaly detection and threat intelligence for securing industrial operations and reducing unplanned downtime caused by cyber incidents.

Integration with Azure Sentinel and the Broader Azure Security Stack

One of the most significant planned integrations at the time of the announcement was with Azure Sentinel, Microsoft’s cloud-native Security Information and Event Management (SIEM) platform. The addition of CyberX’s OT visibility data was expected to give Sentinel the ability to surface cyber threats targeting operational technology assets — something most enterprise SIEMs are not equipped to do out of the box.

This matters because OT attacks — such as those targeting power grids, water treatment facilities, or manufacturing lines — can have physical consequences that go well beyond data theft. Correlating OT signals with IT telemetry inside a unified SIEM is a meaningful step toward converged IT/OT security operations.

Microsoft’s executives also emphasized that the acquisition did not signal a retreat from ecosystem partnerships. Third-party security vendors providing on-the-ground expertise and integration services for OT environments would remain an important part of Microsoft’s go-to-market approach.

CyberX’s Customer Base and Market Position

At the time of the acquisition, CyberX counted among its customers two of the top five U.S. energy providers, a top-five global pharmaceutical company, a top-five U.S. chemical company, and national electric and gas utility operators across Europe and Asia-Pacific. This roster reflects the company’s strength in regulated, high-consequence industries where OT security failures carry serious operational and safety risks.

Strategic Context: The Growing IIoT Security Market

The CyberX acquisition fits into a broader trend of major cloud and security vendors moving to address the OT/ICS security market. Industrial environments are increasingly connected to corporate IT networks and the internet — expanding the attack surface dramatically. High-profile incidents targeting industrial control systems (such as attacks on energy infrastructure) have heightened awareness of the risks.

For Microsoft, adding native OT visibility to Azure IoT and Azure Sentinel positions the company to compete more directly for security budgets in manufacturing, energy, utilities, and critical infrastructure — sectors where Azure was already making inroads through its broader cloud platform.

The acquisition also reflects the difficulty of building ICS/OT security expertise organically. CyberX’s founding team had backgrounds in Israeli military intelligence cyber units, giving it deep domain knowledge in adversarial ICS attack techniques — the kind of institutional knowledge that is hard to replicate quickly.

What This Means for DevOps and Security Teams

For engineering and security teams operating in or adjacent to industrial environments, the key takeaways from this acquisition are:

• OT asset visibility is now a first-class Azure capability. Teams managing hybrid IT/OT environments can expect tighter integration between IIoT device inventory and Azure security tooling.
• Azure Sentinel gains OT context. Security operations teams using Sentinel for IT incident detection can anticipate expanded coverage for OT threats in the same interface.
• Agentless coverage matters. The agentless approach is not optional in OT — it is often a hard requirement. Any security tooling for industrial environments must accommodate devices that cannot run software agents.
• IT/OT convergence security is accelerating. As digital transformation pushes more industrial systems online, the boundary between IT and OT security is dissolving. Architects designing connected factory or smart grid solutions should plan for security tooling that spans both domains.

Note: This article is based on reporting from CRN and TechCrunch from June 2020 and Microsoft’s original acquisition announcement blog post. CyberX technology has since been rebranded and integrated into Microsoft’s security portfolio as Microsoft Defender for IoT.