Schlagwort: Cloud Computing

Kategorien
Services

Google Chromebook: Die Cloud in ihrer besten Form!

Wie ich bereits geschrieben hatte, ist die Mobile Cloud der wahre Megatrend der Zukunft! Mobile Computing meets Cloud Computing!

Das dem so ist, hat Google nun endgültig mit seinen Chromebooks bewiesen!

Chromebooks sind mobile Cloud Desktops, also Notebooks, bei denen sich alle Anwendungen im Web befinden und von dort on Demand geladen werden. Der Start der Chromebooks soll, nach Angaben von Google, in 8 Sekunden(!) erfolgen und das Gerät anschließend vollständig betriebsbereit sein. Im Gegensatz zu herkömmlichen lokalen Systemen sollen die Chromebooks mit der Zeit, auf Grund von Updates, schneller werden. Das macht Sinn, da die eigentliche Arbeit in der Cloud stattfindet und die Chromebooks nur noch als Medium für den Zugriff auf die Anwendungen dienen. Zudem nimmt das Chromebook beim Einschalten ein automatisches Update vor, wodurch das Betriebssystem und sämtliche Anwendungen aktualisiert werden.

Natürlich kann das Chromebook nur mit einer Datenverbindung via WLAN oder UMTS (3G) verwendet werden. Das Chromebook erkennt während des Startvorgangs eine entsprechende Verbindung und stellt mit dieser automatisch den Kontakt her. Sämtliche Daten und Einstellungen werden in der Cloud gespeichert. Was Datenschützern die Haare raufen lässt, hat jedoch einen enormen Vorteil. Die mühenvollen Backups gehören der Vergangenheit an. Ist die Hardware defekt oder wird das Chromebook gestohlen, reicht der Griff zu einem anderen Chromebook oder einem ganz gewöhnlichen PC/Mac mit Internetverbindung. Weiterhin kann damit von jedem Ort und unabhängig von einem bestimmten System auf exakt dieselben Daten zugegriffen werden. Zu Hause oder im Büro (noch) mit einem normalen Notebook oder PC/Mac und von unterwegs im Café oder beim Kunden mit dem Chromebook.

Neben den bekannten Anwendungen wie Google Mail oder die Applikationen aus der Google Apps Suite stehen weitere Anwendungen im Chrome Web Store bereit.

Die Chromebooks verfügen über einen Mehrbenutzerbetrieb. So können sich mehrere Benutzer an dem System mit ihren Zugangsdaten anmelden und erhalten damit Zugriff auf ihre eigenen Anwendungen, Einstellungen und Erweiterungen. Zudem wurde in den Chromebooks u.a. mit dem Sandboxing, Verified Booting und einer Datenverschlüsselung eine mehrschichtige Sicherheitsarchitektur integriert.

Bei den ersten Chromebook Anbietern handelt es sich um Samsung und Acer. Ein Samsung Chromebook inkl. 3G soll für 499 Dollar ab dem 15. Juni bei Amazon erhältlich sein. Der deutsche Markt soll ebenfalls Mitte Juni bedient werden.

An Firmen richten sich die Chromebooks for business, für die ein zentrales Management sowie Software & Hardware as a Service angeboten werden. Der Preis für ein Chromebook for business beträgt 28 Dollar pro Benutzer pro Monat. Für den Bildungsbereich und öffentliche Einrichtungen 20 Dollar pro Benutzer pro Monat. Zudem wird es für Firmen alternativ eine Chromebox geben, die größere Monitore unterstützt.

Mehr zu den Chromebooks.

Kategorien
Management

"Design For Failure" via Amazon Web Services

Um die Möglichkeiten der Cloud eines Anbieter zu nutzen, ist es immens wichtig, die jeweilige Cloud zu verstehen. Daher sollte man sich ausreichend Zeit nehmen und die Whitepaper und Handbücher gründlich zu lesen und zu verstehen, um seine Anwendung somit gegen Fehler innerhalb der Infrastruktur zu schützen.

Hierfür hat Amazon eine Webseite geschaffen, auf der Whitepapers zum Download bereitstehen, die dabei helfen, fehlertolerante Anwendungen zu entwickeln und Cloud Architekturen zu verstehen.

An dieser Stelle ist es sehr interessant zu sehen, dass die Whitepapers bereits im Jahr 2010 bzw. im Januar 2011 erstellt oder aktualisiert wurden.

AWS Cloud Architecture Best Practices Whitepaper – Read

Dieses Whitepaper gibt einen technischen Überblick aller AWS Services und verschiedener Best Practice Ansätze für die architektonische Gestaltung, um damit effiziente und skalierbare Architekturen zu entwerfen.

Building Fault-Tolerant Applications on AWS Whitepaper – Read

In diesem Whitepaper werden Funktionen für die Erhöhung der Fehlertoleranz vorgestellt, die dazu dienen, um hoch zuverlässige und hochverfügbare Anwendungen innerhalb der AWS Cloud zu entwickeln.

Web Hosting Best Practices Whitepaper – Read

Dieses Whitepaper überprüft detailliert Lösungen für das Web Application Hosting. Dazu gehört unter anderem, wie jeder AWS Service genutzt werden kann, um eine hochverfügbare und skalierbare Webanwendung zu entwerfen.

Leveraging Different Storage Options in the AWS Cloud Whitepaper – Read

Dieses Whitepaper dient dazu, einen Überblick über die Speichermöglichkeiten in der AWS Cloud zu geben und darüber hinaus Szenarien vorzustellen, um eine effektive Nutzung zu erzielen.

AWS Security Best Practices Whitepaper – Read

