Die häufigste Falle bei Cloud-Migrationen: Man nimmt die bestehenden Server und schiebt sie 1:1 in die Cloud. Das Ergebnis sind dieselben Probleme wie vorher — nur mit einer höheren Rechnung.

Eine erfolgreiche Migration zu AWS erfordert eine klare Strategie, die vor der ersten technischen Entscheidung steht.

Die 6 Rs der Cloud Migration

Amazon definiert sechs Migrationsstrategien, die sogenannten 6 Rs:

1. Rehost (Lift & Shift)

Anwendungen werden unverändert in die Cloud verschoben. Schnell, aber ohne Cloud-Vorteile.
– Wann sinnvoll: Zeitdruck, Rechenzentrum-Exit, erste Migrationserfahrung sammeln

2. Replatform (Lift & Optimize)

Kleine Anpassungen für Cloud-Dienste: z.B. eigene Datenbank durch Amazon RDS ersetzen.
– Wann sinnvoll: Quick Wins ohne großen Umbau

3. Refactor (Re-Architect)

Anwendungen werden für die Cloud neu gestaltet — Microservices, Serverless, Managed Services.
– Wann sinnvoll: Langfristiger Betrieb, Skalierbarkeit, Kostenoptimierung

4. Repurchase

Ablösung durch SaaS-Lösung (z.B. eigener Mailserver → Amazon WorkMail).

5. Retire

Anwendungen, die nicht mehr benötigt werden, abschalten.

6. Retain

Anwendungen, die vorerst on-premises bleiben — z.B. aus regulatorischen Gründen.

Der Elefant im Raum: Kosten

AWS-Kosten sind der häufigste Grund für Enttäuschung nach der Migration. Typische Kostentreiber:

– Überdimensionierte Instanzen: EC2 m5.xlarge für eine Anwendung, die auf t3.small läuft
– Fehlende Auto-Scaling-Strategie: 24/7 maximale Kapazität statt bedarfsgerechter Skalierung
– Vergessene Ressourcen: EBS-Volumes, Elastic IPs, ungenutzte Load Balancer
– Datenübertragung: Egress-Kosten werden regelmäßig unterschätzt

Empfehlung: Beginnen Sie mit einem AWS Well-Architected Review und nutzen Sie den AWS Cost Explorer ab Tag 1.

Praxis-Checkliste für den Start

1. Application Portfolio Assessment: Welche Anwendungen haben Sie? Welche Abhängigkeiten bestehen?
2. Strategie pro Anwendung: Nicht alles muss refactored werden — die richtige R-Strategie pro Workload wählen
3. Landing Zone einrichten: Multi-Account-Strategie, Netzwerk, IAM, Logging — bevor die erste Anwendung migriert wird
4. Pilot-Workload: Eine unkritische Anwendung als Pilotprojekt migrieren, Erfahrungen sammeln
5. FinOps von Anfang an: Kostenmonitoring und Budgets einrichten

Typische AWS-Services für Java-Anwendungen

Fazit

Cloud-Migration ist ein Organisationsprojekt, kein reines IT-Projekt. Die Technik ist das Einfachste daran — die Herausforderung liegt in Strategie, Kostensteuerung und Organisationsveränderung.

CGS IT Solutions unterstützt Sie bei der Planung und Durchführung Ihrer AWS-Migration — von der Strategie bis zum produktiven Betrieb. Kontaktieren Sie uns für ein unverbindliches Erstgespräch.

Der Beitrag AWS Cloud Migration: Strategie vor Technik erschien zuerst auf CGS IT Solutions GmbH.

Hibernate und JPA haben einen schlechten Ruf in Sachen Performance. Aber in den meisten Fällen liegt das Problem nicht beim Framework, sondern bei typischen Anwendungsfehlern, die sich leicht vermeiden lassen.

Hier sind die fünf häufigsten Performance-Killer — und ihre Lösung.

1. Das N+1 Query Problem

Der Klassiker. Sie laden eine Liste von Bestellungen, und für jede Bestellung wird eine separate Query für den Kunden ausgeführt.

Das Problem:

// 1 Query für Bestellungen + N Queries für Kunden
List<Bestellung> bestellungen = em.createQuery(
    "SELECT b FROM Bestellung b", Bestellung.class)
    .getResultList();

for (Bestellung b : bestellungen) {
    System.out.println(b.getKunde().getName()); // Lazy Load!
}

Die Lösung: JOIN FETCH

List<Bestellung> bestellungen = em.createQuery(
    "SELECT b FROM Bestellung b JOIN FETCH b.kunde",
    Bestellung.class)
    .getResultList();

Eine Query statt N+1. Bei 1.000 Bestellungen ist das der Unterschied zwischen 1 und 1.001 Datenbankaufrufen.

