Kategorien
News

Die Amazon Web Services erweitern Amazon RDS um weitere Funktionen für Oracle Datenbanken

Die Amazon Web Services haben vier neue Funktionen für Amazon RDS for Oracle präsentiert. Darunter die Möglichkeit, die Datenbank in einer Private Cloud zu betreiben. Dazu können Unternehmen nun RDS (Relational Database Service) Instanzen mit einer Oracle Datenbank innerhalb einer VPC (Virtual Private Cloud) nutzen. Administratoren erhalten, im Vergleich zu einer Standard Instanz oder einer virtuellen Maschine, damit mehr Kontrolle.

Die Amazon Web Services erweiterten Amazon RDS um weitere Funktionen für Oracle Datenbanken

Erweiterter Oracle Support

Weitere neue Funktionen sind die Unterstüzung für Oracle APEX (Application Express), XML DB und Time Zone. Mit Time Zone können Administratoren Informationen zu Timestamps persistent speichern, wenn Benutzer die Amazon Web Services über mehrere Zeitzonen hinweg verteilt einsetzen.

Bei APEX handelt es sich um eine freies Web-basiertes Entwicklungstool für Oracle Datenbanken. Mit dem Tool sollen ebenfalls Entwickler mit geringen Programmierkenntnissen Anwendungen entwickeln und ausrollen können. Das Entwicklungs-Framework für APEX bietet Wizards und Eigenschaftsfenster für die jeweiligen Objekte, mit denen Anwendungen geschrieben und gewartet werden sollen. Amazon RDS unterstützt die APEX Version 4.1.1.

XML DB ist eine Funktion von Oracle Datenbanken und bietet native XML Speicher- und Abfrage-Möglichkeiten.

Amazon RDS for Oracle

Mit Amazon RDS lassen sich Oracle Database 11g auf der Amazon Cloud bereitstellen. Der Service bietet Datenbank-Administrationsaufgaben wie das Provisioning, Backups, Software-Patches, Monitoring und Hardware-Skalierung.

Unternehmen können entweder ihre eigenen Datenbanken-Lizenzen nutzen oder lassen Amazon sich um die Lizenzierung kümmern. Die Preise betragen dann 0,11 Dollar pro Stunde bzw. 0,16 Dollar pro Stunde.

Erst kürzlich hatte Amazon eine Reihe von Verbesserungen für seinen Cloud-basierten Datenbank-Service Dynamo vorgestellt. Darunter die Aktualisierung der DynamoDB Management-Konsole.

Kategorien
News

Amazon möchte .NET Entwickler in die AWS Cloud entführen

Die Amazon Web Services hübschen sich weiter auf, um ihre Attraktivität für Microsoft .NET Entwickler zu steigern. Dazu hat das Unternehmen kürzlich zwei Neuigkeiten angekündigt, die sich auf exakt diese Zielgruppe konzentrieren. Bei der einen handelt es sich um Amazon RDS for SQL Server, einem Service für den Microsoft Datenbankserver. Die Zweite ermöglicht nun das Deployment von .NET Anwendungen auf der Amazon Elastic Beanstalk Plattform.

Entwickler haben zusätzlich zu ihrem Code in der Regel ebenfalls mit dem Deployment und der Administration ihrer Datenbanken zu tun, was zu einer nicht trivialen Aufgabe werden kann. Insbesondere dann, wenn Updates eingespielt oder Backups erstellt werden müssen. Die Amazon Web Services haben sich seit längerem diesem Thema angenommen und unterstützen mit Amazon RDS bereits Oracle und MySQL Datenbanken.

Jetzt erweitert Amazon sein Angebot für Windows Entwickler. Amazon RDS for Microsoft SQL Server ermöglicht es der Microsoft Entwickler Gemeinde seine Datenbankoperationen für Microsoft SQL Server 2008 R2 und SQL Server 2012 in die Amazon Cloud auszulagern. Dabei wird der Microsoft SQL Server 2008 R2 bereits jetzt schon, der SQL Server 2012 im Laufe des Jahres unterstützt.

Darüber hinaus können Entwickler von ASP.NET Anwendungen nun ebenfalls Amazons PaaS Elastic Beanstalk für das Deployment in der Amazon Cloud nutzen. Um die Applikation in die Cloud hochzuladen, stellt Amazon das AWS Toolkit for Visual Studio bereit. Elastic Beanstalk übernimmt anschließend automatisch die Kapazitätsplanung, sowie die Konfiguration des Load Balacing und das Monitoring für die Anwendung.

Der AWS Elastic Beanstalk Service befindet sich aktuell noch in der Beta Phase und nutzt die Microsoft Internet Information Services (IIS) 7.5 und das Windows Server 2008 R2 AMI (Amazon Machine Image), um die .NET Anwendungen auszuführen. Neben der Nutzung von mehreren Availability unterstützt Elastic Beanstalk mittlerweile auch die Amazon Virtual Private Cloud.

Neue Kunden können Elastic Beanstalk kostenlos nutzen. Dazu erhalten sie eine Amazon RDS Micro Instance incl. SQL Server Express Edition, die ein Freikontingent von 750 Stunden pro Monat beinhaltet. Zudem dürfen für ein Jahr lang 10 Millionen I/O Anfragen pro Montag gestellt werden und Amazon spendiert sogar noch 20GB Datenbankspeicher.

Kategorien
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.