Connect with us

Entwicklung & Code

Drei Fragen und Antworten: Container und Open Source statt VMware – geht das?


Wie ein Elefant im Porzellanladen baut Broadcom das Virtualisierungsgeschäft um. Viele Unternehmen sehen sich nach Alternativen um – die VMware möglichst direkt ersetzen sollen. Dass es einen besseren Weg gibt, meint Elias Schneider von Codesphere. Er ist Mitgründer und CEO des Karlsruher Start-ups, das einen eigenständigen Cloud-Stack entwickelt, der klassische Virtualisierung durch eine eigene Deploymenttechnologie ersetzt. Wir haben mit ihm darüber gesprochen, warum seiner Meinung nach klassische Virtualisierung nicht mehr die optimale Grundlage für die meisten IT-Abteilungen ist.

Warum funktioniert die klassische Virtualisierung in den meisten Anwendungsfällen nicht mehr am besten?

Virtualisierung war einmal ein echter Gamechanger. Sie passt heute aber in vielen Fällen einfach nicht mehr zu den Anforderungen der IT. Ein Grund ist der technische Fortschritt: Immer mehr Anwendungen werden in Microservices zerlegt und containerisiert betrieben. Das macht sie leichter skalierbar, portierbar und einfacher zu warten, ohne den schweren Hypervisor-Overhead klassischer VMs, der gerade bei kleineren Workloads unnötig Komplexität erzeugt und nebenbei die Cloud-Kosten nach oben treibt.

Außerdem hat sich die Anbieterlandschaft verändert. Seit der Übernahme durch Broadcom sind die Preismodelle bei VMware für viele Unternehmen sprunghaft teurer geworden. Gleichzeitig werden die Modelle unflexibler. Klassische Lizenzen wurden abgeschafft, es gibt teure Jahresabos und Pflicht-Bundles. Service und Support sind auch oft schlechter geworden. Das zwingt viele Kunden in ein enges, proprietäres Ökosystem und erhöht die Abhängigkeit.

Strategisch ist das gefährlich. Gerade in Zeiten, in denen IT-Abteilungen auf Cloud-native Technologien, Open Source und Automatisierung setzen wollen, wirkt klassische Virtualisierung zunehmend als Bremsklotz. Sie erschwert Migrationen in die Cloud, behindert DevOps-Praktiken und widerspricht dem Ziel, souverän über die eigene Infrastruktur zu entscheiden. Deshalb suchen Unternehmen heute nach Alternativen: Lösungen, die effizienter sind, offene Standards unterstützen und ihnen die Kontrolle zurückgeben.

Insbesondere die neuen Lizenzen und Preise treiben VMware-Kunden um. Rechtfertigen die niedrigeren Kosten von Open Source den hohen Aufwand einer Migration hin zu Containern?

Das ist eine berechtigte Frage. Die Antwort lautet: Oft ja, aber nicht nur wegen der Lizenzkosten. Die niedrigeren oder sogar wegfallenden Lizenzkosten bei Open Source (wie Proxmox, OpenStack, KubeVirt) sind natürlich ein starkes Argument, gerade jetzt, wo Broadcoms neue VMware-Preismodelle mit teuren Abos und Bundles viele Unternehmen unter Druck setzen. Statt hoher, unflexibler Kosten pro Core oder Socket zahlt man bei Open Source höchstens für Support. Das ist natürlich ein Unterschied.

Aber das ist nur ein Teil der Rechnung. Der größere Vorteil liegt in Unabhängigkeit und strategischer Flexibilität. Proprietäre Plattformen wie VMware binden Kunden stark, was Migrationen aufwendiger macht. Wer auf Open Source setzt, hat vollen Zugriff auf den Quellcode und kann Anpassungen selbst vornehmen. Außerdem entgeht man dem Risiko plötzlicher Preiserhöhungen oder geänderter Lizenzbedingungen.