2. Eager Loading als Default

@ManyToOne ist standardmäßig EAGER — das bedeutet, jede Relation wird sofort mitgeladen, auch wenn Sie die Daten gar nicht brauchen.

Die Lösung:

@ManyToOne(fetch = FetchType.LAZY)
private Kunde kunde;

Faustregel: Setzen Sie alles auf LAZY und laden Sie gezielt per JOIN FETCH oder EntityGraph, wenn Sie die Daten brauchen.

3. Fehlende Projektionen

Sie brauchen nur Name und E-Mail, laden aber die komplette Entity mit 30 Feldern, LOBs und Relationen.

Das Problem:

// Lädt ALLES — auch Felder, die Sie nicht brauchen
List<Kunde> kunden = em.createQuery(
    "SELECT k FROM Kunde k", Kunde.class)
    .getResultList();

Die Lösung: DTO-Projektionen

record KundeDto(String name, String email) {}

List<KundeDto> kunden = em.createQuery(
    "SELECT new at.cgs.dto.KundeDto(k.name, k.email) FROM Kunde k",
    KundeDto.class)
    .getResultList();

Weniger Daten über die Leitung, kein Dirty Checking, kein Managed State — deutlich schneller.

4. Batch-Operationen ohne Batching

1.000 Entities einzeln persistieren erzeugt 1.000 INSERT-Statements.

Die Lösung:

# application.properties (Quarkus/Spring)
hibernate.jdbc.batch_size=25
hibernate.order_inserts=true
hibernate.order_updates=true

for (int i = 0; i < entities.size(); i++) {
    em.persist(entities.get(i));
    if (i % 25 == 0) {
        em.flush();
        em.clear(); // First-Level Cache leeren!
    }
}

5. Kein Query-Monitoring

Der gefährlichste Fehler: Sie wissen gar nicht, welche Queries Hibernate generiert.

Aktivieren Sie SQL-Logging in der Entwicklung:

# Quarkus
quarkus.hibernate-orm.log.sql=true

# Spring Boot
spring.jpa.show-sql=true
logging.level.org.hibernate.SQL=DEBUG
logging.level.org.hibernate.type.descriptor.sql=TRACE

Für Produktion: Nutzen Sie Hibernate Statistics oder ein APM-Tool (z.B. OpenTelemetry) um langsame Queries zu identifizieren.

Bonus: EntityGraph statt JOIN FETCH

Für flexible Ladingstrategien ohne Query-Anpassung:

@NamedEntityGraph(
    name = "Bestellung.mitKunde",
    attributeNodes = @NamedAttributeNode("kunde")
)
@Entity
public class Bestellung { ... }

// Verwendung
EntityGraph<?> graph = em.getEntityGraph("Bestellung.mitKunde");
List<Bestellung> result = em.createQuery("SELECT b FROM Bestellung b")
    .setHint("jakarta.persistence.fetchgraph", graph)
    .getResultList();

Fazit

JPA und Hibernate sind mächtige Werkzeuge — aber sie verzeihen Unwissenheit nicht. Die gute Nachricht: Die fünf häufigsten Fehler sind leicht zu erkennen und zu beheben. Aktivieren Sie SQL-Logging, prüfen Sie Ihre Fetch-Strategien, und nutzen Sie Projektionen wo möglich.

In unseren Training-Angeboten behandeln wir JPA-Performance als festen Bestandteil der Java-Entwickler-Ausbildung.

Der Beitrag JPA & Hibernate: 5 Performance-Fehler, die fast jedes Projekt macht erschien zuerst auf CGS IT Solutions GmbH.

Microservices sind seit Jahren der Architektur-Trend schlechthin. Und ja — für die richtige Problemstellung sind sie hervorragend. Aber die Realität zeigt: Viele Teams führen Microservices ein, ohne die Voraussetzungen dafür zu haben.

Das Ergebnis ist kein verteiltes System — sondern ein verteilter Monolith: alle Nachteile beider Welten, keine der Vorteile.

Wann Microservices Sinn machen

Microservices lösen organisatorische Probleme, nicht primär technische:

– Mehrere Teams arbeiten unabhängig an verschiedenen Geschäftsbereichen
– Unterschiedliche Release-Zyklen pro Domäne sind notwendig
– Unterschiedliche Skalierungsanforderungen pro Service
– Technologievielfalt ist gewünscht (ein Service in Java, ein anderer in Python)

Wenn Ihr Team aus 3–5 Entwicklern besteht und eine Anwendung betreut: Microservices sind sehr wahrscheinlich der falsche Ansatz.

Der gut strukturierte Monolith

