Gerade zu Beginn eines Projektes ist es natürlich sehr angenehm, einfach die Service-Angebote der großen Cloud-Anbieter zu nutzen. Doch wenn die Architektur einer Anwendung mit der Zeit komplexer wird, reichen die zuschaltbaren Services oft nicht mehr aus.
Skalieren die Projekte oder erhöht sich der Traffic einzelner Services, können die Kosten recht schnell explodieren. Auch datenschutzrechtlich sind Cloud-Native-Strategien nicht unumstritten: Je nach Herkunftsort des App- oder Service-Anbieters unterscheiden sich die dort zu Grunde liegenden Bestimmungen zum Datenschutz erheblich von denen der darauf basierenden Anwendungen.
Dies ist ein Artikel aus unserer Print-Ausgabe 11-12/2021. Bestellen Sie ein kostenfreies Probe-Abo.
Mit erheblichen finanziellen Belastungen müssen Projektleiter insbesondere bei einem gewünschten Wechsel des Cloud-Providers rechnen: Nicht selten wird beim Festlegen ihrer Cloud-Native-Strategie vergessen, einen Wechsel einzuplanen; auch technisch ist der Umzug in eine andere Cloud oft nicht ohne weiteres möglich. Erst dann zeigt sich, ob Cloud-Native oder eher AWS- bzw. Azure-Native gearbeitet wurde.
Um nicht in Kostenfallen und einen Vendor-Lock-in zu geraten, ist Domain-driven Design geeignet zur Modellierung komplexer Software. Im Kern geht es bei DDD darum, monolithische Software-Architekturen zu vermeiden und die Anwendung stattdessen in fachliche Komponenten aufzuteilen. Sind diese in Container verpackt, lassen sich Clouds nutzen, ohne abhängig zu werden.
Bildquelle: Avision