Was die „hohen Migrationsaufwände“ betrifft: Ja, sie sind real. Ein Umstieg auf containerisierte Workloads oder offene Virtualisierungslösungen bedeutet Projektarbeit und Schulung. Und das bedeutet Kosten. Aber dafür bekommt man eine Umgebung, die besser in moderne, Cloud-native Architekturen passt: Container und Automatisierung, alles integriert ohne den Hypervisor-Overhead. Das reduziert Betriebskosten langfristig erheblich und steigert die Agilität der Teams.

Open Source bedeutet auch Transparenz und Sicherheit. Sicherheitslücken sind schneller identifiziert, es gibt keine Blackbox-Abhängigkeit. Zudem treibt eine große Community Innovation voran, statt dass man auf Roadmaps eines einzelnen Herstellers landet.

Es geht also nicht nur um billigere Lizenzen. Die Investition in eine Migration zu Containern oder offenen Virtualisierungslösungen ist eine strategische Entscheidung für mehr Unabhängigkeit, bessere Anpassbarkeit und Kostenkontrolle. Wer sich darauf einlässt, gewinnt nicht nur kurzfristige Einsparungen, sondern auch Zukunftssicherheit für die eigene IT-Strategie.

Ein beliebter Witz in der IT ist, dass man einfach eine weitere Abstraktionsebene baut. Warum sollte das mit einem Ansatz rund um Container jetzt anders sein?

Es stimmt, Container sind eine Abstraktionsebene. Aber sie sind eine, die viele Probleme klassischer Virtualisierung löst. Sie kapseln nur das Nötigste, teilen sich den Kernel des Hosts und sind dadurch leichtgewichtig und ressourcenschonend. So lassen sich deutlich mehr Anwendungen auf derselben Hardware betreiben. Damit kann man viele bisher schwergewichtige Anwendungen auch auf weniger leistungsstarken Servern laufen lassen.

Portabilität ist der zweite große Vorteil. Ein Container läuft überall gleich, on Premises, in der Cloud oder hybrid. Das reduziert Migrationsaufwand und Abhängigkeiten von bestimmten Plattformen. Außerdem sind Container schnell und agil: Sie starten in Sekunden, lassen sich einfach skalieren und passen perfekt zu modernen DevOps-Prozessen und CI/CD. Kurz gesagt: Ja, Container sind eine Abstraktion, aber eine, die Overhead reduziert, Flexibilität erhöht und Unternehmen unabhängiger und effizienter macht.

Herr Schneider, vielen Dank für die Antworten!

In der Serie „Drei Fragen und Antworten“ will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne oder hinterlassen Sie einen Kommentar im Forum.


(fo)



Source link

Entwicklung & Code

Visual Studio Code 1.104: Agent Mode bittet um Bestätigung


Das August-Update für Visual Studio Code steht bereit. Unter der Versionsnummer 1.104 hat Microsofts freier Sourcecode-Editor einige KI-Neuerungen an Bord, darunter die automatische Modellauswahl im GitHub Copilot Chat, eine neue Sicherheitsebene für den Agent Mode und die automatische Verwendung von AGENTS.md-Dateien. Zu den weiteren Updates zählen unter anderem farblich hervorgehobene Fensterumrandungen unter Windows und eine Vorschau für Git-Worktree-Änderungen.

Im GitHub Copilot Chat können Entwicklerinnen und Entwickler nun als Preview-Feature dasjenige Large Language Model (LLM) auswählen lassen, das eine optimale Performance und eine Reduzierung der Rate Limits bieten soll – denn manche Modelle weisen eine stärkere Nutzung auf. Diese Funktion soll zunächst die User mit individuellen Copilot-Abos erreichen und im Verlauf der nächsten Wochen an alle Copilot-Nutzerinnen und -Nutzer ausgespielt werden.

Um die automatische Modellauswahl zu aktivieren, ist im Model Picker die Option Auto anzuklicken. Dann fällt VS Code die Entscheidung zwischen Claude Sonnet 4, GPT-5, GPT-5 mini und GPT-4.1 – sofern das Unternehmen der Entwicklerinnen und Entwickler keines dieser Modelle blockiert hat. Der Name des ausgewählten Modells erscheint beim Hovern über der Antwort in der Chatansicht.


Per "Auto"-Option wählt VS Code automatisch ein Large Language Model aus.

