Kategorie: Uncategorized

  • Big Data – Was ist das?

    Big Data. Jeder spricht davon, doch habe auch ich mich bisher wenig damit beschäftigt. Viele sprechen darüber, welches Potential Big Data hat, doch irgendwie habe ich noch nicht sehr viel davon gesehen, was mir den Alltag erleichtert (ausser dass ich via Kreditkarte, Cumulus Karte und Mobilfunkanbieter auspioniert werden). Daher mal mein nüchterner Blick auf die Sachlage.

    Wikipedia definiert den Term Big Data wie folgt:

    Big data is the term for a collection of data sets so large and complex that it becomes difficult to process using on-hand database management tools or traditional data processing applications. The challenges include capture, curation, storage, search, sharing, transfer, analysis and visualization.

    Ich habe festgestellt, dass dieser Begriff sehr unterschiedlich aufgefasst wird. Es scheint, als klafft vor allem eine Lücke zwischen Business und Wissenschaft. Stellt sich die Frage, ob ein Recordset von 1 GB rohen Daten bereits als Big Data zählt oder nicht? Laut Chief Data Officer von Express Script an seinem Vortrag am Big Data Innovation Summit in Boston ist nicht nur das Volumen ein Kriterium für Big Data, sondern es gibt vier Kriterien:

    1. Volumen. Sehr dehnbarer Begriff. Wissenschaftler reden von Petabytes an Daten, während ein normaler Industrieusecase wohl eher von ein paar GB ausgeht.

    2. Velocity (Geschwindigkeit). Die Geschwindigkeit mit der die Daten gesammelt und weiterverarbeitet werden müssen.

    3. Variety (Vielfältigkeit). Viele verschiedene Quellen an Daten in vielen verschiedenen Formaten, sprich Bild, strukturierter Text, unstrukturierter Text, PDF, MP3 usw.

    4. Veracity (Wahrhaftigkeit). Oftmals sind die Daten, welche erhoben werden nicht relevant fürs Ziel. Es gibt viel «Lärm» und es müssen Mittel und Wege gefunden werden, um die Bedeutungsvollen Daten zu finden.

    Je nach Big Data Anwendung ist (mind.) 1 dieser Dimensionen betroffen (oftmals mehr), aber zu sagen es müssen mind. 1 Petabyte an Daten vorhanden sein, um es Big Data zu nennen würde ein bisschen kurz greifen.

    Zu sagen wäre noch, dass es eine grosse Lücke zwischen dem Potential und der Realisierung gibt cra.org. Gründe dafür sind Komplexität der Daten und Zusammenhänge, Heterogenität und Datenschutz. Viele Visionen und Szenarien, hübsche Videos, die Realität ist jedoch ernüchternd.

    Fazit

    Hauptziel von Big Data ist es Entscheidungen basierend auf Daten zu fällen bzw. aus Daten neue Erkenntnisse zu gewinnen und nicht basierend auf theoretischen Modellen. Big Data ist daher wohl das falsche Wort. Korrekter müsste es heissen «Data Driven», aber ist halt nicht gut genug, um als Buzz Wort durchzugehen.

    Feedback? Mehr Inputs und vor allem ein paar Interessante Case Studies werde ich in einem folgenden Beitrag bringen.

    Und die Realität von Big Data?

    Man schaue sich dieses Video an. Entweder bekomme ich nichts von der Welt mit, oder aber die Visionen und die Realität klaffen wirklich noch weit auseinander… oder es ist nur in der Schweiz noch ein bisschen «bünzlig», was Ärzte und Technologie betrifft:

  • Mobile Dimensionen – Diskussionsgrundlage

    Eigentlich könnte man meinen der Hype um Mobile und Apps wäre langsam vorbei und die Marketeers wären langsam zur Besinnung gekommen. Laut Google Trends haben wir Seit Januar 2013 auch eine Art Plateau erreicht. Und dennoch, jeder Marketing Manager schreit nach einer App. Ein erfolgreicher Produkt Launch ohne App… geht nicht. Hauptsache eine App, ob Sinn macht oder nicht wird oft nicht hinterfragt.

    Google Trends, Apps vs. Webseite

    Interessanterweise nimmt die normale Webseite langsam an Bedeutung ab, zumindest wenn man den Trends Glauben schenken will… oder aber es wird als Selbstverständlich hingenommen.

    Apps, Apps, Apps

    Bereits vor mehr als 2 Jahre habe ich mich bereits mal kritisch zu Apps geäussert: Apps, Apps, Apps … ich kann es nicht mehr hören und dennoch muss ich es immer wieder hören und noch viel schlimmer mit Leute diskutieren, welche unter «App» lediglich das Produkt aus dem Apple App Store verstehen und vollkommen ignorant gegenüber allem anderen sind («Was es gibt auch Apps für Android?»). Diskussionen mit solchen Leuten sind daher sehr schwierig, da ledigliches technisches Verständnis fehlt, daher mein Ansatz die verschiedenen Facetten von Mobile zu illustrieren:

    Mobile Dimensionen

    Mobile Dimensionen

    Diese Grafik sollte die Diskussion mit Entscheidungsträgern vereinfachen (welche leider oftmals wenig technisches Verständnis zeigen). Technologie ist oftmals (trotz mangelndem Verständnis ein Ausgangspunkt): Da werden Begriffe iBook, App und eBook wild durcheinander verwendet, ABER lediglich eine Technologie ist möglich. Je nach Wahl der Technologie hat dies Auswirkungen auf die anderen Dimensionen: ein iBook lässt sich nicht im App Store publizieren (Deployment Dimension), ist nur für iPad vorhanden (Platform Dimension) und ist kaum geeignet, um Business Funktionalität bzw. immersive Funktionen (Scope Dimension) abzubilden.

    Oder als weiteres Beispiel, die Dimension «Update Cycle»: sollte ein regelmässiger und schneller Uupdate Cycle notwendig sein, dann wird sich ein PDF und iBook kaum eignen und auch eine App (Technology Dimension) ist nicht zwingend das Richtige sondern vielleicht eine Web App.

    Einige Dimensionen sind relativ undabhängig, während andere Dimensionen starken Einfluss auf andere Dimensionen haben. Zumindest sollte jeder Dimension vor Beginn eines Projektes Beachtung geschenkt werden, um die optimale Lösung zu erstellen, so dass es nicht nur eine weitere App, die die Welt nicht braucht im App Store gibt, welche zudem noch ein Vermögen kostet aber eigentlich hätte ein einfaches PDF auch gereicht?

    Download

    Die Grafik auch als PDF, zum Ausdrucken. Könnte für das eine oder andere Meeting sicher hilfreich sein.

    Findest du, es fehlt noch eine Mobile Dimension? Über ein Feedback würde ich mich freuen.

  • A Conference Call in Real Life

    Wahrscheinlich ist dieses Video nur lustig für Leute, welche auch Erfahrungen mit Telefonkonferenzen haben. Auf der einen Seite unterhaltsam, auf der anderen Seite erschreckend zugleich, weil es genau so ist.

    Enjoy.

  • Schlecht geplanter Daydeal und wie die Cloud hätte helfen können

    Daydeal.ch ist eine Dealseite wie jede andere spezialisiert auf Gadgets/Tools und sonstiges Geekzeugs. Jeden Tag gibts ein Angebot zwischen 9:00 Uhr und 9:00 Uhr und so lange Vorrat. Heute gabs einen Spezialdeal: Jede Stunde ein Angebot. Coole Sache, das haben sich wohl einige Gedacht: Daher kam immer mal wieder die Nachricht: "Site not available". Heute muss so etwas nicht mehr sein.

    Daydeal

    Rechenpower oder Manpower

    Eine erste Lösung könnte natürlich sein, die Webseite zu überarbeiten und zu optimieren, damit sie mit den verfügbaren Ressourcen performt. Dagegen sprechen jedoch folgende Gründe:

    • Die Applikation ist bereits 100% optimiert und optimal für den Zweck gebaut, so dass sie Ressourcen zu 100% auslastet (fraglich, ob so etwas je der Fall ist).
    • Ein Programmierer braucht 100 Stunden (ca. 2 Wochen), um ein paar Tweaks und Optimierungen zu machen, welche notwendig sind -> Kosten: 200×100 = 20'000.-
    • Gegebenenfalls die Applikation komplett neu schreiben, Technologie neu evaluieren (PHP ist vielleicht nicht die optimale Lösung) -> Kosten: massiv höher.
    • Risiko, gravierende Änderungen zu machen sind nie zu vernachlässigen. Beim Relaunch einer neuen Plattform gibt es immer hier und da kleine Patzer

    Betrachten wir das alles mit den Kosten für ein paar neue Server, welche für 1 Tag benötigt werden, ist der Fall klar: Rechenpower ist günstiger: Ein paar zusätzliche Amazon Server in der Cloud, ein CDN… und schon ist das Problem mit ein paar wenigen Franken gelöst.

    Wie könnte die Cloud Abhilfe schaffen

    Einen besseren Grund für eine Cloud Infrastruktur gibt es fast nicht, denn daydeal hätte offensichtlich für eine kurze Zeit (wohl für den heutigen Tag) mehr Rechenpower benötigt, um die zusätzliche Last zu bewältigen.

    Wären die Server virtualisiert und liegen in einer Cloud Umgebung, hätte der Sysadmin heute morgen lediglich ein paar zusätzliche Instanzen hochgefahren und hinter den Loadbalancer gehängt und schon wäre das Problem gelöst gewesen. Morgen früh kann der Sysadmin dann die zusätzlichen Servers wieder runterfahren. Kostenpunkt: ein paar zusätzliche Franken.

    Alles wäre stressfrei gewesen. Ich gebe zu, dass dafür bereits gewisse voraussetzungen gegeben sein müssen: Loadbalancer muss bereits vorhanden sein und DB und Applikationsserver müssen separiert sein… doch auch das lässt sich im Normalfall relativ schnell einrichten (wenn ich in einer virtualisierten Umgebung bin)

    Was aber auch der Grund sein könnte

    Der Marketing Director hat die geniale Idee, 24 Deals an einem Tag aufzuschalten. Er fragt seinen Praktikanten, ob sich das System entsprechend "verbiegen" lässt, so dass jede Stunde ein neues Produkt rausgeht. Dieser bejaht und schon steht der Deal. Ein Datum wird festgelegt und alle sind glücklich… nur weiss die IT nichts davon.

    Der grosse Tag rückt näher, im Marketing sind alle nervös: Es ist 9 Uhr, los gehts. Natürlich ist in der IT noch niemand im Büro, da die immer erst um 10 Uhr kommen. Um 9:05 Uhr läuft nichts mehr: Server ist down. Marketing Fuzzy ruft frustriert in der IT an… irgend ein Helpdeskler startet Apache neu. Problem gelöst. 15 Minuten später wieder das Gleiche. Marketing Fuzzy wird langsam nervös, Helpdeskler hilflos.

    Endlich 10 Uhr, der Programmierer erscheint im Büro: Alle Warnlämpchen auf rot und der Sysadmin kommt erstmals in Schwitzen. Helpdesk erzählt ihm, dass es Probleme mit der Webseite gibt… wirklich? Helpdesk meint nur, dass der Marketing Fuzzy ziemlich aufgebracht ist. IT Fuzzy schaut sich mal die Seite an… oha… was ist denn das für eine Kampagne? Scheisse, warum hat das niemand gesagt? Rödel, rödel, fluch, fluch… und 3 neue Server sind bereit…. 11 Uhr: Das System läuft wieder ruhig.

    Die Cloud löst nicht magisch alle Probleme

    Die Geschichte ist frei erfunden, könnte aber genau so passieren. Kommunikation zwischen Business und IT sind unerlässlich. Das Marketing mag zwar die Ideen haben, die IT muss diese ermöglichen und ausführen, doch soll das Business nicht erwarten, dass die IT Systeme einfach magisch laufen (auch wenn diese in der Cloud sind). Viele Pannen liessen sich vermeiden, wenn mehr Kommunikation wäre (und das gilt übrigens auch für die IT bezüglich Systemwartungen!)

  • Cloud Computing im Grosskonzern

    Definition der Cloud

    Die Definition vom NIST (National Institut of Standards and Technology) gefällt mir am Besten (neben den ganzen vielen Marketingdefinition, welche nichts und alles bedeuten):

    Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared
    pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that
    can be rapidly provisioned and released with minimal management effort or service provider interaction. [NIST Definition of Cloud Computing]
    Ich würde das in etwa wie folgt übersetzen:
    Cloud Computing ist ein Modell, welches den allgegenwärtigen, on-Demand und schnellen Zugriff via Netzwerk auf einen Pool von konfigurierbaren Computing-Ressourcen (z.B. Netzwerke, Server, Speicher, Anwendungen und Dienste) ermöglicht, welcher schnell bereitgestellt und freigegeben werden kann und dabei minimalen Aufwand und Interaktion des Dienstleisters benötigt.

    5 Eigenschaften eines Cloud Dienstes

    Dazu definiert das NIST 5 Charakteristiken, welche einen Cloud Dienst auszeichnen:

    • On-Demand self-Service: Der Benutzer kann sich selber sein «Angebot zusammenstellen». Beispiele dafür wären: Mehr Speicher kaufen, mehr CPU Leistung kaufen, mehr Features kaufen (z.B. Evernote Premium) usw.
    • Broad network access: Der Service ist via Netzwerk und von unterschiedlichen Plattformen erreichbar.
    • Resource pooling: Die Rechenleistung wird von mehreren Nutzern gleichzeit verwendet. Der Enduser hat keine Kontrolle/Einsicht, wo sein Dienst ausgeführt wird.
    • Rapid elasticity: Kapazitäten können on-Demand hinzugefügt bzw. entfernt werden.
    • Measured service: Das Cloud System optimiert automatisch die Ressourcen. Der Ressourcen Verbrauch wird überwacht, wodurch volle Transparenz geboten wird.
      Im Weiteren definiert das NIST weiter 3 Modell sowie 4 Ausprägungen, welche sehr gut in dieser Graphik von Cambridge Technology Partners
      Schematisch Darstellung Cloud Computing
      Koppelt man diese Graphik mit den oben erwähnten 5 Chrakteristiken ergibt dies eine sehr gute Definition vom Begriff «Cloud Computing». Kein Marketing gefasel und kein Hype, sondern so wie es ist.

    Ist Cloud Computing alter Wein in neuen Schläuchen?

    Eine berechtigte Frage, aber nein. Die alten Weine wurden gemixt und dadurch ist eine neue Sorte entstanden (Graphik vom winwiki):
    Cloud Computing Entwicklung
    Selbsterklärend eigentlich.

    Kritische Cloud Blicke

    Also Otto Normale ist die Cloud beständteil des täglichen Lebens: iCloud, Gmail, YouTube, Basecamp, Evernote und und und… für Grosskonzerne sieht der Himmel jedoch etwas Cloudy aus. Daher mal ein paar kritische Blick auf die Cloud resp. auf Grosskonzerne in der Cloud.

    Aber was ist mit dem Datenschutz in der Cloud

    Und genau das ist das bisher noch ungelöste Problem. Dies mag für den Privaten weniger problematisch sein (wahrscheinlich denkt der eine oder andere seit der NSA Affäre anders), aber grundsätzlich sind wir nicht ganz so bessessen darauf, alle Daten im Haus zu haben. Anders gesagt: Der Aufwand und die Kosten für den Privatanwender sind zu hoch.
    Beispiel: Backup in der Cloud via Mozy: Super einfach, relativ günstig und zuverlässig und meine Daten sind auch sicher wenn das Haus weggeblasen wird. «Inhouse» – Alternative: Eine externe Festplatte (wahrscheinlich ein bisschen günstiger, dafür sind die Daten im Brandfall weg) oder z.B. ein Offsite-Backup bei einem Kumpel einrichten, wofür jedoch ein Server und einiges an Know-How notwendig ist. Die technische Hürde ist für 99% der Benutzer zu hoch.
    Beispiel 2: E-mail. Ich kenne kaum jemand, der seinen eigenen E-mail Server betreibt (nicht einmal ich). Die Meisten sind bei Gmail, Hotmail oder GMX und dann gibts noch ein paar wenige, welche ihre Mails beim Internet Provider haben, aber einen eigenen Mailserver betreiben? Zu teuer, zu wenig zuverlässig.

    Firmen und Datenschutz

    Das sieht doch schon ganz anders aus: Kaum eine Grossfirma wird Mozy als Backup Lösung verwendnen und kaum eine grosse Firma wird nicht irgendwo im eigenen Rechenzentrum einen Exchange Server stehen haben. Meine Erfahrung: Je grösser die Firma, desto paranoider sind die Leute. Darin sehe ich die folgenden Gründe:

    1. Die Firma hat effektiv geheime, schützenswerte Daten, welche vor allem vor Wirtschaftsspionage geschützt werden sollen, wie z.B. Statistiken, Produktionsdaten, Verkaufszahlen usw. Unerlaubter Zugriff auf diese Daten, würde ein Wettbewerbsnachteil bedeuten.
    2. Die Firma hat Personenbezogene Daten: entweder von den Mitarbeitern oder aber von Kunden, z.B.: Telefonnummern, E-mail Adresse, Gesundheitszustand usw.
      Ich frage mich jedoch:
    3. Was möchte ein Cloudanbieter mit Firmengeheimnissen anfangen? Er könnte sie verkaufen und sozusagen zu einer Schwarzmarkt Plattform für Firmengeheimnisse werden. Kurzfristig ist das sicher sehr lukrativ, aber längerfristig wahrscheinlich eher unhaltbar, denn in der Cloud ist Vertrauen das A und O.
    4. Sobald die Daten mein Firmennetz verlassen sind diese mind. für den Geheimdienst einsehbar und dies selbst wenn sie über eine SSL geschützte Leitung verschickt werden: Von daher wohl nicht wirklich sicherer als wenn sie von meinem Computer zum Cloud Provider gehen.
    5. ABER kann ich mein kleines Rechenzentrum genau so effizient schützen, wie das eines Anbieters, welcher als Kernkompetenz das Rechenzentrum hat? Kann ich als Firma mit dem Fortschritt mithalten. Bsp: Ich hoste mein eigenes CMS vs. ein CMS in einer Cloud Umgebung: Mein CMS läuft auf einer veralteten Server und das CMS selber ist vollkommen outdated mit vielen offenen Security Patches. Hätte ich die Cloud Lösung müsste ich mich nicht darum kümmern… lediglich Vertrauen in den Cloud Dienstleister brauche ich.
    6. Falls jemand gezielt meine Daten stehlen möchte, um Wirtschaftsspionage zu betreiben, sind die Daten in meinem Rechenzentrum sicherer als in einem Externen?
      Gut Punk 2 kann effektiv ein Problem sein, da gewisse rechtliche Anforderungen mich zwingen, die Kontrolle über diese Daten zu haben (z.B. Safe Harbor), doch auch dafür gibts Lösungen.

    Weitere Gründe für die Zurückhaltung der Cloud gegenüber

    Und noch mehr Gründe sind im Paper BENEFITS , RISKS AND RECOMMENDATIONS FOR INFORMATION SECURITY:

    1. Eine gewisse Überheblichkeit: Wir können das mind. genauso gut, wenn nicht besser und wir brauchen die volle Kontrolle über den User.
    2. Angst, den Job zu verlieren, denn die IT (sprich die Betreiber von Software und Infrastruktur) wird überflüssig. Bsp: Der Exchange Server wird ausgelagert zu Swisscom. Fallen monatliche Lizenzkosten an, dafür kann ich meinen IT Fritz, welcher den Exchange Server gestreichelt hat entlassen und kann die Exchange Server im Keller verschroten. Diese IT Leute sind also nicht wirklich an einer Cloud Lösung interessiert.
    3. Kontrollverlust. Was passiert wenn der Cloud Anbieter verschwindet? Was wenn sich die Lage ändert? Es entsteht eine Beziehung, welche je nach System und Bindung nicht mehr so schnell gelöst werden kann. Will ich mich dem beugen?

    Was sind die Auswirkungen des Cloud Computings

    Für kleine Unternehmen führt wohl kein Weg an der Cloud vorbei. Die folgenden Gründe sprechen dagegen:

    1. IT Infrastruktur selber zu betreuen ist zu teuer und braucht zu viel Know-how. Ich habe mir zuhause mal einen Server virtualisiert: Headless Virtualbox auf einer Debiankiste und dann da drauf 3 virtuelle Linux Server. Das wurde mir dann einfach zu kompliziert.
    2. Als kleine Firma kann ich mit der raschen Entwicklung nicht mehr mithalten. Ich werde immer veraltete Soft- und Hardware haben.
    3. Die Mitarbeiter sind Cloud Software gewohnt. Sie lieben die Flexibilität, die bunten Benutzerfreundlichen Interfaces und neue Features. Vorbei sind die Zeiten, wo die Software 5 Jahre im Einsatz ist, bis das nächte Release geplant wird.
      Ganz anders sieht das für grosse Firmen aus. Diese sind durch Compliance- und Sicherheitsanforderungen gelähmt. Dazu kommt eine Portion Arroganz: «Wir machen das doch selber viel besser» und zusätzlich eine grosse Portion «Save my Ass» Mentalität.

    Die Private Cloud

    Wohl die meisten Grosskonzerne sind mit irgendwelchen Private Clouds am Experimentieren. Die Server virtualisieren, hype Software drauf knallen und schon ists gelöst. Ist es das wirklich? Ist die private Cloud ein Ersatz für die richtige Cloud? Ich glaube nicht, denn:

    1. Release Zyklen werden durch komplizierte interne Prozesse lang. Der Benutzer kommt nur langsam in den Genuss neuer Features.
    2. Cloud Software für die Private Cloud lässt sich kaum von der Stange kaufen. Warum sollte ein Cloud Provider seine Cloud Lösung verkaufen?
    3. Komplizierte IT Governance und Prozesse machen aus dem Cloud-Genuss einen Cloud Verdruss. Das ist doch das schöne an einer Cloud Lösung: Anmelden, Kredit Karte, Benutzen. Die Private Cloud in einem Grosskonzern stelle ich mir dagegen wie folgt vor: Formular ausfüllen, warten, approven, warten brauchen.
      Somit verfliessen viel Vorteile der Cloud im Sand. Daher wenn schon eine Private Cloud, dann bitte richtig… sprich die ganzen IT Prozesse und Governance muss entsprechend angepasst werden.
      Alles Schlecht? Nein natürlich nicht, aber die Cloud hat noch einige Hürden auf dem Weg in die Grosskonzerne zu überwinden.
  • Der Cloud Computing Buzz – Tag 1

    Im Zuge meiner persönlichen Weiterbildung besuche ich eine Vorlesung an der FHNW Cloud Computing. Ein Blogeintrag ist eine gute Gelegenheit, um das gehörte zu vertiefen und zu reflektieren.

    Tag 1 – Cloud Computing Grundlagen

    Erkenntnis des Tages: Cloud Computing ist und bleibt ein Buzzwort, selbst an einer Fachhochschule. Das Internet ist Cloud Computing und wird als solches seit nun mehr 15 Jahren betrieben. Es gibt eine sehr differenzierte Ausprägung von Cloud Computing:

    • Software as a Service (SaaS)
    • Platform as a Service (PaaS)
    • Infrastructure as a Service (IaaS)

    Hotmail ist und war eine Form von Software as a Service, indem ich meinen E-mail Dienst komplett in die Cloud verlagert habe und wahrscheinlich kaum jemand hat je seinen eigenen E-mail Server betrieben. Wahrscheinlich war auch lange Zeit E-mail das einzige effektive und publike Cloud Computing.

    Ich bin in der Cloud… me too

    «Wir arbeiten in der Cloud.», «Wir bringen ihre Business in die Cloud», «Durch die Cloud haben wir Kosten um 50% gesenkt». Ist doch alles nur Hype und Buzz zugleich, denn von welcher Cloud sprechen wir hier? Lediglich die Virtualisierung der eigenen Server durch den Einsatz von VMWare? Oder durch den Wechsel von Exchange zu Google Apps?

    Die einen wollen unbedingt in die Cloud und die anderen verteufeln die Cloud, da sie nicht sicher ist und in Tat und Wahrheit sind beide bereits in der Cloud. Der Begriff Cloud ist soooooo breit gefächert, dass unter diesem Begriff keine verlässlichen Aussagen getroffen werden können.

    Ist die Cloud schlecht?

    Nein, aber nennen wir es mal nicht Cloud, sondern beim entsprechenden Fachbegriff, SaaS oder IaaS und dann wird plötzlich alles viel klarer. SaaS: Ich biete Dienst XY unter folgenden Konditionen zu folgendem Preis an. Cloud oder nicht Cloud spielt doch gar keine Rolle, hauptsache der Dienst kann sein Versprechen Einhalten.

    Randbedingungen für Cloud Dienste

    Zu diesen Randbedingungen können gehören:

    • Die Daten sind vor unbefugtem Zugriff geschützt
    • Daten sind jederzeit erreichbar
    • Möglichkeit neue User/Instanzen/Dienstleistungen «on-the-fly» hinzufügen
    • Bezahlung nach Aufwand/verbrauch

    Kann das gewährleistet werden kann der dafür gewählte Namen heissen wie er will.

    Fazit 1 – Vertrauen in die Cloud

    Zwei wichtige Take-aways. Grundlage jeder Cloudlösung: Vertrauen. Ohne vertrauen in den Cloud Provider geht nichts und das Modell funktioniert nicht. Ich als Bezieher muss davon überzeugt sein, dass die oben genannten Randbedingungen für die Cloud Lösung erfüllt werden können.

    Fazit 2 – Cloud = Buzz

    Auch hier wird nur mit Wasser gekocht: Sprich Virtualisierung, Automatisierung, Schnittstellen usw. Nichts grundlegend neues, sondern ein bisschen neu verpackt und vermarktet und vor allem viele gute Beispiele aus dem alltäglichen Leben, wie z.B. Dropbox, Google Mail, Github, WordPress, YouTube usw.

    Und hier noch ein paar Links rund ums Cloud Computing Thema in der Schweiz:

  • Node.js Monitor PM2

    Eine Node.js Applikation wird normalerweise wie folgt gestartet:
    ~
    node app.js
    ~
    Jetzt läuft die Node Applikationen. Im Vergleich zu PHP ist das ein komplett andere Denkweise: Apache und PHP gehen Hand in Hand. Apache kann gut ohne PHP leben, PHP jedoch kaum ohne Apache (oder entsprechendem Webserver). Mit einer .php Datei allein wird man kaum eine Sinnvolle Web Applikation bauen, mit einer .js Datei hingegen schon.

    Eine Node App ist ein vollwertiger Server

    Um eine Node Applikation zu betreiben ist kein zusätzlicher Webserver notwendig. Der Webserver ist Teil der App. Das hat jedoch auch einige Folgen: Fehler in der Applikation sind fatal. Nehmen wir wieder PHP als Beispiel. Ein Fehler in der Anwendung führen dazu, dass der Request mit einem Error 500 abgebrochen wird. Der nächste User findet wieder eine jungfräuliche Umgebung vor. Anders bei Node.js: Ein Fehler ist fatal, denn er führt dazu dass die ganze Applikation und damit auch der Server abstürzt und nicht mehr wieder selber hoch kommt. Damit bleibt die Node.js App nach einem Fehler nicht mehr erreichbar, bis sie wieder gestartet wird.

    Node Forever

    Das Modul gibts und ist wohl eines der bekannteren. Node Forever schaut, dass eine Node Applikation wenn sie abstürzt wieder gestartet wird. Ich habe mich nie mit Forever beschäftigt sondern bin eigentlich nur zufällig auf pm2 gestossen.

    Node Runner: PM2

    PM2 ist ein exzellentes Modul, scheint stabil zu sein und sehr einfach zu bedienen und bietet ein paar nützliche Features:
    – Autorestart bei Absturz
    – Logging
    – Hot Reload von Code
    – Monitor
    – Load balancing (noch nicht ausprobiert)
    – Mehrere Apps laufen lassen (noch nicht ausprobiert)
    – und noch mehr
    PM2 Node.js Monitor
    Der Monitor für eine Node.js Applikation. Nicht in alle tiefen, aber doch auf einen Blick den Stand.
    Die Installation und die In Betriebnahme ist denkbar einfach:
    ~
    npm install -g pm2
    pm2 start app.js
    ~
    That’s it. Von jetzt an kann die App noch so fehlerhaft sein und regelmässig abstürzen, sie kommt immer wieder hoch (sollte natürlich das Ziel sein, dass das nie vorkommt).

  • Der Trend zum CMS Minimalismus

    Content Management Systeme gibt es wie Sand am Meer. Die beste und gleichzeitig auch die schlechteste Übersicht ist CMS Matrix. Als Entscheidungsgrundlage vollkommen ungeeignet, aber als schnellen Überblick super. Aktuell haben wir 1270 CMSe in der Liste! Scheint sich wieder ein neuer Trend zu entwickeln: MiniCMS/NoCMS Philosophie. Dazu heute auf t3n gelesen:

    Der Hauptunterschied liegt im Datenmanagement. Bei Pico werden alle Seiten in Textdateien, in diesem Fall *.md-Dateien, bereitgestellt. Das System generiert dann aus diesen *.md-Dateien fertige HTML-Seiten. Ein Vorteil davon: Im Gegensatz zu anderen Systemen wie WordPress ist die Performance höher. Außerdem sind die Anforderungen geringer: Pico benötigt nur Webspace und eignet sich hervorragend für kleine Webprojekte wie Blogs oder Websites kleiner und mittlerer Unternehmen.
    Der Kreis scheint sich langsam aber sich wieder zu schliessen. Zuerst ein kleiner Ausflug in die Geschichte des Webs und deren Technologien.

    Erste Website
    Das hier ist die erste Webseite vom 13. November 1990

    Statische Seiten – NoCMS Philosophie – 1990 – 2000

    Die erste Webseite wurde am 13. November 1990 von Tim Berners-Lee veröffentlicht.
    Die HTML only Philosophie hat wahrscheinlich bis in die späten 90er Jahre angehalten. Ja, da gabs Pearl und sogar PHP (Version 1.0 ist 1996 erschienen), doch der Normale Webdesigner hatte nicht viel Ahnung davon.
    animiertes GIF
    Aber dennoch, eine herrliche Zeit mit guten Erinnerungen: Frames, Tabellen, animierte GIFs, Flash, Dreamweaver und Frontpage und nicht zu vergessen .

    Mehr CMS ist besser – MegaCMS Philosophie 2000 – 2012 – Web 2.0

    Jetzt gehts erst richtig los. PHP, Python, Java, .net: Jede Programmiersprache ist Webfähig oder wird webfähig gemacht und damit beginnt auch die Zeit der CMSe:

    • Drupal (2001)
    • TYPO3 (2001)
    • WordPress (2003)
    • Joomla (2005)

    Es gibt zahlreiche Clouddienste (z.B. [Wordpress.com)(http://wordpress.com)), wodurch die CMS Einstiegshürde massiv sinkt. Es wird mit Features herumgeschlagen und ein CMS als Herzstück der Seite zu haben ist Pflicht. Ich habe sogar Webseiten bestehend aus 1 (ja einer!) Seite gesehen, welche Drupal als darunterliegende Technologie verwenden.
    Die CMSe sind allesamt zu wahren Beastern angewachsen:

    • Drupal 7: 11.5 MB, 1063 Dateien, Handelt sich hier um Drupal Core, eine typische Webseite mit den benötigten Module ist dann wohl eher 50 MB
    • TYPO3 6.1 Introduction Package: 74.2 MB, 9346 Dateien
      Auch Microsoft will sich am Kuchen beteiligen und wirft mit Sharepoint ein fürchterliches Produkt für Webseiten auf den Markt. Scheint mir ein bisschen Me-To Philosophie zu sein, aber die 2007er und 2010er Version ist vollkommen ungeeignet als WebCMS und den darunterliegenden HTML/CSS Code sollte man lieber überspringen.

    Fazit dieser Area: Technologie und Schiess-mich-tot-Features.
    Und um mich vor bösen Kommentaren zu bewahren: Ich bin nicht generell gegen ein CMS, sondern stehe nach wie vor hiner meinen Argumenten aus «10 Gründe warum ich Drupal einsetz» (obwohl nicht mehr ganz aktuell). Ich sträube mich jedoch dagegen, für jede Webseite gleich zum CMS zu greifen, um ein Problem zu lösen. Das hat schon ein bisschen Alkoholiker Feeling…

    Weniger CMS ist mehr – NoDBCMS Philosophie 2010 – ?

    Langsam merken die Leute, dass weniger mehr ist, denn Drupal mit 100 Modulen ist sehr speicherhungrig, das Billighosting für 4.95 bietet jedoch lediglich 32MB Speicher an. Zudem ist vielleicht auch ein bisschen Ernüchterung dabei, dass die vielen dynamischen Funktionen, wie Kommentare, Gästebuch, customized Homepage usw. gar nicht wirklich gebraucht werden.
    Zuerst aufmerksam auf die NoDBCMS wurde ich via Kirby und wie t3n vorschlägt gibts eben auch noch Pico und sicher noch diverse andere Vertreter.
    Die Vorteile eines NoDBCMS liegen auf der Hand:

    • Noch einfachere Installation
    • Weniger Infrastruktur, daher weniger Probleme und weniger Kosten
    • Einfacheres Performance Tuning
    • Tendentiell niedrigere Einstiegshürde für Entwickler
    • Bulkoperationen können sehr einfach gemacht werden: «find/replace» -> ohne in der DB rumwühlen zu müssen
      Klar, nicht für jede Seite geeignet, aber wohl für seeeehr viele. Für den Anfänger ist wohl die grösste Schwierigkeit das Fehlende Admin Interface. Ich möchte jedoch hinweisen, dass das auch ein Vorteil sein kann, denn jeder Benutzer kann mit Files arbeiten.

    Und nur noch zum Vergleich:

    • Pico: 1.1 MB, 206 Dateien
    • Kirby: 0.5 MB, 47 Dateien
      Erste Website

    Kein CMS ist am Besten – NoCMS Philosophie 2010 – ?

    Und weg ist das CMS wieder und damit sind wir wieder zurück in den 90er Jahren: Die Area der Static Site Generators hat begonnen.
    Noch weniger Anforderungen bezüglich der Hosting Umgebung, denn dort liegen nur noch HTML Dateien. Maximale Performance, minimale Maintenance. Die Seiten können auf Dropbox oder Google Drive gehostet werden. Fairerweise sei zu erwähnen, dass es eine kleine Hürde gibt: den Generator. Viel der Tools sind noch wenig benutzerfreundlich, doch Abhilfe naht: websli. In wenigen Worten:

    • Template und Inhalt liegen in der Dropbox
    • Sync auf den Server
    • Magic, magic… Seite wird gerendert
    • Fertig

    Leider ist es noch nicht bereit für eine öffentliche Beta, aber sicher sehr bald. Wer Interesse hat, soll sich doch bei mir melden.

    Fazit

    Das Web ist eine ewige Runde. Mittlerweile haben wir so viele Möglichkeiten, welche es jedoch schlau einzusetzen gilt. Greifen wir nicht wie der Junky stur zum gleichen Tool, sondern nehmen wir das richtige Tool für den Job: Manchmal mag das ein CMS sein, manchmal reicht eine statische Seite vollkommen aus.

  • Die Böse Cloud – Sind Dropbox und Co. sicher?

    Das NSA Skandal ist nicht mehr ganz so im Rampenlicht und dennoch hinterlässt es einen faden Nachgeschmack… wahrscheinlich nicht beim Otto-Normalverbraucher aber dennoch bei den Techies.

    Dropbox Screenshot

    Nicht verwunderlich, dass es dazu auch einige Einträge gegeben hat, so zum Beispiel auf ComputerWorld:

    Nach dem NSA-Skandal sind ausländische Online-Speicherdienste à la Dropbox ein wenig in Verruf geraten. Computerworld hat sich auf die Suche nach helvetischen Alternativen gemacht.

    Fairerweise beginnen sie den Artikel auch gleich mit einem "Disclaimer":

    Um es gleich vorweg zu nehmen: Wer seine Dateien auf einem Online-Speicher ablegen will, der in der Schweiz ansässig ist und im Idealfall auch noch seine Server hierzulande stehen hat, muss einerseits mit weniger Komfort leben und andererseits mit weniger Gratisspeicher Vorlieb nehmen.

    Immerhin es gibt sie also die lokalen Dropboxalternativen:

    Und wie es mit Facebook Alternativen

    Eigentlich könnte man jetzt die Liste noch erweitern: Was gibt es für lokale E-mail Dienste, spriche Gmail Ersatz? Vor Urzeiten hatte ich mal eine E-mail Adresse bei Sunrise, aber das war einmal. Und wenn wir schon gleich dabei sind: Wie wäre es mit einem Facebook Ersatz? Ach ja, Diaspora gäbe es da. Super Konzept aber zu kompliziert damit die Leute es verstehen und niemand braucht es.

    Diaspora Logo

    Lokale Cloud ist sicherer als Dropbox & Co?

    Stellt sich die Frage: Bietet ein lokaler Cloud Dienst mehr Sicherheit als der Platzhirsch? Wahrscheinlich ein wenig, aber nur gerade ein wenig, denn die NSA hört angeblich die Leitungen ab: Und wie kommen die Daten von meinem lokalen Rechenzentrum auf meinen PC: Via Kabel. Wahrscheinlich undenkbar, dass der Trip vom Rechenzentrum in Zürich zum PC in Bern via USA geroutet wird, aber theoretisch dennoch möglich… und schon hat die NSA meine Daten.

    Ganz zu schweigen von E-mails. Meinen lokalen E-mail Server ist sicher in den Schweizer Alpen; doch wo steht der Empfänger? Gmail? Hotmail? Schwups… schon ists bei der NSA im Backup.

    NSA ist Sauron
    (via Flickr @kazvorpal)

    Kein Problem: Ich habe doch alle Daten via SSL verschlüsselt. Auch das ist kein Problem mehr für die NSA. Dann gäbe es noch PGP E-mail Verschlüsselung, doch leider verwendet das niemand und auch hier ist nicht garantiert, dass es nicht geknackt wird.

    Ums gleich vorweg zu nehmen… sie sind überall, und ob sich der Aufwand lohnt sich davor zu verstecken ist jedem selbst überlassen: Das einfachste wäre, einfach zuhause zu bleiben.

    Mega Dropbox

    Für die ganz mutigen wäre da noch der Service Mega, von Kim Dotcom (obwohl er hier nicht mehr beteiligt ist): "The Privacy Company". Es ist nicht wirklich klar, ob Kim Dotcom der Robin Hood oder eher der Pirat ist.

    Möchte ich meine Daten bei einem Internet Piraten hosten? Immerhin hat er als Pirat ein persönliches Interesse daran, dass niemand reinschauen kann oder?

    Fazit

    Die sichere Cloud gibt es nicht, denn Cloud = Internet = Globales Netzwerk, egal ob ich einen schweizer Cloudanbieter oder Dropbox verwende.

    Daher: Ist etwas wirklich streng geheim, dann gehört es nicht in die Cloud. Ist es in der Cloud, musst du damit rechnen, dass irgendjemand sonst noch reinschaut, sei das die NSA, Hacker oder bei einer Datenpanne die ganze Welt.

    Um meine Frage zu beantworten: Sind Dropbox und Co. sicher? – Nein sind sie nicht. Muss es mich stören? Jein, solange ich es mir bewusst bin. Sind schweizer Alternativen sicher? Nein sind sie nicht. Sind sie sicherer? Vielleicht ein wenig.

  • Praktische Tipps zu Nginx

    Basic Auth für Nginx

    Basic Auth mit nginx ist einfach via "location" zu erreichen. In gewissen Fällen kann es jedoch wünschenswert sein, lediglich das html File via Basic Auth zu schützen und Javascript, CSS und Bilddateien ungeschützt zu lassen: sollte auf jeden Fall positiv für die Performance sein.

    Usecase: Newsletter von einem private Blog via Mailchimp erstellen. Das folgende Snippet macht das möglich. Nur Dateien, welche auf .html enden, sind mit Passwort geschützt.

    # location / { # alles wäre geschützt
    location ~^/.*.(html) { # lediglich .html Endungen werden mit Passwort geschützt
        auth_basic "Zugriff nur mit Passwort";
        auth_basic_user_file /home/ubuntu/.pwds/pwd;
    }