Ein Monolith ist kein Anti-Pattern. Ein schlecht strukturierter Monolith ist das Problem. Die Lösung ist nicht automatisch eine Microservice-Architektur, sondern oft ein Modularer Monolith:

– Klare Modul-Grenzen mit definierten APIs
– Eigene Datenhaltung pro Modul (kein Shared Database)
– Module können unabhängig getestet werden
– Spätere Extraktion in Services ist möglich, wenn nötig

Das Beste aus beiden Welten

Monolith mit klaren Modulen
┌──────────────────────────────────┐
│  ┌──────────┐  ┌──────────┐     │
│  │  Bestell- │  │  Kunden- │     │
│  │  wesen    │  │  verw.   │     │
│  │           │  │          │     │
│  └────┬──────┘  └────┬─────┘    │
│       │  definierte   │          │
│       │  Schnittstelle│          │
│  ┌────┴──────┐  ┌────┴─────┐    │
│  │  Lager    │  │  Billing │    │
│  └───────────┘  └──────────┘    │
│                 Ein Deployment   │
└──────────────────────────────────┘

Die Kosten von Microservices

Was selten erwähnt wird — Microservices erfordern erhebliche Infrastruktur:

Wenn Sie diese Infrastruktur nicht haben oder nicht betreiben können, werden Microservices zum Bremsklotz statt zum Beschleuniger.

Entscheidungshilfe

Starten Sie mit einem Monolith, wenn:
– Ein Team, ein Produkt
– Domäne noch nicht vollständig verstanden
– Schnelle Time-to-Market wichtiger als Skalierbarkeit

Wechseln Sie zu Microservices, wenn:
– Team-Autonomie das Hauptziel ist
– Einzelne Domänen unabhängig skaliert werden müssen
– Sie die Infrastruktur betreiben können (oder wollen)

Fazit

Die beste Architektur ist die, die Ihr Team produktiv macht. Für die meisten mittelständischen Unternehmen ist ein modularer Monolith der pragmatischere Weg — mit der Option, gezielt Services zu extrahieren, wenn der Bedarf entsteht.

Bei CGS IT Solutions beraten wir technologieneutral: Wir empfehlen die Architektur, die zu Ihrer Organisation passt — nicht die, die gerade im Trend liegt. Mehr dazu unter Software Architektur.

Der Beitrag Microservices oder Monolith? Die ehrliche Antwort erschien zuerst auf CGS IT Solutions GmbH.

Genau dafür haben wir den CGS Fragenkatalog entwickelt: ein kostenloses, browser-basiertes Quiz-Tool mit über 540 Fragen zu Java und Software Engineering.

Was steckt drin?

Der Fragenkatalog besteht aus zwei Teilen:

• Java 25 Fragenkatalog — 24 Kapitel, 428 Fragen: Von Grundlagen (JVM, Datentypen, Kontrollstrukturen) über Collections, Streams und Generics bis hin zu modernen Features wie Virtual Threads, Pattern Matching und Sealed Classes.
• Software Engineering Fragenkatalog — 12 Kapitel, 115 Fragen: Projektmanagement, Vorgehensmodelle, Qualitätssicherung, Versionskontrolle, UML, Datenbanken und mehr.

Für wen ist das gedacht?

• Java-Entwickler:innen, die ihr Wissen testen und Lücken finden wollen
• Studierende, die sich auf Prüfungen vorbereiten
• Workshop-Teilnehmer:innen unserer Quarkus- und Java-Trainings
• Trainer:innen und Lehrende, die ein fertiges Prüfungstool brauchen

Features

• Sofort-Auswertung — Jede Antwort wird direkt geprüft, mit Erklärung bei falscher Antwort
• Schwierigkeitsgrade — Easy, Medium und Advanced, filterbar
• Fortschritt wird gespeichert — Dank Browser-Speicher geht nichts verloren
• Dark/Light Mode — Augenschonend zu jeder Tageszeit
• Syntax-Highlighting — Java-Code in den Fragen wird korrekt formatiert
• Scoreboard — Live-Übersicht über richtige/falsche Antworten, mit Sprung zu Fehlern
• 100% im Browser — Kein Login, kein Server, keine Installation nötig

Jetzt ausprobieren

Der Fragenkatalog ist kostenlos verfügbar unter quiz.cgs.at — einfach öffnen und loslegen. Kein Account, keine Registrierung.

Sie möchten den Fragenkatalog in Ihrem Unternehmen oder Ihrer Lehrveranstaltung einsetzen? Wir bieten auch maßgeschneiderte Versionen mit eigenen Fragen und Auswertung. Kontaktieren Sie uns für ein individuelles Angebot.

Der Beitrag CGS Fragenkatalog: 540+ Quizfragen zu Java und Software Engineering erschien zuerst auf CGS IT Solutions GmbH.

