Der Cloud Native Ansatz revolutioniert die Softwareentwicklung und beschreibt die Modernisierung von Applikationen, die „cloud ready“ werden, aber nicht zwingend in die public Cloud müssen. Cloud Native Applikationen nutzen die Skalierung, Elastizität, Resilienz und Flexibilität, die Cloud Technologien ermöglichen. Die Cloud Native Journey gibt dir eine Orientierung, um deine Applikationen Step-by-Step auf ein neues Level zu heben.
#simplifyYourBusiness: Wir teilen unser Wissen zu den Themen Software-Modernisierung und Entwicklung
Welche Probleme löst Cloud Native für dich?
Heutzutage stellt sich bei technologischen Veränderungen häufig nicht mehr die Frage „ob“, sondern „wann“. Cloud Native und Container-Technologien halten gerade Einzug in der gesamten IT-Branche und sind dabei, sich zum Standard zu entwickeln. Unternehmen stehen vor großen Herausforderungen.
Wie sieht deine Cloud Native Journey aus?
Wir haben den Weg der Cloud Native Journey als Agentur in fünf Levels eingeteilt, die du wie Berggipfel erreichen kannst. Diese Berggipfel dienen nicht einem Selbstzweck, sondern sollen deine Applikationen und Prozesse „besser“ machen. Besser kann sich auf unterschiedliche Kategorien beziehen, z.B. Time-To-Market, Skalierbarkeit, Fehlerfreiheit oder Userbility. Mittel um die Ziele zu erreichen sind Automatisierung von Build zu Deployment, Container-Technologie, Monitoring und viele mehr.
In der Regel befindest du dich irgendwo entlang der Levels. Wir als Bergführer helfen dir einerseits bei der Einordnung deiner aktuellen Prozesse und Applikationen, als auch bei der Planung und Begleitung für den nächsten Gipfelanstieg. Wir kennen den Weg und wissen, wo die schwierigen Stellen und Fallstricke sind. Wir packen das richtige Werkzeug (Tools) ein und gehen den Weg gemeinsam mit dir, d.h. wir setzen gemeinsam um.

Die Erfolgsfaktoren für deine Cloud Native Journey
- Klarheit über Ziele
- Messbarkeit herstellen
- Automatisierung
- Modernisierung
Klarheit über Ziele
Cloud Native ist kein Selbstzweck. Nach einer Standortbestimmung kannst du dir leichter über deine Ziele klar werden und wo du besser werden möchtest. Damit lässt sich sinnvoll erarbeiten, wie wir dort hinkommen und wie wir das messen können.

Nur eine Applikation in der Cloud zu betreiben, ist kein lohnendes Ziel. Alleine weil eine Applikation auf Kubernetes läuft, wird sie nicht besser. Unser Ziel ist, dass Applikationen und Prozesse besser werden. Aber was bedeutet “besser”? Es hat viele Kategorien - für die einen ist es Schnelligkeit, für die anderen Fehlerfreiheit, für die Dritten gute Benutzbarkeit oder Skalierbarkeit. Wir arbeiten hier mit Kategorien wie Time to Market, Fehlerquote, Betriebskosten etc. und idealerweise mit quantitativ messbaren Qualitätsmerkmalen. Für die anfängliche Standortbestimmung beschreiben wir für jede Kategorie fünf Qualitätslevel, welche an das Capability Maturity Model Integration angelehnt sind. Je höher das Level, desto besser ist dein Softwareprojekt in der entsprechenden Kategorie.
Für eine Standortbestimmung werden Kategorien gewählt und das Projekt gegen die vorgegebene Levelbeschreibung gestellt. Je nach Tiefe der Analyse bzw. der daran teilnehmenden Stakeholder kann die Menge der Kategorien variieren. Daraus entsteht ein Diagramm, das einen Einblick über die Stärken und Schwächen der Applikationen und Prozesse gibt.
Wir sind überzeugt, dass Applikationen relativ gleichmäßig über mehrere Kategorien hinweg verbessert werden sollen. Aus der Standortbestimmung entsteht daher eine Priorisierung, welche Themen zuerst angegangen werden sollen und wo wir den größten Hebel haben. Für diese erarbeiten wir Vorschläge und helfen bei der Umsetzung. All das ergibt deine individuelle Landkarte für deine Cloud Native Journey mit Standort (Startpunkt), Ziele (Berggipfel) sowie Maßnahmen und Werkzeuge (Weg und Ausrüstung).
Messbarkeit herstellen
Bevor es losgeht, müssen wir uns im Klaren sein, was wir messen und wie wir die Messbarkeit entlang unserer Journey sicherstellen können. Haben wir unser GPS mit, damit wir uns nicht verlaufen?

