GitLab today took the wraps off a major update to its continuous integration/continuous delivery (CI/CD) platform that embeds analytics tools in workflows to identify the root cause of inefficiencies, among other additional capabilities.

David DeSanto, senior director for product management at GitLab, said that capability is part of an ongoing effort to include value stream analytics within the core GitLab 14 platform as an alternative to acquiring and deploying a separate platform. There are also additional charts and dashboards that enable DevOps teams to uncover bottlenecks over time.

In addition, GitLab announced it is extending the security capabilities of the platform by adding integrations with open source Semgrep and Trivy vulnerability scanning tools as part of an effort to enable organizations to embrace DevSecOps best practices within workflows. GitLab has also added support for the fuzz testing tool it gained via the acquisitions of Fuzzit and Peach Tech to enable DevOps teams to test application security more thoroughly along with making available additional dashboards to track security metrics.

As part of an effort to enable organizations to better secure their software supply chains, GitLab has also added support for immutable pipeline definitions that can’t be altered without specific levels of permissions being granted. That capability also enables DevOps teams to more easily achieve compliance with any number of regulatory frameworks, noted DeSanto.

The company is also adding a pipeline editor that provides access to a visual tool for creating, managing and visualizing pipelines. That tool is designed to both make DevOps more accessible to novices and provide experienced DevOps teams with an alternative tool for managing pipelines in a way that doesn’t require them to write additional code.

Finally, as part of its comprehensive approach to DevOps, GitLab is also making available agent software for Kubernetes clusters to eliminate the need for organizations to acquire a separate DevOps platform to build and deploy cloud-native applications based on microservices constructed using containers. The company now provides IT organizations with the option of crafting a GitOps workflow for Kubernetes using either an agentless or agent-based approach.

Gitlab is betting that, as DevOps continues to evolve and mature, more organizations will prefer to replace the various tools they need to integrate themselves with a platform that lowers the total cost of DevOps. Gartner is forecasting that, by 2023, 40% of organizations will have switched from multiple point solutions to a DevOps value stream delivery platform to streamline application delivery, versus less than 10% using such a platform in 2020. Today, only 10% of organizations are employing such a platform, according to Gartner.

There should also be many more organizations employing DevOps workflows to build applications. Organizations of all sizes now realize how dependent they are on software to drive a wide range of digital business transformation initiatives. The rate at which that software can now be securely developed and updated, in many cases, goes to the heart of their ability to compete. The issue is finding a way to achieve that goal without constructing a platform that ultimately takes time and resources away from building secure software.

Google has recently announced that Google Cloud Workflows, the service to orchestrate Google Cloud and HTTP-based API services with serverless workflows, is now generally available. Workflows Connectors are now in public preview.

Google Cloud Workflows requires no infrastructure management and scales on demand, including scaling down to zero if no requests are processed, It can be used to develop complex serverless applications, building on workflows that connect series of serverless tasks together in a predetermined order and work with other managed services like Google Cloud’s APIs, Cloud Functions or Cloud Run.

Among the features of the new service, an error handling with configurable retry policies, a reliable workflow execution targeted to enterprise and line-of-business applications and the ability to pass information between steps using JSON parsing and expression-based variable manipulations. Workflows publishes connectors to make it easier to access other Google Cloud APIs within a workflow.

Among the use cases that can benefit from workflows, inventory management processes, e-commerce transactions and other services that require an orchestration layer. Filip Knapik, product manager at GCP, wrote an article before the GA that covers examples for Workflows such as processing files uploaded to a storage bucket, tagging the files based on the extension. He explains:
GCP is not the only cloud provider offering managed workflows. Microsoft has Azure Logic Apps and Amazon introduced AWS Step Function over four years ago. Tim Bray, formerly VP/distinguished engineer at AWS, wrote a detailed comparison between the AWS and GCP services. But regardless of which features they offer and the maturity of the different services, he concludes that choosing the workflow service is a platform choice:

Google Cloud Workflows has a pay-per-use pricing model based on the number of steps and the number of external HTTP calls, with the first 5000 steps and 2000 HTTP calls free every month.