Java 21 ist nicht einfach ein weiteres Update — es ist das umfangreichste LTS-Release seit Java 11. Mit Virtual Threads, ausgereiftem Pattern Matching und Records wird Java zu einer deutlich moderneren Sprache. Hier sind die Features, die im Projektalltag den größten Unterschied machen.

1. Virtual Threads (Project Loom)

Das wahrscheinlich wichtigste Feature: Leichtgewichtige Threads, die von der JVM verwaltet werden.

Vorher: Platform Threads

// Jeder Thread = ein OS-Thread (~1 MB Stack)
// Bei 10.000 gleichzeitigen Requests: 10 GB RAM nur für Threads
ExecutorService executor = Executors.newFixedThreadPool(200);

Nachher: Virtual Threads

// Millionen gleichzeitiger Threads möglich
ExecutorService executor = Executors.newVirtualThreadPerTaskExecutor();

// Oder direkt
Thread.startVirtualThread(() -> {
    var result = httpClient.send(request, BodyHandlers.ofString());
    // Blocking ist OK — der Virtual Thread wird geparkt, nicht der OS-Thread
});

Wann einsetzen: Bei I/O-lastigen Anwendungen (REST-APIs, Datenbankzugriffe, HTTP-Clients). Nicht relevant für CPU-intensive Berechnungen.

Quarkus und Spring Boot unterstützen Virtual Threads bereits — oft reicht eine Konfigurationsänderung.

2. Pattern Matching for switch

Typprüfungen und Casts in einem Schritt — deutlich lesbarer als verschachtelte instanceof-Ketten.

Vorher:

if (shape instanceof Circle c) {
    return c.radius()  c.radius()  Math.PI;
} else if (shape instanceof Rectangle r) {
    return r.width() * r.height();
} else {
    throw new IllegalArgumentException("Unknown shape");
}

Nachher:

return switch (shape) {
    case Circle c    -> c.radius()  c.radius()  Math.PI;
    case Rectangle r -> r.width() * r.height();
    default          -> throw new IllegalArgumentException("Unknown shape");
};

In Kombination mit Sealed Classes prüft der Compiler Vollständigkeit — kein default nötig:

sealed interface Shape permits Circle, Rectangle {}
record Circle(double radius) implements Shape {}
record Rectangle(double width, double height) implements Shape {}

// Compiler weiß: alle Fälle abgedeckt
double area = switch (shape) {
    case Circle c    -> c.radius()  c.radius()  Math.PI;
    case Rectangle r -> r.width() * r.height();
};

3. Records für DTOs und Value Objects

Records eliminieren Boilerplate für unveränderliche Datenobjekte:

// Statt 50 Zeilen mit Konstruktor, Getter, equals, hashCode, toString:
record KundeDto(String name, String email, LocalDate registriert) {}

// Verwendung
var kunde = new KundeDto("Max Mustermann", "max@example.com", LocalDate.now());
System.out.println(kunde.name()); // Accessor ohne "get"

Ideal für: JPA-Projektionen, REST-Request/Response-Objekte, Event-Payloads.

4. Sequenced Collections

Endlich eine einheitliche API für den Zugriff auf erstes und letztes Element:

// Vorher: Inkonsistent
list.get(0);                    // List
set.iterator().next();          // SortedSet
deque.getFirst();               // Deque

// Nachher: Einheitlich
collection.getFirst();
collection.getLast();
collection.reversed();

5. String Templates (Preview)

Interpolation direkt in Java — kein String.format oder +-Verkettung mehr:

// Preview in Java 21, stabil erwartet in Java 23+
String html = STR."""
    <h1>\{kunde.name()}</h1>
    <p>Registriert seit \{kunde.registriert()}</p>
    """;

Migration von Java 11/17 auf 21

Die Migration ist in den meisten Fällen unkompliziert:

1. Build-Tool aktualisieren: Maven Compiler Plugin auf Java 21
2. Dependencies prüfen: Die meisten Libraries unterstützen Java 21
3. Deprecated APIs ersetzen: SecurityManager ist deprecated
4. Schrittweise Features einführen: Records und Pattern Matching zuerst, Virtual Threads nach Lasttests

<properties>
    <maven.compiler.source>21</maven.compiler.source>
    <maven.compiler.target>21</maven.compiler.target>
</properties>

Fazit

Java 21 macht die Sprache kompakter, ausdrucksstärker und leistungsfähiger. Virtual Threads allein rechtfertigen die Migration — sie beseitigen das größte Skalierungsproblem von Java-Anwendungen ohne Code-Änderungen.

