Sysdig Expands Open Source Leadership

In August 2019, Sysdig, Inc. announced the appointment of Kris Nova as Chief Open Source Advocate, a move intended to meet surging demand for the company’s open source security tooling. At the time of the announcement, Sysdig reported a 240 percent increase in adoption of Falco, its open source runtime security project, over the preceding nine months. To support that growth, the company stated it had more than quadrupled the engineering resources dedicated to its open source projects.

Falco was accepted into the Cloud Native Computing Foundation (CNCF) Sandbox in October 2018. By mid-2019 it had attracted production users across government agencies, financial institutions, Fortune 2000 enterprises, and web-scale companies, with contributions from organizations including Frame.io, Shopify, Snap, and Booz Allen Hamilton.

Who Is Kris Nova?

Kris Nova brought deep Kubernetes and cloud-native credentials to the role. Before joining Sysdig, she was a Senior Developer Advocate at Heptio/VMware and, prior to that, a developer advocate and Kubernetes engineer at Deis/Microsoft. Her open source contributions include creating kubicorn, a Kubernetes infrastructure management tool written in Go. Nova also served as a CNCF Ambassador and organized multiple Kubernetes Special Interest Groups (SIGs).

She is the author of Cloud Native Infrastructure (O’Reilly), a practitioner-focused book on designing and running distributed cloud-native systems. Her focus areas at Sysdig were defined as security, intrusion detection, Linux kernel internals, Kubernetes, and eBPF.

“Sysdig is full of genuine and smart Kubernetes experts, the people you want building the projects used to protect your environments. Falco needs to be in any stack and I look forward to helping people to understand why and how to implement.”

— Kris Nova, Chief Open Source Advocate, Sysdig (2019)

“Kris Nova is a Kubernetes pioneer, and we look forward to continuing to grow Falco and drive adoption together.”

— Loris Degioanni, CTO and Founder, Sysdig

Falco: Technical Highlights as of Mid-2019

By the time of Nova’s hire, the Falco project had reached several notable technical milestones:

• eBPF integration: Falco became, by Sysdig’s account, the first major security and behavioral activity monitoring tool for containers powered by Extended Berkeley Packet Filter (eBPF) at the Linux kernel level. This allows syscall capture without kernel module requirements on supported kernels.
• Kubernetes Audit Policy support: Falco was among the first open source security projects to integrate with the Kubernetes Audit Policy, enabling an additional stream of API-server events for threat detection.
• Falco Operator: A Kubernetes Operator was released to automate day-to-day Falco lifecycle management, with inclusion in OperatorHub.io.
• Google Cloud Platform Marketplace: In April 2019, Falco was added to the GCP Marketplace, lowering the barrier to deployment for GCP users.
• containerd and CRI-O support: The Falco 0.15.0 release added support for the containerd and CRI-O container runtimes, enabling compatibility with Red Hat, IBM Cloud, and GKE environments running older platform versions.
• Falco rules library: Released in August 2019, this library lets enterprises adopt community-contributed detection rules without writing them from scratch.

Open Source Roadmap and Governance

A central part of Nova’s mandate was establishing a formal governance model for Falco — a prerequisite for the project advancing beyond the CNCF Sandbox stage. The planned governance work included:

• Defining clear standards and guidelines for contributors and maintainers.
• Implementing Prow, the Kubernetes-native CI and developer productivity tooling already in use by other CNCF projects, to automate common maintainer tasks.
• Introducing more fine-grained access control for project resources.
• Reducing maintainer toil by enabling contributors to run common tasks via CLI commands rather than web GUIs.

Sysdig also noted that approximately 30 percent of its engineers were active contributors to the company’s open source projects at the time, with a commitment to grow that share.

Beyond Falco, Sysdig announced continued involvement with the OpenStack Security SIG — a cross-company working group focused on OpenStack ecosystem security — and membership in the Linux Foundation’s Continuous Delivery Foundation (CDF).

Sysdig’s Open Source History

Sysdig was founded in 2013 and launched with sysdig, an open source Linux system exploration and troubleshooting tool. The company subsequently created two additional open source projects:

• Falco — runtime security and anomaly detection for cloud-native workloads.
• Sysdig Inspect — an open source interface for analyzing sysdig capture files.

By mid-2019, the company reported that its three open source projects had collectively attracted a community of millions of developers, sysadmins, and IT professionals. Sysdig has also been an active adopter and contributor to third-party open source projects including Kubernetes, Prometheus, and Anchore.