In diesem Whitepaper werden bestimmte Tools, Funktionen und Richtlinien beschrieben, um zu verstehen, wie Cloud Anwendungen innerhalb der AWS Infrastruktur von Grund auf geschützt werden können.

Source: http://aws.amazon.com/architecture

Kategorien
Analysen

Was Unternehmen aus dem Amazon EC2 Problem in North Virginia lernen sollten!

Am 21. April haben wir es wieder erlebt. Auch eine hochverfügbare Cloud wie die von Amazon ist nicht vor Fehlern geschützt. Natürlich erhalten Kritiker nun wieder die Gelegenheit gegen die Nutzung der Cloud zu argumentieren. Aber um es vorweg zu nehmen, Anbieter wie Hootsuite, Mobypicture, Foursquare und Reddit hätten von dem Ausfall nicht betroffen sein müssen, hätten Sie auf eine ausfallsichere Architektur gesetzt.

Aus diesem Grund ist es nicht nachvollziehbar, dass diese Unternehmen mit dem Finger auf Amazon zeigen und sagen: „Uns trifft keine Schuld, Amazon ist down!“. Es wäre interessant zu wissen, wer zur Rechenschaft gezogen worden wäre, hätten diese Anbieter keinen Public Cloud Service genutzt, sondern betrieben ein eigenes Rechenzentrum. Denn eines ist klar, (solche) Probleme können in jedem Rechenzentrum auftreten und hätten dann bedeutend schwerwiegendere Probleme. Und wenn die Cloud richtig genutzt worden wäre, wären auch die Probleme bei Amazon in der Form nicht sichtbar geworden.

Was ist passiert?

Hintergrund
Die Amazon Cloud besteht aus mehreren Regionen, verteilt über mehrere Kontinente, in denen sich wiederum mehrere sogenannte Availability Zones befinden. Availability Zones sind verschiedene Standorte innerhalb einer Region, die so konstruiert sind, dass sie isoliert betrieben werden und von Fehlern in anderen Availability Zones nicht betroffen sind.

Durch das Starten von Instanzen in separaten Regionen, können Web Anwendungen so konstruiert werden, dass sich diese geographisch in der Nähe von bestimmten Kunden befinden und rechtlichen oder anderen Anforderungen gerecht werden.

Weiterhin werden Anwendungen vor dem Ausfall eines einzelnen Standorts geschützt, indem Instanzen in separaten Availability Zones ausgeführt werden.

Wie das Konzept genau funktioniert, kann unter Das Konzept hinter den AWS Regionen und Verfügbarkeitszonen nachgelesen werden.

Das Problem
Um 1:41 AM PDT begann das Problem mit Latenzen und Fehlerraten innerhalb der EBS Volumes und Verbindungsproblemen zu den EC2 Instanzen in mehreren Availability Zones der Region US-EAST-1.

Das führte dazu, dass die Webseiten bzw. Webanwendungen, die auf den EC2 Instanzen betrieben werden, nicht mehr erreichbar waren.

Design For Failure

Zunächst muss eines klar sein. Amazon stellt „nur“ virtuelle Ressourcen zum Aufbau einer eigenen virtuellen Infrastruktur bereit. Amazon ist NICHT für die Anwendung und deren Funktionalität zuständig, sondern stellt nur die Infrastruktur bereit, auf der die Anwendungen ausgeführt werden.

„Everything fails, all the time“ Werner Vogels, CTO Amazon.com

Aus diesem Grund rät Amazon: „Design for failure!“ und gibt Tipps, dieses umzusetzen:

  • Avoid single points of failure
  • Assume everything fails, and design backwards
  • Goal: Applications should continue to function even if the underlying physical hardware fails or is removed or replaced.

Und nennt Möglichkeiten für die Realisierung des Designs:

  • Use Elastic IP addresses for consistent and re-mappable routes
  • Use multiple Amazon EC2 Availability Zones (AZs)
  • Create multiple database slaves across AZs
  • Use Amazon Elastic Block Store (EBS) for persistent file systems

Design for failure! Ist im Prinzip nichts Neues. Im Grunde sollte das ebenfalls bei jedem anderen nicht Cloud Anbieter und im eigenen Rechenzentrum beachtet werden. Der Entwickler sollte immer in der Pflicht stehen, seine Anwendung gegen Hardware oder sonstige Ausfälle abzusichern und die Verfügbarkeit sicherzustellen.

Hootsuite und Mobypicture bspw. haben den Fehler gemacht, sich nur auf eine AWS Region zu konzentrieren, anstatt ihren Service über die gesamte Amazon Cloud hinweg zu verteilen. Speziell bei Mobypicture, als einen europäischen Anbieter mit Sitz in Holland, ist genau dies ein wenig verwunderlich. Die deutsche Seite von Foursquare hingegen war bspw. erreichbar und lief stabil, ebenso die von Reddit.

Nicht alles auf eine Karte setzen

Für jedes Unternehmen, das seinen Service über die Cloud anbietet, gilt es daher: „Nutze die gesamte Cloud eines Anbieters und verlasse Dich nicht nur auf einen einzigen Anbieter!“

Durch die Verteilung einer Anwendung über mehrere Regionen und Availability Zones bei einem Anbieter wird die Verfügbarkeit der Anwendung drastisch erhöht. Zudem ist eine MultiVendor Strategie zwingend erforderlich. Außerdem müssen bereits von Beginn an Fallback Szenarien entwickelt werden, um gegen einen plötzlichen Ausfall vorbereitet zu sein.

Es geht also bspw. darum, Systeme aufzubauen, die im Fehlerfall automatisch eine gespiegelte Infrastruktur bei einem anderen Anbieter aufbauen. Besser wäre es, mehrere Anbieter parallel zu nutzen und die Services über mehrere Anbieter hinweg zu verteilen. Dazu gehört z.B.: Instanzen von unterschiedlichen Anbietern parallel produktiv einzusetzen, um damit das Risiko zu streuen.