Per "Auto"-Option wählt VS Code automatisch ein Large Language Model aus.

Per „Auto“-Option wählt VS Code automatisch ein Large Language Model aus.

(Bild: Microsoft)

Der Agent Mode in GitHub Copilot erhält derweil eine neue Sicherheitsebene: Er erfordert nun eine explizite Bestätigung, bevor er Änderungen an sensiblen Dateien („sensitive files“) vornimmt. Welche das sind, können Entwicklerinnen und Entwickler mit der Einstellung chat.tools.edits.autoApprove festlegen. Einige Dateien, wie solche außerhalb des Workspace, werden standardmäßig als sensible Dateien behandelt.

Als experimentelles Feature verwendet der Agent Mode zudem automatisch eine AGENTS.md-Datei – sofern diese im Workspace-Root vorhanden ist – als Kontext für Chatanfragen. Mit einer AGENTS.md-Datei lassen sich einem Agenten Kontext und Anweisungen vermitteln.

Windows-Nutzer können dank der neuen Einstellung window.border ihre VS-Code-Fenster nun mit einem farblich hervorgehobenen Rahmen versehen. Die Farben lassen sich je nach Workspace anpassen, sodass auf einen Blick sichtbar ist, welcher Workspace in welchem Fenster geöffnet ist:


Bunte Rahmen für Workspaces – je nach Workspace können Developer andere Farben vergeben.

Bunte Rahmen für Workspaces – je nach Workspace können Developer andere Farben vergeben.

Bunte Rahmen für Workspaces – je nach Workspace können Developer andere Farben vergeben.

(Bild: Microsoft)

Eine weitere Neuerung betrifft die Versionskontrolle: Eine Vorschau zeigt nun die Änderungen zwischen Worktree-Dateien und dem aktuellen Workspace. Dazu dient ein Rechtsklick auf eine Worktree-Datei, um das Kontextmenü in der Ansicht Source Control Changes zu öffnen. Dort lässt sich dann Compare with Workspace auswählen.


Das Feature "Compare with Workspaces" zeigt die Änderungen zwischen Worktree-Dateien und aktuellem Workspace.

Das Feature "Compare with Workspaces" zeigt die Änderungen zwischen Worktree-Dateien und aktuellem Workspace.

Das Feature „Compare with Workspaces“ zeigt die Änderungen zwischen Worktree-Dateien und aktuellem Workspace.

(Bild: Microsoft)

Nach Review der Änderungen können Entwicklerinnen und Entwickler dann den Befehl Migrate Worktree Changes… aus der Befehlspalette verwenden, um alle Änderungen aus einem Worktree in den aktuellen Workspace zu mergen. Das soll es vereinfachen, mit mehreren Worktrees zu arbeiten und Änderungen selektiv in das Haupt-Repository zu übernehmen.

Weitere Informationen zu diesen und zahlreichen anderen neuen Features lassen sich der offiziellen Ankündigung entnehmen.


(mai)



Source link

Weiterlesen

Entwicklung & Code

Genkit Go 1.0: Google bringt stabiles KI-Framework ins Go-Ökosystem


Google hat mit Genkit Go 1.0 die erste stabile Version seines Open-Source-Frameworks für KI-Entwicklung im Go-Ökosystem veröffentlicht. Entwicklerinnen und Entwickler können damit ab sofort produktionsreife KI-Anwendungen erstellen und deployen. Gleichzeitig bringt Google mit dem neuen CLI-Befehl genkit init:ai-tools eine direkte Integration für gängige KI-Coding-Assistenten.

Eine der spannendsten Neuerungen in Genkit Go 1.0 ist die Möglichkeit, typensichere KI-Flows mit Go-Structs und JSON-Schema-Validierung zu erstellen. Dadurch lassen sich Modellantworten offenbar zuverlässig strukturieren und einfacher testen.

Im folgenden Beispiel aus dem Ankündigungsbeitrag generiert ein Flow ein strukturiertes Rezept:


package main

import (
    "context"
    "encoding/json"
    "fmt"
    "log"

    "github.com/firebase/genkit/go/ai"
    "github.com/firebase/genkit/go/genkit"
    "github.com/firebase/genkit/go/plugins/googlegenai"
)