Why This Matters for DevOps and Security Teams

The appointment of a dedicated open source advocate at a vendor-backed CNCF project reflects a broader trend: as cloud-native security tooling matures, projects require structured governance to remain credible with enterprise adopters. For DevOps and platform engineering teams, the implications are practical:

• Governance matters for compliance: Enterprises subject to regulatory requirements need assurance that open source tooling follows reproducible, auditable development processes.
• eBPF is becoming foundational: Falco’s adoption of eBPF for syscall capture signals a direction the broader security tooling ecosystem has continued to follow.
• Rules-as-code reduces toil: Community-maintained rules libraries mean security teams can benefit from collective threat intelligence without maintaining detection logic entirely in-house.
• Operator pattern simplifies operations: The Falco Operator enables declarative, Kubernetes-native deployment and lifecycle management, fitting naturally into GitOps workflows.

Note: Kris Nova passed away in August 2023. Her contributions to the Kubernetes and cloud-native communities remain widely recognized.

Azure DevOps Server 2019 Update 1 Is Generally Available

Microsoft has released the final version of Azure DevOps Server (ADS) 2019 Update 1 as generally available. The release — targeting the on-premises product formerly known as Team Foundation Server — delivers a new Basic process template, analytics improvements, enhanced GitHub integration, and a range of pipeline and repository quality-of-life upgrades.

New Basic Process Template

Prior to this update, teams starting a new project had to choose from three process templates: Agile, Scrum, and CMMI. Each carries a learning curve, particularly for smaller teams or those new to structured project tracking. The new Basic process template offers a simpler entry point with three core work item types:

• Issues — for tracking features, bugs, and user stories
• Epics — for grouping related Issues together
• Tasks — for granular planning and day-to-day tracking

This stripped-back model suits teams that want to get started quickly without configuring the full Agile or Scrum field sets.

Improved GitHub Integration

ADS 2019 Update 1 deepens the connection between Azure DevOps and GitHub in two important areas:

GitHub Release Task for Azure Pipelines

A new GitHub Release task is available in Azure Pipelines. Teams can add this task to a pipeline to automate the creation of GitHub releases and generate accompanying release notes, reducing manual steps in the release process.

Azure Boards and GitHub Cross-Linking

The Azure Boards GitHub Integration now supports creating links between Azure Boards work items and GitHub pull requests, issues, and commits. A practical example: a team can accept bug reports through GitHub Issues while tracking the remediation work on a linked Azure Board. This keeps engineers working in GitHub while giving project managers full visibility in Boards.

Pull Request and Repository Enhancements

The repository experience has received several targeted improvements:

• Automatic queuing of expired builds — builds that expired before running are now automatically re-queued.
• Fast-forward and semi-linear merge strategies — additional merge options are available when completing pull requests, giving teams more control over their Git history.
• Target branch filter — a new filter makes it easier to find pull requests targeting a specific branch in repositories with high PR volume.
• Draft pull requests — developers can now create a PR in draft state by selecting Create as draft from the Create button dropdown. This is useful for work in progress or when preparing for review without triggering notifications prematurely.

YAML Pipeline Authoring Improvements

Writing and maintaining YAML pipelines is easier in this release thanks to two additions in the pipeline web editor:

• IntelliSense support — when enabled in the YAML editor, IntelliSense surfaces syntax errors and provides inline suggestions, reducing the feedback loop on pipeline authoring mistakes.
• Task assistant — accessible via the Edit option for YAML-based pipelines, the task assistant helps users build common pipeline task definitions without needing to memorise YAML schemas.

Pipeline Deployment and CI Skip Options

Automatic Rollback on Deployment Failure

Azure Pipelines can now be configured to automatically redeploy the last successful deployment if a deployment stage fails. This reduces the manual intervention needed when a bad deployment reaches a stage environment, helping teams recover faster.

Skipping CI on a Commit

To skip the continuous integration pipeline for a specific commit, include [skip ci] in the HEAD commit message. This works for both Azure Repos Git and GitHub Enterprise Server repositories.

git commit -m "Update README [skip ci]"

Azure Boards Updates

Several Azure Boards improvements ship with this update:

• Board status badges — boards can now be shared as embeddable badges, similar to build-status badges, giving external stakeholders a quick visual summary.
• Time-based query macros — new macros allow users to query what has changed since the start of the current day, week, month, or year, simplifying recurring reporting tasks.
• Edit and delete work item comments — a highly requested feature: users can now edit or delete comments they made in work item discussion threads.

Analytics Now Built In

Previously, accessing analytics in ADS required installing a separate Analytics extension. With ADS 2019 Update 1, analytics can be enabled directly from the Project Collection settings, removing the extension dependency and streamlining the setup process for administrators.

Where to Find the Full Release Notes

The changes summarised here cover the most impactful updates for development and DevOps teams. Microsoft publishes a complete list of enhancements and bug fixes in the official ADS 2019 Update 1 release notes on the Azure DevOps documentation site.

Why IT Teams Are Under More Pressure Than Ever

Teamwork, agility, and communication consistently separate high-performing IT teams from the rest. The demands placed on IT organisations have never been greater: deliver new features faster, manage ballooning data volumes, stay within tighter budgets, and do more with fewer resources. Meeting all of these expectations simultaneously requires a fundamental rethink of how development and operations collaborate.

The DevOps philosophy is grounded in a simple but powerful belief: development and operations are not separate disciplines that hand work over a wall — they are one unified team that shares goals, tools, accountability, and knowledge. The name itself reflects that interdependence.

The Silo Problem: Why Traditional Approaches Fall Short

Successful organisations constantly seek ways to innovate, expand, and improve — and IT systems are central to that ambition. But traditional project delivery models frequently get in the way, because development and operations teams work in isolation from each other.

The Limits of Agile Alone

Agile development advocates early delivery and continuous improvement, and it represents a genuine improvement over older waterfall approaches. However, a common implementation gap persists: the operations team is rarely involved during development. Once software is built and deployed, responsibility passes to operations — a team that had no input during creation and may have limited understanding of the new release’s requirements or failure modes.

This handoff creates risk. Operations teams are often the closest to real-world user problems, yet they are excluded from the development process precisely when their insight would be most valuable. The result is software that has never been stress-tested against actual production conditions before it goes live.

A Cautionary Example: Rushed Releases and Real-World Consequences

The 2016 Samsung Galaxy Note 7 battery crisis is frequently cited as a high-profile illustration of what can go wrong when competitive pressure overrides rigorous testing. Reports at the time indicated that Samsung accelerated its development and quality-assurance timelines in order to launch ahead of a competitor release. The outcome — devices that could overheat and catch fire — led to a global recall, significant financial losses, and lasting reputational damage.

While the Note 7 situation involved hardware manufacturing rather than software deployment, the underlying lesson applies directly to DevOps: speed without coordination between the people who build a product and the people who validate and support it in the real world creates compounding risk. Closer collaboration between engineering and operations — with shared responsibility for reliability — can surface problems before they reach users.

How DevOps Addresses These Gaps

DevOps brings development and operations together at every stage of the software delivery lifecycle — not just at handoff. Both teams contribute to design, testing, deployment, and post-release monitoring. Operations engineers understand what is being built and why; developers understand the production environment their code must run in.

Short Sprints, Fast Feedback

One of DevOps’s practical strengths is its use of short, time-boxed delivery cycles — often two to three days within a broader monthly planning horizon. These short sprints enable teams to:

• Roll out new features and fixes frequently rather than in large, risky batches.
• Collect user and system feedback quickly and act on it in the next cycle.
• Identify problems early, when they are smaller and cheaper to fix.
• Maintain shared situational awareness across development and operations throughout the project.

This cadence prioritises minimal disruption and maximum reliability over raw release velocity — a meaningful distinction from simply shipping faster.

The Culture Shift DevOps Requires

Technology and process changes alone are not enough. DevOps demands a genuine cultural shift in how individuals view their roles and responsibilities.

Traditionally, developers have been the “makers” — focused on building new capabilities — while operations teams manage those capabilities in production. DevOps asks both groups to move beyond those boundaries. Developers gain responsibility for the operational impact of their code. Operations engineers contribute earlier in the development cycle, bringing production insight to design decisions.

Practical Steps for a Successful Transition