Denn: Cloud Computing löst nicht alle Probleme automatisch…

Für die Zukunft

Amazon darf auf keinen Fall von einer Schuld freigesprochen werden, dazu werben sie viel zu deutlich mit der eigenen Verfügbarkeit. Dennoch, beim Cloud Computing handelt es sich um bedeutend mehr als nur das Nutzen von ein paar virtuellen Ressourcen und jeder Nutzer der Cloud ist für die Verfügbarkeit seiner Anwendung selber verantwortlich. Dafür stehen ihm ausreichend Mittel und Wege auf Grund der Cloud zur Verfügung!

Kategorien
Analysen

Wo bleibt der Killer PaaS?

Es gibt nunmehr eine Vielzahl von Platform as a Service (PaaS) Angeboten auf dem Markt, die mehr oder weniger jede moderne Programmiersprache unterstützen. Doch eines haben alle gemeinsam. Jedes Angebot setzt auf maximal einem Infrastructure as a Service (IaaS) Angebot auf. Sei es ein Proprietäres oder das eines Drittanbieters. Wie zu erwarten ist derzeit noch die Infrastruktur von AWS die bevorzugte Wahl.

Betrachten wir eine kleine Auswahl von PaaS Angeboten und das darunter eingesetzte IaaS Angebot.

Was also fehlt ist ein unabhängiges gehostetes PaaS Angebot. Eine richtige PaaS Innovation! Eine Art PaaS Broker. SteamCannon geht in diese Richtung. Jedoch ist er 1. kein unabhängiger gehosteter Service (es steht ein AWS AMI zur Verfügung) und 2. wird derzeit nur AWS EC2 unterstützt.

Selbstverständlich muss der Service auch auf einer Plattform betrieben werden, aus diesem Grund mag das Verlangen nach einem unabhängigen gehosteten Service zunächst missverständlich sein. Aber bereits hier muss die Macht der Cloud genutzt werden. Der Killer PaaS darf nicht nur als AMI auf einer Infrastruktur laufen, sondern muss über mehrere Anbieter hinweg verteilt sein. So ist bereits dessen Ausfallsicherheit gewährleistet.

Der Killer

Warum ich diesen Service als Killer PaaS bezeichne ist ganz einfach. Er muss alle IaaS Anbieter und nicht nur einen bestimmten am Markt, sowie alle gängigen Programmiersprachen, unterstützen. Die Funktionalität ist in der Theorie recht simpel. Als Nutzer des Killer PaaS habe ich bereits vorher bei unterschiedlichen IaaS Anbietern wie AWS, Rackspace, GoGrid etc. einen Account registriert. Alternativ bietet mir der Killer PaaS an, dort einen erstellen zu lassen.

Nach belieben werden die Zugangsdaten für den jeweiligen IaaS Anbieter hinterlegt, auf die der Killer PaaS zugreifen kann. Ich kann bereits hier, wenn ich möchte, meinen primäre, sekundären etc. Anbieter festlegen. Mehr habe ich als Nutzer nicht zu tun.

Möchte ich meine Anwendungen in der Cloud betreiben, lade ich den Programmcode auf den Killer PaaS hoch. Dieser kümmert sich nun um den Rest und deployed die Anwendung auf die von mir hinterlegten Infrastrukturen. Das kann er entweder willkürlich vornehmen, da er den Status der jeweiligen Infrastruktur bzgl. Performance etc. kennt, oder er zieht die von mir vorher festgelegten Einstellungen in betracht und verteilt die Anwendung auf den primären Anbieter. Falls dieser zu ausgelastet ist auf den Sekundären usw..

Der Killer PaaS ist so intelligent, dass er die gesamte Anwendung über mehrere Anbieter hinweg verteilt und damit die bestmögliche Performanz und Verfügbarkeit gewährleistet. Habe ich mich als Nutzer jedoch zu Beginn dafür entschieden die Anwendung bei einem primären Anbieter ausführen zu lassen und hat dieser nun Performance- oder anderweitige Probleme, sorgt der Killer PaaS dafür, dass automatisch weitere (oder alle) Ressourcen von einem anderen Anbieter genutzt werden. Mir sind Fälle bekannt, bei denen Anwender bei AWS keine neuen Instanzen in einer AWS Region mehr starten konnten, weil nicht genügend Ressourcen vorhanden waren. Davon darf ich bzw. meine Anwendung jedoch nichts mitbekommen. Wenn meine Anwendung plötzlich einer enormen Belastung, z.B. auf Grund eines Besucherandrangs, ausgesetzt ist und der IaaS Provider ebenfalls einen Ressourcenengpass hat, sorgt der Killer PaaS dafür, dass Ressourcen von einem anderen Anbieter bezogen oder andere Maßnahmen eingeleitet werden.

Mit so einem Killer PaaS können ebenfalls viele Fragen bzgl. SLAs geklärt werden. Die Ausfallsicherheit und Verfügbarkeit der Anwendung wird hier durch den Killer PaaS sichergestellt. Da dieser ebenfalls über mehrere IaaS Anbieter hinweg in der Cloud betrieben wird, ist auch dessen Verfügbarkeit gewährleistet.

Was also benötigt wird ist eine unabhängige Cloud Management Platform wie bspw. enstratus, nur für PaaS.

Kategorien
Services

Big Blues Kampf im Jungle – IBM gegen Amazon

Mit den „Smart Business Clouds“ hat nun auch IBM seine Public Cloud Infrastruktur für Unternehmenskunden vollständig geöffnet und hat angekündigt im Laufe des Jahres ein weiteres Angebot mit einer deutlich höheren Verfügbarkeit zu veröffentlichen.