IAR Systems, a supplier of software tools and services for embedded development, has released an update of its RISC-V build tools that supports implementation in Linux-based frameworks for automated application build and test processes.

This addition further extends IAR Systems’ offering for flexible automated workflows, enabling streamlined workflows from the developer environment to Continuous Integration (CI). Thanks to the tools including the static code analysis tool C-STAT, code quality control from development to building and testing processes can now be achieved.

Smarter and more complex embedded applications are driving a need for more scalable and flexible software development environments. The RISC-V community now range from publicly funded research projects, all the way into some of the world’s largest corporations and what is true for all these organisations is a shared need for automated processes that ensure quality all the way from development into building and testing.

IAR Systems’ build tools for Linux makes it possible to optimise resources when it comes to the time developers spend in their projects, as well as to manage and utilize licenses and servers in an optimal way.

The tools can be easily integrated into different build systems, such as CMake or Ninja, and the command line build utility IARBuild streamlines building for easy integration with Continuous Integration engines like Jenkins and Bamboo.

With the integrated static analysis tool C-STAT, developers will be able to ensure code quality throughout the development and testing process. C-STAT proves code alignment with industry standards like MISRA C:2012, MISRA C++:2008 and MISRA C:2004, and also detects defects, bugs, and security vulnerabilities as defined by CERT C and the Common Weakness Enumeration (CWE).

“We have seen a huge demand for our newly released Build Tools for Linux for other architectures, which has led us to bring this opportunity also to RISC-V,” said Anders Holmberg, General Manager Embedded Development Tools, IAR Systems. “In setting up infrastructure for working with new technology, it can be easier to fully adapt best practices like CI and DevOps, and break with legacy ways of working. This will result in accelerated software development that can be quality-assured through flexible, automated workflows. Through the extended possibilities for building on Linux-based servers, we equip companies with streamlined workflows for enhanced productivity and strengthened team collaboration.”

The build tools for Linux includes the IAR C/C++ Compiler, IAR Assembler, Linker and library tools, IARBuild and runtime libraries. The tools also include the integrated static code analysis tool C-STAT. The IAR C/C++ Compiler adheres to a freestanding implementation of the C18 (ISO/IEC 9899:2018) programming language standard and supports all C++17 features.

Nexcess, the truly managed commerce and content platform, has announced a partnership with Branch, a continuous integration tool for WordPress developers.

WordPress developers are increasingly gravitating to Git-based workflows that allow them to work in isolated environments called branches to ensure that the code in the central repository—the master branch—remains high quality and error-free.

“We chose Branch as a best-in-class deployment tool for automating workflows without heavy lifting.” -Chris Lema

Branch offers a continuous integration and deployment (CI/CD) setup that runs every time a developer pushes a Managed WordPress site, theme or plugin to their Git repository. The cloud-based solution automates the entire workflow, from the build and tests, all the way through getting code from the repository to the server.

At Nexcess, supporting our [Managed WordPress and Managed WooCommerce hosting] customers means giving them the most modern and scalable solutions to power their digital sites and eCommerce stores. We chose Branch as a best-in-class deployment tool for automating workflows without heavy lifting, so developers can work smarter and faster,” said Chris Lema, Vice President of Products, at Nexcess.

Under the partnership, Branch will integrate with Nexcess customers’ existing Git providers like GitHub, Bitbucket and GitLab. Developers can connect their Branch account to Nexcess and select one of Branch’s easy-to-use built-in deployment recipes or define their own custom steps. For example, one ready-made recipe is building front-end assets with NPM, Gulp or Grunt.

Being agile is about finding out what works, and what doesn’t, as quickly as possible. Branch makes building and testing fast and easy for Managed WordPress developers, and we’re proud to bring our innovative workflow solution to Nexcess to both support and inspire their Managed WordPress customers in their commerce endeavor,” says Peter Suhm, founder of Branch.

