Tag: SimpleDB

Categories
Services @de

AWS Cloud Cleaner: Zerstöre Deine Amazon Cloud Infrastruktur innerhalb von Sekunden! [Mobile App]

Der Weg aus der (Amazon) Cloud geht meist schneller als man denken mag. Der “AWS Cloud Cleaner” erledigt das mit einem Tastendruck. Aber Vorsicht, er kennt keine Gnade! Im Anschluss ist die selbst aufgebaute Amazon Infrastruktur vollständig gelöscht.

Ein Klick und die Infrastruktur der Amazon Cloud wird gelöscht!

Cloud Computing stellt das ideale Szenario zum Aufbau von Test- und Demo-Umgebungen dar. Wurde früher Tage oder gar Wochen auf die dafür benötigte Infrastruktur gewartet, bis mit der Installation der Software begonnen werden konnte, um anschließend die Testläufe zu starten, dauert es heute, je nach Expertise, nicht einmal mehr ein paar Stunden, bis der Test starten kann.

Allerdings können Testumgebungen mit der Zeit wachsen, insbesondere dann, wenn quasi unendliche Ressourcen und Kapazitäten zur Verfügung stehen. Diese gilt es am Ende der Testphase einzeln herunterzufahren und zu löschen. Manuell kann dieser Vorgang viel Zeit in Anspruch nehmen und es können zudem Ressourcen übersehen werden.

AWS Cloud Cleaner: Zerstöre Deine Amazon Cloud Infrastruktur in Sekunden!

Ein dafür nützliches Tool, der “AWS Cloud Cleaner” hilft Cloud Nutzern bei dieser Arbeit. Die mobile App für iPhone 3GS, iPhone 4, iPhone 4S, iPod touch (3. Generation), iPod touch (4. Generation) und iPad löscht die innerhalb eines AWS Accouns genutzten Ressourcen mit einem Tastendruck. Zunächst überprüft die App, ob alle Ressourcen und Services in den jeweiligen Regionen verfügbar sind. Anschließend werden diese vollständig und automatisiert gelöscht.

AWS Cloud Cleaner: Zerstöre Deine Amazon Cloud Infrastruktur in Sekunden!

Der “AWS Cloud Cleaner” steht in der Version 1.0.0 im iTunes Store zum Download bereit und unterstützt die folgenden Services:

  • Amazon Elastic Compute Cloud (EC2)
  • Amazon Amazon Simple Storage Service (S3)
  • Amazon Simple Queue Service (SQS)
  • Amazon Simple Notification Service (SNS)
  • Amazon SimpleDB

Diese App sollte wirklich mit Vorsicht benutzt und nicht für Produktionsumgebungen eingesetzt werden! Ansonsten kann es sehr schmerzhaft werden!

Bildquelle: Facebook

Categories
Analysen

Verliert die Google App Engine ihre Attraktivität?

Platform-as-a-Service (PaaS) gehört mit Abstand zu den Zukunftsthemen im Cloud Computing. Im Jahr 2011 kamen neben bereits bestehenden Anbietern wie Heroku, Cloud Foundry, Engine Yard, Beanstalk, Windows Azure, Force.com, OpenShift oder cloudControl, viele weitere hinzu, was die mediale Präsenz dieses Cloud Bereichs anhob. Nur um einen Service ist ein wenig ruhig geworden: Die Google App Engine.

Die Google App Engine war bereits sehr früh verfügbar

Die Google App Engine (GAE) gehört mit der Erscheinung im Jahr 2008 zu einer der ersten PaaS am Markt und war der einzige Service der Python und Java gleichzeitig unterstützte. Aber im Laufe der Jahre hat die Innovation rund um GAE deutlich nachgelassen.

Startups und Entwickler gehörten zu den Hauptnutzern von GAE. Das lag in erster Linie an den Möglichkeiten der weitestgehend kostenlosen Nutzung und den nicht notwendigen Investitionen in SDKs und Plugins. Ein weiterer Grund war die geringe Auswahl an Angeboten. Java und Python Entwickler würden niemals Windows Azure wählen, was zu diesem Zeitpunkt die einzige Alternative war. Nach und nach entwickelte sich Heroku (mittlerweile von Salesforce aufgekauft) zu einer echten Alternative für Python Entwickler, auf Kosten der Google App Engine. Doch bereits während der Anfangsphase der GAE hat Google es verpasst die riesige Anzahl an gehosteten Anwendung an Bord zu behalten und die wichtige Entwickler Community für sich zu gewinnen. Was ist also der Grund für den Abstieg der Google App Engine?