IBMs „Smart Business Clouds“ (SmartCloud) bestehen aus den eigenen vorkonfigurierten x64-basierten CloudBurst Stacks und werden in einer Vielzahl von Cloud Rechenzentren überall auf der Welt betrieben. IBM unterscheidet seine SmartCloud in den Angeboten Enterprise und Enterprise+, die von den IBM’s Global Technology Services vertrieben werden.

Die bereits verfügbare „SmartCloud Enterprise“ Infrastruktur umfasst ausschließlich x64-basierte Server und bietet ein Service Level Agreement (SLA) mit einer Verfügbarkeit von 99,5%. Weiterhin unterstützt IBM auf seinen virtuellen Maschinen 32-bit und 64-bit Betriebssysteme wie Microsoft Windows 2003 und 2008, Red Hat Enterprise Linux 5.4 und 5.5 und Novell SUSE Linux Enterprise 11

Die „SmartCloud Enterprise+“ Infrastruktur wird in der zweiten Jahreshälfte von 2011 erwartet. Kunden erhalten hier die Möglichkeit, x64 basierte oder Power Server zu kaufen, auf denen sie ihre Anwendungen betreiben können. Hier erhöht IBM zudem seine SLAs auf 99,9% Verfügbarkeit

Im Gegensatz zu seinem Angebot „Smart Business Development and Test on the IBM Cloud“, bei dem IBM als Hypervisor auf eine RedHat/ KVM Kombination setzt, nutzen die „SmartClouds“ den VMware ESXi Hypervisor. Um auch Kunden zu bedienen, die auf andere Hypervisor setzen als den von VMware, wird IBM dazu übergehen müssen, ebenfalls KVM und Microsofts Hyper-V zu unterstützen. Auf den Power Servern in der „SmartCloud Enterprise+“ setzt IBM auf seinen eigenen PowerVM Hypervisor und unterstützt hier die Betriebssysteme AIX Unix, Red Hat Enterprise Linux, sowie den SUSE Linux Enterprise Server.

Die Abrechnung der SmartClouds erfolgt pro VM pro Stunde. Zudem steht ein Softwarekatalog bereit, aus dem sich Kunden IBM spezifische Anwendungen wie Middleware, Groupware und Datenbanken, sowie Anwendungen von Drittanbietern wie die Cloud Management Software von Kaavo oder Plattformen zur Entwicklung von Webanwendungen wie von Aviarc, beziehen können.

Die Preise für die SmartClouds sind ebenfalls öffentlich. Vergleichbar mit Amazons EC2 rechnet IBM auch hier on-Demand ab und bietet seinen Kunden Optionen auf reservierte Kapazitäten. Das „SmartCloud Enterprise+“ Angebot hingegen wird nicht stündlich on-Demand abgerechnet. Hier muss sich der Kunde entweder für eine monatliche Abrechnung oder einen festen Vertrag mit Laufzeit entscheiden. Jedoch stehen ihm hier weitere Managed Services, sowie mehrere Sicherheitsstufen zur Verfügung.

Wie ebenfalls von Amazon EC2 bekannt, kann ein Kunde auch bei den „SmartClouds“ zwischen unterschiedlichen Konfigurationen von virtuellen Maschinen wählen. Je nach Leistungsstufe wird hier von Copper bis Platinum unterschieden.

Für eine 32-bit Konfiguration kann je nach Leistungsstufe zwischen 1 bis 4 virtuellen CPUs mit 1,25 GHz, zwischen 2GB bis 4GB virtuellen RAM und zwischen 60GB und 350GB virtuellen Instanzspeicher gewählt werden. Für einen Red Hat Enterprise Linux Server und einer Copper Konfiguration berechnet IBM 15.4 Dollar(cent) pro Stunde.

Für eine 64-bit Konfiguration kann je nach Leistungsstufe zwischen 2 bis 16 virtuellen CPUs mit 1,25 GHz, zwischen 4GB bis 16GB virtuellen RAM und zwischen 60GB und 2TB virtuellen Instanzspeicher gewählt werden.

Im Vergleich zu Amazon EC2 ist die IBM SmartCloud erheblich teurer, was aber daran liegt, das IBM mit seinem Angebot gezielt nur Unternehmen anspricht. So kostet die kleinste 32-bit Copper Instanz mit einem SUSE Enterprise Linux Server 11.0 0,095 Dollar pro Stunde und eine 64-bit Platinum Instanz mit einem Red Hat Linux Enterprise Server 5.4 und 5.5 1,84 Dollar pro Stunde. (Jeweils für nicht reservierte Kapazitäten.)

Das sich das Angebot an Unternehmen richtet, wird bei der Registrierung deutlich. Hier kann zwischen weiteren „Optional Premium Services“ wie „On-boarding support“ (Remote on-boarding support | Einmalig 3.000 Dollar), „Virtual Private Network service“ (Network isolation of your instances through a virtual private network on the IBM Cloud | Einmalig 1.000 Dollar plus 300 Dollar monatlich) oder weiterem „Support“ unterschieden in „Premium support“ für 5% von der Gesamtnutzungsgebühr pro Monat (aber mindestens 75$ pro Monat) und „Advanced Premium support“ für 10% von der Gesamtnutzungsgebühr pro Monat (aber mindestens 1000$ pro Monat), gewählt werden.

Die SmartCloud Enterprise Infrastruktur befindet sich in unterschiedlichen Cloud Rechenzentren überall auf der Welt. Kunden aus den USA beziehen die Services aus Raleigh in North Carolina und Boulder in Colorado. Kanadische Kunden werden aus Toronto in Ontario bedient. Für Europa, den mittleren Osten und Afrika werden die Services über ein Rechenzentrum aus Ehningen in Deutschland bereitgestellt, sowie für asiatische Kunden über ein Rechenzentrum in Singapur und Tokio.