// Define your data structures
type RecipeInput struct {
    Ingredient          string `json:"ingredient" jsonschema:"description=Main ingredient or cuisine type"`
    DietaryRestrictions string `json:"dietaryRestrictions,omitempty" jsonschema:"description=Any dietary restrictions"`
}

type Recipe struct {
    Title        string   `json:"title"`
    Description  string   `json:"description"`
    PrepTime     string   `json:"prepTime"`
    CookTime     string   `json:"cookTime"`
    Servings     int      `json:"servings"`
    Ingredients  []string `json:"ingredients"`
    Instructions []string `json:"instructions"`
    Tips         []string `json:"tips,omitempty"`
}

func main() {
    ctx := context.Background()

    // Initialize Genkit with plugins
    g := genkit.Init(ctx,
        genkit.WithPlugins(&googlegenai.GoogleAI{}),
        genkit.WithDefaultModel("googleai/gemini-2.5-flash"),
    )

    // Define a type-safe flow
    recipeFlow := genkit.DefineFlow(g, "recipeGeneratorFlow", 
        func(ctx context.Context, input *RecipeInput) (*Recipe, error) {
            dietaryRestrictions := input.DietaryRestrictions
            if dietaryRestrictions == "" {
                dietaryRestrictions = "none"
            }

            prompt := fmt.Sprintf(`Create a recipe with the following requirements:
                Main ingredient: %s
                Dietary restrictions: %s`, input.Ingredient, dietaryRestrictions)

            // Generate structured data with type safety
            recipe, _, err := genkit.GenerateData[Recipe](ctx, g,
                ai.WithPrompt(prompt),
            )
            if err != nil {
                return nil, fmt.Errorf("failed to generate recipe: %w", err)
            }

            return recipe, nil
        })

    // Run the flow
    recipe, err := recipeFlow.Run(ctx, &RecipeInput{
        Ingredient:          "avocado",
        DietaryRestrictions: "vegetarian",
    })
    if err != nil {
        log.Fatalf("could not generate recipe: %v", err)
    }

    // Print the structured recipe
    recipeJSON, _ := json.MarshalIndent(recipe, "", "  ")
    fmt.Println("Sample recipe generated:")
    fmt.Println(string(recipeJSON))

    <-ctx.Done() // Used for local testing only
}


Hier wird ein Flow (recipeGeneratorFlow) definiert, der Rezepte auf Basis einer Hauptzutat und optionaler Ernährungsvorgaben wie „vegetarian“ generiert. Der Prompt wird dynamisch gebaut, ans KI-Modell (Google Gemini) übergeben und die Antwort in eine klar definierte Go-Datenstruktur (Recipe) zurückgeschrieben. Am Ende läuft der Flow mit der Eingabe „avocado, vegetarisch“ und gibt ein komplettes JSON-Rezept mit Zutaten, Kochzeit und Tipps zurück.

Darüber hinaus haben Developer mit Genkit Go 1.0 die Möglichkeit, externe APIs über Tool Calling einzubinden und Modelle von Google AI, Vertex AI, OpenAI, Anthropic und Ollama über eine einheitliche Schnittstelle zu nutzen. Die Bereitstellung soll unkompliziert als HTTP-Endpoint erfolgen. Eine Standalone-CLI sowie eine interaktive Developer UI unterstützen beim Schreiben von Tests, Debugging und Monitoring.

Der neue Befehl genkit init:ai-tools richtet automatisch KI-Assistenztools wie Gemini CLI, Firebase Studio, Claude Code und Cursor ein. Somit können Entwicklerinnen und Entwickler damit direkt die Genkit-Dokumentation durchsuchen, Flows testen, Debug-Traces ausführen und Go-Code nach Best Practices generieren.


(mdo)



Source link

Weiterlesen

Entwicklung & Code

Vorstellung Studie Cupra Tindaya: Betont unruhig


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