Refactoring und Vendor lock-in

Ein Hauptproblem der Google App Engine besteht in den massiven Änderungen die vorgenommen werden müssen, wenn eine Anwendung auf die GAE portiert werden soll. Befindet sich die Anwendung dann auf der GAE, kann sie ausschließlich die proprietäre API nutzen, was es Entwickler sehr schwierig macht, später die Plattform wieder zu wechseln. Selbst Standard Java Web Anwendungen müssen an vielen Stellen angepasst werden, um auf der GAE betrieben zu werden. Während Heroku weitere Funktionen hinzufügte und für eine bessere Kontrolle sorgte, schränkte Google die Entwickler mit der proprietären API ein.

Beta-Status und Innovationen

Microsoft, das für seine langen Release-Zyklen bekannt ist, hat es geschafft das Azure SDK mehrfach zu aktualisieren und das Management Portal häufig zu verbessern. Die Google App Engine orientiert sich an Googles “Beta-Status” Tradition. So blieb die GAE für fast drei Jahre im Beta-Status, was professionellen Entwicklern nicht die Sicherheit gab, ihre Produktionsanwendungen auf die GAE zu portieren. Während Google in der jungen Vergangenheit mit Pull Queues, Cloud SQL und der Blobstore API viele der gewünschten Funktionen umsetzen konnte, hat es lange gedauert auf die Bedürfnisse der Kunden zu reagieren.

Schlechte Unterstützung für Unternehmensanwendungen

Lange unterstützte die GAE nur zustandslose Web Anwendungen. Technologisch betrachtet können auf der GAE somit nur Web Anwendungen entwickelt werden, die keine komplexe Business-Logik benötigen. Bspw. verfügt Windows Azure über ein Rollenkonzept (Web Roles), um Web Anwendungen zu betreiben und Worker Roles, um damit lang laufende Prozesse und komplexe Geschäftsregeln ausführen zu lassen. Ähnlich verhält es sich bei Heroku, wo der Web Dyno und Worker Dyno diese Funktionen aufteilen. Bis zur Einführung von Backends in der Version 1.5.0 (Mai 2011), machte diese mangelnde Unterstützung zur Aufteilung einer Anwendung es schwierig Unternehmensanwendungen auf die GAE zu migrieren.

Der Datenzugriff

Lange nutzte die Google App Engine ausschließlich Big Table als primären Datenspeicher. Amazon zog schnell mit SimpleDB nach, führte damit weitere Funktionen ein und veröffentlichte mit RDS einen Database-as-a-Service. Zuletzt folgt dann DynamoDB. Das Fehlen eines guten Speichers für Transaktionsdaten schränkte die Entwickler bei der Nutzung der GAE stark ein. Jede Anwendung die professionell eingesetzt werden soll, benötigt zwangsläufig eine Kombination aus relationaler und NoSQL-Datenbank, um innerhalb der Cloud zu skalieren. Die GAE verfügte nicht über diese Funktionen, die für Daten-intensive Anwendungen erforderlich sind. Services wie BlobStore und Cloud SQL kamen demnach viel zu spät.

Vermarktung

Mit der Google App Engine hatte Google die ideale Position, Startups eine kostengünstige Plattform anzubieten. Sie wäre ideal gewesen, um typische Web-Anwendungen für den Markt der Endverbraucher zu entwickeln und bereitzustellen. Allerdings hat Google sich hier von Anfang nicht deutlich positioniert. Typische Low-End Web-Anwendungen, die prädestiniert für den Einsatz auf der App Engine gewesen wären, haben sich für Heroku entschieden, wohingegen High-End Anwendungen und Anwendungen mit hohen Workloads zu Amazon EC2 gegangen sind. Die Einführung der Amazon Micro Instanzen und die Free Tier Angebote haben der Google App Engine zudem weiterhin geschadet. Bis heute kann man nicht eindeutig sagen, welchen Platz die Google App Engine auf der mittlerweile großen Landkarte des PaaS einnimmt. Soll sie, aus Sicht von Google, genutzt werden, um Low-End Web-Anwendungen zu betreiben oder doch lieber für Unternehmensanwendungen?

