As cloud adoption continues to transform the modern enterprise, organisations consume the cloud differently as they extend the scope and scale of their digital business strategies. They have the option to pick and choose from various hybrid cloud infrastructures and services. But using disparate services and solutions—such as multi-cloud, hybrid environments, software as a service (SaaS) and platform as a service (PaaS), plus various applications and endpoints—introduces implementation, management and security challenges to the cloud computing landscape. And because of the proliferation of multi-cloud, many enterprises maintain heterogeneous cloud environments, with tools and systems from various platforms differing significantly. All of this makes building and managing a consistent security strategy increasingly difficult.

Organisations need to have a security strategy that includes visibility and control across all kinds of cloud infrastructures. This enables them to keep applications and devices secure and connected, from the remote user to the data centre to the cloud. And because each organisation is unique, there are a variety of cloud security options available to meet all of their demands. But beware. Without careful planning, these options can quickly lead to vendor and solution sprawl that introduces another layer of complexity to an already complicated problem.

Application-layer security
The proliferation of BYOD and IoT, especially as workers have become more dispersed and remote, creates a unique level of security complexity at the application level. Business-critical applications, built on a variety of cloud infrastructures, need to adhere to the security policies of an organisation, keeping users, the network, data and workloads all secure. An advanced application-layer security protocol can detect security vulnerabilities before they become a problem. But it not only needs to span the distributed—and evolving—network; it also needs to provide a single source of truth to simplify management and policy enforcement.

Network security
Of course, applications are only part of the equation. Equally important is keeping the network itself secure. Organisations with hybrid cloud infrastructures and multi-cloud environments require secure network connectivity across all locations and endpoints, and even between applications residing within the same cloud or data centre. These cannot operate in isolation.

Security solutions protecting these critical points of interaction need to be able to see each other, share policies and threat intelligence, and participate in a coordinated response to any sort of threat. This, again, can be especially challenging for enterprises faced with skills and resource gaps, particularly when operating remotely from home while attempting to manage multiple cloud instances and networks simultaneously.

Securing the public cloud
Public cloud offers an open system where stored data and critical business applications can be made available to workers, whether local or remote, as well as to the public via the internet. Public, private and hybrid clouds all require consistent security postures to protect users, devices, applications and networks, while high-speed VPN connections protect data. However, public clouds—especially multi-cloud environments—pose a special challenge because each runs its own unique system of rules and protocols. Security policies need to be consistent and enforced across all environments and should be managed with single-pane-of-glass controls.

This means that security solutions deployed on multiple public cloud platforms not only need to function as native solutions but also interoperate in spite of their functional differences. This requires tools designed to operate seamlessly in and across all major public cloud environments, enabling a single, holistic security fabric that can span the most highly distributed and dynamic environments.

Security solutions, and security teams, also need to understand the shared-responsibility model. While needing to trust public cloud providers to protect the network, storage and computing layers, they need to understand—and deploy—security solutions designed to secure anything that they produce, deploy or store in the public cloud. Best-in-breed cloud security solutions incorporate native cloud integrations with all major public cloud providers to ensure privacy and confidentiality.

Hybrid cloud security
Hybrid cloud environments provide for greater flexibility, with a combination of private cloud services, a public cloud and on-premises infrastructure—all orchestrated to work together as seamlessly as possible. However, a hybrid cloud that uses on-premises data centres and public cloud platforms requires rigorous security management.

An effective security solution purpose-built for a hybrid cloud infrastructure should include:

Auto-scale capabilities for network security and capacity
Centralised management for automatic provisioning
Site-to-site VPN connectivity to migrate workloads
Segmentation of persistent connections to deliver end-to-end security
Full transparency and control for compliance governance
Platform security
Finally, and maybe most importantly, is the implementation of a consistent security platform. Platform security provides the architecture, tools and processes needed to secure an entire cloud computing ecosystem. It provides consistent security and connectivity solutions combined with single-pane-of-glass visibility across the ecosystem, enabling organisations to maintain consistent security policies across the entire infrastructure to effectively manage risk at less cost, while easing the burden on security teams.

Securing all types of clouds
Protecting an organisation’s systems and assets in the cloud should be a primary priority, wherever they reside. Making this possible starts by ensuring that multi-cloud and hybrid networks are able to see and talk to each other for quick detection and resolution of security incidents. Regardless of which combinations of cloud your organisation chooses to consume, security needs to be natively deployed and be able to adapt to and protect all of these environments.

Thales announced a new collaboration with Google Cloud that will accelerate the ability of enterprises to safely migrate sensitive data between public cloud, hybrid and private IT infrastructures.