Je nach Zielstellung, wo wir besser werden wollen, definieren wir Metriken entlang unserer Kategorien, z.B. Antwortzeit von Anwendungen, Dauer Testzyklus oder Anzahl gemeldeter Fehler. Diese Daten können beispielsweise aus Ticketsystemen kommen, aus der CI/CD Pipeline oder aus Produktionslogs. Mit den passenden Monitoring- und Logging-Tools werden Observability beim Applikationsbetrieb sichergestellt und wertvolle Insights für unsere Journey (frühzeitige Problemerkennung, Performanceüberwachung), aber auch Ableitungen für den Fachbereich generiert. Sicherheit ist beim Bergsteigen, wie bei der Cloud Native Journey ein zentraler Faktor. Deswegen definieren wir Sicherheitsmetriken, um die Effektivität von Sicherheitsvorkehrungen und die Einhaltung von Compliance-Richtlinien zu überwachen.
Regelmäßige Performance- und Lasttests stellen sicher, dass die Anwendungen unter Spitzenlast gut skalieren und performen. Die Ergebnisse dieser Tests sind wichtige Messgrößen für die Leistungsfähigkeit der Cloud Native Umgebung. Mit Kosteneffizienzmetriken behalten wir die Kosten im Blick. Wir achten darauf, dass die Cloud-Ressourcen effizient genutzt werden und die Gesamtkosten der Journey im Rahmen bleiben. Regelmäßig bewerten wir die Zielstellung mit den festgelegten Metriken. Bei Bedarf werden diese angepasst, um sicherzustellen, dass wir uns weiterhin am richtigen Pfad bewegen.
Automatisierung
Wesentlicher Erfolgsfaktor beim Thema Cloud Native ist die Automatisierung unserer Build- und Deploymentprozesse. Wir steigern damit unseren Fitnessgrad und packen die richtige Ausrüstung ein.

Grundsätzlich sind Geparden große Fans davon, manuell ausgeführte Schritte zu automatisieren. Einerseits führen wiederholt manuelle Tätigkeiten zu einer höheren Fehleranfälligkeit. Andererseits bleibt durch Automatisierung mehr Zeit für spannende und neue Aufgaben. Wichtig ist, dass man bei der Automatisierung weiß, welche Tools einem zur Verfügung stehen und wofür man sie am besten einsetzt, damit das beste Werkzeug für jede Aufgabe gewählt werden kann und man den Weg möglichst zielgerichtet und kräftesparend bewältigen kann. Automatisierung ist hier essentiell, um den Entwicklungsprozess zu beschleunigen und die Anwendungsentwicklung in kurzen Intervallen zu ermöglichen.
Automatisierte Build-, Test- und Bereitstellungsprozesse minimieren manuelle Eingriffe, reduzieren die Fehlerquote und verkürzen die Zeit bis zur Markteinführung (Time to Market). Ziel ist es zudem die Feedbackloops zu verkürzen, um schneller zu lernen. Automatisierung stellt nicht nur Transparenz entlang des Prozesses sicher, sondern wirkt auch direkt als Antwort auf Fachkräftemangel und personengebundenes Fachwissen.
Modernisierung
"Lift and Shift" in die Cloud hat nur begrenzten Nutzen und häufig steht schon am Weg zur Cloud die Modernisierung von bestehenden Applikationen als wichtige Hausaufgabe an.