Kosten

Natürlich mag es niemand, wenn ein vormals kostenloser Service nun bezahlt werden muss. Jedoch muss Google mit der App Engine auch irgendwann Geld verdienen. Allerdings hielten die Entwickler das neue Preismodell für äußerst unangemessen. Es gab einen riesen Aufruhr in der Community, als Google die neue Preisstruktur vorstellte. So stellten viele Kunden fest, dass ihre Kosten plötzlich um das drei- bis fünffache steigen würden. Das führte zu einem großen Bruch mit der Community, wodurch u.a. einige Startups von der Google App Engine zu Amazon EC2 bzw. zu einem klassischen Web Hoster gewechselt sind.

Sonstiges

Die GAE Entwickler Community hat den Eindruck, dass die App Engine im Vergleich zu Android innerhalb von Google schlechter angesehen wird. Das führt ebenfalls zu einer schlechten Stimmung.

Google und VMware kündigten damals auf der Google I/O im Jahr 2010 eine Partnerschaft an, um Spring auf die Google App Engine zu portieren. Trotz der Ankündigung kaufte VMware dennoch RabbitMQ und WaveMaker und brachte mit Cloud Foundry seine eigene PaaS Lösung auf den Markt. Während VMware CloudFoundry als Open PaaS positionierte, blieb die Google App Engine auf der Strecke.

Ein weiterer Rückschlag für Google war der Verlust des bekannten GAE Evangelist Patrick Chanezon, der als Head of Developer Relations zu VMware wechselte, um damit CloudFoundry zu stärken.

Categories
Analysen

Die Amazon Web Services und der Vendor Lock-in

Die Amazon Web Services (AWS) legen ein beachtliches Tempo vor. In regelmäßigen Abständen veröffentlicht das Unternehmen aus Seattle immer mehr Cloud Services, was Amazon innerhalb kürzester Zeit zum Cloud-Primus hat werden lassen. Der letzte Streich, der Amazon Simple Workflow liegt gerade knapp 2 Wochen zurück.

Auf dem ersten Blick ist die Leistung von Amazon wirklich sehr beachtlich. Zudem können die meisten Mitbewerber das vorgelegte Tempo kaum mithalten. Der zweite Blick trübt jedoch die Euphorie um die angebotenen Services. Denn viele Unternehmen nutzen AWS, um ihre ersten Schritte zu gehen und dabei auf eine flexible und öffentliche Cloud Infrastruktur zurückzugreifen. Aber je mehr Angebote wie bspw. Workflow Services oder speziell für die Cloud entwickelte Datenbanken veröffentlicht werden, desto größer wird ebenfalls das Bedenken einem Cloud Vendor Lock-in zum Opfer zu fallen.

Auf Grund der kostengünstigen und einfach zu nutzenden Infrastruktur für Rechenleistung und Speicherplatz, haben sich anfangs viele Kunden für den Einsatz von AWS entschieden. Diese Einfachheit ist weiterhin unumstritten und ermöglicht es insbesondere kleinen Unternehmen und Startups schnell auf die Ressourcen zurückzugreifen, die zu einem bestimmten Zeitpunkt benötigt werden, ohne große vorab Investitionen zu tätigen. Hinzu kommt das bequeme Mitwachsen der Infrastruktur, wenn unerwartet große Anfragen entstehen und die tatsächliche Abrechnung (pay as you go) der Ressourcen. Unternehmen können ihre Workloads also deutlich bequemer und flexibler in der Amazon Cloud verarbeiten lassen als im eigenen Rechenzentrum.

Jedoch führt die Einführung neuer Dienste wie Amazon DynamoDB und Simple Workflow Services (SWF) dazu, dass genau diese Workloads deutlich stärker an die AWS-Infrastruktur gebunden werden. So stellt es für Entwickler bspw. eine größere Herausforderung dar, ihre Daten von der DynamoDB zu einer nicht Amazon Datenbank zu migrieren. Im Falle von SWF, mit der Entwickler workflow-fähige Anwendungen erstellen können, wird die Lücke zwischen der on-Premise Infrastruktur und den Amazon Ressourcen immer kleiner und hebt die Grenze zwischen Kundenseite und AWS-Infrastruktur zunehmend auf.