Fazit

Für Unternehmenskunden sind die IBM „SmartCloud Enterprise Services“ auf Grund ihrer umfangreichen Serviceleistungen ein attraktives wenn auch teures Angebot. Ob IBM damit tatsächlich den Kampf mit Amazon aufnehmen kann und möchte bleibt fraglich. Denn einen entscheidenen und attraktiven Vorteil hat Amazon gegenüber IBM. Die AWS Cloud ist ein echtes Public Cloud Angebot und ist für jedermann zugänglich. So haben auch Entwickler oder „normale Menschen“ mit einer Idee die Möglichkeit die Services von Amazon zu nutzen. IBM hingegen richtet sich gezielt an Unternehmenskunden und hat nicht den Bedarf auf die Wünsche einfacher Benutzer einzugehen.

Aus eigener Sicht betrachtet, muss IBM sich darauf auch nicht einlassen, da die Dienstleistungen seit jeher Unternehmen adressierten. Spannend bleibt, ob und wie Amazon darauf reagiert. Wie bereits oben erwähnt, kann sich Amazon jedoch darauf berufen, die „Cloud für jedermann“ zu sein. Vor allem Startups, Entwickler mit innovativen Ideen und Fachabteilungen die „nur mal etwas ausprobieren wollen“, werden weiterhin auf Grund des unkomplizierten Ressourcenbezugs und der einfachen und kostengünstigen Abrechnung auf die AWS Cloud zurückgreifen.

Kategorien
Events

Die SecTXL ‘11 – "Juristische und Technische Sicherheit für die Cloud!"

Der Hype um das Thema Cloud Computing hat sich mittlerweile auch in Deutschland gelegt und die heiße Phase der Adaption hat begonnen. Damit stehen Unternehmen neben technischen Herausforderungen ebenfalls Fragen bzgl. der Datensicherheit, des Datenschutzes und rechtlicher Themen gegenüber.

Die SecTXL ‘11 nimmt sich am 11.08.2011 in Hamburg genau diesen Themen an und konzentriert sich ganzheitlich mit ihrem Leitsatz „Juristische und Technische Sicherheit für die Cloud!“ auf den Bereich der Cloud Computing Sicherheit. Neben fachlichen Vorträgen von Rechtsanwälten und Experten aus den Bereichen des Datenschutzes und der Datensicherheit werden ebenfalls technische Probleme und deren Lösungen von IT-Architekten vorgestellt. Damit werden Möglichkeiten aufgezeigt, wie sich Unternehmen in Zeiten des Cloud Computing aus dem Blickwinkel der Sicherheit verhalten müssen.

Für eine Festigung und Vertiefung des während der Vorträge vermittelten Wissens finden im Anschluss an die Vortragsreihe eine Auswahl von Workshops statt. In diesen werden die Referenten dann detaillierter auf das von Ihnen vorgestellte Thema eingehen, weitere Ansätze erarbeiten sowie Fragen beantworten.

Mit einem Audience Talk erhalten darüber hinaus drei Teilnehmern die Möglichkeit, vor allen Referenten und den restlichen Teilnehmern einen themenbezogenen Vortrag ihrer Wahl zu halten, in welchem sie ihre Meinung zu einem bestimmten Bereich mitteilen dürfen. Dieser darf natürlich gerne polarisierend sein. Dazu können alle Teilnehmer während der Registrierung oder auch gerne im Nachhinein einen Themenvorschlag einreichen.

Der krönende Abschluß der Veranstaltung sind die SecTXL Awards, bei denen die Referenten für ihre Leistungen ausgezeichnet werden. Dazu stimmen alle Teilnehmer während der Veranstaltung für ihren Favoriten ab.

Mit einem SecTXL Leitfaden Cloud Computing Sicherheit wird zudem im Anschluß der Veranstaltung eine Publikation veröffentlicht, in der alle Referenten ihr Wissen noch einmal zum Besten geben. Diesen werden alle Teilnehmer exklusiv und kostenlos erhalten.

Alle weiteren Informationen und die Anmeldung sind unter http://sectxl.com zu finden.

Kategorien
Analysen

Die "Mobile Cloud" ist der wahre Megatrend

Genau genommen laufen die beiden Megatrends Mobile Computing und Cloud Computing bereits seit mehreren Jahren Hand in Hand nebeneinander her.

Worauf viele Anbieter wie z.B. Apple jahrelang verzichtet haben, hat Google bereits während der Einführung von Android besonderen Wert gelegt und hat damit das enorme Wachstumspotential erkannt. So hat Google z.B. seine Dienste wie Mail, Kalender etc. sowie das App Deployment über den Market Cloud basiert ausgerichtet.

Das erste Android Endgerät (HTC Dream | T-Mobile G1) kam am 22.10.2008 auf den Markt. Zielgruppe waren in erster Linie Privatnutzer, die mit einem Googlekonto ihre E-Mails, Termine, Kontakte etc. synchronisieren wollten. Nach etwas über einem Jahr entwickelte sich das System langsam aber sicher zu einer mobilen Plattform für den Unternehmenseinsatz. Das Update auf Android 1.6 brachte nun auch die lang ersehnte Möglichkeit, das Endgerät via VPN mit einer Gegenstelle zu verbinden. Verbindungen können hierbei über die Protokolle PPTP und L2TP (IPsec PSK bzw. IPsec CRT) hergestellt werden.