• Training: Both teams need grounding in DevOps principles, tools, and shared workflows. This is not a one-time event but an ongoing investment.
• Internal audit: Before sprints begin, identify internal controls, compliance requirements, and regulatory constraints. An unknown compliance obligation discovered mid-sprint can derail a timeline completely.
• Shared metrics: Define what success looks like for the combined team — deployment frequency, change failure rate, mean time to recovery — so both sides are working toward the same outcomes.
• Psychological safety: Teams must feel safe to raise problems early rather than hiding them until a deadline forces the issue.

Data-Driven Insight: The Foundation of DevOps Success

For DevOps to deliver on its promises, decisions must be grounded in real data — not assumptions. Real-time observability of application performance, infrastructure load, and user behaviour gives teams the information they need to make fast, confident decisions.

Without this foundation, teams risk releasing changes that degrade the user experience before anyone notices the problem. With it, teams can predict how a new release will behave under production load, catch regressions early in the pipeline, and continuously improve both the software and the delivery process itself.

Every release cycle produces new knowledge. That knowledge — about system behaviour, user patterns, and failure modes — compounds over time into a significant operational advantage.

The Business Case for DevOps

When development and operations work as a unified, data-informed team, the benefits extend well beyond the IT department:

• Faster response to customer needs: Shorter cycles mean new capabilities reach users sooner.
• Lower costs: Catching defects early is dramatically cheaper than remediating production incidents.
• Greater reliability: Shared ownership of production outcomes reduces the frequency and severity of outages.
• Organisational agility: A team that can deploy confidently and frequently is better positioned to adapt as business requirements evolve.

DevOps is not a silver bullet, and the transition requires sustained commitment from leadership as well as individual contributors. But for organisations willing to invest in the cultural and technical foundations, it offers a genuine path to delivering better software, faster, with less risk.

Originally sourced from BetaNews, January 2017. Rewritten and expanded for a DevOps engineering audience.

Why Front-End Performance Matters in SaaS

Engineering teams at SaaS companies have traditionally invested heavily in back-end optimization — scaling databases, tuning APIs, and improving infrastructure reliability. Many have robust monitoring and alerting in place for server-side issues. However, the front-end is often a blind spot.

Here is the core problem: if the front-end of your web application is slow, it does not matter how performant your database is. Users never interact directly with your database — they interact with the browser. A slow rendering pipeline, bloated JavaScript bundles, or unoptimized assets create a user experience (UX) bottleneck that no amount of back-end tuning can fix.

A common misconception in SaaS is that front-end performance only matters for acquisition. The reasoning goes: “Our users are already paying customers on annual contracts — they’re not going anywhere.” This assumption is dangerous for several reasons:

• Slow web apps interrupt user workflows and create frustration that accumulates over time.
• Frustrated users submit more support tickets, increasing operational costs.
• Users complain publicly — on social media, in user communities, and on software review platforms.
• Poor UX directly influences renewal decisions and word-of-mouth referrals at contract review time.

UX is not just a marketing concern. It is a retention and revenue concern, and front-end performance is a foundational part of UX.

Performance Optimization for DevOps Teams

Key Questions to Ask About Front-End Performance

When evaluating front-end performance for a SaaS web application, DevOps teams should be asking questions such as:

• How long does it take for users to log in and see their initial dashboard?
• Are third-party behavioral analytics scripts adding measurable latency to page loads?
• Are externally managed APIs introducing unpredictable latency into the application?
• How quickly can users navigate between different sections of the application?
• Can users generate and render reports without noticeable delays?
• Do billing and upgrade flows complete quickly and without errors?

Synthetic monitoring — also called proactive or outside-in monitoring — is an effective approach for answering these questions. By scripting key user flows and running them continuously, teams can establish baseline response times, receive alerts when thresholds are breached, and detect regressions before real users are impacted.

Integrating Performance Checks into the CI/CD Pipeline

Monitoring catches performance problems after they reach an environment. A more proactive approach is to prevent performance regressions from being released in the first place by integrating performance analysis directly into the build pipeline.

Performance optimization tools that integrate with continuous integration (CI) platforms such as Jenkins can be configured to fail a build when a performance rule is violated. Teams can define their own thresholds and best-practice rules, so only the checks that matter to their specific application are enforced. This gives teams a configurable, automated performance gate — a fail-safe that catches issues at the point of code merge rather than in production.

Example Scenario: Icon Assets and a Production Incident

Consider the following scenario, which illustrates the value of pre-release performance checking:

Without optimization tooling in the pipeline: Your team ships a UI update that includes a new set of custom icons. QA validates cross-browser rendering. UX research confirms users respond positively. You deploy to production. Within hours, you notice that dashboard load time has increased. You pull waterfall charts, compare before-and-after, and start diagnosing. Meanwhile, Operations flags that SLA thresholds may be breached if the issue isn’t resolved within the hour. You roll back the release. After further investigation, you discover the new icons are four times larger in file size than the previous set. You optimize, create a hotfix, and re-release. The entire incident consumed hours of engineering time and created unnecessary operational risk.

With optimization tooling integrated into staging: You merge the icon update into your staging branch. The build fails automatically. The optimization tool flags that the new icon assets are four times larger than the previous set and surfaces specific recommendations for reducing their size. You optimize the assets before the code ever reaches production. The release goes out on schedule. Dashboard load times remain stable — or improve slightly. No incident. No rollback. No fire drill.

The goal of integrating performance tooling into the DevOps workflow is straightforward: find performance issues earlier, when they are cheaper and less disruptive to fix.

Performance Optimization for Business Teams

The Performance Stakes on Marketing Sites

Nearly every SaaS company relies on a marketing website to support the sales and buying process. These sites tend to be content-heavy — rich with images, video, and a significant payload of third-party tracking and analytics scripts. Those scripts serve a legitimate purpose: they capture behavioral data that helps teams personalize content and optimize conversion funnels. But they carry a real performance cost.

Business teams managing marketing sites should keep in mind that the marketing site is a prospect’s first direct experience with the product. Performance and UX on that site shape expectations about the web application itself. A slow, unreliable marketing website signals to prospective customers that the product may also be slow and unreliable — even if that assumption is unfair.

Key Questions for Business Teams

• Are unoptimized images or videos contributing to slow initial page loads, and is that correlated with a high bounce rate?
• Are there unused or redundant third-party tracking scripts still loading on pages where they serve no purpose?
• What are the critical conversion paths on the site — free trial signups, demo requests, contact forms — and do those flows complete quickly and without errors?

Example Scenario: Homepage Video and Conversion Testing

Consider a common question that marketing teams face: should the homepage include a product video? Video can increase engagement and communicate product value quickly, but it can also add significant page weight.

A reactive approach: You add the video to the homepage and run an A/B test against the version without it. The test runs for several weeks. You eventually determine that the video adds two seconds to page load time and that this latency is associated with a measurable drop in conversions. You remove the video and start over. The test cost you time, traffic, and potential revenue during the experiment period.

A proactive approach using staging analysis: Before changing the live site, you and your development team deploy the video version to a staging environment and run performance analysis against it. You confirm the two-second load time increase before any real visitors are affected. Based on that data, you explore alternatives — for example, SVG animations or CSS-based motion — that achieve a similar visual impact without the payload cost. You validate the new approach in staging, confirm it performs well, then release it to production. Conversion rates improve. No traffic was wasted on a suboptimal experiment.

This approach requires collaboration between business and development teams, but it produces better outcomes than reactive A/B testing alone.

Building a Performance Culture Across the Organization

Performance optimization tools provide value even when used in isolation by a single team. But the most effective SaaS organizations go further by building a shared performance culture across both technical and business functions. This means:

• Aligning on shared KPIs: Agree on the performance metrics that matter most — load time, time to interactive, error rates, conversion rate — and make them visible to all stakeholders.
• Collaborating on strategy: DevOps and business teams should work together to prioritize performance work that has measurable business impact, not just technical elegance.
• Sharing tooling and data: Common dashboards and reporting give every team visibility into performance health, reducing the risk of siloed decisions that inadvertently hurt performance.

When performance is treated as a cross-functional concern rather than a DevOps-only problem, organizations are better positioned to deliver consistently fast, reliable experiences — both to prospects on the marketing site and to paying customers inside the application.

Key Takeaways

• Front-end performance affects UX for paying SaaS customers, not just for prospects. Slow web apps drive support costs, churn risk, and negative word-of-mouth.
• Integrating performance analysis into CI/CD pipelines allows teams to catch regressions before they reach production, reducing the cost and impact of performance incidents.
• Marketing websites are part of the product experience. Poor performance on the marketing site shapes prospect perception of the application itself.
• Proactive performance testing in staging environments gives business teams data to make smarter decisions without exposing real users to degraded experiences.
• Cross-functional alignment on performance KPIs, strategy, and tooling produces better outcomes than siloed optimization efforts.