Hmm.. heute kommt ein SAP Newsletter mit einem Hinweis auf einen 6 wöchigen Online Kurs am HPI (im Rahmen der openHPI Initiative) über das In-Memory Data Management.
Der Kurs hat zwar schon vor 2 Tagen angefangen, aber ich schreibe mich mal dennoch ein. Keine Ahnung warum der Newsletter so spät rausging. Aber einen Kurs mit Hasso himself kann man sich doch nicht entgehen lassen, oder? Das ganze ist natürlich nur eine 25h Aktion, aber vielleicht ja dennoch interessant, ich werde hier berichten.
Oracle hat im JDBC Treiber (und dem eigenen Connection Pool) jede Menge Funktionen eingebaut, die über das Verhalten von JDBC hinausgehen. Oftmals wird dies mit Performance-Vorteilen begründet.
Man sollte diese Feature (nicht nur aus Kompatibilitätsgründen) nicht ungeprüft übernehmen, zum Beispiel hat JBoss AS einen OracleValidConnectionChecker, der mittels Relfection die Oracle Spezialfunktion pingDatabase() verwendet. Alternativ gibt es eine generische Implementierung, die einfach ein Statement absetzt.
Die Prüfung ob eine DB connection noch funktioniert (entweder regelmässig im Hintergrund oder bei jedem ausleihen aus dem Pool) ist recht wichtig für einen stabilen Systembetrieb - aber auch sehr Performancerelevant. Mit pingDatabase würde man so vorgehen:
Wenn man aber die Implementierung analysiert, so stellt man schnell fest, dass die aktuelle Version des Treibers hier nicht sonderlich effizient implementiert ist. Es wird das SQL Statement "SELECT 'X' FROM DUAL" abgesetzt. (Immerhin wird dazu vorher der Rückgabetyp deklariert: ((OracleStatement)stmt).defineColumnType (1, Types.CHAR, 1);)
Es wird kein prepared statement eingesetzt, dass heisst der Datenbank Server muss bei jedem Aufruf das Statement mühsam parsen. Wenn ein Timeout angegeben wurde, so startet der JDBC Treiber bei jedem Ping einen neuen Thread. Auf die timeout Funktion sollte also auf jeden Fall verzichtet werden (Oracle hat diese Variante auch deprecated).
Amazon EC2 ist ein IaaS Anbieter bei dem man eigene virtuelle Systeme starten kann. Diese Systeme können dann alle Systemfunktionen die eine Anwendung benötigt bereitstellen. Dazu gehört zum Beispiel auch der E-Mail Versand (z.B. root Mails oder eben E-Mails der Anwendung wie z.B. Passwort Reminder oder Notifications).
Um sicherzustellen, dass die E-Mails die von einem Amazon EC2 System abgeschickt werden auch ankommen, und nicht in Spam Filter der Provider hängenbleiben sind folgende Punkte zu beachten:
a) wenn man einen Mailserver (MTA) verwendet der die Mails versendet so sollte dieser natürlich sicher konfiguriert sein, und kein Relaying von E-Mails zulassen - da sonst der EC2 Server zur Spamschleuder wird (was nicht nur Ärger mit Amazon nach sich zieht).
b) Der SMTP Server meldet sich mit einem Rechnername. Dort sollte er nicht den internen Amazon EC2 Namen verwenden der dem Rechner zugewiesen wird, denn dir dort verwendete .internal Domain wird von vielen E-Mail Empfängern als ungültig abgelehnt.
c) Die E-Mail Adresse des SMTP Servers (also in dem Fall der virtuelle EC2 Host) sollte in einen gültigen Hostnamen aufgelöst werden, denn sonst springt der Spamschutz der Empfänger an. Dies ist bei Amazon nur sinnvoll machbar wenn man eine Elastic IP verwendet. Dieses Verfahren wird PTR oder auch "reverse DNS" checks genannt.
d) Der Envelop-From (im Falle von Cron Mails z. B. root@host) der versendeten E-Mails sollte eine gültige E-Mail Adresse sein. Insbesondere prüfen E-Mail Server beim Empfang, ob die Domain existiert. Hier sollte also auch nicht der .internal Hostname von AWS verwendet werden.
e) Die Domain einer Absender E-Mail Adresse sollten nicht nur gültig sein, sondern mit dem SPF Mechanismus (Sender Policy Framework) kann der Betreiber der Domain auch angeben von welchen Rechnern legalerweise Mails mit dem Absender versendet werden. Einige Empfänger benutzen das, um das Spamaufkommen zu reduzieren. In der Regel kommt in der Liste der zugelassenen Server nur die MX Server der Domain vor, und eben nicht beliebige IP-Adressen aus den Amazon AWS Netzen. Es bietet sich auch nicht an das komplette EC2 Netz in die Liste aufzunehmen, da sonst alle Amazon Kunden wiederum E-Mails am SPF Filter vorbei versenden können (das ist zwar weniger ein Problem aber eben unschön).
Aus diesen Punkten ergeben sich zwar einige Konfigurationen die man vornehmen kann um von einem EC2 Host direkt an Endempfänger Mails zu versenden. Die Wahrscheinlichkeit dass diese aber häufig als Spam erkannt werden ist groß. Deshalb ist es anzuraten, dass ein Smarthost verwendet wird. (Das hat auch administrative Vorteile wenn die EC2 Hosts Ihre Mails schnell loswerden und man nicht mehrere Mailwarteschlangen überwachen muss).
Um kein eigenes Relay betreiben zu müssen bietet es sich z.B. an den Simple E-Mail Service (SES) von Amazon zu verwenden. Dann muss man nur die SES E-Mail Server von Amazon AWS zusätzlich in die SPF Liste der Absenderdomain aufnehmen. Dies ist hier beschrieben: http://docs.amazonwebservices.com/ses/latest/DeveloperGuide/SPF.html. Im Gegensatz zum kompletten IP-Subnetz von Amazon EC2 hat man bei dieser Vorgehensweise den Vorteil, dass Amazon ein hohes Interesse daran hat, dass nur autorisierte Benutzer die Absenderadresse verwenden. (Gleiches gilt übrigens auch für Google App Engine, hier kann man auch Mail Relays in die SPF Liste aufnehmen). Zudem kann man sich danke Amazon IAM ein Benutzername/Passwort erzeugen der außer dem E-Mail Versand keine weiteren Rechte hat. Dieser kann man dann bedenkenlos im EC2 Image hinterlegen - zumindest solange man dieses nicht mit anderen Amazon Anwendern teilt. Sonst bietet es sich eher an diese Credentials beim Start mit anzugeben.
Im nächsten Post beschreibe ich, wie man bei einem AMI auf Basis von Amazon Linux diese Varianten realisieren kann.
Ich hab ein wenig mit Powershell herumgespielt (weil ich das Script das auch in de.Hackin9.org 08/2011 abgebildet war nicht verstanden habe).
Dabei kam dann folgendes funktionierendes Script heraus, es sortiert mit alle Rechner des AD LDAPs und zeigt diese in einem grafischen Viewer mit Betriebsystemversion und Servicepack Level an:
Ich habe aber keine Ahnung wie man einfacher aus den Dictionary Entries des $c.Properties Member direkte Properties machen kann ohne diese mit einer foreach Schleife und direktem Assignment aufwändig zu kopieren. Ich hoffe ein mitlesender Powershell Guru kann mir das kurz sagen? :)
Update:Max Trinidad (@MaxTrinidad) hat mich auf die Idee mit New-Object gebracht, damit lässt sich das Script etwas vereinfachen und die Attribute in Strings konvertieren:
Mir ist gerade zufällig aufgefallen (als ich diesen Bugreport nachgestellt habe) dass Windows 7 IPv4 Address-Einträge die eine führende 0 haben im hosts file ignoriert:
Leider macht es Oracle recht schwer die Archive für den Datenbank Install aus dem Oracle Technology Network ohne (grafischen) Web Browser herunterzuladen: Man muss angemeldet sein und den Lizenzbedingungen zustimmen. Dabei wird nicht nur JavaScript eingesetzt sondern auch ein Session Cookie verwendet. Das macht die Verwendung von wget - auch wenn man die download URL kennt - leider nicht möglich. Neben dem Herunterladen auf ein internes System mit grafischem Browser ist es stattdessen möglich entweder auf dem Zielserver einen Command-Line Browser zu verwenden der auch Cookies (und SSL) unterstützt oder eben wget auf dem Zielserver und vorher die Cookies mittels Command Line browser ermitteln.
Aktuell teste ich Software auf den HP/UX Servern im HP Partnerprogramm PVP. Diese Server sind recht minimalistisch ausgestattet. Um dort einen SSL fähigen Command-Line Browser zu erhalten benutze ich das Links Paket. Es benötigt Perl und OpenSSL als Abhängigkeiten und wird im Software Depot des HP Porting Centers angeboten (Dort gibt es zwar auch ein Lynx Paket mit weniger Dependencies, das ist allerdings ohne SSL Unterstützung). Einfacherweise installiert man sich zuerst den depothelper vom Porting Center. Dieser übernimmt den restlichen Download, das Auspacken und Installieren des Paketes und aller Abhängigkeiten:
# uname -a
HP-UX server B.11.31 U ia64 3663751510 unlimited-user license
# cd /var/tmp
# ftp hpux.connect.org.uk
User: ftp
Pass: root@
ftp> cd /hpux/Sysadmin/depothelper-2.00/
ftp> get depothelper-2.00-ia64-11.31.depot.gz
ftp> quit
# /usr/contrib/bin/gunzip depothelper-2.00-ia64-11.31.depot.gz
the next command requires an absolute path
# swinstall -s /var/tmp/depothelper-2.00-ia64-11.31.depot depothelper
now you can use depothelper to install a package with dependencies
# /usr/local/bin/depothelper links
================================================
Package-version Comment Download Install
================================================
ia64-11.31 Package list OK OK
db-5.0.26 Dependency (01/07) OK OK (+ deleted depot)
expat-2.0.1 Dependency (02/07) OK OK (+ deleted depot)
gdbm-1.8.3 Dependency (03/07) OK OK (+ deleted depot)
gettext-0.18 Dependency (04/07) OK OK (+ deleted depot)
libiconv-1.13.1 Dependency (05/07) OK OK (+ deleted depot)
openssl-1.0.0a Dependency (06/07) OK OK (+ deleted depot)
perl-5.10.1 Dependency (07/07) OK OK (+ deleted depot)
links-1.00pre23 Requested OK OK (+ deleted depot)
================================================
Wenn auf dem Server kein Links (mit Perl installiert werden soll, so gibt es auch Tipps wie man den Login auf OTN mit einem Lynx Browser auf einem Testsystem absolvieren kann und die dabei erhaltenen gültigen Cookies per File dann an wget auf dem Zielserver weiterreichen kann. Dies ist hier näher beschrieben.
Immer wieder liest man Empfehlungen dass man auf keinen Fall private Nutzung der Unternehmens-IT zulassen darf, dass es problematisch ist wenn man persönliche Mails duldet, ja sogar steuerlich schwierig ist, wenn man den Mitarbeitern geldwerte Vorteile (wie einen Internet Zugang) bietet. Auch vor den Sicherheitsaspekten wird gewarnt. Lizenzgründe oder Haftungsgründe werden angeführt.
Ich möchte mich hier mal auf die andere Seite stellen: warum haben Arbeitgeber ein Interesse daran, dass Mitarbeiter die Firmen-IT auch für Aktivitäten nutzen die nicht direkt im Geschäftsinteresse stehen.
Nun allen voran natürlich die Mitarbeiterzufriedenheit. Gute Mitarbeiter zu halten ist wichtig. Wenn diese ein offenes Klima erleben sind sie viel gewillter zu bleiben. Grade bei Überstunden oder exotischen Arbeitszeiten ist es wichtig nebenbei auch Kontakt mit den Lieben zu halten. Sich mit der Freundin im Messenger auszutauschen damit diese nicht den Arbeiter nach Hause zitiert.
Daneben ist jeder Mitarbeiter der sich im Web bewegt auch ein informierter Mitarbeiter. Im Zweifel auch ein Mitarbeiter der für das Unternehmen Werbung macht. Ganz gemäss des (schon öfters genannten) Cluetrain Manifests werden immer mehr Kunden durch direkte Kontakte mit Mitarbeitern auf Produkte aufmerksam.
Betrachtet man das Leben eines Consultants (Road Warriors) auf der Straße und in Hotels, so hat dieser gewiss andere Probleme als mehr als einen Notebook mit sich herumzuschleppen. Wird Ihm verwehrt diesen auch zum DVD Genuss einzusetzen, so wird er noch weiter benachteiligt und hat irgendwann kein Interesse mehr auf Außeneinsatz.
Die Nutzung von Diensten des Arbeitgebers wie Mail und IM sollte so offen gestaltet sein, dass Mitarbeiter gerne auch nach Feierabend diese Medien nutzen. Ganz im Interesse der Firma: die Mitarbeiter bleiben in Notfällen einfacher ansprechbar.
Das surfen am Arbeitsplatz - sei es nun in Wartezeiten oder der Mittagspause ist eine Entspannung vergleichbar mit der Raucherpause oder dem Mittagsspaziergang. Wird die Nutzung des Webs eingeschränkt oder strikt kontrolliert, so suchen sich kreativ arbeitende Köpfe andere Ablenkungen (zum Beispiel sinnlose Meetings). Es ist also nur in Ausnahmefällen so, dass die Produktivität dadurch gesteigert wird.
Unmotivierte Mitarbeiter die Zeit haben ihren Tag zu vertrödeln sind eine Herausforderung an das Team oder die Vorgesetzten, aber sicher nicht für die interne-IT.
In einem geschlossenen System geht keine Energie verloren. Schade dass Unternehmen kein geschlossenes System sind, denn es ist erschreckend wie viel Wissen und Erfahrung in einem Unternehmen verloren gehen kann.
Einer meiner Aufgaben ist die Beratung von Key Account Kunden bei komplexeren Projekten, um sicherzustellen dass Sie von unserer Erfahrung profitieren und natürlich um unsere Roadmap besser auf die Kundenbedürfnisse abzustimmen. Die Installation von Middleware ist meistens verknüpft mit Konsolidierungs- und Migrationsprojekten (in denen bestehende Anwendungen unterschiedlicher Hersteller auf eine neue Plattform zusammengefasst werden, ganz beliebt sind SAP Einführungen). Deswegen bekomme ich oft (am Rande) mit, wie schmerzhaft es sein kann in einem Unternehmen eine genaue Analyse der (Legacy) IST-Prozesse zu erstellen, oder für ein geplantes neues System die Mindestanforderungen zu definieren.
Ich treffe immer wieder auf die selben Muster:
Es werden andere (neue) Mitarbeiter mit der Umsetzung der neuen Projekte betraut. Entweder weil man den alten Hasen die neue Technologie nicht zutraut, weil die bestehende Mannschaft nicht aus dem Tagesgeschäft entlassen werden solll, oder weil die Verantwortlichkeiten schleichend neu verteilt werden sollen.
Egal welchen Grund es gibt die neuen Mitarbeiter haben keine Erfahrung mit dem Gesamtproblem, und die erfahrenen Mitarbeiter haben entweder keine Motivation oder Gelegenheit mehr zu helfen.
Die Vordenker die das alte System entworfen und vor allem weiterentwickelt haben sind nicht mehr im Unternehmen. Kleine Änderungen und Pflege wird vom Stammpersonal vorgenommen, aber keiner kann die Prozesse komplett überblicken.
Selbst die detaillierteste Systemdokumentation kann ein System (vor allem die Überlegungen bei der Umsetzung) voll beschreiben. Und selbst wenn sie es könnte, so ist sie nicht mehr vollständig erfassbar.
Der Teufel steckt im Detail: die Projekte sind meistens so angelegt dass keine Zeit für Fehler oder Verbesserungen eingeplant werden. Das Second System muss gleich perfekt sein, auch wenn die bestehende Anwendung über Jahrzehnte gewachsen ist. Das sind unrealistische Anforderungen, im besten Fall werden im Laufe des Projektes der Umfang der Pilotprojekte immer kleiner - und damit irgendwann machbar.
Mitarbeiter die für die Umsetzung Hauptverantwortlich sind werden so mit Fakten und Entscheidungen überschüttet, dass Verdrängungs- und Überschätzungsmechanismen einsetzen. Das Gesamtsystem aus einer anderen Sichtweise (z.B. aus Sicht des Controllings oder des Operatings, oder des Supports, oder oder) zu betrachten wird als unnötig oder zu aufwändig angesehen. Daraus ergeben sich oft Entscheidungen die sich im späteren Betrieb als sehr ineffektiv herausstellen.
Oftmals werden einfach zu wenige zentrale Rollen besetzt. Keyuser und Stakeholder aus unterschiedlichen Bereichen gibt es nicht, oder werden nicht gefördert.
Ein weiteres Problem sind knappe Deadlines und neue Technologien. Beide führen dazu dass Unternehmen externe Berater in allen Ebenen beauftragen. Das führt zu dem Effekt, dass die Überlegungen zur Umsetzung nicht immer im Besten Interesse der Firma sind, und die gemachten Erfahrungen auch mit dem Ende des Migrationsprojektes das Unternehmen wieder verlassen. Mehrere hundert Business und Technologie Consultants sind keine Seltenheit.
Ein Problem mit dem man fertig werden muss, ist auch die Tatsache dass die funktionierenden Prozesse nicht notwendigerweise effizient sind. Bei einer genauen Analyse werden die Schwachstellen entdeckt. Oftmals wird die Entscheidung zum Re-Engeneering aber zu leichtfertig getroffen. Der Projekt-Scope weitet sich somit aus.
Pilotprojekte werden oft auch falsch ausgesucht: zwar ist es Sinnvoll nicht mit dem Core Business als erstes auf eine neue Plattform umzuziehen, jedoch ist das bisher manuell betriebene Business einer ausländischen Zweigstelle nicht unbedingt repräsentativ. Von den Problemen wie Zeitverschiebung, kulturelle und Sprachlichen Barrieren oder fehlende Erfahrung der Stammbelegschaft ganz zu schweigen.
Vermutlich lassen sich all diese Probleme nur bedingt vermeiden. Aber wenn man immer wieder obige Punkte vor Augen hält kann man frühzeitig gegensteuern.
Zum Glück verliefen alle Projekte die ich so kenne mehr oder weniger erfolgreich. Hilfreiche waren dabei folgende Faktoren:
Heroes die Verantwortung und Kommunikation übernehmen. Immer wieder alle Parteien an einen Tisch holen.
Manager die Dank Sachverstand Abschätzungen hinterfragen können.
Starke Einbindung von internen Ressourcen in allen Phasen.
Iterative Umsetzung in kleinen Schritten.
Die Auswahl eines Leistungsstarken und flexiblen Softwarepartners mit herausragenden Mitarbeitern (*grins*)
Amazon's Utility Computing Platform EC2 zeichnet sich durch eine einfache Skalierbarkeit aus. Für Anwender die allerdings nicht kurzfristig mehrere hundert Compute Instanzen benötigen war das Pricing nicht so attraktiv. Amazon hat nun Reserved Instances angekündigt. Kann man sich auf eine gleichmäßige Nutzung einer Instanz committen, so sinken die Nutzungspreise erheblich. Ich habe das mal (bei einer Monatsnutzng von 30*24h) hochgerechnet:
Instanz
Stundenpreis
Norm Monat
Monat 1y
Monat 3y
Small
$0,10/$0,05
$72
$48,68
$35,49
XL
$0,80/$0,24
$576
$390
$284
Das Modell scheint bisher noch nicht für die Windows Server verfügbar zu sein. Details unter EC2 Pricing.
Was ich bei Amazon immer wieder gut finde ist es wie durch einfache Bezahlmodelle Anreize für ein bestimmtes Userverhalten geschaffen wird, und dies dank der Anzahl der Benutzer skaliert. Z.b. die Möglichkeit IP Addressen zu reservieren, und solange man diese nutzt sind sie kostenlos. So langsam kommt Amazon mit diesem Pricing in die Regionen von normalen V-Servern (mit dem zusätzlichen Benefit dass man jederzeit mehr Ressourcen auf Stundenbasis dazuschalten kann). Ganz konkurenzfähig sind die Server allerdings immer noch nicht - trotz Dollar Kurs.
Ich habe die Möglichkeit bekommen auf unternehmer.de IT Artikel zu veröffentlichen, und habe diese Möglichkeit genutzt einen Abgesang auf SOA zu verfassen. Die Beiträge bei unternehmer.de richten sich an kleine und mittelständische Unternehmen. Mal sehen ob sich damit die Reichweite meiner Artikel steigern lässt.
Der Oracle University Newsletter zum Ende des Jahres hat mich zum Schmunzeln gebracht, deswegen will ich Ihnen dieses YouTube Video (gefunden auf Irregular Enterprise Blog auf ZDNet) nicht vorenthalten.
Meiner Erfahrung nach werden im Enterprise Umfeld technische Infrastruktur Entscheidungen oftmals via Policy geregelt. Wenn dann neue Anwendungen installiert werden, so müssen diese sich in die vorhandene Landschaft einfügen - ohne gross eine Risikobewertung durchgeführt zu haben.
Typische Kandidaten für diese Vorgaben sind OS (unkritisch solange Erfahrungen damit vorliegen), Cluster, Netzwerk/Firewalls und Storage.
Gerade beim Storage ist das Vertrauen in ein Enterprise SAN grenzenlos (muss es auch sein, war ja teuer). Performance Engpässe werden nie auf der SAN Seite gesucht und Ausfälle werden nicht erwartet (als SPoF darf das SAN einfach nicht ausfallen).
Dabei gibt es ja auch alternative Ansätze. Lokales Storage (mit Sharding, Replikation), NAS oder auch die Auslagerung gewisser Daten in eine Storage Cloud. Auf jeden Fall sollte man sich überlegen: was passiert wenn mein SAN ausfällt, und wie schnell kann ich es wieder ans Laufen bringen.
In einem Artikel den ich auf Highscalability.com gefunden habe bespricht David Marks die Risiken eines SAN Infrastruktur für Web 2.0 Installationen, bei denen Skalierbarkeit und Verfügbarkeit natürlich oberste Prio haben: Should I get a SAN to scale my site architecture (You Can Change It Later Blog).
Amazon wurde gefeiert als sie SLAs für Ihre Cloud Offerings angeboten haben. Das bezieht sich insbesondere auf die Amazon Web Services Dienste S3 (Storage Cloud), EC2 (Compute Cloud), ECB (Elastic Block Storage) und die Host Lösungen für Queueing (SQS) und Datenbank (SimpleDB).
Betrachtet man sich allerdings die SLAs, so muss man sagen diese sind ziemlich nutzlos in einem kommerziellen Umfeld (um traditionalle Bedenken zu zerstreuen):
Die neuen EC2 SLA definieren, dass ein Kunde 10% der Gebühren für die letzten 365 Tage zurückerstattet bekommt, wenn die Verfügbarkeit unter 99.5% fällt. Dabei wird die Zurückerstattung nur für zukünftige Gebühren gut geschrieben. Die Zurückerstattung ist auf 10% gedeckelt. Strafen/Schadensersatz werden keine zugestanden. Und zu allem Übel ist die Definition der Verfügbarkeit noch so, dass der Kunde sich selbst darum kümmern muss ausgefallene Instanzen neu zu starten, und nur wenn dies nicht gelingt gilt der Service als ausgefallen. D.h. wenn eine Amazon Instanz alle Stunde ausfällt und der Startup einer neuen Instanz 5mins dauert, so gelten diese 5 Minuten nicht als Ausfall.
Bei den S3 SLA werden Gutschriften für erfolglose Requests gezählt. 10% bei unter 99.9% und 25% bei unter 99%. Dabei kann Amazon aber weder Requests zählen die nicht angekommen sind, noch steht Amazon mit Strafen/Schadensersatz für Datenverlust ein. Gleiches gilt für EBS, hier gibt es keine SLA, die typische jährliche Fehlerrate (AFR - Anual Failure Rate) wird mit 0.1% - 0.5% angegeben (Lokale Harddisks haben angeblich 4%).
Natürlich wird AWS durch diese SLA unter Druck gesetzt einen guten Service zu erbringen. Von daher haben diese schon einen Effekt. Der Kunde muss darauf aber vertrauen und das Risiko eines Schadens komplett selbst tragen. Eine reduzierte Amazon Rechnung wird Ihn da kaum trösten.
Cloud Computing definiert nicht nur die Technologie neu, sondern auch die Ökonomie des Outsourcings: statt ewig Langer Vertragsverhandlungen, umfangreichen SLA Monitorings, Schuldzuweisungen und umfangreiche Konventionalstrafen (die zu Aufschlägen beim Betreiber führen um sein Risiko abzusichern) wird auf ein Kooperatives Vorgehen gesetzt, das von Vertrauen geprägt ist. Deswegen haben es auch die Großen Anbieter in dem Markt einfacher akzeptiert zu werden. Die technischen Vorkehrungen die ein Betreiber trifft werden stärker betrachtet als seine Vertraglichen Zusagen. Zusätzlich ist die Lösung durch den Kunden schon stärker auf Ausfall ausgelegt.
(Diesen Artikel nehme ich zum Anlass eine neue Cloud Kategorie hier im Blog einzuführen)