Für den Einsatz im Unternehmen stehen Anwendungen für unterschiedliche Bereiche zur Verfügung. Als mobiler Dateimanager ist der Astro File Manager eine gute Alternative. Wie schon auf den Palm Handhelds hat Dataviz ebenfalls für Android eine Version seiner mobilen Office Suite Documents To Go im Portfolio. Über einen kostenlosen Viewer können Word Dokumente, Excel Dateien und Power Point Präsentationen betrachtet werden. Die kostenpflichtige Version gestattet dann auch das Erstellen und Bearbeiten der oben genannten Dateien und zusätzlich das Betrachten von PDF-Dateien. Für Administratoren steht das Programm Server up bereit. Damit können Netzwerke und Webserver mobil überwacht werden und es informiert über unterschiedliche Arten u.a. per SMS oder E-Mail, wenn z.B. ein Server nicht mehr erreichbar ist. Salesforce, Anbieter von Geschäftsanwendungen (u.a. CRM) stellt seine Produkte ebenfalls als mobile Versionen mit dem Namen Salesforce Mobile zur Verfügung. Da diese allerdings über den Webbrowser genutzt werden sind sie daher aber nicht auf Android beschränkt. Für den Abruf von E-Mails bzw. die Synchronisation mit einem Microsoft Exchange Server stehen u.a. Anwendungen wie K-9 Mail, TouchDown oder Aardvark bereit.

Der meiner Ansicht nach größte Vorteil von Android, der auch für den Einsatz im Unternehmen spricht ist die Portabilität. Neben Smartphones funktioniert Android auf den beliebten Netbooks und Tablets. Aber ebenso der Einsatz auf modernen Kassensystemen, MDEs (Mobile Datenerfassung) und jeder Art von Embedded Systems ist vorstellbar.

Optimales Szenario

Das bisher noch einfachste und bzgl. Android mit dem wenigsten Aufwand verbundene Szenario ist der vollständige Einsatz der Google Infrastruktur. Das setzt allerdings voraus, dass von dem Unternehmen bereits Google Apps für die E-Mail Kommunikation und die Verwaltung der Kalender und Kontakte eingesetzt wird. Android ist per se vollständig in die Google Infrastruktur integriert. Somit werden alle Änderungen die z.B. im E-Mail Postfach oder im Kalender stattfinden automatisch mit den Google Servern synchronisiert. Daher sind die Daten eines Benutzers – egal an welchem Arbeitsplatz (Desktop/ Mobil) er sitzt – immer auf dem aktuellen Stand. E-Mails werden über den Push-Mail Dienst automatisch auf das mobile Endgerät zugestellt. Dies ist wohlgemerkt das optimale Szenario und kann so nicht ohne einen Mehraufwand umgesetzt werden, wenn z.B. ein Exchange Server eingesetzt wird.

Ideal für eine Cloud Strategie

Android verfolgt u.a. den Ansatz des Cloud Computing. Das heißt die Daten liegen dabei in einer Serverfarm im Internet und synchronisieren sich in diesem Fall mit dem mobilen Endgerät.
Entscheidet sich ein Unternehmen z.B. für das oben beschriebene Szenario, bei dem die Daten bei Google gespeichert werden, kann hier auf die Bereitstellung und Wartung der mobilen Infrastruktur im eigenen Rechenzentrum verzichtet werden, was einen klaren Kostenvorteil bedeutet. Durch das Speichern der Unternehmensdaten auf den Servern und nicht auf dem mobilen Endgerät sind die Daten geschützt. Das Endgerät kann im Falle eines Diebstahls oder anderen Missgeschicken jederzeit zentral gesperrt bzw. generell zentral administriert werden. Telefongespräche können über das Unternehmensnetzwerk stattfinden. Die Gespräche werden vom mobilen Endgerät gestartet und anschließend vom Unternehmensnetzwerk geroutet (z.B. in das Festnetz) und gesteuert. Der Vorteil besteht in der deutlichen Trennung von privaten und geschäftlichen Gesprächen, der Nutzung einer einzigen Rufnummer und den Zugriff auf die zentrale Kontaktdatenbank des Unternehmens. Neben (mobilen) Telefonkonferenzen über das Unternehmensnetzwerk unabhängig von Ort/ Zeit und beliebig vielen Benutzern besteht die Möglichkeit den aktuellen Status jedes Benutzers abzufragen um so zu sehen ob dieser gerade Verfügbar ist. Weiterhin haben u.a. Außendienstmitarbeiter Zugriff auf sämtliche Daten (z.B. CRM oder ERP) von jedem Ort mittels einer (mobilen) Internetverbindung.

Fazit

Die Mobile Cloud ist kein Zukunftsthema sondern bereits seit längerer Zeit in der Gegenwart angekommen. In ihr verschmelzen die beiden Megatrends Mobile Computing und Cloud Computing zu einem Hypertrend (wenn man diesen so bezeichnen darf) und ermöglichen Unternehmen und Ihren Mitarbeitern somit den Zugriff auf sämtliche Daten von jedem Ort und zu jeder Zeit.

Kategorien
Events

Der Ablauf des CloudOps Summit

Der CloudOps Summit 2010 am 17.03.2011 will den Focus auf den Betrieb und die Architektur von Cloud Computing Infrastrukturen legen und eine Brücke zwischen den bislang oft Marketing-getriebenen Angeboten hin zum Betrieb und den Architekten solcher Lösungen schlagen. Unter dem Motto “Run your Cloud” wollen die Veranstalter besonders das Thema “Betrieb von dynamischen und cloud-basierten Infrastrukturen” in den Vordergrund stellen und die Teilnehmer zu einer intensiven Diskussion einladen.

