Warum über­haupt in die Cloud?

Es gibt viele trif­tige Gründe Ihre aktu­elle Daten­hal­tung in die Cloud zu ver­schie­ben oder für eine neue Unter­neh­mung direkt die Arbeit in der Cloud zu begin­nen. Dies kann in gerin­ge­ren Kos­ten, bes­se­rer Per­for­mance, mehr Sicher­heit etc. begrün­det sein. Jedoch wird heute von den ver­schie­de­nen Cloud Anbie­tern jeder die­ser Aspekte in Super­la­ti­ven bewor­ben, was eine Unter­schei­dung auf dem Papier schwie­rig macht. Zudem han­delt es sich um kom­plexe Pro­dukte, wodurch die Aus­wahl einer Cloud Data Platt­form nicht auf ein­fa­che Art und Weise mög­lich ist.

Annah­men

In die­sem Arti­kel gehen wir davon aus, dass Sie bereits die Ent­schei­dung getrof­fen, dass eine On-premises Lösung nicht (mehr) das Rich­tige für Ihr Unter­neh­men ist und Sie nun in die Cloud migrie­ren oder von Grund auf den Betrieb der Daten­ban­ken in die Cloud ver­le­gen wol­len.
Wei­ter­hin neh­men wir an, dass Sie sich für ein RDBMS (Rela­tio­nal Data­base Manage­ment Sys­tem) ent­schie­den haben und nicht für eine andere Art von Daten­bank­sys­tem (NoSQL), die noch mal beson­dere eigene Her­aus­for­de­run­gen mit sich bringt.

Wel­che Arten von Cloud Datenbanken?

Eine Cloud-Daten­bank ist nicht gleich eine Cloud-Daten­bank. Es gibt ver­schie­dene Vari­an­ten, die ver­schie­dene Trade-offs hin­sicht­lich Kos­ten, Kom­ple­xi­tät, Auf­wand, Per­for­mance etc. mit sich brin­gen. Diese gilt es gegen­ein­an­der abzu­wä­gen und eine Ent­schei­dung auf­grund der eige­nen Bedürf­nisse zu treffen.

Cloud Daten­hal­tungs­tools kom­men gene­rell in drei ver­schie­de­nen Vari­an­ten vor: self-mana­ged, semi-mana­ged und fully-managed

Self-mana­ged: Diese Vari­ante einer Cloud Daten­bank läuft meist in einer vir­tu­el­len Maschine bei einem Cloud-Anbie­ter und umfasst die Instal­la­tion eines bekann­ten Daten­bank­an­bie­ters. Die vir­tu­elle Maschine kann dabei nach eige­nen Vor­stel­lun­gen ska­liert wer­den und bie­tet viel Fle­xi­bi­li­tät. Dadurch ist aller­dings auch der admi­nis­tra­tive Auf­wand hoch und die Ver­ant­wor­tung liegt zum aller­größ­ten Teil bei Ihnen. Es wurde pri­mär von der zugrunde lie­gen­den Hard­ware abstrahiert.

Semi-mana­ged: Eine Semi-mana­ged Cloud Daten­bank läuft größ­ten­teils noch immer in einer vir­tu­el­len Maschine bei einem Cloud-Anbie­ter. Diese wird jedoch zu gro­ßen Tei­len bereits vom Anbie­ter geman­ged. Die­ser küm­mert sich auch um die Instal­la­tion der Daten­bank selbst. Das Sizing des Clus­ters und die Kos­ten­op­ti­mie­rung lie­gen jedoch noch immer bei Ihnen. Der admi­nis­tra­tive Auf­wand sinkt etwas.

Fully-mana­ged: Bei einem fully-mana­ged DBaaS (Data­base as a Ser­vice) han­delt es sich um eine kom­plett vom Pro­vi­der ver­wal­tete Daten­bank. Sie als Kunde haben auf das Sizing, Ska­lie­rung etc. kei­nen Ein­fluss mehr. Dadurch sind sie auch am wenigs­ten fle­xi­bel, haben aber auch den gerings­ten Auf­wand hin­sicht­lich der Admi­nis­tra­tion. Häu­fig schlägt sich dies auch im Preis nie­der, jedoch muss die­ser stets ganz­heit­lich betrach­tet werden.

Defi­nie­ren der wich­tigs­ten Kri­te­rien für Ihr Unternehmen

Zunächst ein­mal soll­ten die wich­tigs­ten Fra­gen in den unten­ste­hen­den drei Kate­go­rien beant­wor­tet wer­den, die die Aus­wahl einer pas­sen­den Lösung im Wei­te­ren lei­ten wer­den. Die Fra­gen sind nicht voll­um­fäng­lich und sol­len pri­mär als Denk­an­stöße die­nen. Ihre Orga­ni­sa­tion hat ggf. noch wei­tere indi­vi­du­elle Kriterien.

1. Wer greift auf die Daten zu? 
   • Sind es pri­mär externe oder interne User?
   • Erfolgt der Zugriff direkt oder via einer Appli­ka­tion (Web­site, App etc.)?
   • Wel­che Funk­tio­nen wer­den von den Nut­zern verwendet?
   • Erfolgt der Zugriff zu Peak Zei­ten auf ein­mal oder über den Tag verteilt?
   • Erfolgt der Zugriff pri­mär lesend, schrei­bend oder beides?
   • Wie sieht das Ver­hal­ten in der Zukunft aus? Wird es sich ändern?
   • Kom­men noch viele Nut­zer hinzu oder bleibt der Nut­zer­kreis rela­tiv stabil?
2. Was für Belas­tun­gen gibt es?
   • Wie groß ist der initiale Load?
   • Wie groß sind die regel­mä­ßi­gen Deltas?
   • In wel­chem Zeit­raum erfolgt der Delta-Load?
   • Wie viele Anfra­gen erfol­gen maxi­mal parallel?
   • Wie sind die Anfra­gen geo­gra­fisch verteilt?
   • Wie sind die Anfra­gen zeit­lich verteilt?
   • Wie ver­än­dert sich die Belas­tung in Zukunft?
3. Wel­che Vor­ga­ben gibt es?
   • Was gibt es für regu­la­to­ri­sche Vorgaben?
   • Was gibt es für tech­ni­sche Vorgaben?
   • Was gibt es für Vor­ga­ben hin­sicht­lich Erreichbarkeit/Skalierbarkeit?
   • Was gibt es für Per­for­mance Vorgaben?
   • Wel­ches Bud­get steht zur Ver­fü­gung für eine initiale Migration?
   • Wel­ches Bud­get steht zur Ver­fü­gung für den Betrieb?
   • Wel­ches Bud­get steht zur Ver­fü­gung für Anpassungen?
   • Wel­che sons­ti­gen Vor­ga­ben gibt es aus der Orga­ni­sa­tion heraus?

Ver­gleich ver­schie­de­ner Lösungen

Auf Basis der obi­gen Fra­gen und ver­schie­de­nen Dimen­sio­nen kommt nun der Punkt, die ver­schie­de­nen Anbie­ter mit­ein­an­der zu ver­glei­chen. Dabei sollte zunächst eine Long­list aller poten­zi­el­len Anbie­ter und im Wei­te­ren durch das Aus­schluss­ver­fah­ren eine Short­list der mög­li­chen Lösun­gen erstellt werden.

Einen guten Start­punkt, wel­che Platt­for­men infrage kom­men und wie sie auf den ers­ten Blick ein­zu­ord­nen sind, geben Ver­gleichs­ser­vices, wie etwa G2.com.

Mit der ent­spre­chen­den Short­list soll­ten dann jeweils Gesprä­che und Demos in Zusam­men­ar­beit mit den jewei­li­gen Her­stel­lern abge­stimmt wer­den. Dabei ist es wich­tig anhand der zuvor erar­bei­te­ten Kri­te­rien Test Cases zu ent­wi­ckeln und diese direkt auf den Demo-Sys­te­men zu bench­mar­ken. Nur so ist ein objek­ti­ver Ver­gleich in der rea­len Welt und mit den tat­säch­lich rele­van­ten Use-Cases zu gewährleisten.

Die Fra­gen und Gewich­tun­gen der ein­zel­nen Aspekte müs­sen von jedem Unter­neh­men selbst bestimmt und auf die jewei­li­gen Anbie­ter ange­wandt werden. 

Fol­gende Punkte ver­an­schau­li­chen, was für Unter­schiede es im Detail bei den Anbie­tern geben kann:

• Was für Workloads sol­len genau statt­fin­den? Sind es ana­ly­ti­sche Workloads mit vie­len Aggre­ga­tio­nen oder doch ein­zelne Zei­len Abfra­gen? Hier unter­schei­den sich die Ange­bote ver­schie­de­ner Anbie­ter stark.
• Bie­tet der Anbie­ter Clus­ter / Warehou­ses an, die her­un­ter­ge­fah­ren wer­den kön­nen, wenn sie nicht gebraucht wer­den und las­sen sich damit grö­ßere Kos­ten spa­ren? Wenn ja, wie rea­lis­tisch ist es, dass die Workloads wirk­lich zurück gefah­ren wer­den können?
• Wel­che Kos­ten fal­len bei ein­ge­hen­dem und aus­ge­hen­dem Netz­werk­ver­kehr an? Wie viele Daten sind vor­ge­se­hen in wel­che Rich­tung zu transferieren?
• Wie schnell kann ein Anbie­ter unter ver­schie­de­nen Workloads wirk­lich ska­lie­ren? Erfah­rungs­ge­mäß gibt es je nach Art des Workloads und dem jewei­li­gen Anbie­ter große Unterschiede.

Ent­schei­dung treffen

Die Ergeb­nisse in Bezug auf Per­for­mance, Kos­ten, Clus­ter-Größe etc. kön­nen dann in tabel­la­ri­scher Form aus­ge­wer­tet und mit Punk­ten hin­sicht­lich der Wich­tig­keit in Ihrer Orga­ni­sa­tion gewich­tet werden.

Die Ent­schei­dung, wel­ches Sys­tem es am Ende wird, kann auf Basis der Punk­te­ver­tei­lung getrof­fen wer­den. Vor allem hin­sicht­lich der Kos­ten ist hier stets eine ganz­heit­li­che Betrach­tung im Sinne der Total Cost of Owner­ship wichtig.

Fazit

Die Aus­wahl eines Cloud Data Platt­form ist ein kom­ple­xer Pro­zess mit viel­fäl­ti­gen Abhän­gig­kei­ten und Dimen­sio­nen, die es zu beden­ken gilt.

Zum einen muss das Ver­hal­ten und die Menge der zukünf­ti­gen Nut­zer abge­schätzt wer­den. Auf der ande­ren Seite muss abge­steckt wer­den, was für Belas­tun­gen es aktu­ell und in Zukunft geben wird, um Lösun­gen in mit einer ange­mes­se­nen Ska­lier-Fähig­keit bereit­stel­len zu kön­nen. Am Schluss sind auch noch diverse Ein­schrän­kun­gen recht­li­cher, orga­ni­sa­to­ri­scher, tech­ni­scher etc. Natur mit ein­zu­be­zie­hen. Sobald alle Anfor­de­run­gen genutzt wur­den, um eine Short­list zu erstel­len folgt ein Bench­mar­king der Lösun­gen unter zuvor defi­nier­ten Test­fäl­len. Auf Basis der Resul­tate und der Total Cost of Owner­ship kann dann eine Ent­schei­dung getrof­fen werden.