Wenn Sie noch auf Java 11 oder 17 sind: Die Migration auf 21 lohnt sich. In unseren Schulungen zeigen wir, wie Sie die neuen Features praxisnah in bestehende Projekte integrieren.

Der Beitrag Java 21 in der Praxis: Die Features, die Ihren Code verändern erschien zuerst auf CGS IT Solutions GmbH.

Java-Microservices galten lange als ressourcenhungrig: langsame Startzeiten, hoher Speicherverbrauch, schwerfällige Application Server. Quarkus ändert das grundlegend.

Als Kubernetes-natives Java-Framework kombiniert Quarkus das Beste aus dem Java-Enterprise-Ökosystem (CDI, JPA, JAX-RS) mit einer Build-Time-Optimierung, die Startzeiten im Millisekundenbereich und minimalen Speicherverbrauch ermöglicht.

Die entscheidenden Vorteile

1. Build-Time statt Runtime

Klassische Java-Frameworks wie Spring erledigen viel Arbeit beim Start: Classpath-Scanning, Reflection, Proxy-Generierung. Quarkus verlagert das alles in den Build-Prozess. Das Ergebnis:

– Startzeit: ~0,5 Sekunden (JVM) bzw. ~15 ms (Native)
– Speicher: ~70 MB (JVM) vs. ~300 MB bei klassischen Frameworks
– Ideal für Serverless und Auto-Scaling-Szenarien

2. Vertraute Standards

Quarkus setzt auf bewährte Java-Standards — keine neue API zu lernen:

– CDI für Dependency Injection
– JAX-RS (RESTEasy) für REST-Endpoints
– JPA (Hibernate ORM) mit Panache für vereinfachten Datenzugriff
– MicroProfile für Health, Metrics, Config, Fault Tolerance

3. Developer Experience

Der Entwicklungsalltag mit Quarkus fühlt sich modern an:

– Live Reload: Code ändern, Browser refreshen — fertig
– Dev Services: Testcontainers starten automatisch (PostgreSQL, Kafka, Redis)
– Unified Config: Eine application.properties für alles

Quickstart: REST-Service in 5 Minuten

# Projekt generieren
mvn io.quarkus.platform:quarkus-maven-plugin:create \
  -DprojectGroupId=at.cgs \
  -DprojectArtifactId=demo-service \
  -Dextensions="resteasy-reactive-jackson,hibernate-orm-panache,jdbc-postgresql"

cd demo-service
./mvnw quarkus:dev

Damit haben Sie einen laufenden REST-Service mit Hot-Reload, Dev-UI unter localhost:8080/q/dev/ und automatischer PostgreSQL-Testinstanz.

Wann Quarkus die richtige Wahl ist

Quarkus eignet sich besonders für:

– Neue Microservices in containerisierten Umgebungen (Kubernetes, OpenShift)
– Serverless Functions (AWS Lambda, Azure Functions)
– Event-Driven Architectures mit Kafka oder AMQP
– Teams mit Java-EE-Erfahrung, die ohne Umlernen modern entwickeln wollen

Weniger geeignet ist es für monolithische Legacy-Anwendungen, die bereits auf Spring Boot aufgebaut sind — hier ist eine Migration selten wirtschaftlich sinnvoll.

Fazit

Quarkus ist kein Hype, sondern eine technisch fundierte Antwort auf die Anforderungen moderner Cloud-Architekturen. Wer Java-Microservices entwickelt, sollte Quarkus ernsthaft evaluieren.

CGS IT Solutions bietet hierzu einen praxisorientierten Quarkus Microservice Workshop an — von den Grundlagen bis zum produktionsreifen Deployment.

Der Beitrag Quarkus: Der moderne Weg zu Java-Microservices erschien zuerst auf CGS IT Solutions GmbH.

Software-Architektur wird oft mit Boxen und Pfeilen gleichgesetzt. Aber Architektur sind die Entscheidungen, die schwer rückgängig zu machen sind — und die den Rahmen für alles Weitere setzen.

Hier sind die fünf Entscheidungen, die den größten Einfluss auf den Erfolg eines Softwareprojekts haben.

1. Synchron oder Asynchron?

Die fundamentalste Entscheidung: Kommunizieren Ihre Komponenten synchron (Request/Response) oder asynchron (Events/Messages)?

Synchron (REST, gRPC):
– Einfacher zu verstehen und zu debuggen
– Direkte Fehlermeldung an den Aufrufer
– Enge Kopplung zwischen Sender und Empfänger

Asynchron (Kafka, RabbitMQ, SQS):
– Lose Kopplung, höhere Resilienz
– Natürliche Skalierbarkeit durch Queues
– Komplexeres Fehlerhandling, Eventual Consistency

Empfehlung: Starten Sie synchron und führen Sie Asynchronität gezielt ein, wo sie Probleme löst — nicht als Grundsatzentscheidung.