Together, the two companies will offer new capabilities that enable security teams to own and control their encryption keys while helping to fulfill heightened regulatory requirements amidst today’s highly-distributed workforce.

Building on a multi-year history of innovation around a variety of cloud security initiatives, Thales and Google Cloud will now empower customers to leverage the full potential of Google Cloud technology for sensitive workloads while gaining the external key management needed to control and secure data across hybrid cloud IT environments.

This collaboration marks a significant moment for organisations to finally seize full control of their data and encryption keys, especially as they pursue hybrid, multi-cloud strategies. Addressing both private and public cloud environments, Thales and Google Cloud will provide a turnkey solution that manages, brokers and stores encryption keys completely controlled by the customer, effectively enabling companies to move data assets to the cloud with confidence.

As uncovered in the Thales 2020 Data Threat Report-Global Edition, this is increasingly becoming more critical as greater than half of the world’s corporate data – of which 48% is sensitive – is stored in the cloud.

“New capabilities are critical to cloud migration and security, especially with such accelerated growth in this area,” said Sunil Potti, VP and GM of Google Cloud Security. “True to our mission, we’ve forged this deeper relationship with Thales to further protect our customer’s most sensitive information. Companies of all shapes and sizes are dealing with an extremely fluid and dynamic business environment where even the best lines of defence are constantly being battle tested. Together with Thales, we acknowledge the current set of circumstances and remain vigilant to provide customers with the most advanced solutions that address today’s cybersecurity needs as well as those that are emerging on the horizon.”

This collaboration greatly simplifies the security of moving to multi-cloud, hybrid cloud, and edge-cloud environments – a journey more companies are making today to address the post-pandemic remote world. According to 451 Research, 62% of enterprises today are pursuing a hybrid IT strategy.

In addition, by working with Thales to handle application and data security in the cloud, Google Cloud customers can now maintain strong data sovereignty with encryption key visibility and lifecycle management. Customers also can address heightened regulatory requirements stemming from recent data and privacy regulations.

“Our collaboration with Google Cloud truly embodies the technology leadership needed to place the control of data directly into the hands of our customers,” said Sebastien Cano, SVP for Cloud Protection & Licensing at Thales. “Companies no longer need to put their sensitive data in untrusted environments and relinquish control of their coveted encryption keys. It has become abundantly clear that an evolution in data protection is taking place at a global level as security professionals work together to build a shared-responsibility security model between enterprise customers and providers. With this joint innovation effort, we’re supporting organisations as they move to the cloud with confidence.”

What Is GitHub Actions?

GitHub Actions is an automation platform built directly into GitHub. It lets you orchestrate any workflow in response to any GitHub event — a push, a pull request, a release, a comment, or even a custom event triggered by a GitHub App. Workflows and the individual steps that make them up are defined as code living inside your repository, which means they can be versioned, reviewed, shared, and forked just like application source code.

When GitHub first introduced Actions, developers embraced it for general automation tasks. The most requested follow-up feature was native CI/CD support — the ability to build, test, and deploy software directly from a workflow file. That capability arrived with the beta announced in August 2019, ahead of general availability at GitHub Universe on 13 November 2019.

CI/CD Across Any OS, Language, and Cloud

GitHub Actions CI/CD runs on Linux, macOS, and Windows. Workflows execute either inside containers or on virtual machines hosted by GitHub. At launch, supported languages and ecosystems included Node.js, Python, Java, PHP, Ruby, C/C++, .NET, Android, and iOS — covering the vast majority of typical development stacks.

Multi-container application testing is supported through Docker Compose. By adding a docker-compose configuration to your workflow file, you can spin up a web service alongside its database and run integration tests against both as part of the same CI pipeline.

Matrix Builds: Test Multiple Configurations in Parallel

Matrix builds allow a single workflow definition to fan out across multiple runtime configurations simultaneously. A typical use case is testing against several versions of a language runtime. The configuration is concise — a few lines added to the workflow YAML are enough to instruct GitHub to spawn parallel jobs for each combination in the matrix.

strategy:
  matrix:
    node-version: [14.x, 16.x, 18.x]

steps:
  - uses: actions/setup-node@v3
    with:
      node-version: ${{ matrix.node-version }}
  - run: npm test

GitHub manages job scheduling and parallelism automatically, so teams get faster feedback without having to manage build infrastructure themselves.

Live Logs and Real-Time Feedback

As a workflow runs, GitHub streams log output in real time to the Actions console. Logs are formatted for readability, with support for colour and emoji output from workflow steps. Each individual log line has a stable permalink, making it straightforward to link a colleague directly to a failed test assertion or a specific deployment step when discussing an issue.

