Seite 3: Teurer Spaß?

Inhaltsverzeichnis

Häufig genannte Kritikpunkte von Microsofts Azure Cosmos DB sind der hohe Preis und das anfangs etwas kompliziertere Abrechnungsmodell. Neben dem belegten Speicher erfolgt die Abrechnung von Azure Cosmos DB über Anforderungseinheiten (RU). RU sind eine definierte Einheit für die Berechnung des Durchsatzes für Lese-, Schreib- und Abfragevorgänge. Dabei haben die verschiedenen Aktionen abhängig von der Größe unterschiedliche RU-Kosten. So ist eine Schreibaktion teurer als eine Leseaktion. Für die Abrechnung werden allerdings nicht die verbrauchten, sondern die bereitgestellten RU gezählt. Dabei hat der Nutzer die Option, die RU pro Sammlung oder pro Datenbank zu bestellen. In beiden Fällen ist eine Mindestabnahme notwendig, 400 RU pro Sammlung oder 50.000 RU pro Datenbank. Bei einem aktuellen Preis von 0,0068 Euro pro 100 RU pro Stunde macht das im Monat circa 19,85 Euro pro Sammlung.

Wenn viele Sammlungen benötigt werden, kann es sinnvoll sein, die Anforderungseinheiten pro Datenbank zu definieren. Bedarf es nur weniger Sammlungen, so lassen sich Kosten sparen, indem man sie zusammenlegt und nur eine nutzt. Um die voraussichtlich benötigten Anforderungseinheiten zu kalkulieren, stellt Microsoft einen Rechner zur Verfügung.

Mit der Bereitstellung der RU erhält man zusätzlich auch ein Limit, wie viele Aktionen pro Sekunde erreicht werden können. Eine automatische Erhöhung der bereitgestellten RU gibt es nicht. Damit fehlt aktuell ein wichtiger Aspekt des auf Flexibilität fußenden Serverless-Gedankens. Die fehlende Anpassung der RU lässt sich allerdings relativ einfach mittels Monitoring-Benachrichtigungen und Azure Functions nachrüsten, da man die aktuell genutzten RU auslesen und die bereitgestellten RU somit programmatisch verändern kann.

Auch wenn Azure Cosmos DB zweifellos eher zu den teureren Diensten zählt, so bietet die Datenbank mit globaler Replikation, geringen Latenzen, der Vielzahl von APIs und der guten Integration in Azure Functions viele Möglichkeiten für die einfache Nutzung in Serverless-Anwendungen. Je nach Anwendungsfall kann die unkomplizierte Integration und die Möglichkeit, bestehenden Code wieder zu verwenden, die Entwicklungskosten reduzieren und so den höheren Preis für den Dienst kompensieren.

Ereignis-Routing per Event Grid

In Serverless-Anwendungen ist es oftmals notwendig, Ereignisse von externen Systemen zu empfangen oder an diese zu verschicken. Auch hierfür bietet Microsoft einen Serverless-Dienst: Azure Event Grid ist ein vollständig verwalteter Dienst für Ereignis-Routing mittels eines Veröffentlichungs-/Abonnenten-Modell (Publisher/Subscriber). Die Kommunikation mit Azure Event Grid erfolgt komplett über HTTP. Über einen HTTP-Endpunkt lassen sich Ereignisse an ein Topic posten. Für dieses kann es ein oder mehrere Abonnenten geben, welche wiederum per HTTP Nachrichten über neue Ereignisse erhalten. Dabei kann man auf Abonnentenebene innerhalb von Azure Filter definieren, sodass nicht jeder Abonnent alle Ereignisse empfangen muss, sondern nur jene, die relevant für ihn sind. Scheitert die Ereignisübermittlung an einen Abonnenten, so wiederholt Azure Event Grid den Zustellungsversuch mehrmals in größer werdenden Abständen. Hierbei ist zu beachten, dass Azure Event Grid nicht die Reihenfolge der Ereignisse in der Übermittlung garantiert. Scheitert die Übermittlung dauerhaft, so wird diese zurzeit verworfen. Einen Dead-Letter-Mechanismus, bei dem nicht übermittelte Ereignisse abgelegt werden, hat Microsoft derzeit nur in einer Preview-Version verfügbar. Die nicht zugestellten Ereignisse fließen dabei in einen Azure Storage Account. Von dort aus lassen sie sich dann anderweitig verarbeiten.

Azure Event Grid kommt innerhalb der Azure-Plattform bereits bei einigen anderen Diensten zum Einsatz. So gibt es eine ganze Reihe von Services, die Statusereignisse an Event Grid senden können. Beispielsweise sendet Azure Blob Storage Ereignisse nach dem Anlegen neuer Blobs. Auch auf der Abonnentenseite bietet Microsoft einige Dienste an, die direkt Ereignisse empfangen können, etwa Azure Functions. Hier stehen entsprechende Trigger bereit, die eine Azure Function auslösen, wenn ein neues Ereignis vorliegt.

Mit diesem Modell werden Sender und Empfänger von Ereignissen entkoppelt, sodass sich beide Seiten nicht kennen. Das ermöglicht eine gut skalierbare und flexible Kommunikation zwischen Diensten und dem System, bei dem sich auch im Nachgang neue Abonnenten hinzufügen lassen, ohne dazu den Sender anpassen zu müssen. Dadurch vereinfacht sich auch die Entwicklung reaktiver Serverless-Anwendungen.

Beispiel: Azure Function mit Event-Grid-Trigger

Dieses C#-Beispiel zeigt eine Azure Function, die den Benutzer bei Versand der Bestellung benachrichtigt. Azure Event Grid (EventGridTrigger) löst die Funktion aus, wenn das Versandunternehmen die Lieferung entgegengenommen hat. Dazu muss das Versandunternehmen einen Endpunkt von Azure Event Grid aufrufen und die Versanddaten übermitteln. Mittels der in den Event-Daten vorhandenen Trackingnummer lässt sich die zugehörige Bestellung aus der Cosmos DB laden. Über die Ausgabe-Bindung TwilioSms erfolgt dann der Versand einer SMS an den Besteller.

[FunctionName("EventGrid")]
 [return: TwilioSms(AccountSidSetting = "AccontSid", AuthTokenSetting = "AuthToken", From = "Telephonnummer")]
 public static CreateMessageOptions Run([EventGridTrigger]EventGridEvent eventGridEvent,
    [CosmosDB("store", "orders", ConnectionStringSetting = "CosmosDbConnectionString")] IEnumerable<Order> orders) 
 {
    var shippingEvent = eventGridEvent.Data as ShippingEvent;
    var order = orders.FirstOrDefault(o => o.TrackingNumber == shippingEvent.TrackingNumber);
    var message = new CreateMessageOptions(new PhoneNumber(order.MobileNumber)) {
        Body = $"Ihre Bestellung wurde {order.Id} verschickt",
    };
    return message;
 }

 public class Order {
    public Guid Id { get; set; }
    public string TrackingNumber { get; set; }
    public string MobileNumber { get; set; }
 }

 public class ShippingEvent {
    public string TrackingNumber { get; set; }
    public string State { get; set; }
 }

Azure Event Grid ist ein vollwertiger Serverless-Dienst. Dies schlägt sich in der Skalierung und im Preismodell nieder. Um die Skalierung müssen sich Entwickler nicht kümmern. Azure skaliert den Dienst automatisch, Microsoft bietet auch keinerlei Optionen zur Konfiguration an. Die Kosten für den Dienst berechnen sich nach Vorgängen. Der Eingang und der Übermittlungsversuch eines Ereignisses sind jeweils ein eigener Vorgang. Die ersten 100.000 Vorgänge pro Monat sind kostenlos. Danach bezahlt man zurzeit für 1.000.000 Vorgänge circa 0,50 Euro.

Aufgrund der einfachen Konfiguration, des günstigen Preismodells und der automatischen Skalierung eignet sich Azure Event Grid besonders für die Entkoppelung und Benachrichtigung von Diensten. Je nach Umfang und Last der Anwendung lässt sich Azure Event Grid im Idealfall sogar komplett kostenlos nutzen.