On 16 October 2024 I spent the day at Red Hat Summit: Connect 2024, Red Hatâs one-day event for the Netherlands. Red Hatâs event page listed it under Utrecht, at the NBC Congrescentrum in Nieuwegein, just south of the city, and the screens in the breakout rooms carried the NBC Congrescentrum logo. This is a throwback post built from my photos, the slides on screen and the stage audio I recorded. It covers the keynote, a Boston Childrenâs Hospital story about medical imaging on OpenShift, OpenShift Virtualization, an Ansible Automation Platform journey at a large Dutch bank, Maxim Burgerhout on automation as a platform, and Kevin Dubois on the trusted software supply chain.
The main theatre during the opening keynote, while the stage was talking about automation.
The event
The published agenda split the day into four tracks: IT Automation, Application Platform & Cloud Services, The Power of AI and Cloud & Infrastructure. The plenary keynote was called âEnabling Open enterprise AI, and modernizing infrastructureâ. Intelâs logo sat next to Red Hatâs on the welcome sign and the room screens. The expo floor had a Red Hat Theatre for short sessions, a Red Hat Village with a services quiz (the prize was a Lego fedora), and partner stands, including Dellâs âJourney to OpenShift made easyâ stand for the APEX Cloud Platform for Red Hat OpenShift, and Kyndryl. A âThank you to our sponsorsâ slide listed Capgemini, among others.
Keynote: open source, open models and Ansible in the AI era
The opening keynote started with culture. One Red Hat speaker told the room that Red Hat is an open source company and will stay one: âEverything else we can discuss.â He gave numbers to support the point, including about 100 million open source developers and 3.9 million open source projects. He also said 76% of the worldâs software is now open source.
The next part covered Red Hatâs AI strategy. The speaker said customers had asked for three things: AI that subject matter experts can use without being data scientists, smaller models that cost less to train and tune, and tooling to bring their own data without making it public. Red Hatâs answer, as presented:
- Granite models, open-sourced together with IBM Research, with open licences and information on the training data.
- InstructLab, so subject matter experts can add knowledge and skills to a model and run it in their own environment.
- RHEL AI, which packages Granite and InstructLab in a RHEL image. The speaker said it supports accelerators from NVIDIA, Intel and AMD and would ship from Dell, Lenovo and Supermicro.
- OpenShift AI for scaling out, with support for both generative and predictive AI, Granite and bring-your-own models.
- Ansible to respond to events from AI applications, plus Lightspeed assistants, extended from Ansible to OpenShift and RHEL.
The line I wrote down: âWe believe that the most valuable and powerful AI models will be open source.â
A live demo followed with Parasol, a fictional insurance company. Its claim adjusters had a backlog, so Parasol tried a chatbot to help them decide on claims faster. With a generic base model, the assistant was not much help, because it knew nothing about claims or repairs. The demo then switched to the developerâs view: the chatbot ârecipeâ and model running locally in the AI Lab in Podman Desktop, and Parasolâs historical claims and repairs data prepared to train the model. For the MLOps side it showed the OpenShift AI console, with data connections, a model server and pipelines.
Before that, a partner from Conclusion joined the stage to talk about automation. He described a workshop and solution brief that helps customers get started with an automation platform: at the end, the customer has a working platform and the partnerâs playbook best practices. His example was the insurer ZLM, where three teams were already writing their first playbooks separately. The partner designed and deployed an Ansible Automation Platform architecture for them, so automation from one team can be reused by others and chained into larger cross-domain workflows (network, storage, Linux and Windows). To show the cost of manual hand-offs, he described one organisation where a single firewall change took 15 days: three days for the service desk to respond, then twelve days for the implementing team. His advice to the room was to start small, and not to reinvent the wheel when experts can help.
Boston Childrenâs Hospital and ChRIS
The keynoteâs healthcare segment came from Boston Childrenâs Hospital. Red Hatâs agenda describes ChRIS as a web-based medical image platform built with Red Hat technologies and deployed on the Massachusetts Open Cloud. It says the hospital has since used Red Hat OpenShift for AI in maternal-fetal healthcare. The slides showed three results.
Left: scan image reconstruction cut from 2 hours to 2 minutes. Right: the automatic leg length discrepancy workflow running on ChRIS.
- Scan image reconstruction: âScan image reconstruction in 2 hours, now just 2 minutes.â
- ML Fetal Motion Quantification: plots of angles over time, comparing a typical fetus with a fetus with a neural tube defect.
- Automatic Leg Length Discrepancy with ChRIS: a five-step pipeline: retrieving from PACS, uploading to ChRIS, finding landmarks with AI, measuring lengths, and pushing the results back to PACS.
The last example is the one I keep coming back to. AI is only one step out of five. The other four are integration with the hospitalâs image archive, which is the part that turns a model into a workflow clinicians can use.
OpenShift Virtualization on the main stage
Later in the morning, the main stage turned to virtualization. A timeline slide titled âRed Hat has experience with virtualizationâ went from 2007 to OpenShift Virtualization in 2020. The product slide called Red Hat OpenShift Virtualization âthe modern option for general purpose virtualizationâ. It listed RHEL and Linux VMs, Windows VM support and built-in migration tools, on a âunified platform for virtual machines and containersâ.
The OpenShift Virtualization slide: VMs and containers on one platform, with migration tools included.
A customer quote slide from SiriusXM (Nate Mason, Associate Director, Unix Systems Group) began with âMigration was the easiest partâ. It credited the Migration Toolkit for Virtualization (MTV) with bringing VMs over with little to no downtime. The segment ended with âFuture-proof your platform, your applications, your teamsâ (cost-efficient operations, AI and MLOps, a trusted platform, integrated teams and training) and the line âRed Hat gives you a blueprint for a future where youâre in control.â
An Ansible Automation Platform journey at ABN AMRO
For the first breakout slot I went to the IT Automation track. The agenda listed the session as ABN AMROâs Ansible Automation Platform Journey: the bankâs automation strategy, its platform setup, automation for mission-critical infrastructure and network tasks, and the challenges it faced. The timeline slide was the most useful slide of the day for anyone planning a rollout:
The automation journey, stage by stage, with the number of managed hosts growing from 500 to about 12,000.
- Stage 1 (2018â2019): off-the-shelf application deployments; an Ansible Tower proof of concept, then go-live (500 hosts).
- Stage 2 (2020â2021): any application deployment (Java, WebSphere and so on); Azure DevOps CI/CD pipeline integration (1,000 hosts); Ansible Automation Platform moved to Azure with a Private Automation Hub (4,000 hosts).
- Stage 3 (2022): private cloud infrastructure and network automation.
- Stage 4 (2023â2024): a target automation platform for the private cloud; upgrade to a highly available Ansible Automation Platform 2.3 (8,000 hosts), then Azure AD SSO with SAML authentication and RBAC (12,000 hosts).
- Stage 5 (2025): dynamic inventory, high availability and scalability (about 12,000 hosts).
The use-case map: one automation platform in the middle, integrations all around it.
The use-case slide connected the platform to VMware vCenter, Cisco, Equinix, Zabbix, Panorama, Red Hat Satellite, Infoblox, Azure AD, NetApp, CyberArk and Zscaler, among others. The listed use cases included SSL certificate management, security scanning and compliance, virtual workplace automation, NetApp-based storage automation and patch management. On the networking side: Infoblox for IP and DNS, Zscaler proxy and private access, Panorama for Palo Alto Networks firewalls, and changes on the Equinix Fabric.
The challenges slide was honest about where it hurt:
- Scaling: the platform needed more CPU and memory for more parallel forks, so resource-heavy jobs could run against many hosts at once.
- Performance: latency to an Azure PaaS PostgreSQL server slowed the Ansible Automation Platform GUI, so the team moved to PostgreSQL on an Azure VM (IaaS).
- Authentication: there was no out-of-the-box Azure AD integration for Private Automation Hub.
My take: this matches what I see when automation grows from one teamâs playbooks to a bank-wide platform. The hard part stops being Ansible and becomes platform operations: database latency, execution capacity, identity and upgrades. If you are on a similar path, plan the database and upgrade path early. I covered the latter in Upgrading to Ansible Automation Platform 2.6+. Package shared content as collections from the start, as described in Ansible Collections: Reusable Automation, so other teams can actually reuse it. Many of those vCenter integrations are the same patterns I wrote about in Ansible for VMware.
Maxim Burgerhout: Deliver value, automatically
After lunch, Maxim Burgerhout of Red Hat presented âDeliver value, automaticallyâ on the main stage. The agenda listed it as âAutomation platform engineering to improve automation adoptionâ. The argument started from a simple premise. IT is growing like never before, staff and resources often stay the same, so automation is now a requirement, and its scope keeps growing. The slides then asked the audience to âstep out of your bubbleâ: what does my organisation need, how can my team contribute, what do other teams need from us, and what does success look like?
Traditional delivery versus a product operating model for the automation platform.
The proposal was centralised, standardised creation and consumption of automation on a single automation platform. Developers, IT ops, SecOps, network ops and lines of business would all use it, across data centre, cloud and edge, with governance built in. âProduction readyâ was defined as fully automated and easily consumable. The talk quoted Evan Bottcherâs 2018 definition of a digital platform: self-service APIs, tools, services, knowledge and support âarranged as a compelling internal productâ. It then contrasted traditional delivery (maintaining a stable state, requirements defined up front, requests handled through tickets) with a product operating model (continuous improvement, problems engineered out pre-emptively, requests handled automatically and on demand). The promised benefits were faster time to value, less waste, lower risk and more agility. The âAdoption best practicesâ slide was organised in four phases (strategy, development, implementation and enablement), from creating an automation strategy and allocating budget and resources to having the platform, key resources and key processes in place.
Kevin Dubois: the trusted software supply chain
In the afternoon I joined Kevin Dubois of Red Hat in the Application Platform & Cloud Services track. The agenda title was âTrusted Application Pipeline - Developer Hub - Lower your developers time to value in a secure wayâ. He framed the problem with survey numbers on legacy modernisation, generative AI adoption and developer cognitive load, citing The Newstack, Gartner and Salesforce. Then came âShift Security Left in the Software Supply Chainâ. Red Hat Trusted Software Supply Chain was shown as Red Hat Developer Hub plus Trusted Artifact Signer and Trusted Profile Analyzer (together, the Trusted Application Pipeline), alongside OpenShift, Quay and Advanced Cluster Security.
The security-augmented development process: signed commits, a signing and SBOM-generating build pipeline, then GitOps deployment with SLSA checks.
The process slide covered each stage. Commits are signed with gitsign. The build pipeline verifies those signatures, packages and builds the container, signs the image with cosign, generates an SBOM and pushes to the registry. Deployment goes through a GitOps repository and Argo, with a âverify SLSA complianceâ step before anything reaches OpenShift. The demo made it concrete. The audience joined a phone-controlled car race backed by Quarkus and Kafka, in two teams named after Dutch snacks (bitterballen and frikandel). He showed the application in Red Hat Developer Hub (based on Backstage), where platform and security teams can offer opinionated templates. He then flipped a feature flag so players shook their phones instead of tapping, and pushed the change. On screen, the pipeline signed the image, uploaded the SBOM to Trusted Profile Analyzer, and had Advanced Cluster Security check the deployment. A Git tag promoted the build to pre-production after verifying the enterprise contract, and the GitOps repository was patched to roll it out. Frikandel won the second race.
My take: OpenShift Virtualization and the supply chain session look like separate topics, but both are about one platform with one set of controls. The VMs move onto the same cluster as the containers, and the security checks move into the same pipeline as the build. That is where I would start with a client today. For the operational side of running VMs on OpenShift, see Operationalizing OpenShift Virtualization. For the signing and provenance pieces, see Supply Chain Security: SBOMs, Sigstore and SLSA in Practice. For the portal on top, see Backstage: Build an Internal Developer Portal. My notes from the main Red Hat events are collected on the Red Hat Summit page.