2. Datenhoheit: Shared Database oder Database per Service?

Teilen sich Ihre Services eine Datenbank — oder hat jeder Service seine eigene?

Die Wahrheit: Die meisten Systeme brauchen einen Mittelweg. Logische Trennung (eigenes Schema pro Service) mit physisch geteilter Infrastruktur ist oft der pragmatische Start.

3. Deployment-Einheit: Monolith, Modulith oder Microservices?

Diese Entscheidung bestimmt Ihre gesamte Infrastruktur, CI/CD-Pipeline und Team-Organisation:

– Monolith: Ein Artefakt, einfaches Deployment, ein Team
– Modulith: Ein Artefakt mit klaren internen Grenzen, mehrere Teams möglich
– Microservices: Mehrere Artefakte, unabhängiges Deployment, Team-pro-Service

Die Entscheidung hängt weniger von der Technik ab als von der Teamgröße und -struktur (Conway’s Law).

4. Frontend-Architektur: Server-Rendered oder SPA?

Oft unterschätzt, aber schwer zu ändern:

Server-Side Rendering (Thymeleaf, JSF, HTMX):
– Weniger Komplexität, kein separater Build-Prozess
– SEO-freundlich out of the box
– Gut für content-lastige Anwendungen

Single Page Application (React, Angular, Vue):
– Reichere Interaktivität
– Eigenes Team für Frontend möglich
– API-first ermöglicht mehrere Clients (Web, Mobile)

Trend: HTMX und Server Components (React) bringen die Welten zusammen.

5. Fehlerbehandlungsstrategie

Die am häufigsten vergessene Architekturentscheidung: Was passiert, wenn etwas schiefgeht?

Definieren Sie frühzeitig:
– Circuit Breaker: Wann wird ein abhängiger Service als „down“ betrachtet?
– Retry-Strategie: Wie oft, mit welchem Backoff?
– Fallback-Verhalten: Degraded Mode oder Fehlerseite?
– Timeout-Budgets: Wie lange darf ein Request maximal dauern?

Ohne diese Entscheidungen wird Ihr System bei der ersten Störung kaskadierend ausfallen.

Architektur-Entscheidungen dokumentieren

Nutzen Sie Architecture Decision Records (ADRs) — kurze Dokumente, die festhalten:

1. Kontext: Welches Problem lösen wir?
2. Entscheidung: Was haben wir entschieden?
3. Konsequenzen: Was folgt daraus (positiv und negativ)?

# ADR-001: Asynchrone Kommunikation für Bestellprozess

Kontext
Der Bestellprozess muss 5 nachgelagerte Systeme benachrichtigen.
Synchrone Aufrufe führen zu Timeouts bei Last.

Entscheidung
Wir verwenden Apache Kafka für die Event-basierte
Kommunikation im Bestellprozess.

Konsequenzen
+ Lose Kopplung, keine kaskadierenden Fehler
+ Natürliche Skalierbarkeit
- Eventual Consistency, kein sofortiges Feedback
- Zusätzliche Infrastruktur (Kafka Cluster)

Fazit

Gute Architektur entsteht nicht durch die Wahl des richtigen Frameworks, sondern durch bewusste Entscheidungen an den richtigen Stellen. Nehmen Sie sich Zeit für diese fünf Weichenstellungen — sie bestimmen den Erfolg Ihres Projekts mehr als jede Technologiewahl.

Bei CGS IT Solutions unterstützen wir Sie als Software-Architekten bei genau diesen Entscheidungen — pragmatisch, erfahrungsbasiert und technologieneutral.

Der Beitrag Software-Architektur: Die 5 Entscheidungen, die alles bestimmen erschien zuerst auf CGS IT Solutions GmbH.

Der CGS AI Assistant ist ein KI-gestützter Chatbot, der Ihnen sofort und kostenlos bei technischen Fragen weiterhilft. Ob Software-Architektur, Cloud-Migration, Java-Entwicklung oder DevOps — stellen Sie Ihre Frage und erhalten Sie eine fundierte Antwort.

Was kann der CGS AI Assistant?

Der Chatbot basiert auf moderner KI-Technologie (LangChain4j) und ist spezialisiert auf die Themengebiete von CGS IT Solutions:

• Software-Architektur: Microservices vs. Monolith, Clean Architecture, Design Patterns
• Java-Entwicklung: Quarkus, Spring Boot, JPA/Hibernate, Java 21+
• Cloud Computing: AWS, Azure, Container, Kubernetes
• DevOps: CI/CD, Docker, Infrastructure as Code
• KI & Automatisierung: LangChain, AI Agents, Workflow-Automatisierung

So funktioniert es

