Foto: I Believe I Can Fly – shutterstock.com

Enterprise Architecture (EA) Tools unterstützen Unternehmen und Organisationen dabei, mit ihren IT-Strategien die Geschäftsziele optimal zu unterstützen. Sie sorgen ebenfalls dafür, dass Unternehmen ihre Roadmaps für die digitale Transformation geordnet vorantreiben können. EA Tools bieten dafür unter anderem Collaboration-, Reporting-, Testing- und Simulationsfunktionen. Mit deren Hilfe lassen sich Modelle implementieren, die Geschäfts- und IT-Prozesse gezielt verbessern.

Um die beste Lösung für Ihr Unternehmen zu finden, sollten Sie zuerst prüfen, ob sich das jeweilige Tool mit Ihrem Technologie-Stack integrieren lässt. Anschließend gilt es abzuwägen, ob die Informationen, Diagramme und Tabellen, die die Software zur Verfügung stellt, für das Unternehmen auch einen echten Nutzwert haben.

Empfehlenswerte Enterprise-Architecture-Tools

Nachfolgend finden Sie einen Überblick über die wichtigsten Enterprise-Architecture-Tools – in alphabetischer Reihenfolge. Sie stellen einen Mix aus Visualisierungs-, Collaboration- und Project-Management-Funktionen bereit und unterstützen eine Vielzahl von Enterprise Architecture Frameworks.

Ardoq

Nachdem zuerst über einfache Formulare Informationen von Usern, Entwicklern und sonstigen Stakeholdern im Unternehmen eingesammelt wurden, lässt sich mithilfe von Ardoq ein digitaler Zwilling der gesamten Organisation erstellen. Der Ansatz setzt also darauf, die Menschen, die in ihren Rollen mit den verschiedensten Systemen arbeiten, realistisch in ihrer Arbeitswelt abzubilden.

Jede Mitarbeiterin und jeder Mitarbeiter im Unternehmen kann später von den Netzwerkvisualisierungen und Datenfluss-Diagrammen profitieren, um seine eigene Rolle optimal zu unterstützen und den Arbeitsplatz immer wieder anzupassen und zu modernisieren. Das Tool lässt sich mit den wichtigsten Cloud-Plattformen integrieren. Es bietet eine API, die individuelle Anpassungen in allen wichtigen Programmiersprachen (Python, C#, Java, etc.) ermöglicht.

Wichtigste Use Cases:

• “Architektonischen Stress” bei Lastspitzen simulieren, falls größere Veränderungen bevorstehen;

• Verstehen, wie verändertes Nutzerverhalten neue Anforderungen generiert;

• Application Portfolio Management, um besser strategisch zu planen.

Atoll Group SAMU

Das EA-Tool SAMU macht die Enterprise Architecture sichtbar, indem es tiefe Verknüpfungen zwischen On-Premises-Systemen, dem Cloud-Layer und Tools für das Business Process Management aufzeigt. Das Tool der Atoll Group bietet vielfältige Integrationsmöglichkeiten, zum Beispiel mit Monitoring-Tools (etwa Tivoli, ServiceNow), Configuration-Management-Datenbanken (zum Beispiel CA, BMC) oder Service-Organisations-Tools (BMC, HPE). Alle Informationen fließen in ein zentrales Datenmodell ein, das um den zusätzlichen Input der Stakeholder weiter angereichert wird.

Wichtigste Use Cases:

• Enterprise-Architektur visualisieren;

• strategische Planungsprozesse und Architektur-Reviews mit Informationen unterfüttern;

• mithilfe einer visuellen Verständnisgrundlage die Kommunikation verbessern.

Avolution Abacus

Dieses Tool erfasst die Breite und den Umfang der Unternehmensarchitektur mit Hilfe eines auf Diagrammen basierenden Dashboards. Die Integration mit gängigen Tools wie SharePoint, Excel, Visio, Google Sheets, Technopedia oder ServiceNow vereinfacht die Nutzung. Abacus wurde inzwischen auch um einen Machine-Learning-Layer ergänzt, der es Anwendern ermöglicht, ein Modell zu trainieren, das ihnen beispielsweise hilft zu erkennen, wer im Unternehmen für welches System verantwortlich ist.

Wichtigste Use Cases:

• die IT für das gesamte Unternehmen “öffnen”, um ein allgemeines Verständnis der Datenflüsse zu erzeugen;

• umfassendes Enterprise Modeling, um eine Roadmap für künftige Entwicklungen zu erstellen;

• Business-Metriken tracken, die mit der Unternehmens-Performance zusammenhängen.

BOC Group ADOIT

ADOIT soll Teams dabei unterstützen, Ressourcen zu verwalten, Bedarfe vorherzusagen und Assets zu tracken. Dazu mappt das Tool jedes System oder Softwarepaket mit einem Objekt. Die Datenflüsse zwischen den Systemen werden in Beziehungen umgewandelt, die von diesen Objekten mithilfe eines anpassbaren Metamodells erfasst werden. Geschäftsprozesse können auf ähnliche Weise über ein gut integriertes Begleitprodukt namens ADONIS modelliert werden. ADOIT ist Web-basiert und lässt sich auch mit Tools wie Atlassian Confluence integrieren, um die Datenerfassung und -entwicklung zu beschleunigen.

Wichtigste Use Cases:

• ein unternehmensweites Modell erstellen, das bei sämtlichen Teammitgliedern ein Verständnis über den Stack schafft – und wie man diesen verbessern kann;

• vollständiger Zugriff auf EA-Daten über eine Mobile-Anwendung;

• bei Fusionen und Übernahmen den Tech-Bereich durch genaues Asset-Mapping orchestrieren.

Bizzdesign Hopex

Nach der Übernahme von Mega International zählt die Hopex-Plattform zum Portfolio von Bizzdesign. Sie soll dabei unterstützen, Unternehmensanwendungen zu modellieren und dabei ein Verständnis der von ihnen unterstützten Geschäfts-Workflows schaffen. Dabei liegt ein Schwerpunkt auf den Bereichen Data Governance und Risikomanagement. Hopex basiert auf Microsoft Azure und stützt sich auf eine Reihe offener Standards wie GraphQL und REST Queries, um Informationen aus Komponentensystemen zu sammeln. Das Reporting ist mit den Office-Tools von Microsoft sowie mit grafischen Lösungen wie Tableau und Qlik integriert.

Wichtigste Use Cases:

• datengestützte Erkenntnisse herbeiführen, um Cloud- und Anwendungsbereitstellung zu steuern;

• akkurate Nutzungsmodelle erstellen, um Architekturanforderungen zu verstehen;

• eine Bedarfsschätzung mit Umfragen und anderen Tools vornehmen, um für die Zukunft zu planen.

Bizzdesign Horizzon

Das Tool dient dazu, Business Workflows und den zugrundeliegenden Tech-Stack zu modellieren. Dazu bietet Horizzon ein Graph-basiertes Modell, das Daten von sämtlichen Stakeholdern einsammelt und diese an eine Analytics-Engine weitergibt. Im Ergebnis entstehen Diagramme, die den aktuellen Systemzustand widerspiegeln. Wichtige Schwerpunkte dieses Tools sind Change Management und Zukunftsplanung: Horizzon ist nicht zuletzt dafür konzipiert worden, die Risiken eines Redesigns zu minimieren. Das Toolset unterstützt die wichtigsten Frameworks ArchiMate, TOGAF und BPMN. Neben Mega hat Bizzdesign im Januar 2025 auch den EA-Geschäftsbereich der Software AG – Alfabet – übernommen.

Wichtigste Use Cases:

• Vorhersage zukünftiger Anforderungen durch Predictive Modeling;

• Orchestrieren von Workflows auf der Basis der technischen und der Business-Architektur;

• Antizipieren von Risiken sowie Security- und Governance-Problemen durch die Modellierung von Datensicherheitsanforderungen.

Capstera

Das Tool von Capstera fokussiert darauf, die Business Architecture selbst abzubilden. Value und Process Maps helfen dabei, die Rollen der verschiedenen Unternehmensbereiche zu definieren und nachzuverfolgen. Dabei können im laufenden Prozess Verknüpfungen mit den zugrundeliegenden Softwarprodukten und Tools hinzugefügt werden.

Wichtigste Use Cases:

• Reports erstellen, die sich erst einmal mit der Business-Architektur selbst beschäftigen;

• Beziehungen zwischen Menschen, Abteilungen und Rollen analysieren;

• die langfristige strategische Planung vorantreiben.

Clausmark Bee360

Teammitglieder, die Clausmarks Flaggschiffprodukt Bee360 (früher Bee4IT) verwenden, wollen eine einfache “Single Source of Truth” über die Workflows im Unternehmen. Ziel ist es, verschiedenen betrieblichen Rollen intelligentere Entscheidungen zu ermöglichen. Das Modul Bee360 FM (Finanzmanagement) bietet etwa die Möglichkeit, Kosten nachzuvollziehen und zuzuordnen. Die Anwender können verschiedene solcher Module miteinander verknüpfen, um EAM, Finanzmanagement, Portfolio Management und Agile Planning nahtlos zu integrieren – bei maximaler Transparenz.

Wichtigste Use Cases:

• C-Suite-Ebene befähigen, Projekte zu managen und Assets zuzuweisen;

• präzise digitale Zwillinge entwickeln, um ein Verständnis über Datenflüsse zu schaffen und künftige Erweiterungen zu planen;

• integrierte Wissensdatenbank aufbauen, um alle digitalen Workflows zu tracken.

EAS

Das Essential-Paket von EAS (Enterprise Architecture Solutions) nahm als Open-Source-Projekt seinen Anfang und hat sich inzwischen zu einer kommerziell verfügbaren Cloud-Lösung weiterentwickelt. Das Tool erstellt ein Metamodell, das die Interaktionen zwischen Systemen und Geschäftsprozessen beschreibt. Ebenfalls enthalten sind Pakete, um gängige Business Workflows wie Datenmanagement oder DSGVO-Compliance zu tracken.

Wichtigste Use Cases:

• den technischen Reifegrad der eigenen Architektur evaluieren;

• Sicherheit und Governance durch besseres Asset Tracking optimieren;

• wachsende Systemkomplexität kontrollieren und managen.

OrbusInfinity

Orbus Software hat Anfang 2025 die Akquisition seines Konkurrenten Capsifi abgeschlossen. Der Anbieter stellt mit OrbusInfinity eine Enterprise-Transformation-Plattform auf KI-Basis zur Verfügung, die schnellere, bessere Entscheidungen, Kosteinesparungen und Risikominimierung verspricht. Architecture-Teams sollen mit Hifle von OrbusInfinity mit einer Vielzahl von Stakeholdern interagieren können, um eine “digitale Blaupause” ihres Unternehmens zu generieren, die eine einheitliche Sicht auf das aktuelle und künftige Geschäft realisieren soll. Diverse Drittanbieter-Tools lassen sich außerdem mit der Plattform integrieren, darunter etwa von Microsoft, Flexera, ManageEngine oder ServiceNow.

Wichtigste Use Cases:

• Stakeholder-Management;

• Enterprise-Landschaften visualisieren;

• Entscheidungsfindung und Datenanalyse automatisieren.

Planview Enterprise One

Planview bietet eine ganze Reihe von Produkten, mit denen Unternehmen Teamwork, Prozesse und die Enterprise Architecture nachvollziehen können. Die Enterprise Tools sind in drei Kategorien unterteilt: strategisches Portfolio-Management, Produktportfolio-Management und Projektportfolio-Management. Im Zusammenspiel entstehen hardware- und Software-übergreifende Layer, die rollenbasierte Perspektiven für Führungskräfte und Teammitglieder eröffnen. Das Toolset integriert mit gängigen Ticket-Tracking-Systemen wie Jira, um Workflow-Analysen und Reports zu erstellen. Inzwischen hat Planview nach einer Übernahme neue Tools in sein Portfolio integriert, die früher unter den Namen Daptiv, Barometer und Projectplace bekannt waren.

Wichtigste Use Cases:

• eine langfristige, strategische Vision für die Architekturentwicklung aufbauen;

• Entwicklungsarbeit auf Projektebene tracken und in eine beliebige Strategie integrieren;

• mit Fokus auf die Customer Experience und die Produktstruktur den Change vorantreiben.

QualiWare Enterprise Architecture

Das Enterprise Architecture Tool von QualiWare ist Teil einer größeren Sammlung von Modellierungswerkzeugen, die darauf abzielt, sämtliche Geschäftsprozesse zu erfassen. Beispielsweise ist es möglich, einen digitalen Zwillinge zu bauen, mit dem sich Customer Journeys nachvollziehen lassen. Qualiware hat diverse KI-Algorithmen integriert, um Dokumentation und Process Discovery zu optimieren.

Wichtigste Use Cases:

• ein kollaboratives Ökosystem für Business Manager aufbauen, das ein Verständnis von der Enterprise Architecture vermittelt;

• architektonische Designelemente erfassen, um ein Wissens-Ökosystem rund um den Stack aufzubauen;

• eine breite Beteiligung in Sachen Dokumentationserstellung und -überprüfung fördern.

Quest Erwin Evolve

Das Erwin Evolve Tool von Quest hat sich von einem Datenmodellierungs-Tool zu einem System für Enterprise-Architecture- und Geschäftsprozess-Modellierung weiterentwickelt. Um die Komplexität moderner, ineinandergreifender Softwaresysteme und der von ihnen gemanagten Geschäftsprozesse zu durchdringen, können Anwender auf benutzerdefinierte Datenstrukturen zurückgreifen. Das Web-Tool erstellt Modelle, rollenbasierte Diagramme und andere Visualisierungen, die in allgemein zugängliche Dashboards einfließen. Zum Paket gehört ein KI-basiertes Modellierungs-Tool, das Whiteboard-Skizzen integrieren kann.

Wichtigste Use Cases:

• einen digitalen Zwilling für die strategische Modellierung der Enterprise Data Architecture erstellen;

• Customer Journeys verstehen;

• Services und Systeme mit Application Portfolio Management tracken.

SAP LeanIX Enterprise Architecture Suite

Die Tool-Sammlung von LeanIX umfasst unter anderem Enterprise Architecture Management und andere Bereiche, die für Aufgaben wie SaaS– und Value-Stream-Management wichtig sind – etwa um Cloud-Deployments und darauf laufende Services zu tracken. Die Daten die dabei über die IT-Infrastruktur gesammelt werden, fließen in ein grafisches Dashboard ein. Das Tool ist eng mit wichtigen Cloud-Workflow-Tools wie Confluence, Jira, Signavio und Lucidchart integriert. Das ist für Teams von Vorteil, die diese Tools bereits nutzen, um ihre Entwicklungsstrategien zu planen und umzusetzen. Seit November 2023 ist LeanIX Teil von SAP.

Wichtigste Use Cases:

• Anwendungsmodernisierung und Cloud-Migration managen;

• Obsoleszenz von Software-Services evaluieren;

• Kosten kontrollieren und managen.

ServiceNow

Die Tool-Sammlung von ServiceNow lässt sich auf verschiedene Architekturtypen herunterbrechen, darunter Assets, DevOps, Security und Service. Die Tools katalogisieren die unterschiedlichen Hardware- und Softwareplattformen, um Workflows und Datenflüsse im Unternehmen abzubilden und zu verstehen. Ausführliche Reportings und detaillierte Dashboards ermöglichen Analysen, auf deren Grundlage Risiken minimiert und die Ausfallsicherheit der Systeme erhöht werden können.

Wichtigste Use Cases:

• Tracken von Assets, Services und Systemen, die das Unternehmen ausmachen;

• Governance-Themen, Risikobegrenzung, IT-Management und Security Operations werden in einer Plattform zusammengeführt;

• durch die Integration von CRM-Tools lassen sich auch kundenorientierte Services managen.

Sparx Systems

Um Teams und Projekte verschiedener Größe und Komplexität zu unterstützen, hat Sparx vier Versionen seines EA-Tools entwickelt. Allen gemeinsam ist eine UML-basierte Modellierung, mit der sich die Komponenten komplexer Systeme tracken lassen. Eine Simulations-Engine ermöglicht “War Gaming” und vermittelt ein Verständnis darüber, wie sich Fehler ausbreiten und kaskadieren können. Sparx stellt zudem eine Vielzahl von vorgefertigten Design Patterns bereit, um Teams bei der Modellierung zu unterstützen.

Wichtigste Use Cases:

• Nachfrage- und Lastveränderungen zur Prognose künftiger Anforderungen simulieren;

• (potenzielle) Probleme durch eine Verbindungs-Matrix im Auge behalten;

• Dokumentation erstellen.

Unicom System Architect

System Architect ist eines der Angebote aus Unicoms Team Blue. Es handelt sich um ein Tool, das ein Metamodell verwendet, um automatisiert so viele Daten wie möglich über die laufenden Systeme zu sammeln – manchmal auch durch ein Reverse Engineering von Datenflüssen. Dieses systemweite Datenmodell kann über benutzerdefinierte Dashboards Teammitgliedern aller Rollen zugänglich gemacht werden. Ein weiteres erwähnenswertes Feature: Die Ressourcenzuweisung lässt sich mit Hilfe von Simulationen optimieren.

Wichtigste Use Cases:

• Was-wäre-wenn-Fragen zum Architekturmodell stellen;

• ein Metamodell von Daten und Systemen aufbauen;

• Migrations- und Transformationspläne erstellen.

ValueBlue BlueDolphin

Dieses EA-Tool sammelt Daten auf dreierlei Art:

1. Es importiert Basisdaten auf der Grundlage standardgesteuerter Automatisierung (ITSM, SAM).

2. Es arbeitet mit den Dateiformaten von Architekten und Systemdesignern – etwa ArchiMate oder BPMN.

3. Es gibt Fragebögen an andere Stakeholder heraus, die auf anpassbaren Vorlagen basieren.

Die aufbereiteten Informationen werden in einer visuellen Umgebung bereitgestellt, die Auskunft über die historische Entwicklung von Systemen gibt.

Wichtigste Use Cases:

• systemweite Daten von internen und externen Stakeholdern automatisiert und formularbasiert erfassen;

• zukunftsorientierte Reportings erzeugen, um den Change zu überwachen und voranzutreiben;

• Kooperation und Zusammenarbeit durch offenes Data Reporting fördern.

(fm)

Dieser Artikel ist im Original bei unserer Schwesterpublikation CIO.com erschienen.

Foto: SkillUp | shutterstock.com

Manche Devs arbeiten mit der Kommandozeile (auch Command Line Interface; CLI), weil sie sie lieben – andere, weil ihnen nichts anderes übrig bleibt. Egal zu welcher Kategorie Sie sich zählen: Diese neun CLI-Tools helfen Ihrer Produktivität und Effizienz (zusätzlich) auf die Sprünge.

tldr

Keine Angst, wir ersparen Ihnen an dieser Stelle eine langwierige, faszinative Abhandlung über die ganz eigene Magie, die die Unix-Shell entfaltet. Fakt ist: Wenn man mit ihr arbeiten will, ist es manchmal erforderlich, vorher ein Handbuch zu lesen. Unix Docs (auch man- oder manual pages) sind diesbezüglich allerdings ein zweischneidiges Schwert: Die benötigte Information ist vorhanden – es ist nur die Frage, wo. Den Teil der Dokumentation aufzuspüren, den Sie gerade benötigen, kann ein entmutigender Task sein. Zwar kann die gute alte Befehlszeile dabei helfen – um ein offizielles Handbuch aufzurufen, genügt:

$ man

Allerdings zeichnen sich man-pages vor allem durch ihre Informationsdichte aus – und die Tatsache, dass sie manchmal aktuelle Informationen für neuere Tools vermissen lassen. Das CLI-Tool tldr versetzt Sie in die Lage, zielgerichteter zu suchen:

$ tldr

Foto: Matthew Tyson | IDG

Falls Sie npm installiert haben, ist die tldr-Installation nur einen kurzen Befehl entfernt:

npm install -g tldr

ngrok

Sobald Sie tldr installiert haben, können Sie damit viele weitere Befehle erkunden. Zum Beispiel:

$ tldr ngrok

Reverse proxy that creates a secure tunnel from a public endpoint to a locally running web service.

Mit ngrok eröffnet sich Ihnen eine stressfreie Möglichkeit, von einem Remote-Browser auf eine Entwicklungsmaschine zuzugreifen. Aber das Tool kann noch weit mehr. Sie können damit beispielsweise in der Cloud entwickeln und die Ergebnisse im Browser in Augenschein nehmen. Zudem können Sie mit ngrok auch schnell und einfach laufende Services über HTTPS veröffentlichen – ohne sich mit der Security-Infrastruktur herumschlagen zu müssen. Angenommen, Sie bauen einen Service Worker auf, der HTTPS benötigt, dann ist alles, was Sie für einen sicheren Kontext tun müssen, ngrok zu starten.

Foto: Matthew Tyson | IDG

Ein Beispiel, bei dem der HTTP-Port 8080 freigegeben wird:

$ ngrok http 8080

Der ngrok-Output sieht wie folgt aus:

https://f951-34-67-117-59.ngrok-free.app -> http://localhost:8080

Anschließend kann jedermann die zugewiesene URL aufrufen (machen Sie sich keine Mühe).

screen

Mit diesem Befehlszeilen-Tool können Sie eine Shell-Sitzung mit oder ohne laufenden Prozess “beiseite legen” und sie anschließend zu einem beliebigen Zeitpunkt fortsetzen – auch wenn Sie die ursprüngliche Session beenden.

$ tldr screen

Hold a session open on a remote server. Manage multiple windows with a single SSH connection.

Nehmen wir an, Sie starten ngrok, um remote auf eine Webanwendung zuzugreifen: Sie starten den Prozess, lassen diesen dann in screen laufen und programmieren so lange etwas. Währenddessen läuft ngrok die ganze Zeit weiter – Sie können über screen jederzeit wieder darauf zugreifen. Veranschaulicht in Code würde das wie folgt aussehen:

$ screen

// Now we are in a new session

$ ngrok http 8080

// Now ngrok is running, exposing http port 8080

Type ctrl-a

// Now we are in screen's command mode

Type the "d" key, to "detach".

// Now you are back in the shell that you started in, while screen is running your ngrok command in the background:

$ screen -list

There is a screen on:

128861.pts-0.dev3 (04/25/24 14:36:58) (Detached)

Tipp

Wenn Sie eine laufende Sitzung, in der Sie sich gerade befinden, benennen wollen, nutzen Sie die Tastenkombination Strg + A und geben :sessionname ein. Das ist besonders nützlich, wenn Sie mit mehreren Screen-Instanzen arbeiten wollen.

Foto: Matthew Tyson | IDG

Wenn wie im Beispiel nur eine screen-Instanz läuft, führt der Befehl $ screen -r (für “re-attach”) Sie zurück zu Ihrer ngrok-Sitzung. Im Fall mehrerer Screens können Sie diese mit Hilfe ihrer ID wieder aufrufen:

$ screen -r

Wenn Sie Ihre Session endgültig beenden wollen, beenden Sie ngrok mit Strg + C und geben anschließend exit in die Kommandozeile ein.

sdkman & nvm

Wenn Sie Java oder JavaScript auf einem Server verwenden, sollten Sie sich mit sdkman (für Java) und nvm (für Node) vertraut machen. Beide Kommandozeilen-Tools sind nützlich, wenn es darum geht, mit mehreren Programmiersprachenversionen auf dem selben Rechner zu jonglieren – und dabei sowohl Path Adjustment als auch Umgebungsvariablen überflüssig machen.

Mit sdkman können Sie beispielsweise neuere Java-Versionen erkunden und anschließend wieder zum aktuellen LTS-Release springen. Dieser Prozess wird durch das sdk-Kommando abstrahiert.

Foto: Matthew Tyson | IDG

Zwischen den Versionen zu wechseln, gestaltet sich denkbar einfach – $ sdk use java 19-open führt Sie direkt zu JDK Version 19.

$ tldr sdk

Manage parallel versions of multiple Software Development Kits.

Supports Java, Groovy, Scala, Kotlin, Gradle, Maven, Vert.x and many others.

Die nvm-Utility funktioniert ganz ähnlich:

$ tldr nvm

Install, uninstall or switch between Node.js versions.

Supports version numbers like "12.8" or "v16.13.1", and labels like "stable", "system", etc.

Foto: Matthew Tyson | IDG

fzf

Sowohl grep als auch find sind Standardbestandteile der Kommandozeilen-Befehlspalette. Allerdings sind beide Tools nicht so funktional, wie sie sein sollten. Das ruft fzf auf den Plan – einen “Fuzzy File Finder”. Mit “Fuzzy” ist dabei gemeint, dass die Details zu dem, was Sie suchen, nicht unbedingt klar definiert sein müssen. Ein Beispiel:

$ tldr fzf

Command-line fuzzy finder.

Similar to sk.

Sobald Sie fzf starten, indiziert das CLI-Tool umgehend das Dateisystem, um Ergebnisvorschläge für Ihre Suchen zu unterbreiten.

Foto: Matthew Tyson | IDG

Aus 878.937 Möglichkeiten hat fzf die 25 Dateien und Verzeichnisse ausgewählt, die unseren Anforderungen entsprechen könnten – und das völlig ohne Umwege.

exa

Mit exa werden langweilige alte ls-Listings schöner und nützlicher:

$ tldr

A modern replacement for ls (List directory contents).

Für eine bessere Developer Experience ohne mentalen Overhead statten Sie ls einfach mit einem exa-Alias aus. Das Tool respektiert die meisten ls-Standardoptionen – exa -l funktioniert also (beispielsweise) genau so, wie Sie es erwarten würden.

Foto: Matthew Tyson | IDG

bat

Die bat-Utility ähnelt dem cat-Tool – ist aber besser:

$ tldr bat

Print and concatenate files.

A cat clone with syntax highlighting and Git integration.

Es handelt sich hierbei im Wesentlichen um eine Komfort- beziehungsweise Developer-Experience-Optimierung – ähnlich wie im Fall von exa. Wenn Sie bat verwenden, erwartet Sie ein vollwertiger File Viewer – inklusive Title, Borders, Line Numbers und insbesondere einer hilfreichen Syntax-Highlighting-Funktion für Programmiersprachen oder Konfigurationsdateien. Dabei reagiert bat auf less/more-Befehle – und wird mit “q” beendet. Die Navigation erfolgt über die Pfeiltasten.

Foto: Matthew Tyson | IDG

nethack

Ein absoluter Kommandozeilen-Klassiker ist nethack – der ursprüngliche, Konsolen-basierte ASCII Dungeon Crawler. Das CLI-Tool wird Ihre Produktivität zwar nicht direkt ankurbeln – kann aber durchaus dabei helfen, ein paar Minuten zur Ruhe zu kommen, um komplexe Dev-Probleme zu durchdringen.

Foto: Matthew Tyson | IDG

Dieser Artikel ist im Original bei unserer Schwesterpublikation Infoworld.com erschienen.

The evolution of Java is the subject of a just-released documentary about the programming language and development platform. “The Java Story: The Official Documentary” tells the story of Java through interviews with the engineers who created it and shepherded it through three decades.

Produced by CultRepo and sponsored by Oracle, JetBrains, IBM, and Azul, the documentary follows Java from its set-top box and browser-based origins at Sun Microsystems in the 1990s and through its rise to dominate server-side computing in the 2000s, the “dark ages” and resurgence with Java 8 under Oracle in the 2010s, and its continuing modernization and promising role in AI today. “From its humble beginnings as a project code-named ‘Oak’ at Sun Microsystems to becoming a global standard for enterprise software and billions of devices, Java’s journey is one of radical innovation, strategic pivots, and enduring community strength,” said Cult.Repo.

The documentary also delves into Sun’s bitter Java licensing dispute with Microsoft, Oracle’s suit of Google over its use of Java APIs Android (Google won), the creation of the Java Community Process, Sun’s open-sourcing of Java, and Oracle’s switch to the six-month release cycle. Technical enhancements such as lambda expressions in Java 8, virtual threads in Java 21 (Project Loom), and the ongoing refactor to bring value objects to the Java object model (Project Valhalla) also get attention.

Technical experts and other Java figures interviewed in the documentary include James Gosling, creator of Java; Kim Polese, Java’s first product manager; Carla Schroer, director of Java compatibility at Sun Microsystems; James Duncan Davidson, creator of Apache Tomcat; Mark Reinhold, chief architect of the Java Platform Group at Oracle; Brian Goetz, Java language architect in the Java Platform Group at Oracle; Rod Johnson, creator of Spring; and Gavin King, creator of Hibernate.

G# (GSharp) is moving forward as a programming language for Microsoft’s .NET platform, touted as bringing Go-, Kotlin-, and Swift-style ergonomics to the CLR (Common Language Runtime). The language is described by its creators as modern, simple, and accessible.

Although pre-1.0 and still growing, G# aims to be for people who want a small, predictable language with direct access to the .NET ecosystem. Developers will see imports, func, structs, slices, maps, channels, go, select, and for in iteration. Also important are nullable flow, direct calls into the CLR (Common Language Runtime), and built-in concurrency.

With G#, copyrighted in 2026, developers get value-oriented structs, reference-oriented classes, data structs, and data classes. For concurrency, G# uses scope for structured concurrency, async func and await for task-based asynchrony, and async sequence[T] for asynchronous streams. G# also makes use of the same Task and Task[T] types familiar from the .NET BCL (Base Class Library).

G# documentation is available on the GitHub site of Microsoft software engineer David Obando. “Every .NET type—your packages, third-party NuGet packages, the BCL—is callable from G# with the syntax you already know. CLR generics use G#’s bracket spelling, and method calls, properties, indexers, and for in over IEnumerable[T] all just work,” according to the website.

A Visual Studio Code extension for G3 can be found at marketplace.visualstudio.com. The extension adds syntax highlighting, language server features, build/run commands, and debugger configuration for .gs and .gsproj files. Developers can install the extension from within VS Code (search for “G#” in the Extensions view) or from the command line.

Oracle’s July 2026 Critical Patch Update, its largest ever, contains 1,449 new security patches spanning 32 product families, from Oracle Database and E-Business Suite to PeopleSoft, GoldenGate, Java SE, and Fusion Middleware.

Fusion Middleware was particularly hard hit, with new security patches for 355 security vulnerabilities, 219 of them remotely exploitable without authentication, meaning they can be exploited over a network without requiring user credentials. Ten of them scored a “perfect” 10.0 on the Common Vulnerability Scoring System (CVSS).

These included easily exploitable vulnerabilities allowing unauthenticated attackers with network access via HTTP to compromise Oracle Data Integrator, Oracle Access Manager, Oracle HTTP Server, Oracle Platform Security for Java, Oracle WebCenter Content, Service Delivery Platform, or Oracle Weblogic Server Proxy Plug-in,

No other products were found to have quite such extreme vulnerabilities, but there were plenty of others scoring almost as badly.

Two critical flaws in Oracle Database Server

The most severe flaw Oracle patched in its flagship database product is CVE-2026-61211, a vulnerability in the RDBMS component’s DBMS_CLOUD package with a CVSS score of 9.9.

This easily exploitable vulnerability allows a low-privileged attacker having Execute DBMS_CLOUD privilege with network access via Oracle Net to compromise the RDBMS, Oracle said in the patch update statement. “While the vulnerability is in RDBMS, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of RDBMS,” it warned.

The flaw affects Database Server versions 19.3 through 19.31 and 23.4.0 through 23.26.2.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said the 9.9 score should be read as serious but conditional. Exposure depends on configuration, he said: On customer-managed databases, DBMS_CLOUD is absent until installed, and grants and network access lists determine the radius from there. “Where DBMS_CLOUD is broadly granted and reachable, the emergency is real and the window is seventy-two hours; where it is absent, the accelerated database wave will do.”

Vibhum Dubey, a cybersecurity researcher and red teamer, said the flaw stood out to him because it checks several boxes that concern defenders.

“Database servers often hold an organization’s most valuable data, so even if exploitation is not publicly observed yet, I don’t think this is the kind of issue you leave until the next routine maintenance window if your environment is exposed,” Dubey said.

A second Database Server flaw, CVE-2026-47040, affects Connection Manager in Oracle Net Services, is remotely exploitable without credentials. Oracle’s risk matrix lists six Database Product vulnerabilities in this cycle as reachable over a network with no authentication required, the statement added.

CVE-2026-7383, an OpenSSL-related TLS vulnerability, affects two products, Database Server and Autonomous Health Framework, since both bundle the same third-party component. Oracle’s advisory notes the Database Server patch for that CVE also resolves 19 related OpenSSL CVEs bundled into the same fix.

Oracle GoldenGate received 27 new patches, nine of which do not require authentication to exploit, including CVE-2026-2332, a flaw in the Big Data and Application Adapters component tied to Eclipse Jetty, the statement added.

There were also two critical flaws in Oracle’s TimesTen in-memory database.

The remainder of the release spans E-Business Suite, WebLogic Server, PeopleSoft, Siebel, JD Edwards, Communications, Retail Applications, Utilities Applications, MySQL, Solaris and VM VirtualBox.

Volume repair

Gogia said the volume itself marks a shift.

“At 1,449 patches, against 481 in April 2026 and 309 a year earlier, patch load has outgrown the queue built to hold it,” he said. He recommended a tiered response: “The reachable and the reported inside seventy-two hours, the trusted core inside ten days, the rest by risk before the October release.”

He also flagged a specific risk in how organizations might triage E-Business Suite. “Oracle’s advisory concedes that E-Business Suite exposure sits partly in underlying Database and Fusion Middleware versions outside the E-Business Suite matrix. The fastest way to mis-prioritise this release is to patch by product logo instead of trust boundary.”

Third Tuesday, quarterly cycle

The July release is the third quarterly Critical Patch Update of 2026, and the first since the introduction in May of the monthly Critical Security Patch Update program.

Gogia said Oracle has effectively layered a second cadence on top of the existing one rather than replacing it.

“Quarterly Critical Patch Updates remain and stay cumulative; monthly Critical Security Patch Updates now sit on top,” he said, adding that enterprise adoption of the new rhythm remains low because of “certification obligations, regression exposure and scarce specialist hours.”

Dubey made a similar point about organizational readiness: “In large enterprises, patching is rarely a technical problem. It is an operational one. Database administrators, application owners, infrastructure teams, business stakeholders, and change advisory boards all have to align.”

Niyati Daftary, principal analyst at Gartner, said the release underscores a broader shift in how patching is approached.

“Patching is no longer a race to remediate every vulnerability. It is a discipline of identifying the exposures that matter most and reducing business risk as efficiently as possible,” she said, adding that organizations should prioritize based on exposure, business impact and exploitability, starting with internet-facing assets and mission-critical systems.

Daftary pointed to continuous threat exposure management and adversarial exposure validation as increasingly relevant frameworks, since CVSS scores “measure theoretical severity rather than actual enterprise risk.” Patching alone will not be sufficient, Daftary said, and organizations should continue investing in defense in depth, including behavioral threat detection and incident response.

Oracle’s next cumulative Critical Patch Update will come on Oct. 20, 2026, with smaller Critical Security Patch Updates on Aug. 18 and Sept. 15.

This article first appeared on CSO.

Oracle’s July 2026 Critical Patch Update, its largest ever, contains 1,449 new security patches spanning 32 product families, from Oracle Database and E-Business Suite to PeopleSoft, GoldenGate, Java SE, and Fusion Middleware.

Fusion Middleware was particularly hard hit, with new security patches for 355 security vulnerabilities, 219 of them remotely exploitable without authentication, meaning they can be exploited over a network without requiring user credentials. Ten of them scored a “perfect” 10.0 on the Common Vulnerability Scoring System (CVSS).

These included easily exploitable vulnerabilities allowing unauthenticated attackers with network access via HTTP to compromise Oracle Data Integrator, Oracle Access Manager, Oracle HTTP Server, Oracle Platform Security for Java, Oracle WebCenter Content, Service Delivery Platform, or Oracle Weblogic Server Proxy Plug-in,

No other products were found to have quite such extreme vulnerabilities, but there were plenty of others scoring almost as badly.

Two critical flaws in Oracle Database Server

The most severe flaw Oracle patched in its flagship database product is CVE-2026-61211, a vulnerability in the RDBMS component’s DBMS_CLOUD package with a CVSS score of 9.9.

This easily exploitable vulnerability allows a low-privileged attacker having Execute DBMS_CLOUD privilege with network access via Oracle Net to compromise the RDBMS, Oracle said in the patch update statement. “While the vulnerability is in RDBMS, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of RDBMS,” it warned.

The flaw affects Database Server versions 19.3 through 19.31 and 23.4.0 through 23.26.2.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said the 9.9 score should be read as serious but conditional. Exposure depends on configuration, he said: On customer-managed databases, DBMS_CLOUD is absent until installed, and grants and network access lists determine the radius from there. “Where DBMS_CLOUD is broadly granted and reachable, the emergency is real and the window is seventy-two hours; where it is absent, the accelerated database wave will do.”

Vibhum Dubey, a cybersecurity researcher and red teamer, said the flaw stood out to him because it checks several boxes that concern defenders.

“Database servers often hold an organization’s most valuable data, so even if exploitation is not publicly observed yet, I don’t think this is the kind of issue you leave until the next routine maintenance window if your environment is exposed,” Dubey said.

A second Database Server flaw, CVE-2026-47040, affects Connection Manager in Oracle Net Services, is remotely exploitable without credentials. Oracle’s risk matrix lists six Database Product vulnerabilities in this cycle as reachable over a network with no authentication required, the statement added.

CVE-2026-7383, an OpenSSL-related TLS vulnerability, affects two products, Database Server and Autonomous Health Framework, since both bundle the same third-party component. Oracle’s advisory notes the Database Server patch for that CVE also resolves 19 related OpenSSL CVEs bundled into the same fix.

Oracle GoldenGate received 27 new patches, nine of which do not require authentication to exploit, including CVE-2026-2332, a flaw in the Big Data and Application Adapters component tied to Eclipse Jetty, the statement added.

There were also two critical flaws in Oracle’s TimesTen in-memory database.

The remainder of the release spans E-Business Suite, WebLogic Server, PeopleSoft, Siebel, JD Edwards, Communications, Retail Applications, Utilities Applications, MySQL, Solaris and VM VirtualBox.

Volume repair

Gogia said the volume itself marks a shift.

“At 1,449 patches, against 481 in April 2026 and 309 a year earlier, patch load has outgrown the queue built to hold it,” he said. He recommended a tiered response: “The reachable and the reported inside seventy-two hours, the trusted core inside ten days, the rest by risk before the October release.”

He also flagged a specific risk in how organizations might triage E-Business Suite. “Oracle’s advisory concedes that E-Business Suite exposure sits partly in underlying Database and Fusion Middleware versions outside the E-Business Suite matrix. The fastest way to mis-prioritise this release is to patch by product logo instead of trust boundary.”

Third Tuesday, quarterly cycle

The July release is the third quarterly Critical Patch Update of 2026, and the first since the introduction in May of the monthly Critical Security Patch Update program.

Gogia said Oracle has effectively layered a second cadence on top of the existing one rather than replacing it.

“Quarterly Critical Patch Updates remain and stay cumulative; monthly Critical Security Patch Updates now sit on top,” he said, adding that enterprise adoption of the new rhythm remains low because of “certification obligations, regression exposure and scarce specialist hours.”

Dubey made a similar point about organizational readiness: “In large enterprises, patching is rarely a technical problem. It is an operational one. Database administrators, application owners, infrastructure teams, business stakeholders, and change advisory boards all have to align.”

Niyati Daftary, principal analyst at Gartner, said the release underscores a broader shift in how patching is approached.

“Patching is no longer a race to remediate every vulnerability. It is a discipline of identifying the exposures that matter most and reducing business risk as efficiently as possible,” she said, adding that organizations should prioritize based on exposure, business impact and exploitability, starting with internet-facing assets and mission-critical systems.

Daftary pointed to continuous threat exposure management and adversarial exposure validation as increasingly relevant frameworks, since CVSS scores “measure theoretical severity rather than actual enterprise risk.” Patching alone will not be sufficient, Daftary said, and organizations should continue investing in defense in depth, including behavioral threat detection and incident response.

Oracle’s next cumulative Critical Patch Update will come on Oct. 20, 2026, with smaller Critical Security Patch Updates on Aug. 18 and Sept. 15.

This article first appeared on CSO.

Oracle’s July 2026 Critical Patch Update, its largest ever, contains 1,449 new security patches spanning 32 product families, from Oracle Database and E-Business Suite to PeopleSoft, GoldenGate, Java SE, and Fusion Middleware.

Fusion Middleware was particularly hard hit, with new security patches for 355 security vulnerabilities, 219 of them remotely exploitable without authentication, meaning they can be exploited over a network without requiring user credentials. Ten of them scored a “perfect” 10.0 on the Common Vulnerability Scoring System (CVSS).

These included easily exploitable vulnerabilities allowing unauthenticated attackers with network access via HTTP to compromise Oracle Data Integrator, Oracle Access Manager, Oracle HTTP Server, Oracle Platform Security for Java, Oracle WebCenter Content, Service Delivery Platform, or Oracle Weblogic Server Proxy Plug-in,

No other products were found to have quite such extreme vulnerabilities, but there were plenty of others scoring almost as badly.

Two critical flaws in Oracle Database Server

The most severe flaw Oracle patched in its flagship database product is CVE-2026-61211, a vulnerability in the RDBMS component’s DBMS_CLOUD package with a CVSS score of 9.9.

This easily exploitable vulnerability allows a low-privileged attacker having Execute DBMS_CLOUD privilege with network access via Oracle Net to compromise the RDBMS, Oracle said in the patch update statement. “While the vulnerability is in RDBMS, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of RDBMS,” it warned.

The flaw affects Database Server versions 19.3 through 19.31 and 23.4.0 through 23.26.2.

Sanchit Vir Gogia, chief analyst at Greyhound Research, said the 9.9 score should be read as serious but conditional. Exposure depends on configuration, he said: On customer-managed databases, DBMS_CLOUD is absent until installed, and grants and network access lists determine the radius from there. “Where DBMS_CLOUD is broadly granted and reachable, the emergency is real and the window is seventy-two hours; where it is absent, the accelerated database wave will do.”

Vibhum Dubey, a cybersecurity researcher and red teamer, said the flaw stood out to him because it checks several boxes that concern defenders.

“Database servers often hold an organization’s most valuable data, so even if exploitation is not publicly observed yet, I don’t think this is the kind of issue you leave until the next routine maintenance window if your environment is exposed,” Dubey said.

A second Database Server flaw, CVE-2026-47040, affects Connection Manager in Oracle Net Services, is remotely exploitable without credentials. Oracle’s risk matrix lists six Database Product vulnerabilities in this cycle as reachable over a network with no authentication required, the statement added.

CVE-2026-7383, an OpenSSL-related TLS vulnerability, affects two products, Database Server and Autonomous Health Framework, since both bundle the same third-party component. Oracle’s advisory notes the Database Server patch for that CVE also resolves 19 related OpenSSL CVEs bundled into the same fix.

Oracle GoldenGate received 27 new patches, nine of which do not require authentication to exploit, including CVE-2026-2332, a flaw in the Big Data and Application Adapters component tied to Eclipse Jetty, the statement added.

There were also two critical flaws in Oracle’s TimesTen in-memory database.

The remainder of the release spans E-Business Suite, WebLogic Server, PeopleSoft, Siebel, JD Edwards, Communications, Retail Applications, Utilities Applications, MySQL, Solaris and VM VirtualBox.

Volume repair

Gogia said the volume itself marks a shift.

“At 1,449 patches, against 481 in April 2026 and 309 a year earlier, patch load has outgrown the queue built to hold it,” he said. He recommended a tiered response: “The reachable and the reported inside seventy-two hours, the trusted core inside ten days, the rest by risk before the October release.”

He also flagged a specific risk in how organizations might triage E-Business Suite. “Oracle’s advisory concedes that E-Business Suite exposure sits partly in underlying Database and Fusion Middleware versions outside the E-Business Suite matrix. The fastest way to mis-prioritise this release is to patch by product logo instead of trust boundary.”

Third Tuesday, quarterly cycle

The July release is the third quarterly Critical Patch Update of 2026, and the first since the introduction in May of the monthly Critical Security Patch Update program.

Gogia said Oracle has effectively layered a second cadence on top of the existing one rather than replacing it.

“Quarterly Critical Patch Updates remain and stay cumulative; monthly Critical Security Patch Updates now sit on top,” he said, adding that enterprise adoption of the new rhythm remains low because of “certification obligations, regression exposure and scarce specialist hours.”

Dubey made a similar point about organizational readiness: “In large enterprises, patching is rarely a technical problem. It is an operational one. Database administrators, application owners, infrastructure teams, business stakeholders, and change advisory boards all have to align.”

Niyati Daftary, principal analyst at Gartner, said the release underscores a broader shift in how patching is approached.

“Patching is no longer a race to remediate every vulnerability. It is a discipline of identifying the exposures that matter most and reducing business risk as efficiently as possible,” she said, adding that organizations should prioritize based on exposure, business impact and exploitability, starting with internet-facing assets and mission-critical systems.

Daftary pointed to continuous threat exposure management and adversarial exposure validation as increasingly relevant frameworks, since CVSS scores “measure theoretical severity rather than actual enterprise risk.” Patching alone will not be sufficient, Daftary said, and organizations should continue investing in defense in depth, including behavioral threat detection and incident response.

Oracle’s next cumulative Critical Patch Update will come on Oct. 20, 2026, with smaller Critical Security Patch Updates on Aug. 18 and Sept. 15.

The evolution of Java is the subject of a just-released documentary about the programming language and development platform. “The Java Story: The Official Documentary” tells the story of Java through interviews with the engineers who created it and shepherded it through three decades.

Produced by CultRepo and sponsored by Oracle, JetBrains, IBM, and Azul, the documentary follows Java from its set-top box and browser-based origins at Sun Microsystems in the 1990s and through its rise to dominate server-side computing in the 2000s, the “dark ages” and resurgence with Java 8 under Oracle in the 2010s, and its continuing modernization and promising role in AI today. “From its humble beginnings as a project code-named ‘Oak’ at Sun Microsystems to becoming a global standard for enterprise software and billions of devices, Java’s journey is one of radical innovation, strategic pivots, and enduring community strength,” said Cult.Repo.

The documentary also delves into Sun’s bitter Java licensing dispute with Microsoft, Oracle’s suit of Google over its use of Java APIs Android (Google won), the creation of the Java Community Process, Sun’s open-sourcing of Java, and Oracle’s switch to the six-month release cycle. Technical enhancements such as lambda expressions in Java 8, virtual threads in Java 21 (Project Loom), and the ongoing refactor to bring value objects to the Java object model (Project Valhalla) also get attention.

Technical experts and other Java figures interviewed in the documentary include James Gosling, creator of Java; Kim Polese, Java’s first product manager; Carla Schroer, director of Java compatibility at Sun Microsystems; James Duncan Davidson, creator of Apache Tomcat; Mark Reinhold, chief architect of the Java Platform Group at Oracle; Brian Goetz, Java language architect in the Java Platform Group at Oracle; Rod Johnson, creator of Spring; and Gavin King, creator of Hibernate.

Major AI labs are unleashing forward-deployed engineers (FDEs) to try and grab enterprise customers. Large consultancies are dishing out tokens and assembling armies of consultants — both human and agent — to do the same.

But smaller firms are in the mix now, as well. AI is helping 28Stone Consulting, a New York-based, 230-person technology consultancy for capital markets, punch above its weight against larger rivals in the rush to deliver FDEs.

In this Q&A, Thomas Dolan and Frank Erickson, founders of 28Stone, argue that agentic AI isn’t a one-size-fits-all solution in vertical markets; success takes discipline, deep domain expertise, and human involvement to mitigate risk.

Many enterprises continue to struggle with the use of AI agents, which is consultancies are stepping in to get projects off the ground. 28Stone is among those that have published blueprints and methodologies on the development and delivery of agentic AI workflows with humans in the loop.

Computerworld spoke with both founding partners about why companies are still stumbling with agentic AI rollouts, and what a disciplined delivery process actually looks like.

After 15 years of delivering software for capital markets firms, is ‘AI-first’ a real distinction or just positioning?

Dolan: “We’re not shying away from being AI-forward. What needs to shine through is AI done intelligently — not stuff you get by buying some tokens for somebody on the trading desk. We’re an AI-first firm.”

Erickson: “And it’s temporary. At some point, AI is going to be synonymous with software development.

“The whole idea of an AI SDLC (software development lifecycle) versus an SDLC is going to be one and the same, a lot like cloud computing today. To not include AI in your strategy, you’d look like a COBOL vendor.”

What does agentic AI delivery look like?

Dolan: “We’ve got several AI initiatives delivering a pure agentic approach. We’ve doubled down on the human expertise wrapper in the SDLC. That doesn’t mean sacrificing any of the benefits of the AI models — quite the opposite.

“You don’t achieve anywhere near the same level of value from applying AI without keeping that expertise — industry, functional and technical — throughout the process.”

Where do humans stay in the loop once agents are doing the work?

Dolan: “We’re believers in starting with requirements discovery. Someone who knows the analytical nuances of a good business analyst is critically important; shaping a product owner’s business information through a markup file that can be fed into a BA agent, then treating the output as if it came from a very fast junior BA. Only then is the story complete.

“The developer takes that story, transforms it into the most efficient input, then owns the output, because they’re accountable for that code. A developer should own the code on both the input and output side.

“Your product owner, who knows the business, that’s great. But expecting them to interact with an agent and output enterprise code is ridiculous. It’s not a great plan.“

Why not just put one do-everything person in charge of AI and agents?

Erickson: “Every analyst, programmer or software engineer isn’t a great requirements analyst. And a great domain analyst with some technical background won’t know if the agent’s code is garbage, maintainable, performant.

“It’s unrealistic to expect one individual to have that breadth across domain, software engineering, testing, deployment. Clients ask all the time, and we push back: ‘Great, if you can find that guy, they’re few and far between.’ To deliver at the enterprise level, you need the human expertise, at depth.“

Dolan: “There’s system speed and latency, important in parts of finance. Then there’s speed of delivery, because other areas evolve quickly and time-to-market is critical.

“Our human wrapper may at first pass come across as a little slowed down. Maybe it is. But [Erickson] has a good analogy about one of the dangers of AI: you can end up going really fast in the wrong direction. By the time you look up, you’re way off base and have to backtrack.“

What about AI in your sector do you think is overhyped?

Dolan: “The hype around the ease of use of AI and the democratization of enterprise software delivery — that ‘anybody could do it now, it’s all being done by machines’ — is another idea that could prove costly in the long run.

“This do-it-yourself reaction is dangerous for clients, and for trust in the overall AI benefit, which is real. We compare it to the beginning of offshoring 20, 30 years ago: a golden idea that was going to cure everything. A lot of firms did it thoughtlessly, thinking it’s just labor arbitrage, and it almost inevitably failed. That all-or-nothing mentality missed that offshoring is an amazing way of getting better value for your dollar, but it has to be done thoughtfully, so the delivery process — the thing that ties it all together — stays unsevered.

“We’re seeing that now. I’ve heard, ‘We’ll just push a button, the machine’s building the system.’ The machine is not building the system. It might be writing the code, the story, running the tests.

The system is built by a team of engineers you bring in and trust. My fear is that people will say, ‘We don’t need this vendor or this technology team. I’ve got a product team. They might not be able to code at all, but they know the business,’ and it fails dramatically. 

“Then people say, ‘We played with AI, it’s not ready yet,’ and throw it all away. One of the best things we can do is ensure clients know the benefit is real.“

Erickson: “The hype can be summed up in a single phrase: vibe coding. That has done AI a massive disservice, because there’s a huge difference between vibe coding and enterprise software development, and some of the loudest proponents of AI are too latched on to it. In our industry, the only way to succeed would be a stable of unicorns. It just doesn’t scale. I get perturbed when our people internally refer to AI tooling as vibe coding; if they think that’s what they’re doing, they’re misunderstood.“

When you engage clients at different levels of AI maturity, how do you get them to a understand what works?

Dolan: “95% of our take on an agentic approach is in line with everyone else’s, but that 5% matters, especially in requirements discovery, in who’s giving the requirements and how they’re thought of. It can set you up for dramatic errors, given the speed at which you’re moving.

“There’s a dangerous human tendency we’re seeing among clients to try and cut corners at the start of a project and — in lieu of having deep, expert driven discovery sessions — just summarize what they may want using AI.

“We would hope our clients are collaborative, everyone understanding it’s early days. If a client insists on doing something we feel strongly against, like a product owner completely owning everything right up to code generation, that’s an issue we have to either push back strongly on or step out of the accountability for.“

AI body shops — LLM providers and giant consultancies — are emerging to help enterprises deploy AI. Does that model work?

Dolan: “Whether you’re partnering with an LLM or with an AI-first, generic software provider — ‘Hey, we’re not industry guys, but we know AI delivery’ — you end up, if you’re a bank or a broker-dealer, saying: ‘All right, we know our business, these guys know the AI side of it. What could go wrong? Put us together and we’ll have quality engineering.’

“The problem is what you miss: the know-how of putting industry and technical expertise together and actually delivering financial services systems. The people working at the generic delivery firms, whether an AI-only firm or a body shop somewhere, don’t have that capability.“

Does AI change the economics for smaller consultancies like yours competing against the big firms, and does it cut both ways?

Dolan: “Over our 15 years pre-AI, there were two recurring reasons we’d lose a project. One: ‘We’d love to work with you guys, given your subject matter expertise, but the costs just aren’t there compared to my budgets. I’m being forced to go to a body shop or an [offshore] delivery center.’ The other side of that coin: ‘We love your capabilities, but you’re a firm of 230 people and I need 300, 400 people.’

“AI changes the options for clients. You don’t have to sacrifice the niche vendor who knows your space just because you need a larger team or a cost target. AI levels the playing field and should allow smaller firms to compete with the larger, big-box generic firms, the Accentures of the world.“

Erickson: “It redefines what scale means. You can look at velocity as a measure of your cost to deliver, not a rate card. Scale can’t be defined in terms of headcount anymore. It’s got to be defined in terms of output.

“There’s a threat in it, too. If you’re an Accenture with hundreds of thousands of low-cost software engineers, how do you train all those people? I feel for them. But for us, a couple hundred people with a specific domain focus, it’s a huge opportunity.“

How has the profile of the people you and others hire changed with this agentic process?

Erickson: “You’re still looking for people with strong engineering and design backgrounds, and communication skills, because they interact across the software development lifecycle more than in the past.

“Many take too much joy in typing out perfect code. Sorry, I don’t need you writing for-loops and classes anymore. I need you reviewing them, understanding them, operating at a higher level. That’s a different kind of person: an engineer, not a programmer or a coder. On the [business analyst] side it’s similar: people took great pride in detailed user stories covering every path. Now it’s conversations, prompts, reviewing output — less doing, more interacting.

“More than ever, they have to be interested in the domain. They can’t just be, ‘I want to learn everything there is to know about Java.’ That’s too narrow. They don’t have to be an expert; they have to be interested. In our case, capital markets is a specific niche. The biggest challenge is getting familiar with the tools — finding time, while delivering for customers, to ramp up and make the mistakes you need to without jeopardizing projects.“

What about governance? Who’s keeping AI delivery and its costs under control?

Erickson: “This is evolving rapidly. People aren’t sure how to put governance around this. The most obvious is financial governance. People are starting to get hefty bills. One of our clients spent a million dollars on tokens over the last eight weeks alone. Sticker shock. The token-maxing policies are starting to show their flaws. It’s wild west still: learn on the fly, then figure out what needs to be governed.“

Are CIOs actually opening their wallets? And when they do, what’s the smarter way to invest?

Erickson: “There’s still a lot of caution. Forecasts keep going down on how long something should take. So: ‘I could wait three months and maybe still get it delivered by the same date someone’s promising me now, but for half the price. I’m going to wait and see when equilibrium is met.’ We haven’t seen the wallets open up like crazy — it’s slow adoption.“

Dolan: “One of our clients is looking at it from a productivity-boost perspective: instead of doing the same for less, I can do much more for the same. AI lets clients pull the trigger on things they wouldn’t have in the past — projects that might not have been approved pre-AI, where the costs have come down to a point that’s palatable with the business.“

Erickson: “And that’s the story we’re hoping to hear more of. There isn’t a huge cost anymore to exploring a business opportunity. The time and money that would have gone to a return-on-investment study could be spent on a proof-of-concept with AI, and the project done a few weeks later. Maybe [there’s] a hint of things to come, where decisions start being made quicker. 

“There’s a little fear on our side, though: a lot of tiny little projects is tough for a consulting business.“

With AI increasingly tucked into every cranny of the enterprise, someone has had to step up and provide the tools necessary to discover, track, and monitor all the agents and LLMs and keep them humming along in their various workflows. Thankfully, the DevOps world answered the call, building the tools to support our new overlords in an emerging subdiscipline interchangeably called “AIOps,” “AgentOps,” and sometimes “agent observability.”

Many of the challenges involved in AgentOps are similar to those tackled by traditional DevOps tools and processes. After all, at their foundation, LLMs are just software running on hardware somewhere. Typical issues involving RAM and disk space are just as important in the agent world, maybe more so because AI operations are even more greedy about consuming storage than regular software is.

Many of the companies supporting agent observability are big names in DevOps circles, having adapted their stacks to address the idiosyncrasies of modern LLMs. IT teams maintaining enterprise agents can treat the LLMs as just one node in a big graph filled with services that are constantly swapping packets and triggering software jobs. Latency and resource constraints must be managed because end-users don’t care whether it’s an LLM, a database, or a plain-old Python script that’s failing, bringing their work to a grinding halt.

But new AI-specific challenges are opening the door to newcomers that are building tools with the peculiarities of LLMs in mind — for example, keeping deeper logs filled with records of prompts. LLMs are also often very non-deterministic by design, making it trickier to pinpoint failure modes. And then there’s the fact that an agent will give a perfectly intelligent answer one minute and hallucinate the next.

Relying on many of the same approaches that DevOps tools do, AgentOps tools watch for misbehavior and flag anything out of the ordinary for deeper analysis. This may be as simple as fixing slow responses, but it can also include AI hallucinations and other issues born of LLMs’ non-determanism.

Teams trying to choose which agent observability tools is best for their use case should look at the size and nature of their agentic systems and projects. Are they adding AI agent features to an existing product or application, or are they building agentic systems from scratch? Are they more focused on maintaining a stable LLM operation or iterating on new approaches? Is AI the center of attention or just an add-on that’s meant to improve an existing stack?

The AgentOps and agent observability options listed below share many of the same features but differ in their focus and their attention to the challenges organizations will encounter when incorporating agents into their stacks. Each tool offers a worthwhile place to start understanding how to care for the growing presence of AI in the production world.

AgentOps.ai

When teams of agents work together, tracking the conversations are essential for understanding and debugging what’s happening. The SDK from AgentOps.ai records events so that the creators can replay past behavior to track details such as token counts, spending, latency, and more. Available as a service and on-premises.

Pricing: Starts at $40 per month plus usage costs at $0.20 per 1M tokens

Standout feature: Replay analytics with “time-travel debugging”

Best suited for: Complex agent debugging

Arize Phoenix

Debugging prompts and LLM responses requires a nuanced understanding of just what’s happening, in part because of the non-determinism that often enters the process. Phoenix from Arize supports this process with robust tracing and the ability to score the results for more precise iteration. Their system can track the results and tool calls from a variety of major platforms (Anthropic, AWS, OpenAI, etc.) that are initiated by the major frameworks (LangChain, LlamaIndex, DSPy, etc.). The result is insight into what data is triggering what chain of responses.

Pricing: Small free tier; Pro plan starts at $50 per month plus costs tied to events

Standout feature: LLM-as-a-Judge metrics for tracking quality

Best suited for: Teams focusing on iterating for accuracy and quality

BigPanda

BigPanda has always offered solutions for tracking performance of complex systems. Now the company is drilling deeper into the challenge of detecting and ending the problems that come from models that go awry. BigPanda’s main system relies on historical data and machine learning algorithms to flag issues. Its own agent layer connects the problematic nodes and errant models while dispatching alerts to the right team members.

Pricing: “Value-based” table on request

Standout feature: Automated triage for faster response

Best suited for: Large teams seeking to reduce alert fatigue from large customer base

Braintrust

Setting up an effective improvement cycle for an AI agent requires a strong feedback loop from production data to the agent’s next generation. Braintrust watches the production workload and creates test vectors that expose how an agent may be drifting, regressing, or departing from its path. The tool automates much of the testing and scoring feedback loop so problematic patterns can be discovered and addressed. A core part of the offering is a specialized data store that can track large and sometimes deeply nested collections of tests and their results. Their approach may be summarized by one of their tag lines: “trace everything.”

Pricing: Free starter tier; Pro plan starts at $249 with some usage-based costs covered

Standout feature: Highly scalable trace ingestion

Best for: Teams developing strong guardrails through continuous testing

Chronicle Labs

When it’s time to release a new version of an agent into the wild, the platform from Chronicle Labs specializes in staging it and testing it with a collection of use tests and regression cases. The tools are also helpful during development cycles. “Backtest your agent against reality,” their sales material promises, with a set of tools that mines the production telemetry for solid test vectors that stress every part of the agent with prompts and challenges that the agent will encounter after leaving the safety of the lab.

Pricing: On request

Standout feature: Back-testing options for complex testing regimes

Best for: Teams chasing strong models with good fidelity to reality

Comet Opik

Building a dashboard for tracking every in-flow and out-flow to agents is one way to be ready to watch for and solve problems. Opik from Comet is just such a tool. The DevOps teams can track each call and add its own automated routines to examine the results, score them based on 30-plus metrics, and if desired, send it off to another LLM to evaluate the results. Agents that are constantly failing stand out. DevOps teams can also ask questions like, “Who is using this model and racking up all of the bills?” The same goes for MCP skills and other cogs in the machine.

Pricing: Free tiers for open source and small projects; Pro plan starts at $19 per month with usage limits

Standout feature: Auto-scoring with 30-plus metrics for evaluating traces

Best for: Teams focusing on RAG and agentic workflows

Datadog

DevOps teams that rely on Datadog to track logs across collections of services can also use it to track LLM operations, which are, of course, just another source and sink for data. It will track performance such as time to first token and offer insight into what might be causing an issue, such as lack of memory. Results then get plugged into the same cost-tracking mechanism so the bean counters can predict when the budget will run out. After all, the CFO likely doesn’t care whether the bill comes from an LLM or an old-school S3 storage bucket. Datadog integrates AI into their tools by treating these models as just another source of data.

Pricing: Small free tier with multiple paid tiers for various levels of enterprise monitoring

Standout feature: Large installed base with broad focus on more than LLMs

Best for: Large enterprise teams working with established infrastructure

Dynatrace

For more than 20 years, Dynatrace has been delivering tools that track dataflows across the full stack. Now that AIs are finding roles in many of the nodes in this complex graph, they’re expanding to track how various AI agents can interact. They want to build one platform that helps track the root cause and, often now, deploy solutions autonomously. They want to focus on being ready to support complex networks of agents that detect problems in either performance or security and then work within defined guardrails to fix them. Determining the right role for their own AI-powered agents is a key part of the product.

Pricing: Plans start at $7 per month with larger plans designed for full enterprise monitoring

Standout feature: High level of autonomous monitoring designed for large installations

Best for: Complex, hybrid environments mixing LLMs with traditional services

Galileo

Placing some AI systems into production is often a harrowing experience because the actual performance is impossible to predict, even with the most rigorous tests. Galileo offers guardrails that track performance and watch for any behavior that deviates from the ground truth. Their “LLM-as-judge” systems are distilled into compact models that can be run locally for lower costs and faster performance.

Pricing: Small free tier; Pro plans start at $50 per month with usage-based limits and costs

Standout feature: Real-time guardrails for deployed agents

Best for: Security-conscious installations that need to defend against hallucination and data leakage

Grafana Labs

Long the go-to source for open source telemetry, Grafana Labs now tracks performance of AI models in constellations of services. Grafana tracks the evolution of answers across the agentic network to recognize how small changes or hallucinations can spin out of control. It bills its system as “actually useful AI” and has even trademarked it. Its cloud assistant can configure and reconfigure the Grafana dash to offer the right level of observability. Its system includes AI-level analysis that can flag models that are responding quickly but offering bad answers because of problems such as model drift or context degradation.

Pricing: Basic free tier; Pro plan begins at $19 per month, includes better retention and some usage-based fees 

Standout feature: Full-stack tool with fully integrated LLM tools

Best for: Large, enterprise-scale system adding AI

Helicone

Sometimes shoehorning in another tool into the chain can be tricky. Helicone is designed as a smart network proxy that will route all model requests while keeping solid debugging records from the data as it goes by. The data it captures can be turned into nice charts that make it easy to spot latency issues or model failures. Naturally, tracking AI spend is also a feature in much demand as bills continue to climb.

Pricing: Small free tier; Pro plan starts at $79 per month, includes features such as team collaboration and improved querying

Standout feature: Proxy-based integration

Best for: Development teams who want to add better monitoring features quickly

Laminar

Tracking agents in development and production means building strong storehouses of data enumerating what happened. Laminar works closely with OpenTelemetry to follow agents operating in production so that flaws and failure modes can be understood from log files stored efficiently with their own compression scheme. Developers can search through traces with an SQL-ish language and Laminar’s transcript view illuminates what happened. When necessary, the traces can enable developers to scroll back in time and replay the same inputs for debugging. The goal is to offer deep insights with high-level visibility of how well the agents are meeting business objectives.

Pricing: Small free tier; “Hobby” tier that adds more features at $30; Pro level starts at $150 per month

Standout feature: Open-source license makes self-hosting a viable option

Best for: Teams fully able to leverage open-source responsibilities

LangChain LangSmith

Real-time data from agents is essential for managing any mutli-agent system in production. LangSmith from LangChain traces costs, tools, and progress toward solutions for a wide collection of agents using SDKs for Python, TypeScript, Go, and Java. The OpenTelemetry-based solution watches for anomalies, issuing warnings and alerts through dashboards and communication channels such as PagerDuty. Deeper analysis can reveal issues such as topic clustering or odd patterns of failure. Coordination with agent deployment platforms such as LangGraph and deepagents ensures greater focus on successful resolution of assignments.

Pricing: Free for solo developers; Pro teams start at $39 per person per month 

Standout feature: Systematic approach to regression testing of prompts

Best for: Teams relying on LangChain and LangGraph frameworks for supporting complex agentic behavior

Lunary

Watching the user experience is essential for building AI applications such as chatbots and assistants. Lunary offers a proxy that traces all interactions and then builds analytical dashboards for measuring metrics such as user satisfaction or model costs. One common usage is finding frequent topics and looking at the responses to ensure they deliver. When prompts aren’t perfect, Lunary lets teams iterate on the prompt text until the right answers are coming out. Its proxy structure and common API format enables Lunary to promise to work with “any LLM, any framework.”

Pricing: Free tier; Pro plan starts at $20 per month

Standout feature: Deep integration with humans for reviewing and optimizing results

Best for: Startups focused on rapid prompt innovation

NewRelic

The platform that began tracking performance of some web applications is now powerful enough to track the flows of data through complex agentic ecologies. NewRelic’s AI-driven monitoring watches for golden signals that can indicate misbehavior or worse throughout the entire lifecycle. It tracks every detail of the interactions through protocols such as MCP and then makes this available to the AI engineers responsible for performance. The dashboard provides the insights necessary to watch for toxic behavior, overt bias, drift, and overblown hallucinations. Predicting and maybe even controlling the cost is also a growing role as tokenomics becomes as important as response time.

Pricing: Free tier; Pro plan fees available through website

Standout feature: Full-stack support with hundreds of integrations with other tools

Best for: Established enterprise teams mixing in AI

Nova AI Ops

The goal of Nova AI Ops is to deliver a team of agents that watch over a cloud and make it, at least partially, self-healing. Each agent uses a mixture of predictive AI and machine learning to watch cloud telemetry reports for anomalies. Then they calculate the “blast radius” and decide whether this is a problem that can be fixed automatically “while you sleep” or saved for the human supervisors. These tools are aimed not just on LLM operations but on the stack as a whole.

Pricing: Small free tier; Standard pricing  begins at $40 per user per month with usage billing

Standout feature: Focus on software reliability engineering helps teams deliver stable stacks

Best for: Teams that want to integrate LLMs into incident response and stability management

Splunk

The platform that began delivering smart logging is now fully AI capable, offering solutions that can watch over agents with much the same way that it continues to track microservices. Splunk now includes a fairly large amount of predictive AI for learning from the information in the logs and then turning this learning into fast solutions. This AI assistant can track deployed AI models connected by protocols such as MCP and watch over behavior while delivering the ability for users to drill down and explore what’s working and what’s failing. Their AI Canvas is meant to offer a central hub where the AI scientists can track both the local behavior of the models as well as their role in a larger data ecosystem.

Pricing: Activity-based pricing tracks usage of LLM backends and storage

Standout feature: Ready to scale to large enterprise stacks

Best for: Teams with legacy systems that are folding in agentic options

SuperPenguin

One of the most important parts of an AI service is the bill. SuperPenguin is a product designed to track consumption and make predictions so that the CFO won’t be surprised. The goal is to provide solid estimates about the total cost of each product by allocating costs to customers, features, and teams. If there’s a sudden shift, a “spike detector” will raise an alarm so that dev teams can ensure that the AI spend is worth it.

Pricing: Small free tier for experimentation; Growth tier for teams, starting at $30 per month; Pro tier offers deeper options starting at $200 per month

Standout feature: Strong accounting with invoice reconciliation and PR-level usage tracking

Best for: Teams that need precise cost accounting

Vellum

Prompt engineers spend time fussing over the details of tweaking, improving, and enhancing the words that guide the LLM. Vellum started as a company that would provide the pipeline so that you could manage and improve the prompts that ran again and again. Now the system is growing more powerful, offering a higher level of automation that lets you meta-manage the prompt chain. They’ve also begun marketing it as a form of personal assistant with pre-built connections to many of the major services such as Gmail. Its llm-cost-optimizer can juggle multiple options while finding a cheaper way to execute a prompt, a process the company suggests can save 60% or more.

Pricing: Open-source free tier; Pro plan starts at $35 per month

Standout feature: Focus on multi-model pipelines for true agentic solutions

Best for: Product teams with complex prompt engineering workflows

Earlier this month Microsoft warned that, because the latest AI models can now help discover vulnerabilities, CSOs will see a higher volume of security updates every month. It wasn’t kidding.

Today the company issued a record number of patches, with 59 rated as critical. And Microsoft is now recommending that customers accelerate their patching schedules to more quickly deal with critical flaws.

“Normally we have to wait for October or November to determine if we’ll break the previous [annual] patch volume record,” which was 1,245 vulnerabilities found in 2020, commented Satnam Narang, senior staff research engineer at Tenable. But not this year. Tenable counted 569 CVEs that were patched officially as part of this month’s Patch Tuesday, excluding the server-side updates not requiring user intervention, smashing last month’s record of 198 fixes

It’s probable, he said, that by the end of this year, Microsoft will have found over 3,000 common vulnerabilities and exposures (CVEs).

Today’s volume of holes is “striking,” he added, “but it reflects how good these tools have become at finding bugs, not how many of those bugs actually pose a risk to organizations.” 

Separately, SAP released 20 new and updated security patches, including a critical memory corruption vulnerability in NetWeaver Application Server ABAP, SAP Kernel, and frontend services tied to SAP GUI for HTML, which has a CVSS score of 9.9.

Microsoft patches

Among the huge number of CVEs that Microsoft found were three zero-days that need to be patched, including two that have been exploited in the wild. 

Those two are both elevation of privilege vulnerabilities: CVE-2026-56155, an Active Directory Federation Services (AD FS) flaw that allows attackers with limited access to elevate privileges to administrator, and CVE-2026-56164, a Microsoft SharePoint Server vulnerability. 

The third is CVE-2026-50661, a security feature bypass in Windows BitLocker, which was noted as having been publicly disclosed. “We surmise that this could be related to a flurry of zero-day vulnerabilities disclosed by the researcher known as Nightmare Eclipse or Chaotic Eclipse,” Narang said, “though no official confirmation was made. We also know that the researcher promised to drop something on Patch Tuesday.”

While these were the most noteworthy flaws this month, Narang said, for CSOs the July patches prove that the state of the Exploitability Index, which rates how likely a vulnerability is to be exploited, must shift, given the machine speed of exploit discovery. For example, he pointed out, in May, Microsoft originally tagged CVE-2026-45659, a SharePoint vulnerability, as exploitation less likely. However, the vulnerability was added to the US Cybersecurity & Infrastructure Security Agency’s list of known exploited vulnerabilities on July 1.

He added that Anthropic’s Red Team’s own findings for known vulnerabilities (n-days) revealed how fragile the monthly Patch Tuesday system has become, with its Mythos Preview model being able to produce proof-of-concept exploits for 13 of 14 vulnerabilities that were rated as Exploitation Less Likely or Exploitation Unlikely.

“What this means is that our way of looking at Patch Tuesday has changed, because the exploitability index is centered around humans, not AI tools, and as these tools continue to improve, defense needs to improve alongside it,” Narang said.

Dustin Childs, head of threat awareness at TrendAI’s Zero Day Initiative, agreed.

“To call this record-breaking is a massive understatement,” said Childs. “This is the ‘Mother of All Releases’. The bug apocalypse has fully descended upon us, with July’s numbers pushing the year-to-date CVE count past every single full-year total of the last 20 years. Security teams need to take an extended break from their regularly scheduled activities to eat this elephant one byte at a time, starting immediately with active exploits in Active Director FS and SharePoint.”

He particularly drew attention to a near-perfect 9.9 CVSS flaw in Windows VMSwitch (CVE-2026-57092) that allows low-privileged attackers to escape virtual machine boundaries for full host compromise.

Jack Bicer, director of vulnerability research at Action1, agreed that IT leadership should prioritize immediate remediation of the actively exploited Active Directory Federation Services elevation of privilege vulnerability and the SharePoint Server elevation of privilege vulnerability .

After that, he said, priority should be given to these critical vulnerabilities: Active Directory Certificate Services Elevation of Privilege Vulnerability (CVE-2026-54121), which introduces the possibility of attackers impersonating trusted systems and potentially compromising AD through certificate abuse; a Windows Active Directory Domain Services remote code execution vulnerability (CVE-2026-49164) which enables unauthenticated remote code execution against one of the most critical components within Windows enterprise environments; a Microsoft Dynamics NAV and Microsoft Dynamics 365 Business Central remote code execution vulnerability (CVE-2026-55944); a Microsoft Exchange Server spoofing vulnerability (CVE-2026-55008); Microsoft SQL Server remote code execution vulnerabilities (CVE-2026-54118 and CVE-2026-54117); and multiple Windows DHCP Server vulnerabilities.

These holes create opportunities for attackers to compromise financial systems, communication platforms, databases, and core network infrastructure, Bicer pointed out, systems which often provide direct access to sensitive business information and frequently serve as high-value targets for ransomware operators and advanced threat actors. 

There are also important security updates for Microsoft Defender, Bicer added, noting that vulnerabilities affecting endpoint protection software deserve immediate attention because successful exploitation undermines one of the organization’s primary defensive controls.

IT teams must prioritize

AJ Grotto, a research scholar at the Centre for International Security and Co-operation and former Senior White House Director for Cyber Policy, said that Microsoft’s July Patch Tuesday “is a stark reminder that security teams are now operating in an era of vulnerability volume and velocity. With 570 vulnerabilities patched, including three actively exploited zero-days, the biggest concern for CSOs isn’t just the number of flaws, but the concentration of risk around identity systems, collaboration platforms, and privilege escalation pathways. The actively exploited vulnerabilities in Active Directory Federation Services and SharePoint are especially concerning because they target technologies that sit at the center of enterprise trust and access.”

He added, “for CSOs, the challenge is no longer just defending against threat actors, it’s keeping up with an accelerating cycle of vulnerabilities and updates across the Microsoft ecosystem in the AI era. Security leaders should think critically about diversifying their vendors to protect their enterprise and save time and money on patching an increasing list of bugs that nearly tripled month-over-month.”

“While the sheer number of [Microsoft] vulnerabilities might seem alarming on the surface,” said Nick Carroll and Rain Baker of the Nightwing ShadowScout threat intelligence team, “this can actually be seen as a positive sign for enterprise security. It means vendors are finding and fixing flaws before adversaries can weaponize them en masse.”

And Josh Taylor, lead cybersecurity analyst at Fortra, noted that 26 of the Microsoft vulnerabilities have a CVSS base score above 9.0, and 13 of those sit at 9.8. “That matters,” he said, “but CVSS is still only one part of the risk story. The real triage problem this month is the mix of exploited issues, a publicly disclosed BitLocker flaw, and a massive concentration of vulnerabilities in Windows and Office.”

He said, “for patching teams, this is the kind of month that rewards discipline. The right move is not panic, it is sequencing: put exploited issues and exposed infrastructure first, then let the normal validation process do its job.”

Others increasing their patch cadence too

Chris Goettl, vice-president of product management at Ivanti, noted many software vendors in addition to Microsoft are increasing their security update cadence. For example, Cisco Systems has just shifted to a risk-based, twice-monthly disclosure model (the first and third Wednesday of each month), Mozilla is on a near weekly security update march, and Oracle’s new Critical Security Patch Update (CSPU) program has been delivering targeted critical-severity fixes on the 3rd Tuesday of non-CPU months since May.

Nightwing also noted that Adobe issued 12 separate security bulletins for products in its first twice-monthly bulletin. Administrators must treat today’s Priority 1 ColdFusion update (APSB26-82) with urgency, as it patches a critical 9.9 CVSS path traversal vulnerability (CVE-2026-48318). It’s one of 11 ColdFusion vulnerabilities patched.

Additionally, retail and web administrators should immediately prioritize Adobe Commerce (APSB26-73), which resolves a 9.6 CVSS flaw allowing unrestricted uploads of dangerous file types (CVE-2026-48356).

SAP vulnerabilities

Jonathan Stross, senior product manager for cybersecurity research and innovation at Pathlock, said the most critical of the SAP fixes is Note 3747367, a memory corruption vulnerability in NetWeaver Application Server ABAP, with a CVSS score of 9.9. The vulnerability affects the ABAP Application Server, SAP Kernel, and frontend services tied to SAP GUI for HTML.

 According to SAP, an authenticated attacker can trigger logical memory-management errors that may lead to unauthorized data access, data modification, or system unavailability. The likely attack scenario involves a compromised account or malicious insider abusing a crafted request that reaches the vulnerable code path. 

“Because a successful exploit can impact confidentiality, integrity, and availability at the platform level, while potentially destabilizing a core ABAP system, organizations should treat this as the highest-priority patch in the July release,” Stross said. 

Prioritize the critical ABAP kernel issue, plus the AppRouter request smuggling note, and the Commerce Cloud sample-credential issue first, he said, because these are the most likely to produce direct security impact in real environments.

But do not treat the updated notes as noise, he added. The July overview includes three re-released items that still matter operationally, and this should be reflected in patch planning and change records. The attack surface is distributed: ABAP, Java, BTP, Commerce, SAProuter, UI5, and supporting libraries all appear in the same monthly cycle, so patching needs coordinated platform ownership.

Thomas Fritsch, an SAP researcher at Onapsis, described the SAP Security notes in detail and noted that SAP teams who can’t immediately install the NetWeaver memory corruption fix can, as a temporary workaround, disable all ICF nodes with a specific property in transaction SICF. However, since the workaround will disable opening transactions in SAP GUI for HTML, it is not an option for all customers and it is strongly recommended to install the patched ABAP Kernel version.

Patching should become continuous

“AI is likely to expose new classes of weaknesses, and will introduce some of its own through AI-assisted development,” commented Gene Moody, Field CTO at Action1. “Logically, with that in mind, the future of updating must become more continuous, more adaptive, and less tied to a fixed calendar. Discovery will not follow business logic; it will be swift and unforgiving. We must accept that, and be just as diligent in our defense, because the cost of failure is higher than the inconvenience of change.”

He added, “in my crystal ball, I see a future where Microsoft and others move steadily away from scheduled monthly patch cycles in favor of rolling updates for most security issues in as close to live time as they can be researched and released. That would be a win for the entire industry. Faster patch creation and delivery, paired with more agile practices on the customer side, would finally start to align patching with the pace of modern discovery and exploitation.”

“What needs to happen is simple,” he said. “Patching on a calendar is no longer a safe assumption in today’s threat landscape. Patching where and when needed versus scheduled is the only path forward.”

Europe is sweltering. The summer of 2026 has seen historic heat waves that have taken a significant toll on infrastructure. In recent weeks, across the continent, problems have been reported in the power grid, telecommunications, and rail transportation. IT infrastructure has not been spared from the situation.

“The heat affects equipment long before anyone notices a problem,” explains Ricardo Román, sales director at Fracttal, in an email. “Every piece of equipment has a temperature range within which it is designed to operate, and when it operates above that range, it begins to degrade silently,” he says. A process of wear and tear begins that will eventually take its toll. With technology, this happens much faster. “In a data center, this effect is amplified because there’s no margin for error,” he notes. When something starts to fail, everything grinds to a halt.

In fact, this latest heat wave has already had negative impacts on data centers outside of Spain. In the United Kingdom, high temperatures shut down hospital data centers and caused the University of Cambridge’s Dawn supercomputer to go offline, as its cooling systems were unable to cope with the temperatures. That’s the crux of the problem. “In IT, heat isn’t a computing problem—it’s a problem of maintaining the assets that support the data center,” explains Román. 

Heat thus becomes yet another risk for the IT industry and, in particular, for data centers.

Temperatures are a clear and growing concern when it comes to corporate risk prevention. “I see it in conversations with clients: In the past, the maintenance team was the one monitoring the temperature in a technical room,” Román says. “Today, management also monitors it, because they know that if that goes down, the service goes down—and behind the service is the end customer,” he adds. Maintenance has gone from being a cost “to a lever for business continuity that no one dares to touch.”

As a World Economic Forum analysis warns, we’re experiencing a boom in AI-driven data centers, but the impact of climate risks on them is being overlooked. Their estimates suggest these risks could result in an additional annual cost of $81 billion by 2035 and $168 billion by 2065. These calculations include all kinds of threats, such as floods or droughts, but most of the impact comes from extreme heat.

These projections are confirmed by data from the industry itself: Over the past three years, extreme weather events have accounted for one-third of the losses incurred by the U.S. division of the data center company Zurich. According to projections by the climate risk analysis firm First Street, 79% of global data centers will face increased risks from extreme weather. MapleCroft estimated in 2025 that 56% of major data centers had a high or very high risk rating for extreme heat, and that this figure would rise to 80% by 2080.

These percentages cannot be easily extrapolated to Europe in general—and to Spain in particular—as one might think, although they do make the trend clear. Guillermo Benito, CTO of Nabiax, points out during a video call that these studies are based on global samples and thus place significant weight on the capacity of Asia and the United States. “We represent a small percentage there, but that said, all countries will have to adapt. The two major challenges for data centers are energy and cooling,” Benitonotes.

Spain: A pioneer in heat?

In late June, French Labor Minister Jean-Pierre Farandou proposed taking a training course in Spain to learn how to prevent high temperatures from paralyzing a country. Although Spain’s climate varies by region, high summer temperatures are common in many areas (though climate change has made them more extreme and frequent in recent years), and the infrastructure of knowledge and solutions that Farandou wanted to learn about has been established. The big question is whether this also applies to data centers. Is Spain better prepared than other European regions?

“Heat waves are becoming increasingly intense and frequent. What used to happen once every two years now happens two, three, or four times a year,” Benito says. Speaking from his own experience, he adds: “In Spain, data centers already take these factors into account.” When it comes to redundancy, monitoring, or maintenance, these factors are already factored in. “It’s not like it’s an unforeseen event. It’s already been taken into account, and we build in a lot of redundancy—a wide safety margin,” he says.

The difference compared to central or northern Europe is that some haven’t considered this possibility. Benito points out that the same thing happens with homes. “For many years, they’ve been designing with two assumptions: that they have plenty of water because their climates are humid, and that it never gets hot,” he says. And this is a problem, because their summer temperatures have risen significantly during extreme heat waves. “Temperatures in the UK have gone up by 10 or 15 degrees, and their data centers aren’t prepared for that,” he says. In fact, he shares an anecdote about “a certain hyperscaler that, a few years ago, when its data centers in the United Kingdom went down, held a global conference to figure out how this had happened and draw lessons from it.” The curious thing is that what they learned was something that was already well known in Spain.

İsmail Enes Ayhan | Unsplash

It was already getting hot in southern Europe, and preparations were needed. Now, temperatures are becoming a topic of conversation outside the region, and climate change has made its way into IT strategy. Benito confirms that, yes, the conversation is more visible in global settings. “For several reasons. The first is because, obviously, it affects operations. Another is the market. Customers also demand that you address this.” Before, the focus was on power capacity and square meters. Now, the expert points out, people are asking where the electricity comes from and whether it’s clean, and they’re demanding emissions guarantees. The sector is making significant investments to become sustainable, he argues.

Beyond consumption data and the improvements that can be made, the big question is whether these high temperatures are already impacting decision-making—whether decisions on where to locate data centers (or not) are already being made with heat in mind.

Industry representatives explain that while the climate can have an impact and is already taken into account when deciding where to locate a data center, it is not yet the sole factor or the most decisive one. In other words, many other factors must be considered, and these carry much more weight in the decision-making process. One such factor is energy, which is essential for these infrastructures and must be constant, resilient, and have a low carbon footprint. It is also an area where cooling plays a major role. As Román points out, cooling can account for between 30 and 40% of energy consumption, “and in poorly managed facilities, that figure approaches 50%.” Energy efficiency and cooling efficiency are thus essential—and not just for sustainability reasons. “It’s a matter of the bottom line.”

Another factor is space. As Benito says, you need “stable locations where you can grow.” This isn’t just about whether the infrastructure fits, but also about how it aligns with the needs of its customers. As this expert points out, the concentration of data centers near Madrid or Barcelona isn’t “just a whim,” but because you need to be close to large population centers to provide them with low latency. “Other supercomputing applications can be located farther away, and that’s already happening,” he explains, but generally speaking, you can’t just put data centers anywhere. You have to strike a balance between needs and available space.

How to survive the heat

So, how can we survive the heat, especially when projections suggest that the future will bring even higher temperatures? The key is to understand that this is no longer a curiosity or an occasional incident. As Román points out, air-conditioning systems are running longer and longer. What worked 10 years ago will now barely suffice—it’s “pushed to its limits.” “Heat is shifting from being an August blip to a variable that must be monitored year-round. One you endure; the other you manage.”

“By the time the room’s thermometer rises, it’s already too late. What you need to monitor isn’t the room—it’s the equipment—and you have to do it sooner,” he says. Román recommends a three-step strategy. First, don’t measure the environment; instead, measure the equipment and its variations in temperature, vibrations, and energy consumption. Next, take action on any deviations: Don’t wait for a failure, but instead act on early indicators that things aren’t normal. And finally, keep a comprehensive record of historical data, which will be key to anticipating issues and learning from them. “And here I’m going to be honest, because this is what I see every day: The technology to do all this already exists and isn’t expensive,” he asserts. “Many critical facilities are still managed using an Excel spreadsheet and the memory of a technician who’s been there for twenty years,” he warns. And that’s a problem.

In the specific case of data centers, Spain has done its homework. The high temperatures (which exceeded those recorded in the United Kingdom, where some data centers did shut down) did not bring them to a halt during this heat wave.

Unlike what might happen in other countries, Spain has optimized its cooling systems to be efficient and sustainable, as Benito explains, noting that the country must also contend with water stress. “In other countries, I can use water and let it evaporate as I please because I know it’s going to rain again—or at least that was the case until recently. In Spain, we’ve known for a long time that this isn’t the case,” he says. That’s why we work with closed-loop systems. “Most of us operators don’t use any water,” he says. The same water, mixed with certain cooling agents, circulates continuously. “Once the loop is filled, we don’t lose a single drop,” he asserts.

What this expert is now seeing at international conferences is that in other countries where water wasn’t an apparent problem, people are starting to talk about working this way—”as a technical innovation.” “That’s where we say, ‘Yes, just like the ones we have in Spain or Portugal,’” he remarks with a touch of humor. “Water, like energy, is a challenge,” he says, so everything has already been designed with that in mind. It isn’t wasted, it doesn’t evaporate, and it isn’t consumed, he says.

If you’re a software developer or architect, you might wonder if programming certifications are still worth the effort, especially in the era of rapid AI-driven evolution. The short answer is, it depends.

“Certifications are shifting from a checkbox to a compass. They’re less about proving you memorized syntax and more about proving you can architect systems, instruct AI coding assistants, and solve problems end-to-end,” says Faizel Khan, lead AI engineer at Landing Point, an executive search and recruiting firm.

“In the AI era, fewer students will get trained on the job, which means they have to train themselves,” Khan says. “Certifications—especially architectural ones like AWS, Kubernetes, Terraform—are still the clearest path to do that.”

Pros and cons of programming certifications

It’s not all black and white when it comes to deciding whether to pursue programming certifications. The effort involves both pros and cons.

“In terms of pros, certifications concretely demonstrate that you have a skillset at a documented level,” says Chris Riccio, vice president of engineering at Uplevel, an engineering optimization system provider. “They also show that you’ve put in the time and effort to learn, study, and prepare.”

Programming certifications are “a useful way to validate foundational skills and show that someone understands core concepts,” says Greg Fuller, vice president of Skillsoft’s training provider, Codecademy. “They’re especially helpful for people entering the field or shifting from adjacent roles.”

Certifications offer a structured path to demonstrate proficiency, and they can confirm your ability to build and deploy in various environments, Fuller says.

These types of certifications often demonstrate baseline proficiency and continuous learning, says Reshmi Ramachandran, head of partnerships and GTM strategy for Cprime, a consultancy. “These are often key indications of proficiency for companies looking to filter large candidate pools,” she says.

Certifications really do two things, Khan adds. “First, they force you to learn by doing,” he says. “If you’re taking AWS Solutions Architect or Terraform, you don’t pass by guessing—you plan, build, and test systems. That practice matters. Second, they act as a public signal. Think of it like a micro-degree. You’re not just saying, ‘I know cloud.’ You’re showing you’ve crossed a bar that thousands of other engineers recognize.”

But there are cons, too. “In tech, employers don’t just want credentials, they want proof you can deliver,” says Kevin Miller, CTO at IFS, a maker of factory automation software. “Programming certifications can be a valuable indicator of your baseline knowledge and competencies, especially if you’re early in your career or pivoting into tech, but their importance is dwindling.”

AI tools that can generate, debug, and optimize code are already performing tasks once done by entry-level developers, “which means fewer traditional programming roles are available,” Miller says. “As a result, the job market is becoming more competitive, and certifications aren’t seen as the noteworthy achievement they once were.”

What’s more, not all certifications carry the same weight, Riccio says. “Some may reflect only familiarity rather than true expertise,” he says. “Certifications also often measure ‘book knowledge’ rather than practical experience, and they don’t always map clearly to the requirements of a specific role.”

Programming certifications “can be a helpful signal, especially for confirming baseline knowledge in areas like cloud, security, or devops, but they’re not the full picture,” says Morgan Watts, vice president of IT at 8×8, a contact center platform developer.

“I’m more interested in a candidate’s attitude and aptitude: what problems they’ve solved, what they’ve built, and how they’ve approached challenges,” Watts says. “Certifications can show commitment and discipline, and they’re especially useful in highly specialized roles. But I’m cautious when someone presents a laundry list of certifications with little evidence of real-world application.”

A certification without experience doesn’t carry much weight, Watts says, and over-certification can sometimes signal the wrong focus. “Ultimately, it’s the ability to apply knowledge, collaborate, and adapt that sets great developers apart,” he says.

Finally, certifications can age fast, Khan says. “Tech stacks evolve and a badge from two years ago may already feel dusty,” he says. “And some certifications are paper-thin—multiple-choice exams that don’t prove you can debug production at 2 a.m. So, the risk is you collect badges but still can’t ship.”

Which certifications will get you noticed?

Despite the drawbacks, certifications are still very much in demand, and some carry more weight than others.

The most in-demand certifications are typically platform-based—Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, and others, Riccio says. “Many of these platforms provide managed services that integrate with existing systems or serve as the glue between them,” he says. “Today’s engineering teams aren’t just building standalone systems in isolation; they’re using other systems to store data, orchestrate business workflows, and connect applications.”

A certification that demonstrates the ability to build solutions on these platforms can put a development professional ahead of the competition, Riccio says.

“The certifications I see in highest demand tend to reflect the evolving tech landscape,” Watts says. “Cloud certifications from AWS, Azure, and GCP are incredibly valuable, especially as distributed systems become the norm.”

Also in demand are certifications for devops and CI/CD tools including Kubernetes, Docker, and Jenkins, Watts says, “because deployment automation and reliability are critical at scale. Also, with AI reshaping development, we’re seeing growing interest in certifications around machine learning, data science, and AI model integration. These certifications stand out because they align directly with the skills that teams need to move faster and more intelligently.”

On the AI front, certifications in TensorFlow and other machine learning platforms are gaining traction as organizations look to embed AI across the development process, Watts says. “These are the certifications that align closely with where modern engineering is headed—scalable, secure, and AI-enabled,” he says.

And then there are cybersecurity credentials that continue to be in high demand. Security certifications, such as CompTIA Security+ or Certified Ethical Hacker, “have become essential as every company faces increasing cyber threats and compliance requirements,” Miller says.

“Core programming certifications are still a bit niche, but the adjacent skills, like those that help developers deploy, secure, and scale their code, are driving demand,” Fuller says. “Companies want developers who understand the full lifecycle, not just how to write code.”

Also see: The best Java certifications for software developers.

Certifications in the hiring process

Experts are clear that programming certifications alone will not get you the job. But they do play a role in the hiring process.

“The information technology world is characterized by rapid and continuous evolution, including the skills and knowledge required to work in the field,” says Diane Rafferty, managing director of the National Technology Group at Atrium, a global talent solutions and extended workforce management firm.

“Certifications not only prove that you have the skills and knowledge needed, but they also show employers that you’re invested in your education and career growth,” Rafferty says. “They can give you a competitive edge when looking for a job, as many companies now require candidates to have them.”

Certifications are one part of the hiring equation, “but never the only part,” Watts says. “They help validate that a candidate has taken the time to build foundational knowledge, and that’s a good sign. But I put more weight on how a person thinks, solves problems, and contributes to the team. I look for people who are curious and proactive, who are learning because they want to, not just because a course told them to.”

Certifications can also play a valuable role in retention, Watts says. “I encourage team members to pursue growth, and when they invest in their own development, the whole organization benefits,” he says. “But again, it’s that balance of knowledge, attitude, and applied experience that really moves the needle.”

Certifications “may allow you to breeze through the initial résumé screening process, potentially getting you to the next stage faster,” Riccio says. “At a minimum, they will set your profile apart from the rest of the pack. They also demonstrate that you’ve reached a baseline level of expertise, allowing hiring managers to quickly evaluate whether you have the skills for the role.”

Employers today “care far less about whether someone has passed an exam and far more about whether they can apply knowledge effectively in real-world situations, leverage AI tools, and solve complex problems,” Miller says. “A certification might get someone an interview, but being able to demonstrate problem-solving skills, teamwork, and adaptability will really make them stand out.”

Popular programming certifications

The following certifications consistently rose to the top in my conversations with tech leaders and hiring managers.

AWS Certified Developer—Associate

Showcases skills and knowledge in developing, optimizing, packaging, and deploying applications, using CI/CD workflows, and identifying and resolving application issues, according to AWS. This certification is said to be a good starting point on the AWS certification journey for professionals in IT or cloud developer job roles.

Azure Developer Associate

This certificate from Microsoft is intended for developers participating in all phases of cloud development, including design, deployment, maintenance, and monitoring. The course teaches developers how to create end-to-end solutions in Microsoft Azure, using the Microsoft Learn Sandbox environment to access Azure resources and services.

Certified Kubernetes Application Developer (CKAD)

This certification was created by the Linux Foundation and Cloud Native Computing Foundation. It demonstrates that candidates can design, build, and deploy cloud-native applications for Kubernetes.

Certified Secure Software Lifecycle Professional (CSSLP)

This certification, from ISC2, focuses on secure software development practices. It recognizes leading application security skills and demonstrates advanced technical skills and knowledge needed for authentication, authorization, and auditing throughout the software development lifecycle.

Databricks Certified Machine Learning Professional

Professionals learn about the latest data and AI techniques and how they can use the Databricks Data Intelligence Platform to build a variety of solutions across data engineering, data warehousing, data science, and AI.

Professional Cloud Architect

This certification from Google assesses the ability to design and plan a cloud solution architecture, manage and provision the cloud solution infrastructure, design for security and compliance, analyze and optimize technical and business processes manage implementations of cloud architecture, and ensure solution and operations reliability.

Terraform Associate

This certification from HashiCorp is for cloud engineers specializing in operations, IT, or development who know the basic concepts and skills associated with Terraform. It validates foundational skills in using Terraform for infrastructure as code development.

Over its more than 15 years in the wild, Google’s Go programming language has evolved from a curiosity for alpha geeks to the battle-tested programming language behind some of the world’s most important cloud-native software projects.

If you’ve ever wondered why Go is the language of choice for projects like Docker and Kubernetes, this article is for you. We’ll discuss Go’s defining characteristics and how it differs from other programming languages. You will also learn what kinds of projects Go is best suited for, including the state of Go development for AI-powered tools. We’ll conclude with an overview of Go’s feature set, some limitations of the language, and where it may be going from here.

Also see: Golang tutorial: Get started with the Go language.

Go is small and simple

Go, or Golang as it’s often called, was created by Google employees—chiefly longtime Unix guru and Google distinguished engineer Rob Pike—but it’s not strictly speaking a “Google project.” Rather, Go is a community-developed open source project, spearheaded by leadership with strong opinions about how Go should be used and the direction the language should take.

Go is meant to be easy to learn and straightforward to use, with syntax that is simple to read and understand. Go does not have a large feature set, especially when compared to languages like C++. Go’s syntax is reminiscent of C, making it relatively easy for longtime C developers to learn. That said, many features of Go, especially its concurrency and functional programming features, harken back to languages like Erlang.

As a C-like language for building and maintaining cross-platform enterprise applications of all sorts, Go has much in common with Java. And as a means for enabling rapid development of code that might run anywhere, you could draw a parallel between Go and Python, though the differences outweigh the similarities.

The Go documentation describes Go as “a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language.” Even a large Go program will compile in a matter of seconds. Plus, Go avoids much of the overhead of C-style include files and libraries.

Advantages of the Go language

Go is a versatile, convenient, fast, portable, interoperable, and widely supported modern language. These characteristics have helped to make it a top choice for large-scale development projects. Let’s look more closely at each of these positive qualities of Go.

Go is versatile and convenient

Go has been compared to interpreted languages like Python in its ability to satisfy many common programming needs. Some of this functionality is built into the language itself, such as goroutines for concurrency and thread-like behavior, while additional capabilities are available in Go standard library packages, like the http package. Like Python, Go provides automatic memory management capabilities including garbage collection.

Unlike interpreted languages, however, Go code compiles to a fast-running native binary. And unlike C or C++, Go compiles extremely fast—fast enough to make working with Go feel more like working with an interpreted language than a compiled one. Further, the Go build system is less complex than those of other compiled languages. It takes few steps and little bookkeeping to build and run a Go project.

Go is faster than many other languages

Go binaries run more slowly than their C counterparts, but the difference in speed is negligible for most applications. Go performance is as good as C for the vast majority of work, and generally much faster than other languages known for speed of development—including JavaScript, Python, and Ruby.

Go is portable and interoperable

Executables created with the Go toolchain can stand alone, with no default external dependencies. The Go toolchain is available for a wide variety of operating systems and hardware platforms, and can be used to compile binaries across platforms. What’s more, Go delivers all of the above without sacrificing access to the underlying system. Go programs can talk to external C libraries or make native system calls. In Docker, for instance, Go interacts with low-level Linux functions, cgroups, and namespaces to work container magic.

Go is widely supported

The Go toolchain is freely available as a Linux, macOS, or Windows binary, or as a Docker container. Go is included by default in many popular Linux distributions, such as Red Hat Enterprise Linux and Fedora, making it somewhat easier to deploy Go source to those platforms. Support for Go is also strong across many third-party development environments, from Microsoft’s Visual Studio Code to ActiveState’s Komodo IDE.

Also see: 8 reasons developers love Go—and 8 reasons they don’t.

Optimal use cases for the Go language

No language is suited to every job, but some languages are suited to more jobs than others. Go shines brightest in cloud-native development projects, distributed network services, and for developing utilities and stand-alone tools. Let’s consider the qualities that make Go especially well-suited to each of these project types.

Cloud-native development

Go’s concurrency and networking features, and its high degree of portability, make it well-suited for building cloud-native apps. In fact, Go was used to build several cornerstones of cloud-native computing including Docker, Kubernetes, and Istio.

Distributed network services

Network applications live and die by concurrency, and Go’s native concurrency features—goroutines and channels, mainly—are well suited for such work. Consequently, many Go projects are for networking, distributed functions, and cloud services. These include APIs, web servers, Kubernetes-ready frameworks for microservices, and much more.

Utilities and standalone tools

Go programs compile to binaries with minimal external dependencies. That makes them ideally suited to creating utilities and other tools, because they launch quickly and can be readily packaged up for redistribution. One example is an access server called Teleport, which can be deployed on servers quickly by compiling it from source or downloading a prebuilt binary.

Limitations of the Go language

Now let’s consider some of the limitations of Go. For one, it omits many language features developers may desire. It also packs everything into its binaries, so Go programs can be large. Furthermore, Go’s garbage collection mechanism delivers automatic memory management at the cost of absolute performance. The language also lacks a standard toolkit for building GUIs, and it is unsuited to systems programming.

Let’s look at each of these issues in detail.

Go omits many desirable language features

Go’s opinionated set of features draws both praise and criticism. Go is designed to err on the side of being small and easy to understand, with certain features deliberately omitted. The result is that some features that are commonplace in other languages simply aren’t available in Go. This is purposeful, but it’s still a drawback for some types of projects.

One thing Go omits that you will find in other languages is macros, commonly defined as the ability to generate program code at compile time. C, C++, and (the rising star) Rust all have macro systems. Go does not have macros, or at least not of the same variety as those languages. What Go does have is a tool command, go generate, which looks for magic comments in Go source and executes them. This can be used to generate Go source code, or even run other commands, but its main use is to programmatically generate code, usually as a precursor to the build process. (Technical blogger Eli Bendersky explains the ‘go generate’ command in detail.)

Another longstanding complaint with Go was, until recently, the lack of generic functions, which allow a function to accept many different types of variables. Go’s development team held out against adding generics to the language for many years because they wanted a syntax and set of behaviors that complemented the rest of Go. But as of Go 1.18, released in early 2022, the language includes a syntax for generics. Because go generate and its code-generation abilities emerged as one possible way to partially address the lack of generics, this functionality is no longer as commonly used in Go.

The fact is that Go adds major language features rarely, and only after much consideration. This works to preserve broad compatibility across versions, but it comes at the cost of slower innovation.

Also see: What you need to know about Go, Rust, and Zig.

Go’s binaries are large

Another potential downside to Go is the size of the generated binaries. Go binaries are statically compiled by default, meaning that everything needed at runtime is included in the binary image. This approach simplifies the build and deployment process, but at the cost of a simple “Hello, world!” weighing in at around 1.5MB on 64-bit Windows. The Go team has been working to reduce the size of those binaries with each successive release. It is also possible to shrink Go binaries with compression or by removing Go’s debug information. This last option may work better for standalone distributed apps than for cloud or network services, where having debug information is useful if a service fails in place.

Go’s garbage collection is resource hungry

Yet another touted feature of Go, automatic memory management, can be seen as a drawback, as garbage collection requires a certain amount of processing overhead. By design, Go doesn’t provide manual memory management, and garbage collection in Go has been criticized for not dealing well with the kinds of memory loads that appear in enterprise applications.

That said, each new version of Go seems to improve the memory management features. For example, Go 1.8 brought significantly shorter lag times for garbage collection, and Go 1.25 introduced a new, experimental garbage collector. While Go developers can use manual memory allocation in a C extension, or by way of a third-party manual memory management library, most prefer native solutions.

Go doesn’t have a standard GUI toolkit

Most Go applications are command-line tools or network services. That said, various projects are working to bring rich GUIs for Go applications. There are bindings for the GTK and GTK3 frameworks. Another project is intended to provide platform-native UIs across platforms, although it focuses on Go 1.24 forward only. But no clear winner or safe long-term bet has emerged in this space. Also, because Go is platform-independent by design, it is unlikely any project in this vein will become a part of the standard package set.

You shouldn’t use Go for systems programming

Finally, although Go can talk to native system functions, it was not designed for developing low-level system components such as kernels, device drivers, or embedded systems. After all, the Go runtime and the garbage collector for Go applications are dependent on the underlying operating system. (Developers interested in a cutting-edge language for that kind of work might look into using Rust.)

The future of the Go language

Go’s development is turning more toward the wants and needs of its developer base, with Go’s minders changing the language to better accommodate this audience rather than leading by stubborn example. A case in point is generics, which were finally added to the language after much deliberation about the best way to do so.

The 2024 Go Developer Survey found developers were overall satisfied with Go. Challenges that surfaced were generally due to the verbosity of error handling, missing or immature frameworks, and using Go’s type system—areas ripe for future development.

Like most languages, Go has gravitated to a core set of use cases over time, finding its niche in network services. In the future, Go is likely to continue expanding its hold there. Other use cases cited in the developer survey include creating APIs or RPC services (74% of respondents), followed by CLI applications (63%), web services (45%), libraries/frameworks (44%), automation (39%), and data processing (37%). While only 4% of respondents mentioned using Go to develop AI technologies, those who did reported that Go was a strong platform for running AI-powered workloads in production. For those wanting to develop ML/AI with Go, lack of tooling (23%) and the fact that Python is the default choice for such work (16%) topped the reasons why.

It remains to be seen how far Go’s speed and development simplicity will take it into other use cases, especially those dominated by other languages and their existing use cases. Rust covers safe and fast systems programming (a space Go is unlikely to enter); Python is still a common default for ML/AI, prototyping, automation, and glue code; and Java remains a stalwart for enterprise applications.

But Go’s future as a major programming language is already assured—certainly in the cloud, where the speed and simplicity of Go ease the development of scalable infrastructure that can be maintained over the long run.

Also see: Go language evolving for future hardware, AI workloads.

Spring is a reliable and popular framework for building web and enterprise Java applications. In this article, you’ll learn how to unit test each layer of a Spring MVC application, using built-in testing tools from JUnit 5 and Spring to mock each component’s dependencies. In addition to unit testing with MockMvc, Mockito, and Spring’s TestEntityManager, I’ll also briefly introduce slice testing using the @WebMvcTest and @DataJpaTest annotations, used to optimize unit tests on web controllers and databases.

Also see: How to test your Java applications with JUnit 5.

Overview of testing Spring MVC applications

Spring MVC applications are defined using three technology layers:

• Controllers accept web requests and return web responses.
• Services implement the application’s business logic.
• Repositories persist data to and from your back-end SQL or NoSQL database.

When we unit test Spring MVC applications, we test each layer separately from the others. We create mock implementations, typically using Mockito, for each layer’s dependencies, then we simulate the logic we want to test. For example, a controller may call a service to retrieve a list of objects. When testing the controller, we create a mock service that either returns the list of objects, returns an empty list, or throws an exception. This test ensures the controller behaves correctly.

We’ll use Spring MVC to build and test a simple web service that manages widgets. The structure of the web service is shown here:

Steven Haines

This is a classic MVC pattern. We have a widget controller that handles RESTful requests and delegates its business functionality to a widget service, which uses a widget repository to persist widgets to and from an in-memory H2 database.

Get the source: Download the source code for this article.

Unit testing a Spring MVC controller with MockMvc

Setting up a Spring MVC controller test is a two-step process:

• Annotate your test class with @WebMvcTest.
• Autowire a MockMvc instance into your controller.

We could annotate all our test classes with @SpringBootTest, but we’ll use @WebMvcTest instead. The reason is that the @WebMvcTest annotation is used for slice testing. Whereas @SpringBootTest loads your entire Spring application context, @WebMvcTest loads only your web-related resources. Furthermore, if you specify a controller class in the annotation, it will only load the specific controller you want to test. Testing a single “slice” of your application reduces both the amount of compute resources required to set up the test and the time required to run a test.

For example, when we test a controller, we’ll mock just the services it uses, and we won’t need any repositories at all. If we don’t need them, then we needn’t waste time loading them. Slice tests were created to make tests perform better and run faster.

Here’s the source code for the Widget class we’ll be managing:

package com.infoworld.widgetservice.model;
import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.GenerationType;
import jakarta.persistence.Id;

@Entity
public class Widget {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    private String name;
    private int version;

    public Widget() {
    }

    public Widget(String name) {
        this.name = name;
    }

    public Widget(String name, int version) {
        this.name = name;
        this.version = version;
    }

    public Widget(Long id, String name, int version) {
        this.id = id;
        this.name = name;
        this.version = version;
    }

    public Long getId() {
        return id;
    }

    public void setId(Long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public int getVersion() {
        return version;
    }

    public void setVersion(int version) {
        this.version = version;
    }
}

A Widget is a JPA entity that manages three fields:

• id is the primary key of the table, annotated with @Id and @GeneratedValue, with an automatic generation strategy.
• name is the name of the widget.
• version is the version of the widget resource. We’ll use this value to populate our eTag value and check it in our PUT operation’s If-Match header value. This ensures the widget being updated is not stale.

Here’s the source code for the controller we’ll be testing (WidgetController.java):

package com.infoworld.widgetservice.web;

import java.net.URI;
import java.net.URISyntaxException;
import java.util.List;
import java.util.Optional;
import com.infoworld.widgetservice.model.Widget;
import com.infoworld.widgetservice.service.WidgetService;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.DeleteMapping;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.PutMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestHeader;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class WidgetController {
    @Autowired
    private WidgetService widgetService;
    @GetMapping("/widget/{id}")
    public ResponseEntity getWidget(@PathVariable Long id) {
        return widgetService.findById(id)
                .map(widget -> {
                    try {
                        return ResponseEntity
                                .ok()
                                .location(new URI("/widget/" + id))
                                .eTag(Integer.toString(
                                               widget.getVersion()))
                                .body(widget);
                    } catch (URISyntaxException e) {
                        return ResponseEntity
                          .status(HttpStatus.INTERNAL_SERVER_ERROR)
                          .build();
                    }
                })
                .orElse(ResponseEntity.notFound().build());
    }
    @GetMapping("/widgets")
    public List getWidgets() {
        return widgetService.findAll();
    }
    @PostMapping("/widgets")
    public ResponseEntity createWidget(@RequestBody Widget widget)
    {
        Widget newWidget = widgetService.create(widget);
        try {
           return ResponseEntity
                   .created(new URI("/widget/" + newWidget.getId()))
                   .eTag(Integer.toString(newWidget.getVersion()))
                   .body(newWidget);
        } catch (URISyntaxException e) {
            return ResponseEntity
                    .status(HttpStatus.INTERNAL_SERVER_ERROR)
                    .build();
        }
    }

    @PutMapping("/widget/{id}")
    public ResponseEntity updateWidget(@PathVariable Long id,
                                          @RequestBody Widget widget,
                         @RequestHeader("If-Match") Integer ifMatch) {
        Optional existingWidget = widgetService.findById(id);
        return existingWidget.map(w -> {
            if (w.getVersion() != ifMatch) {
                return ResponseEntity.status(HttpStatus.CONFLICT)
                                     .build();
            }

            w.setName(widget.getName());
            w.setVersion(w.getVersion() + 1);

            Widget updatedWidget = widgetService.save(w);
            try {
                return ResponseEntity.ok()
                        .location(new URI("/widget/" + 
                                      updatedWidget.getId()))
                        .eTag(Integer.toString(
                                      updatedWidget.getVersion()))
                        .body(updatedWidget);
            } catch (URISyntaxException e) {
                throw new RuntimeException(e);
            }
        }).orElse(ResponseEntity.notFound().build());
    }

    @DeleteMapping("widget/{id}")
    public ResponseEntity deleteWidget(@PathVariable Long id) {
        Optional existingWidget = widgetService.findById(id);
        return existingWidget.map(w -> {
           widgetService.deleteById(w.getId());
           return ResponseEntity.ok().build();
        }).orElse(ResponseEntity.notFound().build());
    }
}

The WidgetController handles GET, POST, PUT, and DELETE operations, following standard RESTful principles, so we’re going to write tests for each operation.

The following source code shows the structure of our test class (WidgetControllerTest.java):

package com.infoworld.widgetservice.web;

@WebMvcTest(WidgetController.class)
public class WidgetControllerTest {
    @Autowired
    private MockMvc mockMvc;

    @MockitoBean
    private WidgetService widgetService;
}

I omitted the imports for readability, but the important thing to note is that the class is annotated with the @WebMvcTest annotation, and that we pass in the WidgetController.class as the controller we’re testing. This tells Spring to only load the WidgetController and no other Spring resources. The @WebMvcTest annotation includes other annotations, but the important one for our tests is @AutoConfigureMockMvc, which will cause Spring to create a MockMvc instance and add it to the application context. That lets us autowire it into our test class using the @Autowired annotation.

Next, we use the @MockitoBean annotation to use Mockito to create a mock implementation of the WidgetService, after which Spring will autowire it into the WidgetController class. This lets us control the behavior of the WidgetService for the WidgetController test cases we’re writing. Note that starting in Spring Boot version 3.4, @MockitoBean replaced @MockBean. Everything you know about @MockBean translates to using @MockitoBean—with some improvements.

Unit testing GET /widgets

Let’s start with the easiest test case, a test for GET /widgets:

@Test
void testGetWidgets() throws Exception {
    List widgets = new ArrayList();
    widgets.add(new Widget(1L, "Widget 1", 1));
    widgets.add(new Widget(2L, "Widget 2", 1));
    widgets.add(new Widget(3L, "Widget 3", 1));

    when(widgetService.findAll()).thenReturn(widgets);

    mockMvc.perform(get("/widgets"))
            .andExpect(status().isOk())
            .andExpect(jsonPath("$.length()").value(3))
            .andExpect(jsonPath("$[0].id").value(1L))
            .andExpect(jsonPath("$[0].name").value("Widget 1"))
            .andExpect(jsonPath("$[0].version").value(1));
};

The testGetWidgets() method creates a list of three widgets and then configures the mock WidgetService to return the list when its findAll() method is called. The WidgetControllerTest class statically imports the org.mockito.Mockito.when() method that accepts a method call, which in this case is widgetService.findAll(), and returns a Mockito OngoingStubbing instance. This OngoingStubbing instance exposes methods like thenReturn(), thenThrow(), thenCallRealMethod(), thenAnswer(), and then().

Here, we use the thenReturn() method to tell Mockito to return the list of widgets when the WidgetService’s findAll() method is called. The @MockitoBean annotation causes the mock WidgetService to be autowired into the WidgetController. So, when the getWidgets() method is called in response to a GET /widgets, it calls the WidgetService’s findAll() method and returns our list of widgets as a web response.

Next, we use MockMvc’s perform() method to execute a web request. This diagram shows the various classes that interact with the perform() method:

Steven Haines

The perform() method accepts a RequestBuilder. Spring defines several built-in RequestBuilders that we can statically import into our tests, including get(), post(), put(), and delete(). The perform() method returns a ResultActions instance that exposes methods such as andExpect(), andExpectAll(), andDo(), and andReturn(). Here, we invoke the andExpect() method, which accepts a ResultMatcher.

A ResultMatcher defines a match() method that throws an AssertionError if the assertion fails. Spring defines several ResultMatchers that we can statically import:

• status() allows us to check the HTTP status code of response.
• content() allows us to check the content headers of the response, such as Content-Type.
• header() allows us to check any of the HTTP header values.
• jsonPath() allows us to inspect the contents of a JSON document.

After MockMvc performs a GET to /widgets, we expect the HTTP status code to be 200 OK. We can then use the jsonPath matcher to check the body results, using the following JSON path expressions:

• $.length(): The $ references the root of the JSON document. If the response is a list, then we can call the length() method to get the number of elements in the list.
• $[0].id: JSON path expressions for a list use an array syntax starting at 0. This expression gets the ID of the first element in the list.
• $[0].name: This expression gets the name of the first element and compares it to “Widget 1”.
• $[0].version: This expression gets the version of the first element and compares it to 1.

Unit testing the GET /widget/{id} handler

Here’s the source code to test the GET /coffee/{id} widget:

@Test
void testGetWidgetById() throws Exception {
    Widget widget = new Widget(1L, "My Widget", 1);          
    when(widgetService.findById(1L))
           .thenReturn(Optional.of(widget));

    mockMvc.perform(get("/widget/{id}", 1))
            // Validate that we get a 200 OK Response Code
            .andExpect(status().isOk())

            // Validate Headers
            .andExpect(content()
                      .contentType(MediaType.APPLICATION_JSON))
            .andExpect(header().string(HttpHeaders.LOCATION,
                                       "/widget/1"))
            .andExpect(header().string(HttpHeaders.ETAG, "\"1\""))

            // Validate content
            .andExpect(jsonPath("$.id").value(1L))
            .andExpect(jsonPath("$.name").value("My Widget"))
            .andExpect(jsonPath("$.version").value(1));
 }

This test method is very similar to the testGetWidgets() method, but with some notable changes:

• The GET URI is defined using a URI template. You can specify any number of variables enclosed in braces in the URI template and then send a list of arguments that will replace those variables in the order they appear in the template.
• We check that the returned Content-Type is “application/json”, which is a constant in the MediaType class. We access the content using the content() method, which returns a ContentResultMatchers instance that provides various methods, including contentType(), which allows us to validate the content headers.
• We check for specific header values using the header() method. The header() method returns a HeadersResultMatchers instance, which can check for header String, long, and date values, as well as checking to see whether or not specific headers exist. In this case, we use constants defined in the HttpHeaders class to check the location and eTag header values.
• We check the body of the response using JSON path expressions. In this case, we do not have a list of objects, so we can access the individual fields in the JSON document directly. For example, $.id retrieves the id field value in the root of the document.

Unit testing a GET /widget/{id} Not Found code

Next, we test the GET /widget/{id}, passing it an invalid ID so that it returns a 404 Not Found response code:

@Test
void testGetWidgetByIdNotFound() throws Exception {
   when(widgetService.findById(1L)).thenReturn(Optional.empty());

   mockMvc.perform(get("/widget/{id}", 1))
            // Validate that we get a 404 Not Found Response Code
            .andExpect(status().isNotFound());
}

The testGetWidgetByIdNotFound() method configures the mock WidgetService to return Optional.empty() when its findById() is called with a value of 1. We then perform a GET request to /widget/1, then assert that the returned HTTP status code is 404 Not Found.

Unit testing POST /widgets

Here’s how to test a Widget creation:

@Test
void testCreateWidget() throws Exception {
    Widget widget = new Widget(1L, "Widget 1", 1);
    when(widgetService.create(any())).thenReturn(widget);

    mockMvc.perform(post("/widgets")
            .contentType(MediaType.APPLICATION_JSON)
            .content("{\"name\": \"Widget 1\"}"))

            // Validate that we get a 201 Created Response Code
            .andExpect(status().isCreated())

            // Validate Headers
            .andExpect(content().contentType(
                                      MediaType.APPLICATION_JSON))
            .andExpect(header().string(HttpHeaders.LOCATION, 
                                       "/widget/1"))
            .andExpect(header().string(HttpHeaders.ETAG, "\"1\""))

            // Validate content
            .andExpect(jsonPath("$.id").value(1L))
            .andExpect(jsonPath("$.name").value("Widget 1"))
            .andExpect(jsonPath("$.version").value(1));

The testCreateWidget() method first creates a Widget to return when the WidgetService’s create() method is called with any argument. The any() matcher matches any argument and, because the createWidget() handler will create a new Widget instance, we will not have access to that instance when the test runs. We then invoke MockMvc’s perform() method to the ”/widgets” URI, sending the content body of a new widget named “Widget 1”, using the content() method. We expect a 201 Created HTTP response code, an “application/json” content type, a location header of “/widget/1”, and an eTag value of the String “1”. The body of the response should match the Widget we returned from the create() method, namely an ID of 1, a name of “Widget 1”, and a version of 1.

Unit testing PUT /widget

This code runs three tests for the PUT operation:

@Test
public void testSuccessfulUpdate() throws Exception {
    // Create a mock Widget when the WidgetService's findById(1L) 
    // is called
    Widget mockWidget = new Widget(1L, "Widget 1", 5);
    when(widgetService.findById(1L))
                      .thenReturn(Optional.of(mockWidget));

    // Create a mock Coffee that is returned when the 
    // CoffeeController saves the Coffee to the database
    Widget savedWidget = new Widget(1L, "Updated Widget 1", 6);
    when(widgetService.save(any())).thenReturn(savedWidget);

    // Execute a PUT /widget/1 with a matching version: 5
    mockMvc.perform(put("/widget/{id}", 1L)
                    .contentType(MediaType.APPLICATION_JSON)
                    .header(HttpHeaders.IF_MATCH, 5)
                    .content("{\"id\": 1, " +
                             "\"name\": \"Updated Widget 1\"}"))

            // Validate that we get a 200 OK HTTP Response
           .andExpect(status().isOk())

            // Validate the headers
           .andExpect(content()
                        .contentType(MediaType.APPLICATION_JSON))
           .andExpect(header().string(HttpHeaders.LOCATION, 
                                      "/widget/1"))
           .andExpect(header().string(HttpHeaders.ETAG, "\"6\""))

           // Validate the contents of the response
           .andExpect(jsonPath("$.id").value(1L))
           .andExpect(jsonPath("$.name")
                               .value("Updated Widget 1"))
           .andExpect(jsonPath("$.version").value(6));
}

@Test
public void testUpdateConflict() throws Exception {
   // Create a mock coffee with a version set to 5
   Widget mockWidget = new Widget(1L, "Widget 1", 5);

    // Return the mock Coffee when the CoffeeService's 
    // findById(1L) is called
    when(widgetService.findById(1L))
                      .thenReturn(Optional.of(mockWidget));

    // Execute a PUT /widget/1 with a mismatched version number: 2
    mockMvc.perform(put("/widget/{id}", 1L)
                    .contentType(MediaType.APPLICATION_JSON)
                    .header(HttpHeaders.IF_MATCH, 2)
                    .content("{\"id\": 1, " + 
                             "\"name\":  \"Updated Widget 1\"}"))
             // Validate that we get a 409 Conflict HTTP Response
            .andExpect(status().isConflict());
}

@Test
public void testUpdateNotFound() throws Exception {
   // Return the mock Coffee when the CoffeeService's 
   // findById(1L) is called
   when(widgetService.findById(1L)).thenReturn(Optional.empty());

   // Execute a PUT /coffee/1 with a mismatched version number: 2
   mockMvc.perform(put("/widget/{id}", 1L)
                    .contentType(MediaType.APPLICATION_JSON)
                    .header(HttpHeaders.IF_MATCH, 2)
                    .content("{\"id\": 1, " + 
                             "\"name\":  \"Updated Coffee 1\"}"))

           // Validate that we get 404 Not Found
           .andExpect(status().isNotFound());
}

We have three variations:

• A successful update.
• A failed update because of a version conflict.
• A failed update because the widget was not found.

In RESTful web services, version management is handled by the entity tag, or eTag. When you retrieve an entity, it has an eTag value. When you want to update the entity, you pass that eTag value in the If-Match HTTP header. If the If-Match header does not match the current eTag, which is the Widget version in our implementation, then the PUT handler returns a 409 Conflict HTTP response code. If you get this error, it means that you need to retrieve the entity again and retry your operation. This way, if two different clients attempt to update the same entity simultaneously, only one will succeed.

In the testSuccessfulUpdate() method, we return a Widget with a version of 5 when the WidgetService’s findById() method is called. We then pass an If-Match header value of 5 and then validate that we get a 200 OK HTTP response code and the expected header and body values. In the testUpdateConflict() method, we do the same thing, but we set the If-Match header to 2, which does not match 5, so we validate that we get a 409 Conflict HTTP response code. And finally, in the testUpdateNotFound() method, we configure the WidgetService to return an Optional.empty() when its findById() method is called, so we execute the PUT operation and validate that we get a 404 Not Found HTTP response code.

Unit testing DELETE /widget

Finally, here is the source code for our two DELETE /widget tests:

@Test
void testDeleteSuccess() throws Exception {
    // Setup mocked product
    Widget mockWidget = new Widget(1L, "Widget 1", 5);

    // Setup the mocked service
    when(widgetService.findById(1L))
                      .thenReturn(Optional.of(mockWidget));
    doNothing().when(widgetService).deleteById(1L);

    // Execute our DELETE request
    mockMvc.perform(delete("/widget/{id}", 1L))
            .andExpect(status().isOk());
}

@Test
void testDeleteNotFound() throws Exception {
    // Setup the mocked service
    when(widgetService.findById(1L)).thenReturn(Optional.empty());

    // Execute our DELETE request
    mockMvc.perform(delete("/widget/{id}", 1L))
            .andExpect(status().isNotFound());
}

The DELETE handler first tries to find the widget by ID and then calls the WidgetService’s deleteById() method. The testDeleteSuccess() method configures the WidgetService to return a mock Widget when the findById() method is called and then configures it to do nothing when the deleteById() method is called. The deleteById() method returns void, so we do not need to mock a response, though we do want to allow the method to be called. We execute the DELETE operation and validate that we receive a 200 OK HTTP response code. The testDeleteNotFound() method configures the WidgetService to return Optional.empty() when its findById() method is called. We execute the DELETE operation and validate that we receive a 404 Not Found HTTP response code.

At this point, we have a comprehensive set of tests for all of our controller operations. Let’s continue down our stack and test our service.

Unit testing a Spring MVC service

Next, we’ll test a WidgetService class, shown here:

package com.infoworld.widgetservice.service;

import java.util.List;
import java.util.Optional;

import com.infoworld.widgetservice.model.Widget;
import com.infoworld.widgetservice.repository.WidgetRepository;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class WidgetService {
    @Autowired
    private WidgetRepository widgetRepository;

    public List findAll() {
        return widgetRepository.findAll();
    }

    public Optional findById(Long id) {
        return widgetRepository.findById(id);
    }

    public Widget create(Widget widget) {
        widget.setVersion(1);
        return widgetRepository.save(widget);
    }

    public Widget save(Widget widget) {
        return widgetRepository.save(widget);
    }

    public void deleteById(Long id) {
        widgetRepository.deleteById(id);
    }
}

The WidgetService is very simple. It autowires in a WidgetRepository and then delegates almost all its functionality to the WidgetRepository. The only business logic it implements is that it sets the Widget version to 1 in the create() method, when it is persisting a new Widget to the database.

While Spring supports slice testing for our controller and (as you’ll soon see) our repository, it doesn’t have a slice testing annotation for our service. We could use the @SpringBootTest annotation, but then Spring would load all the controllers, repositories, and any other Spring resources in our application into the Spring application context. We can avoid by using Mockito directly.

Here is the source code for the WidgetServiceTest class:

package com.infoworld.widgetservice.service;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;
import static org.mockito.Mockito.when;

import java.util.Optional;

import com.infoworld.widgetservice.model.Widget;
import com.infoworld.widgetservice.repository.WidgetRepository;

import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;
import org.mockito.InjectMocks;
import org.mockito.Mock;
import org.mockito.junit.jupiter.MockitoExtension;

@ExtendWith(MockitoExtension.class)
public class WidgetServiceTest {
    @Mock
    private WidgetRepository repository;

    @InjectMocks
    private WidgetService service;

    @Test
    void testFindById() {
        Widget widget = new Widget(1L, "My Widget", 1);
        when(repository.findById(1L)).thenReturn(Optional.of(widget));

        Optional w = service.findById(1L);
        assertTrue(w.isPresent());
        assertEquals(1L, w.get().getId());
        assertEquals("My Widget", w.get().getName());
        assertEquals(1, w.get().getVersion());
    }
}

JUnit 5 supports extensions and Mockito has defined a test extension that we can access through the @ExtendWith annotation. This extension allows Mockito to read our class, find objects to mock, and inject mocks into other classes. The WidgetServiceTest tells Mockito to create a mock WidgetRepository, by annotating it with the @Mock annotation, and then to inject that mock into the WidgetService, using the @InjectMocks annotation. The result is that we have a WidgetService that we can test and it will have a mock WidgetRepository that we can configure for our test cases.

Also see: Advanced unit testing with JUnit 5, Mockito, and Hamcrest.

This is not a comprehensive test, but it should get you started. It has a single method, testFindById(), that demonstrates how to test a service method. It creates a mock Widget instance and then uses the Mockito when() method, just as we used in the controller test, to configure the WidgetRepository to return an Optional of that Widget when its findById() method is called. Then it invokes the WidgetService’s findById() method and validates that the mock Widget is returned.

Slice testing a Spring Data JPA repository

Next, we’ll slice test our JPA repository (WidgetRepository.java), shown here:

package com.infoworld.widgetservice.repository;

import java.util.List;
import com.infoworld.widgetservice.model.Widget;
import org.springframework.data.jpa.repository.JpaRepository;

public interface WidgetRepository extends JpaRepository {
    List findByName(String name);
}

The WidgetRepository is a Spring Data JPA repository, which means that we define the interface and Spring generates the implementation. It extends the JpaRepository interface, which accepts two arguments:

• The type of entity that it persists, namely a Widget.
• The type of primary key, which in this case is a Long.

It generates common CRUD method implementations for us to create, update, delete, and find widgets, and then we can define our own query methods using a specific naming convention. For example, we define a findByName() method that returns a List of Widgets. Because “name” is a field in our Widget entity, Spring will generate a query that finds all widgets with the specified name.

Here is our WidgetRepositoryTest class:

package com.infoworld.widgetservice.repository;

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertNotNull;
import static org.junit.jupiter.api.Assertions.assertNull;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

import com.infoworld.widgetservice.model.Widget;

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.orm.jpa.DataJpaTest;
import org.springframework.boot.test.autoconfigure.orm.jpa.TestEntityManager;

@DataJpaTest
public class WidgetRepositoryTest {
    @Autowired
    private TestEntityManager entityManager;

    @Autowired
    private WidgetRepository widgetRepository;

    private final List widgetIds = new ArrayList();
    private final List testWidgets = Arrays.asList(
            new Widget("Widget 1", 1),
            new Widget("Widget 2", 1),
            new Widget("Widget 3", 1)
    );

    @BeforeEach
    void setup() {
        testWidgets.forEach(widget -> {
            entityManager.persist(widget);
            widgetIds.add((Long)entityManager.getId(widget));
        });
        entityManager.flush();
    }

    @AfterEach
    void teardown() {
        widgetIds.forEach(id -> {
            Widget widget = entityManager.find(Widget.class, id);
            if (widget != null) {
                entityManager.remove(widget);
            }
        });
        widgetIds.clear();
    }

    @Test
    void testFindAll() {
        List widgetList = widgetRepository.findAll();
        assertEquals(3, widgetList.size());
    }

    @Test
    void testFindById() {
        Widget widget = widgetRepository.findById(
                               widgetIds.getFirst()).orElse(null);

        assertNotNull(widget);
        assertEquals(widgetIds.getFirst(), widget.getId());
        assertEquals("Widget 1", widget.getName());
        assertEquals(1, widget.getVersion());
    }

    @Test
    void testFindByIdNotFound() {
        Widget widget = widgetRepository.findById(
            widgetIds.getFirst() + testWidgets.size()).orElse(null);
        assertNull(widget);
    }

    @Test
    void testCreateWidget() {
        Widget widget = new Widget("New Widget", 1);
        Widget insertedWidget = widgetRepository.save(widget);

        assertNotNull(insertedWidget);
        assertEquals("New Widget", insertedWidget.getName());
        assertEquals(1, insertedWidget.getVersion());
        widgetIds.add(insertedWidget.getId());
    }

    @Test
    void testFindByName() {
        List found = widgetRepository.findByName("Widget 2");
        assertEquals(1, found.size(), "Expected to find 1 Widget");

        Widget widget = found.getFirst();
        assertEquals("Widget 2", widget.getName());
        assertEquals(1, widget.getVersion());
    }
}

The WidgetRepositoryTest class is annotated with the @DataJpaTest annotation, which is a slice-testing annotation that loads repositories and entities into the Spring application context and creates a TestEntityManager that we can autowire into our test class. The TestEntityManager allows us to perform database operations outside of our repository so that we can set up and tear down our test scenarios.

In the WidgetRepositoryTest class, we autowire in both our WidgetRepository and TestEntityManager. Then, we define a setup() method that is annotated with JUnit’s @BeforeEach annotation, so it will be executed before each test case runs. Next, we define a teardown() method that is annotated with JUnit’s @AfterEach annotation, so it will be executed after each test completes. The class defines a testWidgets list that contains three test widgets and then the setup() method inserts those into the database using the TestEntityManager’s persist() method. After it inserts each widget, it saves the automatically generated ID so that we can reference it in our tests. Finally, after persisting the widgets, it flushes them to the database by calling the TestEntityManager’s flush() method. The teardown() method iterates over all Widget IDs, finds the Widget using the TestEntityManager’s find() method, and, if it is found, removes it from the database. Finally, it clears the widget ID list so that the setup() method can rebuild it for the next test. (Note that the TestEntityManager removes entities directly; it does not have a remove by ID method, so we first have to find each Widget and then remove them one-by-one.)

Even though most of the methods being tested are autogenerated and well tested, I wanted to demonstrate how to write several kinds of tests. The only method that we really need to test is the findByName() method because that is the only custom method we define. For example, if we were to define the method as findByNam() instead of findByName(), then the method would not work, so it is definitely worth testing.

Conclusion

Spring provides robust support for testing each layer of a Spring MVC application. In this article, we reviewed how to test controllers, using MockMvc; services, using the JUnit Mockito extension; and repositories, using the Spring TestEntityManager. We also reviewed slice testing as a strategy to reduce testing resource utilization and minimize the time required to execute tests. Slice testing is implemented in Spring using the @WebMvcTest and @DataJpaTest annotations. I hope these examples have given you everything you need to feel comfortable writing robust tests for your Spring MVC applications.

A portmanteau of “development” and “operations,” devops emerged as a way of bringing together two previously separate groups responsible for the building and deploying of software.

In the old world, developers (devs) typically wrote code before throwing it over to the system administrators (operations, or ops) to deploy and integrate that code. But as the industry shifted towards agile development and cloud-native computing, many organizations reoriented around modern, cloud-native practices in the pursuit of faster, better releases.

This required a new way to perform these key functions in a more streamlined, efficient, and cohesive way, one where the old frustrations of disconnected dev and ops functions would be eliminated. With two groups working together, developers can rapidly roll out small code enhancements via continuous integration and delivery rather than spending years on “big bang” product releases.

Devops was born at cloud-native companies like Facebook, Netflix, Spotify, and Amazon; but it’s become one of the defining technology industry trends of the past decade, primarily because it bridges so many of the changes that have shaped modern software development.

As agile development and cloud-native computing have become ubiquitous, devops has enabled the entire industry to speed up its software development cycles. Thus, devops has now thoroughly infiltrated the enterprise, especially in organizations that rely on software to run their business, such as banks, airlines, and retailers. And it’s spawned a host of other “ops” practices, some of which we’ll touch on here.[JF1] 

Devops practices

Devops requires a shift in mindset from both sides of the dev and ops divide. Development teams should focus on learning and adopting agile processes, standardizing platforms, and helping drive operational efficiencies. Operations teams must now focus on improving stability and velocity, while also reducing costs by working hand in hand with the developer team.

Broadly speaking, these teams need to all speak a common language and there needs to be a shared goal and understanding of each other’s key skills for devops to thrive.

More specifically, engineers Damon Edwards and John Willis created the CALMS model to bring together what are commonly understood to be the key principles of devops:

• Culture: One that embraces agile methodologies and is open to change, constant improvement, and accountability for the end-to-end quality of software.
• Automation: Automating away toil is a key goal for any devops team.
• Lean: Ensuring the smooth flow of software through key steps as quickly as possible.
• Measurement: You can’t improve what you don’t measure. Devops pushes for a culture of constant measurement and feedback that can be used to improve and pivot as required, on the fly.
• Sharing: Knowledge sharing across an organization is a key tenet of devops.

“Who could go back to the old way of trying to figure out how to get your laptop environment looking the same as the production environment? All these things make it so clear that there’s a better way to work. I think it’s very tough to turn back once you’ve done things like continuous integration, like continuous delivery. Once you’ve experienced it, it’s really tough to go back to the old way of doing things,” Kim told InfoWorld.

What is a devops engineer?

Naturally, the emergence of devops has spawned a whole new set of job titles, most prominent of which is the catch-all devops engineer.

Generally speaking, this role is the natural evolution of the system administrator — but in a world where developers and ops work in close tandem to deliver better software. This person should have a blend of programming and system administrator skills so that he or she can effectively bridge those two sides of the team.

That bridging of the two sides requires strong social skills more than technical. As Kim put it, “one of the most important skills, abilities, traits needed in these pioneering rebellions — using devops to overthrow the ancient powerful order, who are very happy to do things the way they have for 30 to 40 years — are the cross-functional skills to be able to reach across the table to their business counterparts and help solve problems.”

This person, or team of people, will also have to be a born optimizer, tasked with continually improving the speed and quality of software delivery from the team, be that through better practices, removing bottlenecks, or applying automation to smooth out software delivery.

The good news is that these skills are valuable to the enterprise. Salaries for this set of job titles have risen steadily over the years, with 95% of devops practitioners making more than $75,000 a year in salary in 2020 in the United States. In Europe and the UK, where salaries are lower across the board, 71% made more than $50,000 a year in 2020, up from 67% in 2019.

Key devops tools

While devops is at its heart a cultural shift, a set of tools has emerged to help organizations adopt devops practices.

This stack typically includes infrastructure as code, configuration management, collaboration, version control, continuous integration and delivery (CI/CD), deployment automation, testing, and monitoring tools.

Here are some of the tools/categories that are increasingly relevant in 2025, and what is changing:

• CI/CD and delivery automation: Traditional tools like Jenkins remain in many stacks, but newer orchestration tools and CLI-driven or GitOps-centric platforms are growing in importance (e.g. ArgoCD, Flux, Tekton). Also, platforms that integrate more tightly with monitoring, secrets management, drift detection, and policy enforcement are gaining traction.
• Security, compliance, and devsecops tooling: Security tools are increasingly integrated into devops pipelines. Expect to see more use of static analysis (SAST), dynamic testing (DAST), dependency and supply chain scanning (SCA), secret management, and policy as code. The push is toward embedding security earlier and bridging gaps between dev, security, and machine learning teams. (InfoWorld:)
• AI  and automation augmentation: AI-assisted tools are increasingly part of tooling stacks: auto-suggestions in CI/CD, anomaly detection, predictive scaling, intelligent test suite selection, and more. The hope is that these tools will reduce manual interventions and improve reliability. Tools that are “AI ready”—that is, they integrate well with AI or have mature built-in automation or assistance—increasingly stand out from the pack.

Devops challenges

Even as devops becomes more widely adopted, there remain real obstacles that can slow progress or limit impact. One major challenge is the persistent skills gap. The modern devops engineer (or team) is expected to master not just source control, CI/CD, and scripting, but also cloud architecture, infrastructure as code, security best practices, observability, and strong cross-team communication. In many organizations these capabilities are uneven: some teams excel, others lag behind. A 2024 survey showed that while 83% of developers report participating in devops activities, using multiple CI/CD tools was correlated with worse performance — a sign that complexity without deep expertise can backfire.

Toolchain fragmentation and complexity is a related issue. Devops toolchains have sprouted into a sometimes bewildering array of packages and techniques to master: version control, CI build/test, security scanning, artifact management, monitoring, observability, deployment, secret management, and more.

The more tools you have, the more difficult it becomes to integrate them cleanly, manage their versions, ensure compatibility, and avoid duplicated effort. Organizations often get stuck with “tool sprawl” — tools chosen by different teams, legacy systems, or overlapping functionalities — which introduce friction, maintenance burden, and sometimes vulnerabilities.

Finally, although devops has spread far and wide, there is still cultural resistance and alignment. Devops isn’t just about tools and processes; it’s about collaboration, shared responsibility, and continuous feedback. Teams rooted in traditional silos (dev vs ops, or security separate) may resist changes to roles and workflows. Leadership support, communication of shared goals, trust, and allowance for continuous learning are all necessary.

Many CIOs focus too much on tools or implementation first, rather than organizational culture and behaviors; but without addressing culture, even the best tools or processes may not yield the hoped-for velocity, quality, or reliability. Organizations that succeed here tend to have proactive strategies: dedicated training programs, mentorship, internal “guilds,” pairing junior and senior engineers, and making sure leadership supports ongoing learning rather than one-off bootcamps.

Why do devops?

Whoever you ask will tell you that devops is a major culture shift for organizations, so why go through that pain at all?

Devops aims to combine the formerly conflicting aims of developers and system administrators. Under its principles, all software development aims to meet business demands, add functionality, and improve the usability of applications while also ensuring those applications are stable, secure, and reliable. Done right, this improves the velocity and quality of your output, while also improving the lives of those working on these outcomes.

Does devops save money — or add cost?

Devops teams are recognizing that speed and agility are only part of success — unchecked cloud bills and waste undermine long-term sustainability. Waste in devops often comes in the form of “devops debt”— idle cloud capacity, dead code, or false-positive security alerts—which was called a “hidden tax on innovation” in recent Java-environment studies.

 Embedding finops practices can help fight these costs. Teams should shift left on cost: estimating costs when spinning up new environments, resizing instances, and scaling down unused resources before they become runaway expenses.

How to start with devops

There are lots of resources for help getting started with devops, including Kim’s own Devops Handbook, or you can enlist the help of external consultants. But you have to be methodical and focus on your people more than on the tools and technology you will eventually use if you want to ensure lasting buy-in across the business.

A proven route to achieving this is a “land and expand” strategy, where a small group starts by mapping key value streams and identifying a single product team or workload for trialing devops practices. If this team is successful in proving the value of the shift, you will likely start to get interest from other teams and from senior leadership.

If you are at the start of your devops journey, however, make sure you are prepared for the disruption a change like this can have on your organization, and keep your eye on the prize of building better, faster, stronger software.

More on devops:

• Devops debt: The hidden tax on innovation
• 10 big devops mistakes and how to avoid them
• Smarter devops: How to avoid deployment horrors

What is cloud native? Cloud native defined

The term “cloud-native computing” encompasses the modern approach to building and running software applications that exploit the flexibility, scalability, and resilience of cloud computing. The phrase is a catch-all that encompasses not just the specific architecture choices and environments used to build applications for the public cloud, but also the software engineering techniques and philosophies used by cloud developers.

The Cloud Native Computing Foundation (CNCF) is an open source organization that hosts many important cloud-related projects and helps set the tone for the world of cloud development. The CNCF offers its own definition of cloud native:

Cloud native practices empower organizations to develop, build, and deploy workloads in computing environments (public, private, hybrid cloud) to meet their organizational needs at scale in a programmatic and repeatable manner. It is characterized by loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.

Cloud native technologies and architectures typically consist of some combination of containers, service meshes, multi-tenancy, microservices, immutable infrastructure, serverless, and declarative APIs — this list is not exhaustive.

This definition is a good start, but as cloud infrastructure becomes ubiquitous, the cloud native world is beginning to spread behind the core of this definition. We’ll explore that evolution as well, and look into the near future of cloud-native computing.

Cloud native architectural principles

Let’s start by exploring the pillars of cloud-native architecture. Many of these technologies and techniques were considered innovative and even revolutionary when they hit the market over the past few decades, but now have become widely accepted across the software development landscape.

Microservices. One of the huge cultural shifts that made cloud-native computing possible was the move from huge, monolithic applications to microservices: small, loosely coupled, and independently deployable components that work together to form a cloud-native application. These microservices can be scaled across cloud environments, though (as we’ll see in a moment) this makes systems more complex.

Containers and orchestration. In could-native architectures, individual microservices are executed inside containers — lightweight, portable virtual execution environments that can run on a variety of servers and cloud platforms. Containers insulate the developers from having to worry about the underlying machines on which their code will execute. That is, all they have to do is write to the container environment. 

Getting the containers to run properly and communicate with one another is where the complexity of cloud native computing starts to emerge. Initially, containers were created and managed by relatively simple platforms, the most common of which was Docker. But as cloud-native applications got more complex, container orchestration platforms that augmented Docker’s functionality emerged, such as Kubernetes, which allows you to deploy and manage multi-container applications at scale. Kubernetes is critical to cloud native computing as we know it — it’s worth noting that the CNCF was set up as a spinoff of the Linux Foundation on the same day that Kubernetes 1.0 was announced — and adhering to Kubernetes best practices is an important key to cloud native success. 

Open standards and APIs. The fact that containers and cloud platforms are largely defined by open standards and open source technologies is the secret sauce that makes all this modularity and orchestration possible, and standardized and documented APIs offer the means of communication between distributed components of a larger application. In theory, anyway, this standardization means that every component should be able to communicate with other components of an application without knowing about their inner workings, or about the inner workings of the various platform layers on which everything operates.

DevOps, agile methodologies, and infrastructure as code. Because cloud-native applications exist as a series of small, discrete units of functionality, cloud-native teams can build and update them using agile philosophies like DevOps, which promotes rapid, iterative CI/CD development. This enables teams to deliver business value more quickly and more reliably.

The virtualized nature of cloud environments also make them great candidates for infrastructure as code (IaC), a practice in which teams use tools like Terraform, Pulumi, and AWS CloudFormation, to manage infrastructure declaratively and version those declarations just like application code. IaC boosts automation, repeatability, and resilience across environments—all big advantages in the cloud world. IaC also goes hand-in-hand with the concept of immutable infrastructure—the idea that, once deployed, infastructure-level entities like virtual machines, containers, or network appliances don’t change, which makes them easier to manage and secure. IaC stores declarative configuration code in version control, which creates an audit log of any changes.

Foundry

How the cloud-native stack is expanding

As cloud-native development becomes the norm, the cloud-native ecosystem is expanding; the CNCF maintains a graphical representation of what it calls the  cloud native landscape that hammers home to expansive and bewildering variety of products, services, and open source projects that contribute to (and seek to profit from) to cloud-native computing. And there are a number of areas where new and developing tools are complicating the picture sketched out by the pillars we discussed above.   

An expanding Kubernetes ecosystem. Kubernetes is complex, and teams now rely on an entire ecosystem of projects to get the most out of it: Helm for packaging, ArgoCD for GitOps-style deployments, and Kustomize for configuration management. And just as Kubernetes augmented Docker for enterprise-scale deployments. Kubernetes itself has been augmented and expanded by service mesh offerings like Istio and Linkerd, which offer fine-grained traffic control and improved security

Observability needs. The complex and distributed world of cloud-native computing requires in-depth observability to ensure that developers and admins have a handle on what’s happening with their applications. Cloud-native observability uses distributed tracing and aggregated logs to provide deep insight into performance and reliability. Tools like Prometheus, Grafana, Jaeger, and OpenTelemetry support comprehensive, real-time observability across the stack.

Serverless computing.  Serverless computing, particularly in its function-as-a-service guise, offers to strip needed compute resources down to their bare minimum, with functions running on service provider clouds using exactly as much as they need and no more. Because these services can be exposed as endpoints via APIs, they are increasingly integrated into distributed applications, operating side-by-side with functionality provided by containerized microservices. Watch out, though: the big FaaS providers (Amazon, Microsoft, and Google) would love to lock you in to their ecosystems.  

FinOps. Cloud computing was initially billed as a way to cut costs — no need to pay for an in-house data center that you barely use — but in practice it replaces capex with opex, and sometimes you can run up truly shocking cloud service bills if you aren’t careful. Serverless computing is one way to cut down on those costs, but financial operations, or FinOps, is a more systematic discipline that aims to aligns engineering, finance, and product to optimize cloud spending. FinOps best practices make use of those observability tools to best determine what departments and applications are eating up resources.

How cloud-native architecture is adapting to AI workloads

Enterprises deploy larger AI models and make use of more and more real-time inference services. That’s putting demands on cloud-native systems and forcing them to adapt to remain scalable and reliable.

For instance, organizations are re-engineering cloud environments around GPU-accelerated clusters, low-latency networking, and predictable orchestration. These needs align with established cloud-native patterns: containers package AI services consistently, while Kubernetes provides resilient scheduling and horizontal scale for inference workloads that can spike without warning.

Kubernetes itself is changing to better support AI inference, adding hardware-aware scheduling for GPUs, model-specific autoscaling behavior, and deeper observability into inference pipelines. These enhancements make Kubernetes a more natural platform for serving generative AI workloads.

AI’s resource demands are amplifying traditional cloud-native challenges. Observability becomes more complex as inference paths span GPUs, CPUs, vector databases, and distributed storage. FinOps teams contend with cost volatility from training and inference bursts. And security teams must track new risks around model provenance, data access, and supply-chain integrity.

Application frameworks for building distributed cloud-native apps

Microsoft’s Aspire is one of the most visible examples of a shift towards application frameworks to simplify how teams build distributed systems. Opinionated frameworks like Aspire provide structure, observability, and integration out of the box so developer don’t need to stitch together containers, microservices, and orchestration tooling by hand.

Aspire in particular is a prescriptive framework for cloud-native applications, bundling containerized services, environment configuration, health checks, and observability into a unified development model. Aspire provides defaults for service-to-service communication, configuration, and deployment, along with a built-in dashboard for visibility across distributed components.

While Aspire was originally aligned with Microsoft’s .NET platform,Redmond now sees it as having a  polyglot future. This positions Aspire as part of a broader trend: frameworks that help teams build cloud-native, service-oriented systems without being locked into a single language ecosystem. Several other frameworks are gaining traction: Dapr provides a portable runtime that abstracts many of the plumbing tasks in cloud-native distributed applications, and Orleans offers an actor-model-based framework for large-scale systems in the .NET world, and Akka gives JVM teams a mature, reactive toolkit for elastic, resilient services.

Frameworks and tools in the expanding cloud-native ecosystem

While frameworks like Aspire simplify how developers compose and structure distributed applications, most cloud-native systems still depend on a broader ecosystem of platforms and operational tooling. This deeper layer is where much of the complexity—and innovation—of cloud-native computing lives, particularly as Kubernetes continues to serve as the industry’s control plane for modern infrastructure.

Kubernetes provides the core abstractions for deploying and orchestrating containerized workloads at scale. Managed distributions such as Google Kubernetes Engine (GKE), Amazon EKS, Azure AKS, and Red Hat OpenShift build on these primitives with security, lifecycle automation, and enterprise support. Platform vendors are increasingly automating cluster operations—upgrades, scaling, remediation—to reduce the operational burden on engineering teams.

Surrounding Kubernetes is a rapidly expanding ecosystem of complementary frameworks and tools. Service meshes like Istio and Linkerd provide fine-grained traffic management, policy enforcement, and mTLS-based security across microservices. GitOps platforms such as Argo CD and Flux bring declarative, version-controlled deployments to cloud-native environments. Meanwhile, projects like Crossplane turn Kubernetes into a universal control plane for cloud infrastructure, letting teams provision databases, queues, and storage through familiar Kubernetes APIs. These tools illustrate how cloud-native development now spans multiple layers: developer-focused application frameworks like Aspire at the top, and a powerful, evolving Kubernetes ecosystem underneath that keeps modern distributed applications running.

Advantages and challenges for cloud-native development

Cloud native has become so ubiquitous that its advantages are almost taken for granted at this point, but it’s worth reflecting on the beneficial shift the cloud native paradigm represents. Huge, monolithic codebases that saw updates rolled out once every couple of years have been replaced by microservice-based applications that can be improved continuously. Cloud-based deployments, when managed correctly, make better use of compute resources and allow companies to offer their products as SaaS or PaaS services. 

But cloud-native deployments come with a number of challenges, too:

• Complexity and operational overhead: You’ll have noticed by now that many of the cloud-native tools we’ve discussed, like service meshes and observability tools, are needed to deal with the complexity of cloud-native applications and environments. Individual microservices are deceptively simple, but coordinating them all in a distributed environment is a big lift.
• Security: More services executing on more machines, communicating by open APIs, all adds up to a bigger attack surface for hackers. Containers and APIs each have their own special security needs, and a policy engine can be an important tool for imposing a security baseline on a sprawling cloud-native app. DevSecOps, which adds security to DevOps, has become an important cloud-native development practice to try to close these gaps.
• Vendor lock-in: This may come as a surprise, since cloud-native is based on open standards and open source. But there are differences in how the big cloud and serverless providers works, and once you’ve written code with one provider in mind, it can be hard to migrate elsewhere.
• A persistent skills gap: Cloud-native computing and development may have years under its belt at this point, but the number of developers who are truly skilled in this arena is a smaller portion of the workforce than you’d think. Companies face difficult choices in bridging this skills gap, whether that’s bidding up salaries, working to upskill current workers, or allowing remote work so they can cast a wide net. 

Cloud native in the real world

Cloud native computing is often associated with giants like Netflix, Spotify, Uber, and AirBNB, where many of its technologies were pioneered in the early ’10s. But the CNCF’s Case Studies page provides an in-depth look at how cloud native technologies are helping companies. Examples include the following:

• A UK-based payment technology company that can switch between data centers and clouds with zero downtime
• A software company whose product collects and analyzes data from IoT devices — and can scale up as the number of gadgets grows
• A Czech web service company that managed to improve performance while reducing costs by migrating to the cloud

Cloud-native infrastructure’s capability to quickly scale up to large workloads also make it an attractive platform for developing AI/ML applications: another one of those CNCF case studies looks at how IBM uses Kubernetes to train its Watsonx assistant. The big three providers are putting a lot of effort into pitching their platforms as the place for you to develop your own generative AI tools, with offerings like Azure AI Foundry,Google Firebase Studio, and Amazon Bedrock. It seems clear that cloud native technology is ready for what comes next.

Learn more about related cloud-native technologies:

• Platform-as-a-service (PaaS) explained
• What is cloud computing
• Multicloud explained
• Agile methodology explained
• Agile development best practices
• Devops explained
• Devops best practices
• Microservices explained
• Microservices tutorial
• Docker and Linux containers explained
• Kubernetes tutorial
• CI/CD (continuous integration and continuous delivery) explained
• CI/CD best practices

Over the past decade, software development has been shaped by two closely related transformations. One is the rise of devops and continuous integration and continuous delivery (CI/CD), which brought development and operations teams together around automated, incremental software delivery.

The other is the shift from monolithic applications to distributed, cloud-native systems built from microservices and containers, typically managed by orchestration platforms such as Kubernetes.

While Kubernetes and similar platforms simplify many aspects of running distributed applications, operating these systems at scale is still complicated. Configuration sprawl, environment drift, and the need for rapid, reliable change all introduce operational challenges. GitOps emerged as a way to address those challenges by extending familiar devops and CI/CD techniques beyond application code and into infrastructure and system configuration.

At the heart of GitOps is the concept of infrastructure as code (IaC). In a GitOps model, not only application code but also infrastructure definitions, deployment configurations, and operational settings are described in files stored in a version control system. Automated processes continuously compare the running system with those declarations and work to bring the live environment back into alignment when differences appear.

In this approach, the version control repository serves as the system of record for how applications and their supporting infrastructure should look in production. Changes flow through the same review, approval, and automation pipelines that developers already use for software, bringing greater consistency, traceability, and repeatability to cloud-native operations.

At a high level, GitOps refers to a set of operational practices for managing cloud-native systems using declarative configuration, version control, and automated reconciliation. Rather than treating infrastructure and application configuration as mutable runtime state, GitOps treats them as versioned artifacts that move through the same review, testing, and deployment processes as application code.

GitOps defined

The term GitOps was originally coined and popularized by Weaveworks, which helped formalize the approach in the context of Kubernetes operations. While that early work shaped the way GitOps was discussed and implemented, GitOps has since evolved into a broadly adopted, vendor-neutral pattern. Today, it describes a shared set of ideas rather than a specific product or platform.

The defining characteristic of GitOps is its reliance on declarative configuration stored in a version control system. Instead of issuing imperative commands to change live systems, teams describe the desired state of applications and infrastructure in configuration files. Automated agents then continuously compare that declared state with what is actually running and work to reconcile any differences. This pull-based model—where systems converge toward the desired state defined in version control—provides built-in drift detection, repeatability, and a clear audit trail for every change.

Because GitOps centers on configuration files stored in a version control system, familiar software development practices carry over naturally. Changes are proposed through commits, reviewed before being accepted, and tracked over time. Rollbacks are accomplished by reverting to known-good versions, and the history of how a system evolved is preserved alongside the configuration itself.

While the use of Git as the version control system is not strictly required, it has become the default choice because of its ubiquity in modern devops workflows and its strong support for collaboration and change management, so its place in the name has stuck.

What is the CI/CD process?

A complete look at CI/CD is beyond the scope of this article—see the InfoWorld explainer on the subject—but we need to say a few words about CI/CD because it’s at the core of how GitOps works. The continuous integration half of CI/CD is enabled by version control repositories like Git: Developers can make constant small improvements to their codebase, rather than rolling out huge, monolithic new versions every few months or years. The continuous deployment piece is made possible by automated systems called pipelines that build, test, and deploy the new code to production.

Again, we keep talking about code here, and that usually summons up visions of executable code written in a programming language such as C or Java or JavaScript. But in GitOps, the “code” we’re managing is largely made up of configuration files. This isn’t just a minor detail — it’s at the heart of what GitOps does. These config files are, as we’ve said, the “single source of truth” describing what our system should look like. They are declarative rather than instructive. That means that instead of saying “start up ten servers,” the configuration file will simply say, “this system includes ten servers.”

GitOps and Kubernetes

GitOps first took hold in the Kubernetes ecosystem, where declarative configuration and continuous reconciliation are core design principles. As a result, Kubernetes remains the most common and best-understood environment for applying GitOps practices. A typical GitOps-driven update process for a Kubernetes application looks like this:

1. A developer proposes a change by committing updated application code or configuration to a version control repository, usually through a pull request.
2. That change is reviewed and approved, then merged into the main branch.
3. The merge triggers an automated CI/CD pipeline that tests the change, builds new artifacts if needed, and publishes them to a registry.
4. A GitOps controller or similar automated agent detects the updated desired state stored in version control.
5. The controller compares that desired state with the current state of the Kubernetes cluster and applies the necessary changes to bring the cluster back into alignment.

This pull-based reconciliation loop—where the cluster continuously converges toward the desired state defined in version control—is central to how GitOps works in practice. While Kubernetes provides a natural fit for this model, it represents just one canonical use case. The same patterns increasingly apply to infrastructure provisioning, policy enforcement, and multi-cluster operations beyond Kubernetes itself.

GitOps tooling in practice: Argo CD, Flux, and the ecosystem

GitOps is enabled by a set of tools that embody the principles we’ve outlined, with some open-source projects emerging as de facto standards in cloud-native environments.

At the center of the GitOps ecosystem is Argo CD, an open-source controller that continuously monitors a version control repository and ensures that the state of running systems matches the declared desired state. Argo CD is widely used in Kubernetes environments because it directly implements pull-based reconciliation: it compares the desired state stored in Git with the cluster’s actual state and applies changes to correct any drift.

Alongside Argo CD, Flux is another prominent open source GitOps engine. Both Flux and Argo CD help teams adopt GitOps workflows by managing the synchronization loop between code and runtime, but they differ in operational philosophy, integration surfaces, and ecosystem fit.

GitOps tooling often appears as part of broader platforms or integrated stacks rather than as isolated utilities. For example, multicloud and cluster management solutions now routinely include GitOps support, with Argo CD or compatible controllers bundled alongside deployment, policy, and governance capabilities.

In addition to Flux and Argo CD, a range of auxiliary tools contribute to a complete GitOps ecosystem: policy as code engines (e.g., Open Policy Agent), drift detection systems, and infrastructure provisioning tools that mesh with Git-centric workflows.

GitOps, devops, and normalization

GitOps grew out of the same forces that drove devops into mainstream IT practice, and in its early days, GitOps was often discussed as a distinct extension of devops, specifically tailored to managing declarative infrastructure and Kubernetes-centric systems. At the time, GitOps was still relatively new and not yet widely adopted outside cloud-native pioneers.

Over the last several years, however, GitOps practices have become deeply woven into how teams operate modern cloud environments. Rather than being treated as an optional add-on or marketing term, the core ideas of GitOps — using version-controlled, declarative configuration and automated reconciliation loops to continuously align running systems with intended state — are now part of standard operational practice in many Kubernetes-centric shops. In this sense, GitOps has shifted from a buzzword about what might be possible to a baseline pattern for cloud-native operations, much like devops itself did years earlier.

In environments where Kubernetes and declarative systems are the norm, GitOps workflows are the default way teams manage and deploy change. Many organizations now implement these patterns without explicitly calling them “GitOps,” just as few teams today explicitly say they do “CI/CD” even though continuous pipelines are taken for granted. The term has become less prominent in marketing, but its practices are often embedded in pipelines, controllers, and platform tooling.

That normalization shows up in how GitOps workflows are woven into broader operational frameworks. For example, platform engineering teams frequently build internal developer platforms that encapsulate GitOps patterns behind standardized developer APIs, making the pattern invisible to most application teams while still providing the auditability and automation that GitOps promises.

GitOps beyond Kubernetes: infrastructure, policy, and drift

While GitOps first gained traction as a way to manage Kubernetes deployments, its core principles apply broadly to infrastructure and operational concerns beyond any single orchestration platform. GitOps treats desired state as declarative configuration stored in version control and uses automated reconciliation to ensure running systems align with that state. That pattern naturally extends to infrastructure provisioning, policy enforcement, configuration drift detection, and governance workflows across diverse environments.

In modern operational stacks, infrastructure is increasingly defined declaratively, whether through Kubernetes manifests, Terraform modules, or other infrastructure-as-code formats. Storing these declarations in version control enables the same peer-review, auditability, and rollback practices developers already use for application code. Automated tooling then continuously detects when the live infrastructure diverges from the declared state and works to bring it back into alignment, reducing the risk of configuration drift and inadvertent misconfigurations.

Configuration drift — the state where an environment has diverged from what’s declared in version control — remains a major operational headache, especially in complex, dynamic systems. Drift can arise from ad hoc fixes, emergency updates, or manual changes made outside normal pipelines, and it can lead to inconsistencies, outages, and security gaps. By continually checking running systems against the desired state in Git and reconciling deviations automatically, GitOps workflows help teams keep environments predictable and auditable.

Policy enforcement and compliance are another natural extension of GitOps patterns. As organizations adopt declarative practices, policy-as-code engines and drift detection systems can be woven into GitOps pipelines to validate that proposed configurations meet security, compliance, or operational standards before they’re ever applied to running systems. Embedding policy checks into declarative workflows brings consistency to governance while preserving the automation and speed that devops teams expect.

GitOps – beyond Kubernetes

GitOps began as a way to bring devops discipline to Kubernetes operations, but its longer-term impact has been more subtle. In many ways, it’s been absorbed into the fabric of modern cloud-native operations, where declarative configuration, version control, and automated reconciliation are taken for granted. Today, GitOps is less about a specific set of tools or a named practice and more about an operational mindset. By treating infrastructure and configuration as versioned, auditable artifacts and relying on automation to enforce consistency, GitOps helps teams manage complexity at scale. Even as the term itself fades from the spotlight, the practices it introduced continue to shape how distributed systems are built, deployed, and operated.

Resulta difícil encontrar un área de la empresa moderna en la que la inteligencia artificial (IA) no haya encontrado aplicación, y los procesos de selección tecnológica no son una excepción. Una encuesta de MyPerfectResume revela que el 73% de los empleadores afirma utilizar IA en las decisiones de contratación, mientras que el 52% la emplea para decisiones relacionadas con la reestructuración organizativa y la planificación de puestos.

Por otro lado, los candidatos también recurren cada vez más a estas herramientas. Según datos de SAP, el 52% de las personas que buscan empleo actualmente utiliza IA para apoyar su proceso de búsqueda, principalmente para mejorar los materiales de candidatura (85%) y prepararse para entrevistas (73%).

Jasmine Escalera, experta en carreras profesionales de Zety, plataforma especializada en orientación laboral y creación de currículums, considera que “la tecnología puede ayudar a las empresas a ser más eficientes, pero las decisiones de contratación siguen beneficiándose del criterio humano, especialmente cuando la experiencia de un candidato requiere un contexto que los sistemas automatizados de evaluación no siempre son capaces de comprender”.

Está claro que la IA ya forma parte esencial del proceso de contratación. Por ello, las organizaciones deben definir una estrategia clara sobre cómo utilizarla en el futuro, abordando cuestiones como los sesgos en la selección, la transparencia y el equilibrio adecuado entre la intervención humana y la asistencia tecnológica.

Identificar las señales de alerta

La IA promete aportar eficiencia tanto a candidatos como a empleadores, pero una excesiva dependencia de la tecnología puede generar consecuencias no deseadas. Los datos de MyPerfectResume muestran además que el 65% de los encuestados considera que la IA rechaza automáticamente a candidatos antes de que una persona llegue a revisar sus solicitudes, mientras que un 14% afirma que la IA descarta de entrada a más de la mitad de los aspirantes.

Asimismo, el 47% cree que la tecnología ha dejado fuera del proceso a candidatos que, de otro modo, habrían avanzado en la selección. Además, el 51% asegura utilizar IA para identificar perfiles considerados de riesgo, como profesionales percibidos como job hoppers —personas con frecuentes cambios de empleo— o candidatos con interrupciones en su trayectoria laboral.

Según Escalera, marcar a determinados candidatos como riesgosos y descartarlos antes de que un reclutador revise su currículum puede excluir perfiles cuya experiencia profesional cuenta una historia más compleja de lo que un algoritmo está preparado para interpretar. Por ejemplo, quienes regresan al mercado laboral tras un periodo de ausencia pueden aportar capacidades valiosas que no encajan fácilmente en los criterios automatizados de evaluación.

También preocupa que la IA descarte a profesionales que desean cambiar de sector o que cuentan con cualificaciones que no se reflejan exactamente en el lenguaje utilizado en una oferta de empleo, impidiendo que un reclutador humano llegue siquiera a revisar su candidatura.

Laurie Cure, directora ejecutiva de la consultora Innovative Connections, afirma haber observado casos en los que la IA ha eliminado a candidatos altamente cualificados, pero más nerviosos durante las entrevistas, que necesitaban más tiempo del previsto por el sistema para responder a una pregunta. También señala situaciones en las que los aspirantes utilizan un lenguaje diferente al que la IA está programada para detectar, lo que impide que sean recomendados para continuar en el proceso.

Además, ha constatado escenarios en los que la IA utiliza datos históricos para identificar patrones asociados a empleados considerados exitosos, priorizando determinadas universidades, trayectorias profesionales, antigüedad o características similares. Aunque estos elementos no constituyen necesariamente un sesgo en sí mismos, pueden perpetuar la creencia de que existe una correlación directa entre dichos factores y el rendimiento profesional, algo que a menudo no se sostiene.

Por ello, añade Cure, es esencial que las personas sigan formando parte activa de estos procesos, aportando contexto, intuición, matices y la capacidad de detectar potencial en los candidatos, algo que la IA todavía no puede replicar.

Y dice: “Creo que estamos permitiendo que la IA se convierta en el proceso, cuando debería limitarse a apoyarlo para hacer que la contratación sea mejor”.

Priorizar la precisión frente a la velocidad

Para Cure, uno de los principales problemas es que muchas organizaciones han perdido el equilibrio adecuado. En lugar de utilizar la IA como complemento al trabajo humano, la emplean para realizar la mayor parte, o incluso la totalidad, del cribado curricular.

Las empresas que implementan IA únicamente para acelerar determinadas fases del proceso, sin valorar previamente si realmente aportará beneficios, corren el riesgo de introducir sesgos no deseados.

“Esto permite gestionar grandes volúmenes de candidaturas y aporta una mayor consistencia en la aplicación de los criterios de selección, pero probablemente deja fuera a muchos buenos candidatos”, señala, para añadir: “El componente humano debe desempeñar un papel muy activo en la definición de los requisitos de los puestos para evitar que sean excesivamente restrictivos. Las organizaciones deben prestar atención a cómo instruyen a la IA para realizar su trabajo y ser cautelosas al definir los criterios de evaluación y filtrado”.

En última instancia, la IA no es una herramienta que pueda implantarse y olvidarse, ni debería contemplarse únicamente como un mecanismo para ganar eficiencia, ya que muchos procesos continúan beneficiándose —e incluso dependen— del juicio humano.

Por ello, resulta fundamental realizar auditorías periódicas de los sistemas de IA utilizados en contratación y recordar que el uso de estas tecnologías no exime a las organizaciones de sus obligaciones legales y éticas en materia de igualdad de oportunidades laborales. Esto hace que el equilibrio entre intervención humana y automatización sea aún más relevante.

Transparencia y confianza de los candidatos

La irrupción de la IA también ha introducido un factor de desconfianza en los procesos de selección. Los empleadores no siempre tienen claro hasta qué punto los candidatos han recurrido a herramientas de IA, mientras que los aspirantes desconocen en muchos casos cómo se utiliza exactamente esta tecnología durante la contratación.

Los candidatos saben que las empresas están incorporando IA a sus procesos, pero a menudo desconocen el alcance de su utilización y en qué momento pueden esperar interactuar con una persona.

“Esa falta de claridad puede generar escepticismo y frustración, especialmente en un mercado laboral que ya resulta extremadamente competitivo”, explica Escalera. A su juicio, “el objetivo no debería ser convencer a los candidatos de que la IA no se utiliza, sino ayudarles a comprender cómo la tecnología sirve de apoyo a la toma de decisiones, en lugar de sustituir el criterio humano que hay detrás de ellas”.

Como recomendación, Cure propone que las organizaciones comiencen elaborando un mapa completo de su proceso de contratación, identificando cada una de sus fases. Esto permite visualizar con claridad dónde la IA aporta valor y en qué puntos sigue siendo necesaria la intervención humana.

Las empresas pueden acabar dependiendo excesivamente de la IA o, por el contrario, dedicar recursos humanos a tareas que podrían automatizarse y destinarse a actividades de mayor valor añadido.

“Las personas aportan una comprensión más amplia de la trayectoria profesional de un candidato y tienen la capacidad de detectar cuándo alguien posee el potencial necesario para evolucionar dentro de un puesto. También son capaces de interpretar trayectorias profesionales no convencionales y motivaciones personales con mayor precisión que la IA. Por su parte, la IA aporta consistencia, eficiencia, estandarización de criterios y un nivel de objetividad beneficioso para el proceso. Si logramos combinar eficazmente ambos elementos en los puntos adecuados, la contratación sale reforzada, no debilitada”, concluye Cure.