Nach einer Serie von Lightning Talks von 5 bis 7 Minuten Länge, sollen die Teilnehmer im Rahmen von 4 Workshop-Tracks mit jeweils 2 Vorträgen die Gelegenheit haben, die Themen zu vertiefen. Die Workshop-Tracks sind wie folgt strukturiert:

Track 1 – Management

  • Datenschutz/Datensicherheit
  • Compliance
  • Strategien
  • Nachhaltigkeit

Dieser Track wird den Schwerpunkt auf Themen legen, mit den sich heute die Vorstände und IT-Strategen befassen müssen, um für einen erfolgreichen und nachhaltigen Einsatz von Cloud Computing im Unternehmen vorbereitet zu sein. Auch wird hier Raum für die Diskussion wirtschaftlichen und ökonomischen Aspekte und der damit verbundenen Chancen des Cloud Computing Paradigmas für Unternehmen sein.

Track 2 – Operations

  • Anbieter/Lösungen/Tools
  • Herausforderungen bei der Umsetzung
  • Migration

Im Operationstrack wollen die Veranstalter die Diskussion auf Erfahrungen bei Durchführung von konkreten Cloud Computing Projekten diskutieren und besonders auf Hindernisse, Herausforderungen und Werkzeuge eingehen. Ein weiterer Schwerpunkt wird die Migration existierender Anwendungen sein.

Track 3 – Architecture

  • Best Practices/Methoden
  • Standards/Zertifizierung
  • Open Source

Dieser Track soll Diskussionen um die Standardisierung und ‘Best Practices’ von Cloud Computing Lösungen und Architekturen umfassen und auch auf damit verbundene Themen wie Stacks, Plattformen und Open Source eingehen.

Track 4 – Investors/Startups

  • Elevator Pitches

Im Rahmen der Elevator Pitches wird ausgesuchten Startups die Gelegenheit gegeben sich und Ihre Cloud Computing Lösungen oder Projekte vorzustellen. Die Veranstalter wollen so die Chancen des Cloud Computing aufzeigen und entsprechende Firmen und Produkte präsentieren, die allen auf dem Weg in die Clouds begleiten werden.

Weitere Informationen und die Anmeldung sind auf http://cloudops.cloudcontrolled.com zu finden.

Kategorien
Tutorials

Ubuntu Enterprise Cloud Topologien

Eine Ubuntu Enterprise Cloud kann aus zwei, bzw. bis zu hunderten oder sogar tausenden physikalischen bestehen. Es ist daher wichtig, die möglichen Topologien zu verstehen, die auf Basis der vorhandenen physikalischen Maschinen aufzubauen sind.

1 physikalisches System (Nicht für den produktiven Einsatz empfohlen)

Dies ist die einfachste mögliche Konfiguration. Dabei werden der CLC/Walrus/CC/SC und NC alle gemeinsam auf einer einzigen Maschine betrieben. Diese Konfiguration unterscheidet sich nicht von allen anderen möglichen. Der einzige Unterschied besteht darin, dass der Netzwerkverkehr hierbei nicht durch das lokale Netzwerk übertragen wird.

    1. Maschine A: CLC/Walrus/CC/SC/NC

Beispiel Konfiguration (für ein bestehendes LAN)

Netzwerk Konfiguration:

  • Netzwerk: 192.168.1.0/24
  • DHCP und DNS Server: 192.168.1.2
  • UEC Server: 192.168.1.4
  • /etc/network/interfaces auf dem UEC Server
iface eth0 inet manual

auto br0
iface br0 inet static
    address 192.168.1.4
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    gateway 192.168.1.2
    # dns-* options are implemented by the resolvconf package, if installed
    # these are google's dns servers
    dns-nameservers 8.8.8.8 8.8.4.4
    # this setting could be "local" if you all your local hosts
    #  were named something like a.localdomain b.localdomain c.localdomain etc
    dns-search localdomain
    bridge_ports eth0
    bridge_fd 9
    bridge_hello 2
    bridge_maxage 12
    bridge_stp off
  • /etc/eucalyptus/eucalyptus.conf – wichtige Einträge:
VNET_PUBINTERFACE="br0" # must match the br definition above
VNET_PRIVINTERFACE="br0" # must match the br definition above
VNET_MODE="MANAGED-NOVLAN"
VNET_SUBNET="172.19.0.0" # ips from this range are bound to $VNET_PRIVINTERFACE:priv
VNET_NETMASK="255.255.0.0"
VNET_DNS="192.168.1.2" # what DNS server nodes are given
# v - should be ips on the LAN, not in use anywhere, and excluded from the DHCP server
VNET_PUBLICIPS="192.168.1.100-192.168.1.110"

Sollten das Netzwerk nach der Konfiguration nicht starten helfen die folgenden Befehle beim Korrigieren.

sudo stop eucalyptus CLEAN=1
sudo /etc/init.d/eucalyptus-nc stop
# fix the config file here
sudo start eucalyptus CLEAN=1
sudo /etc/init.d/eucalyptus-nc start

Der Parameter CLEAN sorgt dafür, dass sich das Netzwerk nicht bei jedem Neustart resetet. Es sollte darauf geachtet werden, dass kein System auf die ETH0 Schnittstelle gebunden ist. Um sicherzugehen, dass man mit einer sauberen Konfiguration arbeiten kann, ist ein Neustart des gesamten Systems. Wurde die PRIV Schnittstelle falsch konfiguriert, werden die Nodes ihre DHCP-Antworten von dem LAN-DHCP-Server anstelle des privaten CC-DHCP-Server erhalten.

Mindestens 2 physikalische Systeme

Bei dieser Konfiguration werden alle Verwaltungskomponenten für den Benutzer wie CLC und Walrus, sowie die Verwaltungskomponenten für das Backend wie der CC und SC auf einer gemeinsamen Maschine installiert. Der NC für das Hosting der virtuellen Maschinen erhält eine eigene physikalische Maschine.

    1. Maschine A: CLC/Walrus/CC/SC
    2. Maschine B: NC
    3. (weitere NCs…)