“We chose Nexcess for its full-stack support and suite of services for driving our Managed WordPress and WooCommerce projects forward. With the addition of Branch’s deployment recipes, we are excited to develop faster and better than ever before,” said Steve Zehngut, founder of Zeek Interactive.

Why Cloud Security Reading Still Matters

Cloud environments are not secure by default. Misconfigured S3 buckets, over-permissive IAM roles, unencrypted data in transit, and weak secrets management are recurring causes of real-world breaches. Whether you run workloads on AWS, Azure, or Google Cloud Platform, understanding the underlying security principles — not just the vendor dashboards — is what separates a reactive team from a proactive one.

Books offer something documentation and blog posts rarely do: a structured, end-to-end treatment of a subject. The titles below range from vendor-neutral fundamentals to practitioner-focused guides on cloud-native security architecture. They are suitable for beginners building a foundation and for experienced engineers looking to formalise or deepen their knowledge.

What to Look for in a Cloud Security Book

Before committing time to a book, consider the following criteria:

• Publication date: Cloud services evolve rapidly. A book more than three to four years old may reference deprecated services or outdated compliance frameworks. Prioritise recent editions or books that focus on durable principles over specific console walkthroughs.
• Author credibility: Look for practitioners with demonstrable experience — security architects, penetration testers, or engineers who have built and defended production cloud environments.
• Coverage of the shared responsibility model: Any credible cloud security book should clearly explain what the cloud provider secures versus what the customer is responsible for. This model underpins everything else.
• Practical exercises: Lab-based or hands-on chapters accelerate retention and give you directly applicable skills.
• Multi-cloud or platform-specific focus: Decide whether you need a vendor-neutral treatment (useful for architects and decision-makers) or a deep dive into a specific platform (useful for engineers operating daily in AWS, Azure, or GCP).

Core Topic Areas Worth Prioritising

A well-rounded cloud security reading list should cover the following domains. Use this as a checklist when evaluating which gaps in your knowledge to fill next:

Identity and Access Management (IAM)

Excessive permissions and poorly scoped roles are among the most exploited attack surfaces in cloud environments. Books and resources in this area cover least-privilege design, role-based access control (RBAC), attribute-based access control (ABAC), federation, single sign-on (SSO), and privileged access management (PAM).

Network Security in the Cloud

Traditional perimeter-based security does not translate directly to cloud-native architectures. Core concepts include virtual private clouds (VPCs), security groups, network access control lists (NACLs), private endpoints, zero-trust networking, and micro-segmentation.

Data Protection and Encryption

Encryption at rest and in transit, key management services (KMS), secrets management tools (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), and data classification frameworks are essential knowledge for anyone handling sensitive workloads in the cloud.

Compliance and Governance

Regulatory requirements such as GDPR, HIPAA, PCI-DSS, and SOC 2 impose specific technical and organisational controls. Understanding how cloud services map to these frameworks — and where responsibility remains with the customer — is critical for compliance-driven teams.

Incident Response and Threat Detection

Cloud environments generate large volumes of logs and telemetry. Books in this area cover SIEM integration, cloud-native logging services (AWS CloudTrail, Azure Monitor, GCP Cloud Audit Logs), threat detection, and incident response playbooks tailored to cloud scenarios.

DevSecOps and Secure CI/CD

Shifting security left means integrating static analysis, dependency scanning, container image scanning, and infrastructure-as-code (IaC) policy checks into the development pipeline. This is increasingly a required competency for platform and DevOps engineers, not just security specialists.

Building Your Reading List: A Suggested Approach

Rather than reading exhaustively, map books to your current role and the most pressing security risks in your environment:

1. Assess your knowledge gaps. Use a framework such as the CSA Cloud Controls Matrix or the MITRE ATT&CK Cloud matrix to identify where your understanding is weakest.
2. Match books to gaps. Select titles that directly address those areas rather than reading generalist books cover to cover.
3. Combine reading with practice. Set up a personal cloud lab (free-tier accounts on AWS, Azure, or GCP are sufficient for most exercises) to apply concepts as you read.
4. Revisit titles as services evolve. Check whether newer editions exist before starting a book you last read two or more years ago.

