consera.io

AUSGANGSSITUATION

Microsoft veröffentlicht laufend Updates für seine Cloud-Services – neue Features, geänderte Einstellungen, Sicherheits-Patches. Für Unternehmen, die auf Microsoft 365 und Azure setzen, war das ein echtes Problem: Es gab keinen zentralen Ort, an dem man alle Updates übersichtlich sehen konnte. Stattdessen herrschte Unordnung. Niemand wusste auf Anhieb, welche Updates für die eigene Infrastruktur relevant waren und welche man ignorieren konnte.

Die Konsequenz: IT-Teams verbrachten Stunden damit, sich durch Microsofts Kommunikationskanäle zu wühlen, verpassten kritische Änderungen oder reagierten zu spät. Das war nicht nur ineffizient – es war ein Risiko.

DIE IDEE

Was wäre, wenn man alle Microsoft-Updates automatisch crawlen, bündeln und dann durch Experten bewerten lassen könnte? Nicht einfach eine Liste, sondern eine Plattform, die versteht, welche Updates für welchen Kunden relevant sind.

Daraus entstand consera: Eine Plattform, die alle Microsoft-Updates zentral sammelt und aufbereitet. Der eigentliche Clou kam durch die Anbindung der Azure Tenants. Dadurch entstand ein automatisches Matching – die Plattform konnte jedem Kunden genau die Updates anzeigen, die seine tatsächlich genutzten Services betrafen.

Kunden konnten ihre Updates tracken, einen Status vergeben und so nachvollziehen, ob ein Update bereits umgesetzt wurde oder ob die eigene Infrastruktur darauf reagiert hat.

TECHNISCHE UMSETZUNG

Backend: Das Backend wurde vollständig in Python mit FastAPI entwickelt. Die Entscheidung für Python fiel nicht von Anfang an – ursprünglich lief das Backend auf Express.js. Weil aber viele Azure Functions bereits in Python geschrieben waren, führte die Zweisprachigkeit zu Reibung: unterschiedliche Toolchains, langsamere Entwicklungszyklen, komplizierte CI/CD-Pipelines. Die Entscheidung, das Backend komplett auf Python/FastAPI umzuschreiben, war kurzfristig ein Rückschlag. Langfristig hat sie die Developer Experience massiv verbessert, weil das gesamte Team dieselbe Sprache sprach.

Datenbank: PostgreSQL – zuverlässig, bewährt, genau richtig für die strukturierten Daten der Plattform.

Frontend: Realisiert mit Nuxt.js. Bewusst schlank gehalten – die Komplexität lag im Backend und in der Datenverarbeitung, nicht in der UI.

Authentifizierung: Anfangs mit Auth0. Das stellte sich aber als overengineered und kostenintensiv heraus. Die Umstellung auf eine eigene JWT-Authentifizierung brauchte Entwicklungszeit, gab aber volle Kontrolle und passte nahtlos zum Backend.

KI-Bewertung: Im späteren Verlauf wurde die manuelle Expertenbewertung der Updates durch eine KI-gestützte Lösung ergänzt. Die Wissensbasis der Experten floss als Grundlage ein, auf der die KI über die OpenAI API ihre Bewertungen traf. So skalierte die Qualität der Bewertungen, ohne dass jedes Update manuell geprüft werden musste.

Admin-Portal: Ein separates Frontend für die Administration mit einer eigenen API-Schnittstelle, geschützt durch eine Middleware. So war klar getrennt, was Admins und was Kunden tun dürfen.

HERAUSFORDERUNGEN & LEARNINGS

Microsofts RSS-Schnittstelle bricht weg.

Eine der größten Herausforderungen kam von außen: Microsoft stellte seine RSS-Schnittstelle für Updates zunächst komplett ein und brachte sie später in veränderter Form zurück. Plötzlich konnten keine neuen Updates mehr gezogen werden – das Herzstück der Plattform stand still. Es musste schnell reagiert werden.

Das Learning daraus: Die Struktur der gecrawlten Updates wurde grundlegend standardisiert. Statt statisch auf ein bestimmtes Format zu bauen, entstand eine flexible Architektur, in der neue Quellen und geänderte Formate deutlich einfacher integriert werden konnten. Die Abhängigkeit von einer einzigen, statisch definierten Struktur war damit gelöst.

Backend-Umstellung. Der Wechsel von Express.js zu FastAPI war ein bewusster Rückschritt, um langfristig schneller voranzukommen. Die Entscheidung fiel nicht leicht, hat sich aber durch bessere CI/CD-Pipelines und eine einheitliche Codebasis mehrfach ausgezahlt.

