- Ein Account, der die merkwürdigen Dinge teilt, die man bei Microsoft Azure jeden Tag erlebt. Inzwischen sind es über 400 Tage
- Tag 403: Kürzlich fand der #Microsoft Cloud for Sustainability Technical Summit statt. In der Praxis wirkte er jedoch eher wie ein #Copilot-Summit mit leichtem Fokus auf Nachhaltigkeit. (Dieser Screenshot stammt nur aus den ersten drei Sessions.)
- Tag 402: Die neuen #AI-Funktionen der Azure CLI funktionieren bisher großartig (Fehler-Screenshot)
- Tag 401: Bild eines Link-Fehlers. Nur eines von unzähligen Beispielen für #Azure-Dokumentationslinks, die zu Abschnitten führen, die gar nicht existieren
...
1 Kommentare
Meinungen auf Hacker News
Als ich früher bei Mojang gearbeitet habe, versuchten wir nach der Übernahme durch Microsoft, von AWS zu Azure zu wechseln.
Oberflächlich ergab das Sinn: Während die AWS-Kosten im sechsstelligen Dollarbereich pro Monat lagen, konnten wir Azure kostenlos nutzen.
Aber nach etwa einem Jahr und unzähligen Stunden, die unser Team und die von der Azure-Organisation bereitgestellten Solution Experts investiert hatten, waren sich alle einig, dass wir die sechsstelligen Kosten an einen der großen Microsoft-Konkurrenten weiter zahlen mussten.
Seitdem sehe ich Azure nicht mehr als praxistauglichen Cloud-Anbieter. Vielleicht muss ich es eines Tages neu bewerten, aber es wäre nicht das erste Mal, dass ich mich irre.
Im Großen und Ganzen war es okay, aber die Probleme begannen, als wir CosmosDB nutzten, das damals DocumentDB hieß.
Das frühe DocumentDB war wirklich miserabel, die Preise waren extrem schwer vorherzusagen, sodass an Wochenenden absurde Rechnungen entstanden, und das bereitgestellte .NET SDK war ebenfalls voller Bugs und schrecklich.
Am schlimmsten war, dass die Web-UI direkt an eine bestimmte CosmosDB-Instanz gekoppelt zu sein schien.
Wenn man die Datenbankressourcen zu knapp bemessen hatte, wurde sie langsam, und sogar das Webinterface, das man zum Erhöhen der Ressourcen verwenden musste, verzögerte sich mit.
Es gab also Situationen, in denen wir die gesamte Anwendung abschalten mussten, nur um die Cosmos-Ressourcen hochzusetzen, und Microsoft wirkte dabei völlig amateurhaft.
Ich habe den Eindruck, dass Cosmos heute deutlich besser ist, aber der Nachgeschmack von damals war sehr bitter.
Wenn es so etwas wie kostenlose Credits gäbe, würde ich Azure vielleicht noch einmal ausprobieren, aber derzeit würde ich es absolut nicht empfehlen.
Den größten E-Mail-Dienst der Welt auf einem Windows-Stack zu betreiben, wäre eine enorme Bestätigung gewesen, aber es dauerte Jahre, bis es gelang.
https://www.zdnet.com/article/ms-moving-hotmail-to-win2000-s...
https://jimbojones.livejournal.com/23143.html
Ich vermute, es waren AWS-spezifische Funktionen wie die Art, wie AWS Serverless handhabt, die sich nicht direkt nach Azure übertragen ließen, aber ich lerne immer gern, warum eine Migration von X nach Y gescheitert ist.
Vermutlich hat auch geholfen, dass die Technologien im Gaming-Bereich inzwischen weiter ausgereift sind.
Korrektur: AWS -> Azure :)
Da AWS insgesamt voraus war, gab es damals eine technologische Lücke, und später scheint diese Lücke geschlossen worden zu sein.
Schon gut, Microsoft wird es nächste Woche umbenennen und die Admin-UI sowie die API komplett austauschen.
Der neue Name wird dann Dynamics CoPilot OneAI 365 for Business OneCloud sein.
live.comsein, andereoutlook.com, wieder anderesharepoint.comodermsbinbows.comund so weiter.Aber die Dokumentation und alle anderen Verweise werden natürlich beim alten Namen bleiben.
Meiner Erfahrung nach habe ich Organisationen gesehen, die alles nutzten, von On-Premises-Serverracks über Linode bis AWS und Azure, und die Beschwerden über Cloud-Infrastruktur standen im Verhältnis zur Nutzung von Managed Services.
Teams, die sich hauptsächlich auf virtuelle Maschinen und höchstens auf eine Managed Relational Database stützten, beschwerten sich kaum.
Man muss zwar ein paar Skripte mehr pflegen, aber das ist nur eine kleine Unannehmlichkeit im Vergleich dazu, mit den Problemen und Eigenheiten von Managed Services zu kämpfen.
Natürlich sind normale virtuelle Maschinen leichter zu warten als Managed Services, und genau deshalb bezahlt man Cloud-Anbieter deutlich mehr für Managed Services, damit man es nicht selbst machen muss.
Bedeutet das am Ende, dass dieser Aufwand im Grunde sinnlos ist?
Für viele Unternehmen sind Managed Services der Hauptgrund für den Umzug in die Cloud, daher ist diese Aussage keineswegs unstrittig.
Ein Kunde brauchte einen IPsec-Tunnel in die VPC mit den Produktionsservern, und weil wir diese Konfiguration nicht nur für einen Kunden selbst betreiben wollten, sahen wir uns die AWS-Angebote an und fanden eine Managed-IPsec-Lösung.
Dann meldete der Kunde, dass der Tunnel down sei, und die Lösung war, dass der Kunde seine Seite neu starten musste, um die Verbindung wiederherzustellen.
Man kann S3-Logging aktivieren, um nachzusehen, warum, aber laut AWS-Seite sollte alles normal sein.
Selbst mit nur EC2 passieren seltsame Dinge.
Kürzlich reagierte eine EC2-Instanz nicht mehr, aber die Auto Scaling Group ersetzte sie nicht; jede Aktion lieferte den Fehler, die Instanz laufe nicht, obwohl ihr Status „running“ war.
Zum Glück stimmt mein Chef zu, aber er hat nicht die volle Entscheidungsgewalt.
Wegen Vendor Lock-in und API-Kompatibilität, die fast, aber eben nicht ganz zu Open Source passt, mache ich mir umso mehr Sorgen, je mehr Teams das übernehmen.
Sie sagen: „Aber es ist doch einfacher!“ — wir werden sehen.
Vor etwa 2014 senkte AWS regelmäßig die Preise wichtiger Dienste und gab damit sinkende Technologiekosten weiter.
Azure mochte das nicht und begann, die AWS-Preise zu matchen; bei denselben Rabatten für dieselben Dienste zogen sie sofort nach.
Das ist eine Form von Predatory Pricing, weil es darauf abzielt, den Anreiz für Preissenkungen zu zerstören, indem Wettbewerber selbst durch niedrigere Preise keinen Marktanteil gewinnen.
Ich wollte Azure wirklich mögen, weil es gut in die Tools integriert ist, bin aber immer wieder auf Einschränkungen bei der Verfügbarkeit virtueller Maschinen und merkwürdige UX-Probleme gestoßen
Bei AWS hatte ich nie den Fall, keine Maschine zu bekommen, oder den Verdacht, dass eine von mir ausgeführte Aktion nicht tatsächlich übernommen wurde
Über Azure FaaS habe ich auch ein paar Mal nachgedacht, aber inzwischen bin ich klar bei: „Nicht benutzen, schnell weglaufen“
Die Erfahrung rund um Azure Functions ist so seltsam, dass man sich damit nicht wohlfühlen kann, und der Zugriff auf Logs oder andere binäre Artefakte ist unglaublich schmerzhaft
Es ist so einfach, auf einer leeren Windows-/Linux-VM einen self-contained .NET-Build laufen zu lassen, dass es keinen Grund gibt, sich auf all diese zusätzliche Komplexität einzulassen
Außerdem gibt es Automatisierung zerstörendes Verhalten, etwa dass SQL Server einen Callback sendet, er laufe, obwohl er tatsächlich erst 20 Minuten später bereit ist
Ich bin halb überzeugt, dass
terraform time_sleepeigens geschaffen wurde, um Azure-Probleme abzufangenDas ist derselbe Dienst, bei dem man am Ende landet, wenn eine Function App über einfache Funktionen hinaus längere Laufzeiten oder keine Cold-Start-Latenz braucht
App Services braucht etwas Eingewöhnung, ist aber ein abgeschotteter Win-Server-/IIS-Container mit eingebautem FTPS, Health-Check-Endpunkten für Self-Healing, Deployments mit Angabe des Speichers, Auto-Scaling-Optionen und 99,95 % SLA
Vor ein paar Jahren war die Performance nicht besonders, aber die Premium-SKUs mit 2 oder mehr vCPUs auf aktuellen CPUs waren unproblematisch
Es ist teurer als virtuelle Maschinen, aber sich um Sicherheit und Updates von Webserver-VMs zu kümmern, ist enorm viel Arbeit
Wir haben ein Unternehmen übernommen, das auf Azure gehostet war
Sie nutzten gehostetes Postgres und .NET-Services auf Windows, und die Infrastruktur war klein, etwa 200–300 Kerne und 1 TB Arbeitsspeicher
Alle paar Tage nahm Microsoft unter dem Vorwand von Wartung willkürlich Instanzen vom Netz und kappte das Netzwerk für mehr als 10 Minuten
Das gehostete Postgres hatte eine katastrophale Performance, also migrierten wir; ein in Indien ansässiger Experte riet zu einem anderen Volume-Typ, und nach einem Neustart der Instanz kam die Datenbank wegen I/O-Latenzen nicht mehr hoch
Dieser Experte war angeblich beschäftigt und wich drei Tage hintereinander Meetings aus; der RCA war ein halbfertiges Dokument, vermutlich von einem LLM geschrieben, in dem stand, es sei nicht ihre Schuld, aber die Charts erzählten etwas anderes
Das Einzige, womit Azure GCP und AWS schlägt, ist, dass das Dashboard schnell lädt
Allerdings ist es traurig, dass zwei ähnliche Netzwerkoperationen, parallel ausgeführt, entweder fehlschlagen oder zehnmal länger dauern als nacheinander
Lauft weg, nicht benutzen
Unter allen PaaS-Anbietern hat Azure die schlechtesten Abstraktionen und Services
Es ist traurig, dass sich im Großen und Ganzen alle darauf einigen, solche seltsamen Dienste zu konsumieren, und dadurch Jobs für Cloud-Architekten und Experten entstehen
Weil die Partner weiterhin relevant gehalten werden müssen, werden schlechtes Design und lose Kopplungen mit durchgefüttert
Eigentlich ist das auch meine Meinung zur gesamten Enterprise-IT
In einem kleinen Unternehmen mit etwa 30 Entwicklern habe ich ein Azure-Chaos geerbt, dann für die benötigten Services Abstraktionen in unseren Entwicklungstools geschaffen, die näher am Branchenstandard lagen, und bin ein paar Jahre später zu Hetzner umgezogen
Die Entwickler hier merken praktisch keinen Unterschied
Unsere Tools kümmern sich um Workflow- und Service-Abstraktionen, und solche Dinge sollten sich nicht ändern, nur weil der Anbieter wechselt
Die Monatsrechnung sank auf ein Zehntel, und einen Teil dieses Geldes haben wir in die bestmögliche Entwicklererfahrung gesteckt, die wir uns vorstellen konnten
Ich halte das für einen sehr guten Tausch
Es gibt nur zwei Fälle, in denen die großen Clouds sinnvoll sind
Entweder wirklich kleine MVP-Größe oder riesige global verteilte Umgebungen, die Elastizität brauchen
Für die meisten Unternehmen sind beides eher Ausnahmen
Ich denke, jeder Azure-Nutzer könnte 100 Gründe, Azure nicht zu nutzen zusammenstellen, und bei der meisten großen Software wäre es ähnlich
Selbst als jemand mit wenig Kontakt zu anderen Clouds war leicht zu erkennen, dass die Azure User Experience schlecht gepflegt ist und hinterherhinkt
Die Zahl der Seiten, auf denen man „Mehr anzeigen“ klicken muss, damit die Filterleiste richtig funktioniert, sollte inzwischen offensichtlich 0 sein
Das ist objektiv ein schlechtes Pattern, existiert seit Jahren und sollte „leicht“ zu beheben sein, wird aber vermutlich nie Priorität bekommen
Am Ende werden solche Probleme nicht behoben, solange ihre Lösung nicht zu den Kernwerten der Organisation gehört oder den Umsatz eindeutig beeinträchtigt
Für die Nutzer-Community sind Öffentlichkeit und Sichtbarkeit solcher Probleme immer wichtig
Ich nutze sowohl AWS als auch Azure, und eine Sache, die ich an Azure wirklich mag, ist das Portal
Wie bei AWS 2.0 ist der ganze Cloud-Kleinkram abstrahiert, und übrig bleiben nur die Einstellungen, die man tatsächlich anfassen muss, und ihre Beziehungen zueinander
Ich mag AWS ebenfalls, aber jedes Mal, wenn ich in eine fremde Umgebung komme und alle Verknüpfungen reverse-engineeren muss, brauche ich danach einen Drink
Als ich Azure ein paar Tage ausprobiert habe, war das Portal wirklich schmerzhaft
Jeder Klick brauchte 5 bis 10 Sekunden bis zur Antwort, und selbst bei Änderungen an Grundeinstellungen musste ich manchmal über 2 Minuten lang auf einen Ajax-Spinner schauen
Wie kann man es genießen, so zu arbeiten?
Es wirkt, als würde jemand sie absichtlich so verwirrend wie möglich machen, aber ich kann mir den Zweck nicht einmal vorstellen
Ich meine nicht, dass die Meinung ungültig oder gelogen ist, aber ich habe noch nie jemanden getroffen, der das Azure-Portal mag, nicht einmal Menschen, die stündlich im Azure-Ökosystem leben
Falls nicht, ist es lustig
Ich stehe komplett auf der Gegenseite, also muss man es wohl als Geschmackssache sehen
Ich habe beide ziemlich viel genutzt, und das Azure-Dashboard nervt immer noch, aber was die Benutzbarkeit angeht, ist es AWS deutlich überlegen
Außerdem investiert Microsoft offensichtlich Zeit und Geld in die Dokumentation, während die AWS-Doku immer eher schlecht war
Wenn man ein kleines Unternehmen ist und keine Container betreibt, ist Cloudflare als Cloud stark unterschätzt.
Ich weiß, dass sie aus anderen Gründen kritisiert werden, aber wenn man von den großen 3 oder 4 genug hat, ist die Developer Experience tatsächlich hervorragend.
[1]: https://blog.cloudflare.com/container-platform-preview/
Für Svelte-Sites mag ich das, aber an Sprache und Request-Response-basierte Einschränkungen gebunden zu sein, ist eine enorme Begrenzung.
Mindestens Container und persistente Volumes müssten da sein, damit es für mich interessant wird.
Ich hasse Azure wirklich mit Leidenschaft.
Ich bin in einem Team, das Tools baut, um die Erstellung von Projekten/Accounts/Subscriptions je Cloud-Anbieter zu automatisieren.
Unser Hauptanbieter ist GCP, und die Implementierung war ziemlich einfach.
Es gab ein paar Fallstricke, aber die ließen sich leicht umgehen.
Jetzt müssen wir im Rahmen von Multi-Cloud Azure unterstützen.
Früher waren wir bei AWS, sind aber zu 95 % raus; ein paar Teams sind zwar noch dort, aber außer Terraform-Modulen bauen wir dafür kaum noch Tools.
Azure API, MS Graph API und die Go-SDKs für beide sind jedoch der größte Müllhaufen, mit dem ich je zu tun hatte.
Alles ist ein Pointer, und sogar String-Literale müssen zu Pointern gemacht werden, außer manchmal dann doch nicht.
Die Dokumentation ist ungenau; manche APIs akzeptieren nur IDs, andere dagegen vollständige Pfade.
Einiges ist dokumentiert, aber bei vielen APIs steht das falsche Format.
Keine API gibt die IDs zugehöriger Ressourcen zurück, sodass man alles suchen muss, und es gibt viel zu viele namensbasierte Suchen.
Wir mussten sogar eine ID-Caching-Schicht hinzufügen, um während der Erstellung nicht dieselbe Ressource wiederholt abzufragen.
Für die Erstellung verwenden wir eine State Machine und können ab Zwischenständen fortsetzen, deshalb brauchen wir viel Code zum Prüfen und Wiederaufnehmen.
Insgesamt ist es der Cloud-Anbieter mit dem schlechtesten Design und der schlechtesten Implementierung; wenn ich die Wahl hätte, würde ich ihn niemals empfehlen oder auswählen.
Dinge, die intern in Go geschrieben sind, sind normalerweise großartig.
Wir haben intern eines gebaut, interessieren uns aber auch für Third-Party-Optionen.
Allerdings könnten unsere internen Geschäftsregeln bedeuten, dass Selberbauen sinnvoller ist als Kaufen.