Supplementary Resources Beyond Books

Books are one component of a broader learning strategy. Pair your reading with:

• Vendor security documentation: AWS Well-Architected Framework Security Pillar, Microsoft Azure Security Benchmark, and Google Cloud Security Foundations Blueprint are all freely available and regularly updated.
• Cloud Security Alliance (CSA) publications: The CSA publishes guidance documents, research papers, and the Cloud Controls Matrix at no cost.
• Certification study materials: Certifications such as AWS Certified Security – Specialty, CCSP (Certified Cloud Security Professional), and CompTIA Cloud+ come with structured syllabi that complement book-based learning.
• Threat intelligence feeds and breach post-mortems: Reading real-world incident reports (many published by cloud vendors and security firms) reinforces the practical relevance of what you read in books.

Final Thoughts

Cloud security is not a one-time certification or a single book. It is an ongoing discipline that requires continuous learning as attack surfaces shift and cloud providers introduce new services. Building a deliberate reading habit — even one chapter per week — compounds into significant expertise over time. Start with the domain most relevant to your current work, apply what you learn in a lab environment, and expand from there.

If your organisation lacks in-house cloud security expertise, consider evaluating managed security service providers (MSSPs) with proven cloud practices as a complementary measure while your team builds capability.

New Relic Unveils a New Generation of Observability at FutureStack 2019

At its annual FutureStack conference in New York City, New Relic announced a series of significant platform innovations centred on making New Relic One the industry’s first observability platform described as simultaneously open, connected, and programmable. CEO and founder Lew Cirne led the announcements, which included new products for log management, distributed tracing, metrics ingestion, and AI-powered incident response.

The additions respond directly to how modern engineering teams operate: running distributed, containerised workloads across multiple clouds, often managing data from a heterogeneous mix of agents, open-source tools, and third-party services. New Relic One aims to consolidate that data into a single platform with built-in intelligence and extensibility.

“New Relic One is now the world’s first observability platform that is open, enabling customers to bring in agent-based and open telemetry data so they have no blind spots; connected, allowing customers to see relationships between their systems so they can act more quickly and effectively; and programmable, empowering customers to build entirely new applications on top of New Relic to fuel their business. It’s not a platform unless you can build apps on it.”

— Lew Cirne, CEO and Founder, New Relic

Programmability: Building Custom Applications on New Relic One

One of the headline announcements was the general availability of programmability across the New Relic One platform. This capability allows New Relic customers, partners, and developers to build purpose-built applications directly on top of New Relic One — combining observability data with their own business data in a single interface.

Key Programmability Features

• Familiar tech stack: Applications are built using React.js and GraphQL — widely used technologies in modern web development — lowering the barrier to entry for engineering teams already familiar with the JavaScript ecosystem.
• Fast time-to-app: New Relic claims developers can go from idea to working application in minutes, not days.
• No additional cost: Programmability is available to all existing New Relic customers at no extra charge.
• Open-source app catalogue: New Relic released an initial set of applications, co-developed with early-access customers and partners, on GitHub under the Apache licence.

“The new programmability features have equipped us to get significantly more value from New Relic, at no additional cost. Our DevOps & SRE teams are now able to create tailored apps, for their specific business needs, that easily fit into our workstream. At an enterprise-scale, programmability has enabled an agility in data for both application and platform teams.”

— Joshua Biggley, Sr. Engineer, Enterprise Monitoring, Cardinal Health

Initial Open-Source New Relic One Applications

New Relic released the following apps as free, open-source downloads from GitHub at launch:

• Cloud Optimize — Compares provisioned cloud resource sizes against actual utilisation, helping teams identify over-provisioned infrastructure and reduce cloud spend.
• GitHub Integration — Surfaces service ownership and recent commit history directly within New Relic One, so on-call engineers can immediately understand what a service does and who last changed it.
• Site Analyzer — Models how improvements to performance KPIs such as page load time and traffic volume can translate into better conversion and customer experience metrics.
• Status Page — Aggregates Statuspage.io status feeds into a single dashboard, giving teams a unified view of upstream dependencies during an incident.
• Customer Journeys — Tracks cohort progress through conversion funnels, providing product and engineering teams with visibility into how user behaviour correlates with technical performance.