1. Öffnen Sie den CGS AI Assistant
2. Stellen Sie Ihre Frage in natürlicher Sprache (Deutsch oder Englisch)
3. Erhalten Sie eine sofortige, fachlich fundierte Antwort

Der Chatbot ist kostenlos und ohne Registrierung nutzbar.

Die Technologie dahinter

Der CGS AI Assistant wurde mit LangChain4j entwickelt — einem Java-Framework für die Integration von Large Language Models. Er demonstriert gleichzeitig unsere Kompetenz in der KI-Integration:

• Backend: Java mit Quarkus und LangChain4j
• LLM-Integration: Angebunden an moderne Sprachmodelle
• Deployment: Containerisiert auf Cloud-Infrastruktur

Mehr über KI-Agents und LangChain4j erfahren Sie in unserem Blogpost KI Agents mit LangChain4j.

Interesse an einem eigenen KI-Chatbot?

Wir entwickeln maßgeschneiderte KI-Assistenten für Ihr Unternehmen — trainiert auf Ihre Daten, integriert in Ihre Systeme. Kontaktieren Sie uns für ein unverbindliches Gespräch.

Der Beitrag CGS AI Assistant: Unser KI-Chatbot für Ihre Fragen erschien zuerst auf CGS IT Solutions GmbH.

—

Claude Code – Was ist das?

Claude Code ist ein KI-gestütztes Kommandozeilen-Tool von Anthropic, das direkt im Terminal arbeitet. Anders als klassische Chatbots ist Claude Code ein vollwertiger Entwicklungsassistent: Er liest Code, versteht Projektstrukturen, bearbeitet Dateien, führt Befehle aus und interagiert mit APIs – alles aus dem Terminal heraus.

Bei CGS IT Solutions setzen wir Claude Code aktiv in unserer täglichen Arbeit ein – von der Architekturanalyse über Content-Automatisierung bis hin zur Verwaltung unserer Webauftritte.

Warum Claude Code?

Als Software-Architekten und Entwickler arbeiten wir täglich mit komplexen Codebasen, Cloud-Infrastruktur und Automatisierungspipelines. Claude Code fügt sich nahtlos in diesen Workflow ein:

• Direkte Terminal-Integration – kein Browser, kein Copy-Paste, arbeitet dort wo wir arbeiten
• Versteht den gesamten Projektkontext – liest Dateien, analysiert Abhängigkeiten, versteht Architektur
• Führt Aktionen aus – erstellt Dateien, führt Builds aus, interagiert mit Git und APIs
• Sicheres Arbeiten – jeder Befehl kann vor Ausführung geprüft und genehmigt werden

Die wichtigsten Claude Code Commands

Hier ein Überblick über die Befehle, die wir im Alltag am häufigsten nutzen:

Grundlegende Befehle

• /help – Hilfe und Übersicht aller verfügbaren Befehle
• /init – Projektanalyse und Erstellung einer CLAUDE.md Kontextdatei
• /clear – Konversation zurücksetzen und frisch starten
• /compact – Kontext komprimieren um Tokens zu sparen

Entwicklungs-Workflow

• /review – Code-Review des aktuellen Diffs oder einer Pull Request
• /pr-comments – GitHub PR-Kommentare abrufen und bearbeiten

Speicher und Kontext

• /memory – Projektnotizen und Präferenzen dauerhaft speichern
• CLAUDE.md – Die zentrale Kontextdatei, die Claude bei jedem Start liest

Terminal-Nutzung

• Shift+Tab – Zwischen Chat- und Terminal-Modus wechseln
• Esc – Laufende Aktion abbrechen
• Multi-Turn Conversations – Claude behält den Kontext über mehrere Interaktionen

Praxisbeispiel: Website-Management mit Claude Code

Ein konkretes Beispiel aus unserem Alltag: Wir verwalten unsere WordPress-Websites (cgs.at und preisradar.cgs.at) direkt über Claude Code. Über die WordPress REST API können wir:

• Blog-Beiträge als Markdown schreiben und automatisch als Entwurf hochladen
• Content-Backups aller Seiten und Beiträge erstellen
• Inhalte über mehrere Websites hinweg verwalten
• Wiederkehrende Aufgaben mit Shell-Scripts automatisieren

Das Besondere: Claude Code versteht den Gesamtkontext unserer Projekte und kann so kontextbezogen arbeiten – von der API-Authentifizierung bis zur Content-Erstellung.

CGS AI Assistant – Unser KI-Chatbot mit LangChain4j

Neben Claude Code setzen wir auch auf selbst entwickelte KI-Lösungen: Der CGS AI Assistant ist unser hauseigener KI-Chatbot, gebaut mit LangChain4j und Quarkus. Er beantwortet rund um die Uhr Fragen zu den Leistungen, Technologien und Lösungen von CGS IT Solutions.