Es scheint so, als wolle Amazon den Microsoft-Weg gehen, eben nur in der Cloud. Microsoft führte nach Betriebssystemen und Office Produkten immer weitere Funktionen ein und stimmte diese perfekt aufeinander ab. Hinzu kommen bereits vorhandene oder im Laufe der Zeit eingeführte Funktionen, die auch von anderen Herstellern angeboten wurden, aber eine untergeordnete Rolle spielten. So waren die Kunden nicht bereit für eine Funktion zu bezahlen, die in der Software bereits enthalten war, selbst wenn die vom Drittanbieter angebotene in den meisten Fällen deutlich besser war.

Eine weitere nicht zu unterschätzende Problematik ist die Abwanderung von Daten – nicht Diebstahl! Mit Amazon SWF können Anwendungs- und Serviceübergreifende Anwendungen entwickelt werden die einen flüssigen und integrierten Übergang zwischen Anwendungen auf der Kundenseite und der AWS Infrastruktur herstellen. Mit den Simple Workflow Services werden die Daten quasi aus dem eigenen Rechenzentrum in die Amazon Cloud übertragen und sind dort eng in die Workflow Prozesse und die Infrastruktur verankert.

Ähnlich verhält es sich bei der Nutzung von Amazon DynamoDB, aber auch Amazon SimpleDB. Kommt eine dieser Datenbank zum Einsatz ist ein Wechseln zu einem anderen Cloud Anbieter nicht möglich. So kann u.a. die Entwicklung einer Anwendung im Zusammenhang mit einer dieser Datenbanken nicht offline stattfinden, da Amazon DynamoDB bzw. Amazon SimpleDB nur in der Amazon Cloud laufen. Auch der AWS Storage Gateway ist aus der Lock-in Sicht eher kritisch zu betrachten, der er die Daten aus dem eigenen Rechenzentrum heraus auf Amazon S3 speichert.

Amazon ist aus gutem Grund der weltweit führende Cloud Computing Anbieter. Aber Erfolg und Macht führen in der Regel dazu, beides auch zu festigen und stetig auszubauen. Daher sollte sich jeder überlegen, in wie weit und vor allem wie integriert er welchen Service nutzen will und sich zudem nach Alternativen umschauen und eine Multi-Vendor Strategie fahren.

Denn unter diesen Gesichtspunkten stellt sich Frage, ob Zynga wirklich nur aus Performancegründen den Weg in die eigene Cloud gewählt hat.

Bildquelle: http://www.flyingomelette.com

Categories
Literatur

Buch – Programming Amazon Web Services: S3, EC2, SQS, FPS, and SimpleDB

Titel: Programming Amazon Web Services: S3, EC2, SQS, FPS, and SimpleDB

Autor: James Murty

Beschreibung:
“Building on the success of its storefront and fulfillment services, Amazon now allows businesses to “rent” computing power, data storage and bandwidth on its vast network platform. This book demonstrates how developers working with small- to mid-sized companies can take advantage of Amazon Web Services (AWS) such as the Simple Storage Service (S3), Elastic Compute Cloud (EC2), Simple Queue Service (SQS), Flexible Payments Service (FPS), and SimpleDB to build web-scale business applications. With AWS, Amazon offers a new paradigm for IT infrastructure: use what you need, as you need it, and pay as you go. Programming Web Services explains how you can access Amazon’s open APIs to store and run applications, rather than spend precious time and resources building your own. With this book, you’ll learn all the technical details you need to: Store and retrieve any amount of data using application servers, unlimited data storage, and bandwidth with the Amazon S3 service Buy computing time using Amazon EC2’s interface to requisition machines, load them with an application environment, manage access permissions, and run your image using as many or few systems as needed Use Amazon’s web-scale messaging infrastructure to store messages as they travel between computers with Amazon SQS Leverage the Amazon FPS service to structure payment instructions and allow the movement of money between any two entities, humans or computers Create and store multiple data sets, query your data easily, and return the results using Amazon SimpleDB. Scale up or down at a moment’s notice, using these services to employ as much time and space as you need Whether you’re starting a new online business, need to ramp upexisting services, or require an offsite backup for your home, Programming Web Services gives you the background and the practical knowledge you need to start using AWS. Other books explain how to build web services. This book teaches businesses how to take make use of existing services from an established technology leader. ”

Bestellmöglichkeit: Amazon

Cover: