Posts Tagged: ‘cloudblog’

Cloud macht Analytics Beine

22. Oktober 2013 Posted by Philipp Boltze

 

Bild

Wer letzte Woche auf der IBM Business Connect in Mannheim war, wird meinen Vortrag mit gleichem Titel vielleicht schon gehört haben. Für alle Anderen möchte ich hier aber nochmals beschreiben, warum Cloud und Analytics so wunderbar zusammen passen ....

 

BildImmer mehr Leute ....  wollen immer mehr Daten .....  in immer anderen Formen  ....  immer schneller  .....   analysieren. So oder so ähnlich mag der Leiter Business Intelligence - Mr. B.I. -  eines großen Konzern gedacht haben, als er mit seinem Problem zu uns kam.
Aber das oben Beschriebene ist eigentlich gar nicht ein Problem an sich. Dumm ist nur, dass die dafür erforderliche IT Infrastruktur exponentiell wächst (2 x 2 x 2 x 2 = 16!). Und das noch Dümmere ist, dass so eine BI Umgebung ja nicht immer den gleichbleibenden IT Bedarf analog zu einer Glühbirne benötigt, sondern es Lastspitzen gibt und die Hardware muss so groß ausgelegt werden, dass auch die Lastspitzen abgefangen werden können. Ganz schön doof, ganz schön umflexibel und ganz schön teuer!

 

Tja, und wie können wir nun diesem armen Mann helfen? 

"Was wäre denn, wenn Sie unbegrenzte IT Ressourcen hätten und für diese auch nur so lange zahlen müssten, wie Sie sie benötigen?"    -   "EIN TRAUM!"

 

Der aufmerksame Leser wird sicher schon ahnen, was jetzt kommt:       Ab in die Cloud!

 

Schnell war klar, dass wir hier den Beweis antreten mussten. Ein Proof of Concept.

 

Und das Konzept war einfach: Lade Deinen Daten in unsere IBM Cloud. Wir bereiten ein DB2 und ein Cognos Image soweit vor und können nun beide so oft und so viel hoch- und runterfahren wie wir wollen. Also mal ein einzelner Cognos Server, mal 3 parallel. Je nachdem, was benötigt wird.

 

Die Ergebnisse konnten sich mehr als sehen lassen. 

Bild

Ich will sie auch gar nicht weiter kommentieren.

 

Ein wichtiger Punkt dabei ist es natürlich, wie ich dieses "Atmen" des Systems, also das Hinzufügen und Wegnehmen von Instanzen realisiere. Erst wenn ich das mache, kann ich die Vorteile der Cloud, z.B. stundenweise Abrechnung, nutzen. Wir haben uns dabei zwei mögliche Varianten angeschaut:

Bild

  1. Zeitgesteuert
    Aus Erfahrung weiß man, daß Montag früh z.B. viele Nutzer sich ihre Reports holen und dass am Mittwoch Nachmittag eher Saure-Gurken-Zeit ist. Basierend auf diesen Erfahrungswerten kann man, durch sog. Scripte gesteuert, Instanzen hinzufügen und wieder wegnehmen. Man kann damit allerdings nicht auf unvorhersehbare Ereignisse reagieren. Zumindest nicht automatisiert.
     
  2. Workload gesteuert
    Die andere Möglichkeit ist es, sich die Anfragen anzuschauen, und ähnlich wie an der Aldi Kasse einfach neue Instanzen (Kassen) hinzufügen, wenn die Schlange zu lang wird. Da das Hinzufügen eines neuen Servers allerdings einige Minute in Anspruch nimmt, muss man sich auch anschauen, wie viel im Einkaufskorb, respektiv wie umfangreich der Report ist und die Warteschlange entsprechend bewerten. Hier gehört durchaus etwas Intelligenz rein; man bekommt dann aber auch ein System, dass sehr schnell auch auf unerwartete Gegebenheiten reagiert.

 

 

Aber was haben wir daraus gelernt?

 

  • Clouds, zumindest wenn man sie sich mit Anderen teilt (shared), können zwar kaum Leistungsgarantien geben, aber zumindest die IBM Cloud hat trotzdem alle Erwartungen mehr als übertroffen.
    Wer jetzt noch auf Private Clouds geht, wie sie SoftLayer anbietet, der bekommt nicht nur eine stundengenaue Abrechnung, sondern muss sich die Leistung noch nicht mal mit Anderen teilen. (siehe dazu sich meine Blog zu SoftLayer)
     
  • Das Hinzufügen und Wegnehmen von zusätzlichen Cognos Instanzen geht sehr schnell und einfach
     
  • Es muss im Einzelfall geprüft werden, ob man die kostengünstigere, zeitgesteuerte Variante nehmen kann, oder doch den Aufwand betreiben muss, die Workload qualitativ zu bewerten.
     
  • Ganz entscheidend, und damit kommen wir zum berühmten Bottleneck der Lösung, ist die Verbindung zwischen dem Datenpool und der Cloud. Ich muss wissen, wie viele Daten in die Cloud transferiert werden müssen und vor allem auch welche Spitzenlast, also wie viele Daten in einem bestimmten Zeitraum übertragen werden müssen. Dies bestimmt dann die Verbindung: Entweder eine einfache VPN Verbindung oder doch eine Direktverbindung mit extrem hohem Datendurchsatz.
     
  • Und zum Thema Datenschutz muss sich natürlich jeder selbst Gedanken machen. Hier muss man aber vor allem prüfen, WELCHE Daten ich wirklich in die Cloud transferieren muss, um daraus Reports zu ziehen. Eine Versicherung ist sicher eher an der Auswertung der etwas unkritischeren Rechnungsdaten interessiert und nicht an der Krankenakte des Kunden.

 

Sie sehen an diesem Beispiel, wie einfach und sinnvoll es ist, Analytics in der Cloud zu betreiben. Sprechen Sie uns doch einfach mal an, wenn auch Sie an einem Test (PoC) interessiert sind.

 

 

 

Schlange oder Frosch – Auf dem Weg in die Cloud

1. Oktober 2013 Posted by Philipp Boltze

 

Der aufmerksame CloudBlog Leser wird sich langsam fragen, was denn nun als nächstes kommt. 

Ich konnte Sie hoffentlich von den Vorzügen der Cloud überzeugen, Ihnen klar machen, wie wichtig Standardisierung ist und Ihnen sogar noch den Fachbegriff DevOps grob erläutern. Aber was nun? 

 

Dazu passt einen gerade geführte Diskussion mit einem großen, internationalem Kunden, mit dem wir nun schon mehre Workshops hatten und genau dieses Thema sehr intensiv diskutieren: Wie bekommen wir seinen 1.000 in ganz Europa verstreuten Server in die Cloud?

 

Lassen Sie mich dazu nochmals ganz kurz ausholen: Er möchte ja nicht wirklich seine Rechner in die Cloud stellen, sondern seine Anwendungen

Bei Anwendungen unterscheidet man erstmal in zwei Kategorien:

 

BildBild1. Born on the Enterprise - also Anwendungen die in einem traditionellen Umfeld mit lokalen Servern, vielleicht bereits virtualisiert, im eigenen Unternehmen entstanden sind und dort auch heute betrieben werden. Diese Anwendungen skalieren typischerweise vertikal, also wer mehr will, braucht einen größeren Server. Sie bauen auf existierenden Middleware (z.B. Datenbank) auf und sind kompatibel mit bestehenden Systemen. Sie werden dann Cloud Enabled.

 

2. Born on the Web - also Anwendungen, die speziell für die Cloud geschrieben und dort "geboren" sind. Sie sind typischerweise hoch elastisch und skalieren horizontal, wer also mehr will, nimmt einfach mehr Server. Sie basieren auf standardisiertern Servern und nutzen somit das neue Umfeld voll aus. Diese Anwendungen sind also Cloud Centric.

 

Kommen wir aber wieder zu den 1.000 Servern zurück. Im Zweifelsfall weiß der Kunde bereits, was das für Server sind, wie groß sie sind und welche Ausstattung drin ist. Falls nicht, gibt es dazu auch einfache Sniffer Tools. Aber das sagt einem halt noch wenig über die Anwendungen, die darauf laufen und im Zweifelsfall nur einen Bruchteil der vorhandenen Ressourcen wirklich nutzen. Würde man  also eine Cloud bauend, die genau so groß ist, wie die Summe der 1.000 Server wäre sie viel zu groß - und im Zweifelsfall auch viel zu teuer!

Also muss der Kunden wissen, was das für Anwendungen sind: Wer sind die User, wie sehr schwanken die Ressourcenanforderungen der Anwendung (Volaität), benötigt die Anwendungen spezielle Hardware, Betriebssysteme  oder Middleware?

 

Ich habe hierzu mal eine MindMap erstellt, was man denn alles über seine Anwendungen wissen sollte - die Betonung liegt auf sollte. Denn die Realität ist meist doch ganz anders. Der Eigentümer einer Anwendung hat vor 3 Jahren das Unternehmen verlassen. Mit ihm auch alles Wissen zur Anwendung selbst. Keiner traut sich sie einfach zu beenden, da man natürlich nicht weiß, wer oder welche anderen Systeme alles darauf zugreifen. 

Der Frust-Faktor dieses Arbeitsschrittes ist also beliebig groß!

Bild

 

Nehmen wir aber mal an, dass wir einigermaßen die Daten zu den Anwendungen bekommen haben. Jetzt kann man, z.B. mit Hilfe des IBM eCumulus Tools erkennen, welche Anwendungen die berühmten "low hanging fruits" sind, also die Systeme, die man mit relativ geringen Aufwand migrieren kann und die dann relativ viel Nutzen bringen. Reif also für die erste Welle in die Cloud

 

Es ergeben sich damit mehrere Wellen, in denen die Anwendungen Schritt für Schritt in die Cloud transferiert werden. Und es bleiben sicher noch eine ganze Menge übrig, die sich nicht lohnen oder aus technischen Gründen gar nicht in die Cloud transferiert werden können.

 

Soviel also zu den bestehenden Anwendungen, die ja typischerweise zur ersten Kategorie - Born on the Enterprise - gehören

 

Aber, so fragte sich der CIO, was ist, wenn ich einen "leapfrog" (übersetzt: Bocksprung) mache. Ich also wie ein Frosch von der alten Welt gleich in die Neue springe? 

 

Klar, eine gute Idee! Warum sich wie eine Schlange durch das Tal der Migrationstränen schlängeln, wenn ich auch gleich auf eine neue Cloud-Anwendung springen kann. Entweder selbst geschrieben oder gleich fertig, vielleicht sogar als Software as a Service (SaaS) eingekauft. Um dies zu beurteilen muss ich in einem Business Case die Kosten der Neuanschaffung und Einführung dem Aufwand der Migration gegenüberstellen. Also doch wieder alle Informationen zu den Anwendungen. Und zusätzlich natürlich noch "Was macht sie eigentlich?" und "Gibt es eine vergleichbare Anwendung für die Cloud auf dem Markt?".

 

Dies mag der Grund sein, warum so viele Unternehmen sich anfänglich dazu entschließen mit ganz neuen Projekten und Anwendungen in die Cloud zu gehen und erst im zweiten Schritt sich über die bestehenden Anwendungen Gedanken machen. 

Die Frage lautet also: Will ich schnell, punktuelle Erfolge oder mittelfristig mein Unternehmen auf ein neues, agiles Bereitstellungsmodell umstellen?

 

Wie ist das bei Ihnen?

 

DevOps für “ganz Dummies”

17. September 2013 Posted by Philipp Boltze

 

BildSeit Monaten sagt mir unser Cloud Architekt, dass DevOps und Cloud unbedingt zusammen genannt werden müssen. Er geht sogar soweit, dass er sagt  " DevOps macht erst Sinn in Kombination mit Cloud"

 

Ist ja alles schön und gut, aber was ist DevOps? Spätestens nach dem 2. Satz konnte ich ihm dann nicht mehr folgen. Hat das was mit DefCon, der Verteidigungsbereitschaft oder dem Computerspiel zu tun? Oder ist es nicht der Lageraum des amerikanischen Präsidenten, in dem er den  Überfall auf Bin Laden verfolgt hat?

 

Kürzlich hat er sich aber ein Herz  - und ganz viel Zeit - genommen, um DevOps für so "ganz Dummies" wie mich zu erklären. Und ich habe es verstanden. Zumindest in Grundzügen und möchte das Gelernte hier gerne wiedergeben, damit auch andere davon profitieren können.

 

 

BildEs war einmal ein alter Kampf zwischen Anwendungsentwicklern und den Kollegen im Rechenzentrum, die die  Anwendungen dann betreiben. Bei Asterix und Obelix wären das bestimmt die Ost- und die Westgoten  Beide scheinen wohl in der Vergangenheit wenig miteinander gesprochen zu haben. 2 Mal im Jahr purzelte aus der Anwendungsentwicklung ein neues Release, dass dann getestet und schließlich in Produktion genommen werden musste. So weit, so gut.

Mittlerweile ist die Welt aber eine Andere: Die Fachabteilung fordert ständig neue oder veränderte Funktionen und kann nicht mehr 6 Monate darauf warten. Beim Webphotodienst Flickr purzeln mittlerweile bis zu 10 neue Releases pro Tag aus der Entwicklung! Und, wie gesagt, jedes neue Release muss getestet werden, bevor es produktiv eingesetzt werden kann. Produktiv einsetzen heisst Testen, Testen und nochmals Testen; idealerweise unter produktionsnahen Bedingungen. Ein Test der Anwendung funktioniert nicht ohne Infrastruktur - die Ostgoten brauchen also die Westgoten. 

Entwicklung und Betrieb müssen also sehr eng zusammenarbeiten - Hand in Hand. Vor allem die Bereitstellung von Testumgebungen muss extrem schnell gehen. Am besten automatisiert und standardisiert.

Automatisiert? Standardisiert? Spätestens hier klingelten bei mir natürlich alle Cloud-Glocken. Logisch. Wo sonst kann man innerhalb von Minuten ganze Systemlandschaften schnell und einfach aufbauen, betreiben und genauso schnell auch wieder verwerfen. in der Cloud natürlich.

 

Aber reicht es denn aus, einfach eine ganz normale Infrastruktur Cloud zu nehmen - also IaaS?

Sicher ist das schon einmal ein guter Anfang und man spart auf jeden sehr viel Zeit bei der Bereitstellung der virtuellen Server. Aber 10 "Drops" pro Tag, wie im Fall Flickr, oder auch nur im 10 Monat wird hiermit schon zur Herausforderung. Was wäre wenn bei der  Anwendungsbereitstellung gleich die notwendige Infrastruktur mit aufgebaut wird, automatisierte Testroutinen ablaufen und nach erfolgreichen Testläufen ebenso ein Rückbau erfolgt?

 

Der Testaufbau und das Testverfahren müssen hochgradig standardisiert und automatisiert erfolgen. Der Tester kann sich nicht erst noch Gedanken machen, welche Systeme wo und wie notwendig sind. Hier hilft eine weitere, ganz entscheidende Cloud Funktionalität der IBM: Patterns. Sie sind nicht nur einfach eine Abfolge von Befehlen (Scripte), sondern erkennen intelligent was von Seiten der Applikation erforderlich ist und was auf der Infrastruktur-Seite vorhanden ist. Dementsprechend werden dann ganze Landschaften, in unserem Fall Testlandschaften, in wenigen Minuten aufgebaut und vorher hinterlegte Testverfahren angestoßen. Dies ersetzt zwar nicht den Job des Testers (auch wenn in vielen Fällen automatisierte Tests heute Gang und Gebe sind), erleichtert ihn aber ungemein. 

In einem meiner nächsten Blogs werde ich nochmals genauer auf das Thema Patterns eingehen, denn erst sie machen aus Clouds intelligente Clouds.

 

So, nun hoffe ich, dass ich mein neu erlerntes Wissen an Sie weitergeben konnte und auch Sie jetzt den Begriff DevOps  einsortieren können und zumindest so tun können, als ob Sie schon seit Ewigkeiten nach diesem Verfahren arbeiten.

 

Sollten Sie aber Appetit auf mehr DevOps bekommen haben, so empfehlen ich Ihnen den, von Michael Brokmann und Robert Michel geschriebenen Guide "DevOps für Einsteiger" und die speziell für DevOps angelegte Webseite

Hier erfahren Sie dann auch mehr über die Verbindung der beiden Reiche und die Bedeutung des aufkommenden Riesen Cloud.

 

You can have any color – as long as it’s black.

6. September 2013 Posted by Philipp Boltze

 

You can have any color - as long as it's black.

 

imgres.jpg

Kennen Sie diesen Spruch von Henry Ford aus dem Jahre 1908? Er begründete damit die Industrialisierung des Automobils und machte es für eine breite Käuferschicht bezahlbar.

Mit Hilfe von von standardisierten Teilen wurden am Fließband Autos zusammengebaut. Und die Standardfarbe war nunmal "black".

 

 

Seitdem ist in der Automobilindustrie viel passiert, aber das Grundprinzip ist geblieben. Auch heute spricht man noch von Standard-Komponenten, wie z.B. der Bodengruppe. Oder schauen Sie sich mal bei VW, Skoda und Seat die Bedienungselemente für die Heizung an: Standard!

 

Tja, und bei der IT? Seit Jahren wird über Standards geredet, aber wenn man in die Realität schaut, findet man in den meisten Rechenzentren immer noch einen Haufen unterschiedlicher Rechner, die für die jeweiligen Einsatzgebiete und Anwendungen speziell angepasst sind.

 

 

Und was macht Cloud?

 

Cloud proklamiert den Standard! Den standardisierten Server, die standardisierte Plattform oder die standardisierte Applikation. Je größer die Standardisierung, desto mehr Anwendungen kann ich aus dem gleichen "Clloud-Topf" bedienen und dadurch Kosten sparen: Bei der Hardware, beim Betrieb der Server und auch beim Betrieb der Applikationen. 

Jetzt fängt Cloud an Spaß zu machen. Ich bin immer wieder wieder erstaunt, in wievielten Unternehmen die IT von Standards spricht, aber in Wirklichkeit nur jede Applikation und jeden Service genau beschrieben hat und dies in einem Services dokumentiert, der den Umfang der Gelben Seiten von New York hat. 

Lassen Sie mir ein - vielleicht in die andere Richtung extrem - Beispiel geben:  Die Standard Servern auf der IBM SmartCloud Enterprise:

 

Pasted Graphic.tiff

 

Dazu gibt es dann einige wenige Betriebssystemimages sowie  Storage-Blöcke und ein paar Infrastruktur Optionen. 

That's it.

Dann kann ich den Server auch ab 7 Cent / Stunde anbieten.

 

Pasted Graphic 2.tiffFür einen Kunden haben wir mal aufgemalt, wie viele seiner bisherigen Instanzen er mit einigen wenigen Standard-Größen abdecken kann.

 

Sicherlich kann man sagen, dass hier Ressourcen "vergeudet" werden, weil wir hier mehr CPU oder RAM zu Verfügung stellen, als unbedingt notwendig. Auf der anderen Seite wird man sowieso eine gewisse "Überprovisionierung" vornehmen. Ähnlich wie bei Airlines bucht  man mehr Instanzen auf die Cloud, als eigentlich Ressourcen vorhanden sind, da man erfahrungsgemäß nur selten die vollen Kapazitäten ausschöpft.

 

Aber was interessiert das Mr. Business?

Sehr viel! Denn in Zukunft wird er bei jeder neuen Anforderung gefragt: Willst Du Deine Lösung auf einem Standardserver aus der Cloud in 10 Minuten haben oder sollen wir einen individuellen Server in 10 Wochen beschaffen? Ach ja, und wenn Du dann mal mehr oder weniger Kapazität als geplant brauchst ist das in der Cloud auch kein Problem.

Es geht um Schnelligkeit, Agilität und Flexibilität.

Die Cloud ist da, hat Platz und geht schnell. Alles Andere, Individuelle, dauert Zeit und kostet viel Geld.

 

Mr. Business muss sich also zukünftig sehr genau überlegen, ob er wirklich den genau passenden Server für seine neue Anwendung haben möchte, oder vielleicht doch besser eine günstige, schnelle Lösung mit einem Cloud Server "von der Stange".

 

Bei sehr vielen Kundendiskussionen erlebe ich immer wieder, dass sich die IT nicht traut Standards festzulegen und sie dann dem Business gegenüber durchzusetzen. Auf der anderen Seite erlebe ich aber auch, dass das Business eigentlich sehr schnell zu überzeugen ist, wenn man die Sachverhalt und die Vorzüge einer Cloud erläutert. Wichtig ist dabei immer die Wahlfreiheit: Standard in 10 Minuten oder Individuell in 10 Wochen.

 

Und wie funktioniert das bei Ihnen?

 

 

Lesen Sie dazu auch meinen Blog zum Thema Shades of Cloud. in dem erklärt wird, warum Mr. Business, Mr. Rechenzentrum und Mr. CIO alle von Cloud reden, aber etwas unterschiedliches damit meinen.

 

 

 

 

Shades of Cloud

27. August 2013 Posted by Philipp Boltze

Shades of Cloud - hat das was mit Shades of Grey, dem gerade sehr stark diskutierten Erotikroman zu tun? 

 

Leider nicht, da muss ich Sie enttäuschen.

 

Aber die Geschichte ist auf eine andere Art und Weise spannend und lesenswert:

 

Seit mehr als 2 Jahren diskutiere ich in zahllosen Kundensituationen Cloud und , wie sollte es anders sein, kann man viele der Diskussionen und Gesprächspartner irgendwie kategorisieren. Zumindest kommen oft ähnliche Argumente:

 

  • Da gibt zum einen den IT Experten, nennen wir ihn mal Mr. Rechenzentrum.
    Für ihn ist Cloud nicht wirklich etwas Neues. Das macht er, nach seinen Aussagen meist schon seit mehreren Jahren. Virtuelle Systeme sind für ihn Tagesgeschäft und er könnte sie mir innerhalb weniger Minuten zur Verfügung stellen. Eine typische Aussage könnte sein: "Ich verstehe den ganzen Hype rund um Cloud gar nicht. Und mit einer Public Cloud brauchen Sie uns gar nicht erst zu kommen. Unsere Daten sind viel zu sensibel und die Systeme müssen 100% ausfallsicher sein."

 

  • Dann gibt es den IT Manager, er könnte Mr. CIO heißen.
    Er steckt gerade in der Zwickmühle. Sein Vorstand liest immer wieder, dass Cloud die Zukunft ist und man damit ganz viel Geld sparen kann. Er solle doch mal eine Strategie entwickeln, wie die Firma auf Cloud umsteigen kann. Gleichzeit sagen ihm aber seine Leute (Mr. Rechenzentrum), dass sie doch schon eine Cloud haben und die Firmendaten externen Cloud Providern anzuvertrauen viel zu unsicher sei. Ein typisches Zitat könnte sein: "Wie soll ich diesen ganzen Cloud- und Flohzirkus unter Kontrolle halten? Ich habe genug mit dem Tagesgeschäft zu tun und bei den Budgetkürzungen kann ich mich nicht noch um neue Projekte kümmern."

 

  • Es gibt aber auch den Finanzer oder Controller mit Namen Mr. Pfennigfuchser.
    Er liest aufmerksam die Fachpresse und für ihn ist Cloud ein Synonym für Geld sparen. Die hohen und undurchschaubaren IT Kosten waren ihm schon immer ein Dorn im Auge. "Mit Cloud Computing habe ich endlich Transparenz über meine Kosten und reduziere mein CAPEX erheblich" - so ein typischer Kommentar.

 

  • Last but not least gibt es natürlich den Leiter der Fachabteilung, z.B. den Vertriebs- oder Entwicklungschef. Ich nenne ihn mal Mr. Business. 
    Er macht  iCloud auf seinem iPhone. Hier nutzt er schon kräftig Apps wie DropBox, iMessage oder Evernote um Dateien mit seinen Mitarbeitern und Kunden zu teilen, zu kommunizieren oder einfach nur seine Notizen zu verwalten. Für ihn ist Cloud einfach, schnell und für jeden sofort verfügbar. Beim letzten Branchenkongress hat er neidisch zu Kollegen geschaut, die auf ihrem iPad sofort die gewünschten Verkaufsanalysen hatten oder mit ihren Kunden über soziale Netzwerke Kontakt hielten. Sein Motto lautet: "Um im Markt überleben zu können, muss ich schnell und kreativ sein. Hindernisse werden entweder aus dem Weg geräumt oder umgangen"

 

Na, finden Sie sich schon wieder? Oder zumindest Ihre Kollegen?  

 

Sie sehen aber schon, dass Cloud nicht gleich Cloud ist. Jeder hat ein anderes Verständnis davon und eine andere Erwartungshaltung. Technisch gesehen reden aber alle von der gleichen Lösung, oder zumindest einer ähnlichen.

 

 

 

Und das ist genau das, was ich mit Shades of Cloud meine. Wenn mir jemand sagt, dass er einen Cloud hat, frage ich immer, was er denn genau anbietet: Durch Virtualisierung erreicht man Effizienz. Durch weitere Automatisierung kommt Geschwindigkeit mit rein. Mit Standardisierung beginnen die Synergien und Flexibilität. Den vollen Spaß und Agilität einer Cloud gibt es aber erst, wenn man "cloudifiziert" hat, also die Services auch wirklich schnell, einfach und bedarfsgerecht zur Verfügung stellt.

 

Uff, das war jetzt eine ganze Menge für den armen User, der "einfach nur schnell mal etwas machen wollte". 

Man kann es aber auch in einem Satz zusammen fassen: Geben Sie sich erst zufrieden, wenn durch  Cloud beim User die erwartete Flexibilität und Geschwindigkeit angekommen ist. 

 

Lassen Sie mich den Blog heute mit einem kleinen Beispiel aus der realen Welt abschließen:

 

Die IT Abteilung eines großen Weltkonzerns ist in Sachen Cloud schon recht gut unterwegs: Virtualisierung, Automatisierung, ja sogar an die Standardisierung haben sie sich ran gewagt. Mit Hilfe von vBlock läuft eine wunderbare Cloud. Virtuelle Server können innerhalb von Minuten erstellt werden. Alle sind auf "Wolke Sieben".

Nur der Anwendungsentwickler beklagt sich, dass für ihn immer noch einen SLA von 20 Arbeitstagen gilt, um einen neuen virtuellen Server zu Testzwecken  zu bekommen. 

 

Ist das Cloud? 

 

Noch ein Cloud Blog?

30. Juli 2013 Posted by Philipp Boltze

 

Und wieder ein neuer Blog. Und dann auch noch zum Thema Cloud! Ist denn das nötig? Wer soll denn das noch lesen? Ist denn nicht schon alles zu Cloud gesagt? 

 

Ich glaube: Nein!

 

Scheinbar gibt es immer noch tausend Gründe, warum Menschen noch mehr über Cloud erfahren sollten. Lassen Sie mich nur einige wenige aufzählen:

 

  1. Es gibt noch sooo viele Fragen, oder sagen wir mal Unklarheiten. Seit mehr als 3 Jahre beschäftige ich mich jetzt schon mit dem Thema als Business Developer und immer wieder stelle ich als erstes Frage: "Was verstehen Sie unter Cloud?" Von "Ich weiß nicht mehr wo meine Daten sind" bis hin zu "das haben wir doch schon vor Ewigkeiten bei uns realisiert" gibt es fast alles. Und genau hier möchte ich mit manchen Vorurteilen und Wissenslücken aufräumen.
     
  2. Jeden Tag kommen neue Produkte und Dienstleistungen zu Cloud auf den Markt. Neben BigData fließen wohl in kaum einen Bereich so viele Entwicklungsgelder. Es gibt also immer wieder etwas Neues zu berichten.
     
  3. Die meisten Blogs zu Cloud, die ich kenne, sind entweder extrem technisch und erklären noch das letzte Bit oder aber sie sind für den gelegentlichen Nutzer geschrieben. Aber Cloud Blogs, auf Deutsch, für Entscheidungsträger gibt es noch viel zu wenige.

 

Es gibt also noch durchaus Platz für einen weiteren Blog. Und den möchte ich gerne ausfüllen.

 

Mein Name ist Philipp Boltze und ich bin seit über 20 Jahren bei der IBM in unterschiedlichen Vertriebs- und Managementfunktionen tätig gewesen. Ich habe viele große Kunden der IBM betreut, Marketing in Deutschland und Europa gemacht und weiß, wie wichtig es ist, auf  die Fragen und Herausforderungen eines Kunden einzugehen und nicht einfach sein Produkt anzubieten frei nach dem Motto "Friss oder stirb".

 

An dieser Stelle möchte ich regelmäßig - sofern mir der Alltag hierzu die nötige  Zeit lässt - über interessante und spannenden Themen rund um Cloud schreiben. Nicht zu technisch, denn das beherrsche ich auch nicht bis in alle Tiefen, aber auch nicht zu oberflächlich. Halt so, dass man etwas damit anfangen kann und danach sagen kann "Mensch, beim Boltze, da habe ich wieder was gelernt" (danke Otto Walkes für dieses abgewandelte Zitat). 

Zusätzlich will ich gerne noch auf technisch anspruchsvollere Dokumente verweisen und zumindest dazu einen kurze Einleitung schreiben.

 

Ziel sollte es sein, dass Sie, lieber Leser*  meines Blogs vertrauter mit den Vorteilen, aber auch den Herausforderungen rund um Cloud werden und damit hoffentlich die richtigen Weichen in Ihrem Unternehmen stellen. 

Und, wie bei einem Blog sicher üblich und gern gesehen, fordere ich Sie auf mit mir und den anderen Lesern zu diskutieren. Es gibt immer mehrere Meinungen und Sichtweisen. Nur wer sie kennt, kann von sich behaupten, sich in einem Thema auszukennen.

 

Ich freue mich darauf. Und ich möchte Ihnen schon heute meinen nächsten Blogbeitrag Ankündigen: 

Shades of Cloud - Was kann man von welcher Cloud erwarten.

 

Das aber erst nach meinem Sommerurlaub auf den Seen südlich Berlins. Da wird es sicher viele Clouds geben und hoffentlich auch ein bisschen Sonne.

 

 

* Liebe  Leserinnen, verzeihen sie es mir mir bitte, wenn ich in meinen Blogs die politisch inkorrekte Form der Anrede der Einfach halt halber nutze.