So wie wir beim Bergsteigen mit unseren aktuellen Ressourcen, unserem Körper und den Rahmenbedingungen wie Wetter etc. arbeiten müssen, findet auch unsere Reise entlang der Cloud Native Journey basierend auf bestehenden Applikationen und Prozessen statt. Wir können uns dabei nicht nur auf neue Cloud Native Anwendungen fokussieren, sondern sehen gerade bei der Modernisierung von bestehenden Applikationen einen wesentlichen Hebel. Mit modernen Architekturen und der Zerstückelung von großen Monolithen in kleinere Applikationen (bis hin zu Microservices) erhöhen wir Geschwindigkeit und Skalierbarkeit.
Zudem gilt es, Luft und Ressourcen freizumachen, um den kraftvollen Aufstieg auf den nächsten Gipfel zu ermöglichen. Microservices und Modularität erhöhen die Unabhängigkeit der Entwicklungsteams und die Entwicklungsgeschwindigkeit. Modernisierte Applikationen können leichter an aktuelle Anforderungen angepasst werden und reduzieren z. B. Sicherheitsrisiken oder das Risiko, dass Probleme vom Hersteller nicht mehr supportet werden. Damit bleiben wir schlank, agil und wendig und verhindern, dass Applikationen verrosten.
Starte jetzt deine
Cloud Native Journey!
Melde dich für einen Austausch mit unseren Bergführer:innen
Diese Kunden sind erfolgreich mit uns

Keycloak.X mit Auto-Update Service für das ORF Presseportal
Gepardec bringt die neueste Keycloak Version innerhalb von 3 Wochen auf OpenShift in den Produktiveinsatz und aktualisiert Keycloak ab sofort laufend mit ihrem Auto-Update Service.
So haben wir das geschafft
SV Batch: Erfolgreiches JBoss EAP 8 Upgrade
Gepardec upgraded das interne Framework eines österreichischen Dienstleisters in der Sozialversicherung zur Batchverarbeitung auf EAP 8. Innerhalb weniger Wochen wird die Software, bestehend aus ca. 10.000 Line of Code, auf die neueste JBoss und Java 17 aktualisiert.
So haben wir das geschafft
Automatisches Deployment von JBoss Applikationen
Die Anzahl der Deployments auf verschiedenen Stages (Entwicklung, Test, Produktion) nimmt ständig zu und unterschiedliche Zuständigkeiten sowie manuelle Tätigkeiten führen zu uneinheitlichen Serverlandschaften. Um die Deploymentprozesse zu vereinheitlichen und zu automatisieren wurde das Projekt ADEBA ins Leben gerufen und gemeinsam mit Gepardec umgesetzt.
So haben wir das geschafft
Ein neues Zeitalter für die Österreichische Gesundheitskasse
Gepardec bringt die zentrale Fachanwendung der Österreichischen Gesundheitskasse (ÖGK) in ein neues Zeitalter. Eine evolutionäre Architektur, User Experience Design und eine leistungsfähige CI/CD-Infrastruktur ermöglichen der ÖGK eine zukunftssichere Softwareentwicklung.
So haben wir das geschafftEiner der größten Red Hat SSO-Cluster weltweit
APA-Tech hat im Auftrag des ORF den Single Sign-On Dienst "Media Key" mit uns entwickelt. Dazu haben wir mit Red Hat SSO (auf von Basis Keycloak) einen der größten und schnellsten Cluster dieser Art aufgesetzt und customized.
So haben wir das geschafftNeues aus unserem Revier
Bei der Erstellung von Software-Anwendungen ist es fast unabdingbar, dass man auf bestehende 3rd-Party-Libraries zurückgreifen muss. Selbst triviale Web-Anwendungen weisen mittlerweile Abhängigkeiten auf Libraries im mittleren zweistelligen Bereich auf.
Doch das Einbinden von externen Libraries bringt auch Risiken mit sich, da durch deren Nutzung unbeabsichtigt Sicherheitslücken in die eigene Anwendung integriert werden können.
Man muss nicht weit in die Vergangenheit blicken, um Beispiele für Anwendungen und Unternehmen zu finden, die von solchen Problemen betroffen waren (z.B. Equifax 2017, Log4J 2021).
Vorfälle wie diese haben dazu geführt, dass Software-Hersteller ein größeres Augenmerk auf die verwendeten Software-Dependencies und die Software-Supply-Chain ihrer Applikationen richten.