In den Weiten des Volkswagen-Konzerns darf sich kaum eine Marke optisch so weit vorwagen wie Cupra. Tatsächlich seriennah dürfte die Studie Tindaya kaum sein, und doch ist die spektakuläre Formgebung mehr als nur ein Blickfang auf der IAA. Der Name Tindaya, nach einem Vulkan auf der Insel Fuerteventura, ist dabei durchaus Programm.

Terramar, Tavascan, Formentor und auch noch der Ateca, dessen Produktion absehbar ausläuft: An SUVs mangelt es der Marke Cupra derzeit wahrlich nicht. Ist dort perspektivisch Platz für ein weiteres Modell mit rund 4,7 m Länge? Ja, befanden offenbar die Verantwortlichen. Die Studie Tindaya ist 4,72 m lang und ausschließlich auf batterieelektrische Antriebe ausgerichtet. Welche Plattform in einem Serienmodell genutzt werden würde, ist aktuell noch zweitrangig. Viel spricht dafür, dass es die Basis des kommenden VW ID.4 sein könnte.

Das kantig-faltige Design ist bewusst überzeichnet. Allein schon der gesetzliche Fußgängerschutz würde einem Serieneinsatz dieser Front vermutlich entgegenstehen. Riesige Radhäuser, in denen selbst 23-Zoll-Felgen samt Reifen mit geringer Flankenhöhe nicht übertrieben scheinen, haben da vermutlich bessere Chancen. Innen gibt es vier Einzelsitze, ein 24-Zoll-Display, ein Lenkrad im Gaming-Stil und eine Mittelkonsole, die an die 2023er-Studie des Lamborghini Lanzador erinnert. In der Mitte der bis in den Fond durchgehenden Konsole befindet sich ein Zentralknopf, mit dem sich verschiedene Funktionen ansteuern lassen.

Ein aufregend gestaltetes Serienmodell würde sich bei den Antriebskomponenten vermutlich im Baukasten des Konzerns bedienen. Hinter- wie Allradantrieb wären damit möglich. Das Leistungsangebot dürfte sich zwischen 210 und 250 kW bewegen, wobei wir damit rechnen, dass sich Volkswagen irgendwann genötigt sehen könnte, in dieser Hinsicht nachzulegen. Ein Ende des Wettrüstens ist schließlich nicht abzusehen – ganz im Gegenteil: Der Umstieg auf Elektromobilität macht mehr Leistung vergleichsweise problemlos möglich, was eher Folgen für die Verkehrssicherheit haben wird als auf den Bedarf an Fahrenergie.


Falls Sie sich gerade fragen, ob die Umgebung, in der diese Pressebilder entstanden sind, nicht doch ein wenig … (Bild:

Cupra

)

Unter anderem Volkswagen hat mit dem E-Motor APP550 gezeigt, dass sich selbst 210 kW Spitzenleistung potenziell mitführen lassen, ohne beim Verbrauch dramatisch über dem zu liegen, was ein elektrischer Kleinwagen wie der Opel Corsa-e auch braucht. Auch in dieser Hinsicht unterscheiden sich Verbrenner und batterieelektrischer Antrieb enorm. Das Potenzial eines aufgeladenen V8 wird auch bei gemäßigter Fahrweise immer ein Stück weit zu füttern sein. Beim ungleich effizienteren E-Motor steigt der Verbrauch erst dann, wenn die Leistung abgerufen wird.

Zweigeteilt ist die Welt bei Volkswagen hinsichtlich der Ladeleistung. Audi und Porsche haben schon Modelle mit 800 Volt Spannungsebene, was Ladeleistung von deutlich mehr als 200 kW an der gängigen, mit 500 Ampere abgesicherten Ladeinfrastruktur erlaubt. Marken wie Skoda, VW und eben auch Cupra nutzen derzeit ein 400-Volt-System. Damit ist an Ladesäulen mit 500 A bei 200 kW die Spitze erreicht. Mittelfristig werden auch andere Konzernmarken Elektroautos mit 800 Volt ins Sortiment aufnehmen. Ob ein Serienableger der Studie Tindaya dazu gehören könnte, ist ungewiss.

Lesen Sie mehr zur Marke Cupra


(mfz)



Source link

Weiterlesen

Beliebt