Open: New Relic Logs, Traces, and Metrics

New Relic’s “open” pillar focuses on eliminating blind spots by making it straightforward to ingest the full range of telemetry data — logs, metrics, events, and traces — regardless of source.

New Relic Logs

New Relic Logs is a log management capability integrated directly into New Relic One. Rather than context-switching between a dedicated log aggregation tool and an APM or infrastructure dashboard, teams can search, filter, and correlate log data alongside application traces and infrastructure metrics in a single interface.

• Ad hoc log searches return results without pre-defined indexing configurations.
• Designed to scale without the operational overhead of self-hosted log management solutions (e.g. managing Elasticsearch clusters).
• Available to New Relic customers at time of announcement.

New Relic Traces and New Relic Metrics

New Relic Traces and New Relic Metrics extend the platform’s data ingestion capabilities to cover distributed tracing and time-series metrics from any source — not just New Relic’s own agents.

• Agent-based and agentless: Teams can send data from existing New Relic agents or route telemetry from open-source and third-party instrumentation directly into the platform.
• OpenTelemetry support: New Relic confirmed active contributions to and support for the OpenTelemetry project, as well as involvement in AdoptOpenJDK and the Cloud Native Computing Foundation (CNCF).
• Both products were made generally available at FutureStack 2019.

Together, Logs, Traces, and Metrics cover the four pillars of observability telemetry (the fourth being Events), giving teams a complete data foundation within a single platform.

Connected: New Relic AI for AIOps and Smarter Incident Response

New Relic AI is the company’s answer to alert fatigue — a chronic problem for DevOps, SRE, and on-call engineering teams operating large-scale systems. The product applies machine learning to correlate, aggregate, and de-duplicate incident signals, presenting teams with a prioritised, contextualised view of issues rather than a flood of raw alerts.

New Relic AI Capabilities

• Noise reduction: New Relic reported that initial customers observed more than 80% reduction in alerting noise. (See review notes.)
• Automatic anomaly detection: The system identifies unusual behaviour in production metrics without requiring teams to define manual thresholds for every signal.
• PagerDuty integration: New Relic AI connects directly with PagerDuty, enriching incidents with contextual observability data without requiring changes to existing on-call rotations or escalation policies.
• Slack integration: Critical incident context and anomaly alerts are surfaced in Slack channels, keeping teams informed in the tools they already use during an incident.
• Reduced MTTR: By automatically correlating related alerts and surfacing probable root causes, New Relic AI aims to cut mean time to resolution.

Why This Matters for DevOps and SRE Teams

The FutureStack 2019 announcements reflect a broader shift in how observability platforms are expected to work. Stitching together separate tools for logs, metrics, traces, and alerting introduces toil, context loss, and integration maintenance burden. The New Relic One direction — a unified data plane with open ingest, cross-signal correlation, and a programmable surface for custom applications — addresses operational pain points that are well-recognised across the industry.

For teams already invested in open-source telemetry standards like OpenTelemetry, New Relic’s stated commitment to those projects (including contributions to CNCF) signals that vendor lock-in at the instrumentation layer is less of a concern than it was with earlier generations of APM tooling.

The programmability layer is particularly notable for platform engineering teams: the ability to embed observability data into custom internal tooling — without maintaining a separate backend — has meaningful implications for developer experience and operational efficiency at scale.

What Is a Workflow, Really?

Most discussions of workflows begin with Wikipedia, and there is a reason for that: the definition is actually quite good. A workflow, according to the free encyclopedia, is “an orchestrated and repeatable pattern of business activity enabled by the systematic organization of resources into processes that transform materials, provide services, or process information.”

Strip away the formality and the meaning is straightforward: workflows define jobs. They describe the component tasks that make up a role and specify the actions a person—or a system—must perform to be considered productive.