Probieren Sie ihn aus: cgsitchat.cgs-it.org

Fazit

Claude Code ist für uns kein Spielzeug, sondern ein produktiver Bestandteil unseres Entwickler-Toolkits. Die Kombination aus Kontextverständnis, Terminal-Integration und der Fähigkeit, tatsächlich Aktionen auszuführen, macht es zu einem echten Produktivitäts-Multiplikator.

Mehr Informationen zu Claude Code: claude.ai/code

Sie möchten erfahren, wie KI-Tools Ihren Entwicklungsprozess unterstützen können? Kontaktieren Sie uns – wir beraten Sie gerne.

Der Beitrag Claude Code bei CGS IT – KI-gestützte Softwareentwicklung in der Praxis erschien zuerst auf CGS IT Solutions GmbH.

Ab sofort steht Ihnen der CGS AI Assistant unter

https://cgsitchat.cgs-it.org/

zur Verfügung – unser neuer KI-gestützter Chat, der Ihnen rund um die Uhr Antworten zu den Leistungen, Technologien und Lösungen von CGS IT Solutions liefert.

Warum ein KI-Chat für CGS IT?

Als Unternehmen, das sich auf Software- und Enterprise-Architektur, Cloud-Transformation und moderne Java-Entwicklung spezialisiert hat, setzen wir nicht nur bei unseren Kunden auf innovative Technologien – wir nutzen sie auch selbst. Der CGS AI Assistant ist ein konkretes Beispiel dafür, wie KI-Agents im Unternehmenskontext sinnvoll eingesetzt werden können.

Ob Sie sich über unsere Architekturberatung informieren möchten, Fragen zu Quarkus-Microservices haben oder wissen wollen, wie wir Cloud-Migrationen begleiten – der CGS AI Assistant hilft Ihnen, schnell die passende Antwort zu finden.

Was kann der CGS AI Assistant?

Der Chat ist darauf trainiert, Fragen rund um das Leistungsspektrum von CGS IT Solutions zu beantworten. Dazu gehören unter anderem:

• Architektur & Beratung – Enterprise Architektur, Software Architektur, Cloud & DevOps Architektur sowie Architektur-Reviews
• Technologien & Lösungen – Quarkus, Keycloak/Red Hat SSO, Cloud Computing, CI/CD mit GitHub und unsere Automatisierungslösungen
• Schulungen & Workshops – Informationen zu unseren Trainings im Java- und Cloud-Umfeld
• Allgemeine Fragen – Kontaktmöglichkeiten, Firmendaten und aktuelle Projekte wie das CGS Preisradar

Der Assistent ersetzt keine persönliche Beratung, bietet aber einen schnellen und unkomplizierten Einstieg, um sich einen ersten Überblick zu verschaffen.

Ihr Chatbot für Inter- und Intranet

Mit diesem Framework bieten wir einen sofortigen Einstieg für Ihre lösungen auch an. Dabei ist ein Chatbot der nur mit Ihren Daten arbeitet in wenigen Stunden einsatzbereit und trotzdem sicher und zuverlässig.

1. Unser Chatbot kann mit statischen oder selbst leicht aktualisierbaren Dokumenten bestückt werden.
2. Aber auch für grössere Datenmengen via Vector Datenbank oder direkten Datenbank und API zugriffen im Hintergrund Datenquellen zur Verfügung stellen
3. In allen Fällen antwortet er nur auf der Basis der vorhandenen Informationen
4. Der LLM Provider kann flexibel ausgewählt werden. Wir unterstützten über 20 populäre LLM-Anbieter
5. Eine hausinterne installation steht jederzeit zur Verfügung
6. Das Paket ist aber auch als fixfertiges abgesichertes Produkt via Amazon Web Services (Europa) verfügbar in einer eigenen gesicherten VPC – Virtuellen private Cloud und Dokumenten und Daten nur in gesicherten Backens.

Jetzt ausprobieren

Testen Sie den CGS AI Assistant direkt unter:

cgsitchat.cgs-it.org

Wir freuen uns auf Ihr Feedback! Wenn Sie Fragen haben oder eine ähnliche Lösung für Ihr Unternehmen umsetzen möchten, kontaktieren Sie uns gerne.

Sie möchten erfahren, wie KI-gestützte Assistenten und Automatisierung Ihre Geschäftsprozesse verbessern können? CGS IT Solutions berät Sie gerne – von der Architektur bis zur Umsetzung.

Der Beitrag Neu: Der CGS AI Assistant – Unser KI-Chat für CGS IT Solutions erschien zuerst auf CGS IT Solutions GmbH.