Mindestens 3 physikalische Systeme

Bei dieser Konfiguration werden die Verwaltungskomponenten für den Benutzer wie CLC und Walrus auf eine physikalische Maschine, sowie die Verwaltungskomponenten für das Backend wie der CC und SC auf einer weiteren zweiten Maschine installiert. Der NC für das Hosting der virtuellen Maschinen wird auf eine dritte physikalische Maschine installiert.

    1. Maschine A: CLC/Walrus
    2. Maschine B: CC/SC
    3. Maschine C: NC
    4. (weitere NCs…)

Mindestens 4 physikalische Systeme

Bei dieser Konfiguration erhalten der CLC und Walrus jeweils eine eigene physikalische Maschine. Auf die dritte Maschine werden der CC und SC installiert. Für den NC wird eine vierte physikalische Maschine eingesetzt.

    1. Maschine A: CLC
    2. Maschine B: Walrus
    3. Maschine C: CC/SC
    4. Maschine D: NC
    5. (weitere NCs…)

Mindestens 5 physikalische Systeme

Für diese Konfiguration werden der CLC und der Walrus auf einer gemeinsamen Maschine konfiguriert. Auf eine dritte Maschine werden der CC1 sowie der SC1 installiert. Für den NC1 kommt eine eigene Maschine zum Einsatz. Um die Performance der Cloud zu erhöhen und die Last besser zu verteilen, werden auf einer vierten Maschine ein CC2 und ein SC2 konfiguriert. Auf eine fünfte Maschine wird ein NC2 installiert, der anschließend seine Ressourcen von dem CC2 und SC2 erhält.

    1. Maschine A: CLC/Walrus
    2. Maschine B: CC1/SC1
    3. Maschine C: NC1
    4. Maschine D: CC2/SC2
    5. Maschine E: NC2
    6. (weitere CCs/SCs/NCs…)

Quelle: UECTopologies

Kategorien
News

Salesforce.com stellt fünf neue Services für die Erstellung von Cloud 2-Apps vor

Mit Appforce, Siteforce, VMforce, ISVforce und Heroku hat salesforce.com fünf neue Cloud Plattform Services für die Erstellung von Cloud 2-Apps vorgestellt. Force.com 2 beseitigt dabei Hardware- und Softwarekomplexität und ermöglicht Unternehmen und ISVs, Anwendungsentwicklungsprojekte zu beschleunigen.

  • Appforce – Kollaborative Apps für verschiedene Abteilungen
    Appforce hilft Unternehmen leistungsfähige und skalierbare Apps für alle Abteilungen zu erstellen. Nutzer können Formulare anlegen, Reports anpassen, Unternehmensprozesse visuell abbilden und gleichzeitig sicher stellen, dass diese messbar und prüffähig sind. Und sie können über Salesforce Chatter zusammenarbeiten.
  • Siteforce – Pixelgenaue Erstellung von Webseiten ohne Code
    Die Erstellung von Webseiten ist oft langwierig und mühsam und fordert kontinuierlich neue Landing Pages, Produkte und Kampagnen. Zusätzlich stehen Entwickler heute vor der Herausforderung, soziale, mobile und Echtzeit-Funktionen zu integrieren. Siteforce gibt Anwendern die Werkzeuge an die Hand, um einfache Änderungen vornehmen zu können. Web-Entwickler haben die Möglichkeit, schnell leistungsstarke Seiten zu liefern. Siteforce macht es einfach, in Echtzeit Seiten zu entwerfen, Inhalte zu verwalten und vorgefertigte Komponenten wiederzuverwenden.
  • VMforce – Der Weg für Java-Entwickler in die Cloud
    VMforce, die salesforce.com-Partnerschaft mit VMware, ermöglicht es 6 Millionen Java-Entwicklern, ihre bestehende Java-Expertise sowie die Vorteile des Cloud Computings einzusetzen und neue, mobile und soziale Echtzeit-Anwendungen für Unternehmen in der Cloud zu erstellen. Mit VMforce können Entwickler ihre Java-Anwendungen direkt auf Force.com laufen lassen, die beliebten Java-Entwicklungsumgebungen Spring Framework und Eclipse IDE nutzen und offene Standards, wie zum Beispiel JPA für die Entwicklung von Javaanwendungen für Unternehmen verwenden. VMforce ist derzeit für ausgewählte Kunden als Beta-Programm verfügbar.
  • Heroku – Die Ruby Cloud Application-Plattform
    Heroku ist die führende Ruby Platform-as-a-service, die von Beginn an in einer offenen Umgebung erstellt wurde, um die Vorteile der Programmiersprache nutzen zu können. Ruby ist die führende Sprache für die Erstellung einer neuen Generation von Apps. Diese sind sozial, kollaborativ und ermöglichen Echtzeit-Zugang zu Informationen über mobile Endgeräte. Heroku ist heute Grundlage für mehr als 105.000 Apps.
  • ISVforce – Ermöglicht ISVs die Erstellung und Bereitstellung von multi-tenant Cloud-Apps
    ISVforce bietet ISVs umfassende Services für Anwendungsentwicklung, Tests und Bereitstellung, automatische Upgrade-Möglichkeiten, den AppExchange-Marktplatz für Cloud Apps sowie eine Echtzeit-Konsole zur Überwachung der Nutzung durch Kunden. ISVforce legt all diese Services hinter jede ISV App. Führende ISVs wie Blackboard, BMC und CA nutzen ISVforce um Anwendungen zu erstellen und zu liefern.