That sounds abstract, but it has very practical implications for DevOps teams. Before you can automate something, monitor it, hand it off to another team, or measure its efficiency, you first have to define it as a discrete workflow. That act of definition is where most organizations stumble.

Why Workflow Thinking Matters Now

The conversation about workflows has sharpened considerably with the rise of AI and machine learning. Automation systems—whether physical robots on a factory floor, software bots processing invoices, or ML models triaging support tickets—can only be applied to tasks that have been clearly defined. You cannot automate an activity you have not first articulated.

This is the central argument for decomposing work into explicit workflows:

• Visibility: You can only improve what you can see. Documented workflows expose bottlenecks, redundancies, and hand-off gaps that are otherwise invisible.
• Automation readiness: A well-defined task is an automatable task. Whether the replacement is a shell script, a CI pipeline step, or an AI agent, granular task definition is the prerequisite.
• Accountability: Explicit workflows make ownership clear. Each step has an owner—human or system—and that ownership is auditable.
• Scalability: Repeatable, documented workflows scale. Ad-hoc, undocumented work does not.

Cross-Team Collaboration Through Workflow Design

One underappreciated benefit of a workflow-centric approach is what it does for cross-functional collaboration. When work is decomposed into discrete steps, those steps can be fulfilled by the person or team best positioned to handle them—regardless of physical location, department, or reporting structure.

A security engineer in one office, a platform engineer in another, and a compliance analyst working remotely can all contribute to a single deployment pipeline if the workflow is clearly defined and tooling connects them. Geography and org-chart proximity become secondary to capability and workflow fit.

IT and software engineering teams have understood this for years. When a compute job needs to run, an efficient operation evaluates which platform, which cloud region, and which resource configuration delivers the best price-to-performance ratio for that specific workload. The same logic—matching the right resource to the right task—can and should apply to human work as well.

The DevOps Parallel: CI/CD as a Workflow Model

DevOps practitioners will recognize the core workflow loop immediately, because it mirrors Continuous Integration and Continuous Deployment (CI/CD):

1. Define the workflow—break the job into explicit, measurable steps.
2. Integrate those steps—connect people, systems, and tools so the workflow runs end to end.
3. Measure the outcome—collect data on duration, error rate, throughput, and quality.
4. Iterate—remove inefficiencies, add automations, refine hand-offs, and repeat.

CI/CD pipelines are, at their core, rigorously defined workflows for software delivery. The pipeline enforces a repeatable sequence: code commit → automated test → build → deploy → verify. Each stage is explicit, measurable, and improvable. That is precisely the discipline that workflow thinking brings to broader organizational work.

The always-on nature of modern software systems—services that must be available around the clock, deployments that cannot wait for a maintenance window—demands this kind of continuous, iterative workflow management. Work itself has taken on the same always-on character as the web services it produces.

Practical Steps for DevOps Teams

If your team wants to move toward genuine workflow-driven operations, consider these starting points:

• Map existing workflows before automating them. Automating a broken process produces a faster broken process. Document the current state first.
• Identify automation candidates by repetition and volume. Tasks that happen frequently, follow a fixed pattern, and require low creative judgment are the best early candidates for automation.
• Instrument your workflows. Add observability—logs, metrics, traces—to workflow steps so you can measure improvement over time.
• Treat workflow definitions as code. Version-control your pipeline configurations, runbooks, and process documentation alongside your application code.
• Build in feedback loops. Every workflow should have a mechanism for surfacing failures and triggering review. Without feedback, iteration is impossible.

The Bigger Picture

Work as it existed in the pre-digital era—siloed, undocumented, and measured only by presence rather than output—is disappearing. The organizations that thrive in its place will be those that define their workflows explicitly, automate what can be automated, connect the people who need to collaborate, and continuously refine how they operate.

This is not a threat to skilled work; it is a redirect. When routine tasks are handled by well-defined automated workflows, human effort can concentrate on the creative, judgmental, and relational work that tools genuinely cannot do.

Define your workflows before you start. Then iterate. The web is always on—and increasingly, so is the work that keeps it running.