Warum war der Umstieg auf FastApi besser?

Für eine simple User-API mit Validierung brauchst du bei Express sofort drei Pakete: Express selbst, Joi für die Validierung und swagger-ui-express für die Dokumentation. Das Validierungsschema musst du separat in Joi-Syntax definieren, dann eine eigene Middleware schreiben, die bei jedem Request das Schema prüft und Fehler formatiert. Und wenn du eine OpenAPI-Doku willst, darfst du die Spec nochmal von Hand als YAML oder JSON schreiben und zusätzlich swagger-jsdoc konfigurieren. Im Ergebnis hast du für einen einzigen POST-Endpoint schon rund 30 Zeilen Boilerplate, bevor die eigentliche Geschäftslogik überhaupt anfängt.

// Express.js — User-API mit Validierung
const express = require('express');
const Joi = require('joi');          // extra Paket!
const swaggerUi = require('swagger-ui-express'); // extra!
const app = express();

app.use(express.json());

// Schema manuell definieren (Joi)
const userSchema = Joi.object({
  name: Joi.string().min(2).max(50).required(),
  email: Joi.string().email().required(),
  age: Joi.number().integer().min(0).max(150)
});

// Validierungs-Middleware manuell schreiben
const validate = (schema) => (req, res, next) => {
  const { error } = schema.validate(req.body);
  if (error) {
    return res.status(422).json({
      error: error.details[0].message
    });
  }
  next();
};

// Route definieren
app.post('/users', validate(userSchema), (req, res) => {
  const { name, email, age } = req.body;
  // Datenbank-Logik hier ...
  res.status(201).json({
    id: 1,
    name,
    email,
    age: age || null
  });
});

// Swagger-Docs? → Noch mehr Setup nötig:
// OpenAPI-Spec manuell schreiben (YAML/JSON)
// + swagger-jsdoc konfigurieren
// + swagger-ui-express einbinden

app.listen(3000);

Derselbe Endpoint braucht bei FastAPI etwa die Hälfte des Codes. Die Validierung ist direkt in die Pydantic-Klasse eingebaut. Du definierst dein Datenmodell einmal als Python-Klasse mit Type-Hints, und FastAPI übernimmt daraus automatisch die Request-Validierung, die Fehler-Responses (422 mit Details) und die vollständige OpenAPI-Dokumentation unter /docs. Kein Extra-Paket, keine Middleware, keine manuelle Spec. Dazu kommt nativer async/await-Support, der bei Express erst mit zusätzlichem Wrapper-Code sauber funktioniert.

# FastAPI — User-API mit Validierung
from fastapi import FastAPI
from pydantic import BaseModel, EmailStr, Field

app = FastAPI()  # Docs automatisch unter /docs


# Schema = Python-Klasse (Pydantic)
class User(BaseModel):
    name: str = Field(min_length=2, max_length=50)
    email: EmailStr
    age: int | None = Field(None, ge=0, le=150)


class UserResponse(User):
    id: int


# Route definieren — fertig!
@app.post("/users", response_model=UserResponse,
           status_code=201)
async def create_user(user: User):
    # Datenbank-Logik hier ...
    return UserResponse(id=1, **user.model_dump())


# ✅ Validierung?     → automatisch (Pydantic)
# ✅ Fehler-Response?  → automatisch (422 + Details)
# ✅ OpenAPI-Docs?     → automatisch (/docs)
# ✅ Async-Support?    → eingebaut
# ✅ Type-Hints?       → eingebaut

Auth0 raus, eigene Lösung rein. Manchmal ist weniger mehr. Auth0 bot Features, die nicht gebraucht wurden, und verursachte Kosten und Komplexität, die nicht im Verhältnis zum Nutzen standen. Die eigene JWT-Lösung war schlanker, billiger und besser integriert.

RÜCKBLICK

consera zeigt, wie aus einem konkreten Problem – dem Update-Chaos bei Microsoft-Services – ein echtes Produkt entstehen kann. Nicht durch perfekte Planung von Anfang an, sondern durch ständiges Anpassen: Technologien umstellen, wenn sie nicht passen. Externe Abhängigkeiten abstrahieren, bevor sie zum Risiko werden. Manuelle Prozesse durch KI skalierbar machen, sobald die Wissensbasis steht.

Die wichtigste Erkenntnis: Gute Software entsteht nicht, indem man alles beim ersten Mal richtig macht. Sie entsteht, indem man schnell erkennt, was nicht funktioniert – und den Mut hat, es zu ändern.