Actions and Workflows Are Code

Individual Actions — the reusable building blocks of a workflow — are themselves code. You can write them in JavaScript or package them as Docker container Actions, both of which can interact with the full GitHub API and any other public HTTP API. Workflows are defined in YAML files stored under .github/workflows/ in a repository.

Because Actions are code in a repository, forking a repository also forks its workflow definitions. This gives contributors an immediately runnable CI environment that mirrors the upstream project, lowering the barrier to contribution and making it easier to reproduce build failures locally or in a fork.

Actions can also be shared publicly on GitHub Marketplace and referenced from any workflow by pointing to a repository and tag:

steps:
  - uses: actions/checkout@v4
  - uses: actions/setup-python@v5
    with:
      python-version: '3.11'

Trigger Workflows on Any GitHub Event

GitHub Actions is not limited to code-related events. Workflows can be triggered across the full developer lifecycle: push, pull request, issue creation, label changes, release publication, scheduled cron expressions, and more. GitHub Apps can also register custom events, enabling third-party tools and internal platforms to kick off Actions workflows in response to domain-specific activity.

Common automation use cases beyond CI/CD include automatic issue labelling and triage, release note generation, dependency update PRs, and community management tasks such as welcoming first-time contributors.

Integration with GitHub Package Registry

Publishing build artefacts and container images is a standard step in any CI/CD pipeline. GitHub Actions integrates with GitHub Package Registry (now GitHub Packages), enabling workflows to publish and consume packages — including npm packages, Docker images, Maven artefacts, and others — as part of an end-to-end build and deployment process without leaving the GitHub ecosystem.

Suggested Workflows for Faster Onboarding

When you enable Actions on a repository, GitHub analyses the project and suggests starter workflows appropriate for the detected language or framework. This reduces the time from zero to a running pipeline, particularly for teams new to CI/CD or new to GitHub Actions specifically.

Pricing: Free for Public Repositories

GitHub Actions is free for public repositories. This applies to all hosted runner usage on Linux, macOS, and Windows for open source projects. For private repositories, GitHub uses a pay-as-you-go model based on compute minutes consumed, with a free monthly allowance that varies by account plan.

Self-hosted runners — where you supply your own machines and register them with Actions — are free to use regardless of whether the repository is public or private. This option is particularly useful for workloads with specific hardware requirements, air-gapped environments, or large build jobs where hosted runner costs would otherwise be significant.

Self-Hosted Runners and Enterprise Support

For teams running their own infrastructure — whether on-premises virtual machines or cloud instances they manage themselves — GitHub Actions supports self-hosted runners. Installing the Actions runner agent on a machine and registering it with a repository or organisation allows workflows to target that machine using the runs-on: self-hosted label.

At the time of the August 2019 announcement, GitHub also indicated that Actions support for GitHub Enterprise Server was planned for the following year, including a hybrid deployment model where source code and packages remain on-premises while GitHub.com orchestrates the workflow execution.

Getting Started

To add a CI workflow to an existing repository, create a file at .github/workflows/ci.yml. A minimal example for a Node.js project looks like this:

name: CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v3
        with:
          node-version: '20.x'
      - run: npm ci
      - run: npm test

Commit and push the file. GitHub will pick it up automatically and run the workflow on the next qualifying event.

Full documentation is available at docs.github.com/en/actions.

Background: Why CloudFormation Users Were Frustrated

AWS CloudFormation is one of the most widely used infrastructure-as-code (IaC) tools in the cloud ecosystem, allowing engineers to define and provision AWS infrastructure through declarative templates. However, for years, a persistent complaint from the CloudFormation community was that AWS’s own IaC tool lagged behind the pace of new AWS service releases — meaning engineers could not manage newly launched services through CloudFormation on day one of general availability.

In response to sustained user pressure, AWS released a public roadmap for CloudFormation in mid-2019, hosted on GitHub. The move was intended to give teams greater visibility into which CloudFormation resource types were being worked on and roughly when they might become available.

AWS evangelist Jeff Barr acknowledged the gap directly in a blog post at the time: “While our goal of providing 100% coverage remains, the reality is that it will take us some time to get there.” He attributed the lag to AWS prioritising scalability of the CloudFormation service itself over complete service coverage.

What the CloudFormation Public Roadmap Contains

The CloudFormation roadmap, modelled after a similar roadmap AWS had released for containers earlier that year, organises planned work into four status categories:

• Shipped: The CloudFormation resource type is complete and available for production use across all AWS public regions.
• Coming Soon: Work is well underway; expect availability within a few months.
• We’re Working On It: Active development is in progress, but on a longer timeline than “Coming Soon.”
• Researching: AWS has not yet determined how to implement the feature and is in an exploratory phase.

Importantly, the roadmap is scoped specifically to coverage updates for existing CloudFormation resource types and resource types with no existing CloudFormation support. It does not include information about AWS services that have not yet been publicly released.

AWS also made clear in its FAQ that specific release dates would not be provided on the roadmap, citing security and stability as primary priorities that could affect timelines.

Community Reaction: Cautious Optimism

Reaction from experienced AWS practitioners was generally positive but measured. Ryan Marsh, a DevOps and serverless coach at TheStack.io in Houston, offered qualified praise:

“This is exactly what we’ve been asking for, in lieu of same-day GA of course. Furthermore, we need to see more of this type of leadership with AWS’s various open source endeavors, many of which still feel controlled by the company — not the community — and yet have no public roadmap.”

Scott Piper, an AWS security consultant at Summit Route in Salt Lake City, took a more sceptical view of how much practical impact the roadmap would have:

“I think the increased transparency is good, although I wonder how many people actually monitor or care about it. I think most people have maybe one feature they want to have happen and so this gives them a better way of tracking the progress of that feature.”

Piper also raised a practical concern about the GitHub thumbs-up mechanism AWS uses to gauge user interest in features: “GitHub suffers from bots like every other social platform, and probably more so.” He suggested that for most customers, feature prioritisation at AWS still ultimately correlates with AWS spend — large enterprise customers with significant annual contracts having more direct influence over AWS engineering priorities than community votes.

CloudFormation vs. Terraform: The Coverage Gap Problem

The frustration driving the roadmap request was not merely academic. Several organisations reported that CloudFormation’s coverage lag had pushed them toward Terraform, the open-source IaC tool developed by HashiCorp. Because Terraform’s AWS provider is maintained by both HashiCorp and the community, it often gains support for new AWS services faster than CloudFormation itself does.

This is a notable irony: AWS’s own IaC tooling has at times provided less coverage of AWS services than a third-party tool. The public roadmap was partly AWS’s acknowledgement of this tension and an attempt to rebuild trust with teams who had already switched or were considering switching.

The CDK Factor: Has AWS Shifted Focus?

One context point worth understanding is that 2019 was also the year AWS launched the AWS Cloud Development Kit (CDK). CDK is an IaC framework that allows developers to define cloud infrastructure using familiar general-purpose programming languages — TypeScript, Python, Java, and others — rather than the JSON or YAML templates that CloudFormation requires.

CDK compiles down to CloudFormation templates under the hood, so it inherits CloudFormation’s coverage limitations. However, its developer experience is significantly different and was well received. Amazon CTO Werner Vogels, in an interview with TechTarget at the time, indicated that AWS had been directing more engineering attention toward CDK based on developer demand:

“I think overall, we’re on a good path — the right path. But I love the fact that there is a long list of requests for CloudFormation. It means that customers are passionate about it and want us to do more.”

For DevOps teams evaluating their IaC strategy, this raises a practical question: if AWS’s own engineering investment was increasingly going into CDK rather than raw CloudFormation template coverage, how quickly would the coverage gap actually close?

Key Takeaways for DevOps Engineers

• The roadmap provides visibility, not velocity guarantees. AWS explicitly declined to commit to specific release dates. Teams should treat the roadmap as a planning input, not a delivery contract.
• Scope is limited to existing services. If you are waiting for a brand-new, unreleased AWS service to get CloudFormation support, the roadmap will not tell you anything until that service is publicly available.
• Community input has limits. GitHub reactions do factor into prioritisation, but large enterprise spend is a more direct lever. Small teams should not assume a popular GitHub issue will move quickly.
• CDK is an alternative worth evaluating. If template verbosity is a pain point in addition to coverage, CDK’s programming-language-native approach addresses a different set of frustrations than raw CloudFormation.
• Terraform remains a valid option for coverage-sensitive workflows. For teams where day-one support of new AWS services is a hard requirement, Terraform’s provider ecosystem may still be a better fit.

Summary

The release of the AWS CloudFormation public roadmap in 2019 was a meaningful transparency improvement, responding directly to years of user criticism about feature lag. Hosted on GitHub and organised into four clear status categories, it gave CloudFormation users a structured way to track resource type coverage progress and provide feedback. However, the roadmap came with important caveats: no release dates, limited scope, and no explicit commitment to accelerated delivery. For DevOps teams building on AWS, it remains one useful signal among several when making IaC tooling decisions.