{Wegen Inventur geschlossen?!?}
Bei der Erstellung von Software-Anwendungen ist es fast unabdingbar, dass man auf bestehende 3rd-Party-Libraries zurückgreifen muss. Selbst triviale Web-Anwendungen weisen mittlerweile Abhängigkeiten auf Libraries im mittleren zweistelligen Bereich auf.
Doch das Einbinden von externen Libraries bringt auch Risiken mit sich, da durch deren Nutzung unbeabsichtigt Sicherheitslücken in die eigene Anwendung integriert werden können.
Man muss nicht weit in die Vergangenheit blicken, um Beispiele für Anwendungen und Unternehmen zu finden, die von solchen Problemen betroffen waren (z.B. Equifax 2017, Log4J 2021).
Vorfälle wie diese haben dazu geführt, dass Software-Hersteller ein größeres Augenmerk auf die verwendeten Software-Dependencies und die Software-Supply-Chain ihrer Applikationen richten.
Rückblick auf unser ViennaDevOps Meetup vom 28.01.25.
Erstes Meetup im Jahr – und wir sind direkt mit voller Power gestartet! Dieses Mal durften wir das ViennaDevOps Meetup in unserer Wiener Steppe hosten. Über 60 Anmeldungen zeigen: Die Community ist hungrig auf spannende DevOps-Insights.


Vienna DevOps Meetup
Rückblick auf unser ViennaDevOps Meetup vom 28.01.25.
Erstes Meetup im Jahr – und wir sind direkt mit voller Power gestartet! Dieses Mal durften wir das ViennaDevOps Meetup in unserer Wiener Steppe hosten. Über 60 Anmeldungen zeigen: Die Community ist hungrig auf spannende DevOps-Insights.
Mit neuen Anforderungen wie NIS2, dem DORA (Digital Operational Resilience Act) und dem Cyber Resilience Act (CRA) stehen IT-Führungskräfte vor einer wachsenden Herausforderung: Software muss kontinuierlich aktualisiert werden, um sicher und compliant zu bleiben. Doch während Updates in der IT-Infrastruktur längst Standard sind, tun sich viele Entwicklungsteams schwer damit, Updates nahtlos in ihren Software Development Lifecycle (SDLC) zu integrieren.
Warum ist das so? Und wie kannst du als CTO, IT-Leiter:in oder Software-Architekt:in sicherstellen, dass deine Software nicht nur up-to-date bleibt, sondern auch langfristig effizient weiterentwickelt werden kann?
In diesem Beitrag zeigen wir, warum kontinuierliche Updates entscheidend sind, welche Herausforderungen es gibt und welche Lösungen helfen, den Update-Prozess zu automatisieren.


Update or Die: Wie IT-Führungskräfte ihre Software sicher und compliant halten
Mit neuen Anforderungen wie NIS2, dem DORA (Digital Operational Resilience Act) und dem Cyber Resilience Act (CRA) stehen IT-Führungskräfte vor einer wachsenden Herausforderung: Software muss kontinuierlich aktualisiert werden, um sicher und compliant zu bleiben. Doch während Updates in der IT-Infrastruktur längst Standard sind, tun sich viele Entwicklungsteams schwer damit, Updates nahtlos in ihren Software Development Lifecycle (SDLC) zu integrieren.
Warum ist das so? Und wie kannst du als CTO, IT-Leiter:in oder Software-Architekt:in sicherstellen, dass deine Software nicht nur up-to-date bleibt, sondern auch langfristig effizient weiterentwickelt werden kann?
In diesem Beitrag zeigen wir, warum kontinuierliche Updates entscheidend sind, welche Herausforderungen es gibt und welche Lösungen helfen, den Update-Prozess zu automatisieren.