Platform as a Service

Now some say this last part, the deployment and scaling of single web applications is what most PaaS providers consider their sweet spot – the single reason how they justify their own margin. Be it Heroku, Engine Yard, phpfog, Scalarium, us or almost any of the impressive list of newcomers have one thing in common. Most sit on top of Amazon Web Services. The single most important reason for that is, there really isn’t much alternatives out there. Yes it’s true, there are other IaaS providers around but most of them are still trying to figure out why an API is a must have feature. This comes as no surprise, because the hosting industry isn’t used to innovate in software. For years they simply used Parallels stuff and competed in pricing. Only this time Parallels missed the bus and is way late to the Cloud party. (On a side note, that “Understanding the Cloud” article is probably the worst piece of info I’ve come across in a very long time.)

Ok, so this wasn’t exactly on topic but it’s important to understand because it is the reason why Amazon’s move into PaaS might turn out to be a big problem for some but not all the other PaaS providers. Effectively Beanstalk is free. Yes you still have to pay for the underlying AWS services you use but there is no extra for Beanstalk itself. By contrast all other PaaS prizes include Amazon’s margin plus the PaaS margin. At this point it looks a little as if Amazon is going to squash the PaaS providers much like it did with the “Cloud Management Platforms” when they launched the AWS console. Anyone remember Rightscale? Sure they support more than just EC2 but as we learned earlier none of those other IaaS providers ever really mattered in the first place.

Gameover Heroku?

Surely not. I wrote earlier that Beanstalk might be a problem for some but not all PaaS companies around. Heroku isn’t one of them, and not because they’ve been acquired by Salesforce, but because they are multi tenant. Beanstalk is not, in fact it allows you full access to all underlying AWS services including logging in to EC2 instances. That makes multi tenancy quite hard. At least for now, of course that may be subject to change in the future. Sure differentiation by additional services like an add-on marketplace as suggested here does help a little. But on its own it’s probably not enough. PaaS providers better have another competitive advantage. For add-on providers it’s always better to partner with multiple PaaS providers. No matter if those providers support the same or different languages. Because a variety of add-ons is highly latency sensitive it is best to have those add-ons in the same datacenter as the app servers. This basically means in the same AWS region. That’s why everyone needs Amazon and also Amazon needs to be careful not to ruin that evolving ecosystem because their first and foremost interest must be to have the highest possible occupation of virtual machines possible at all times. They need a wide variety of consumers on top of EC2 for that.

Multi Tenancy

Multi tenancy seems to be the way to go then. Because it allows to scale in much finer grained portions and it also allows providers to offer marketing wise very efficient free tiers. Amazon really has no interest in offering multi-tenant itself, because multi-tenancy means less virtual machines are necessary to host the same amount of applications. Good for Heroku and us, one might think. Not so good for the single-tenant ones. Now I know it’s not black and white and Rightscale also is still around and probably doing just fine. Smaller PaaS providers might differentiate by being close to the customer. But close also often means small, which might be a nice place to be but probably isn’t if you’re venture backed. Good thing is from the way Beanstalk is designed right now it doesn’t seem like Amazon is going for multi tenancy anytime soon and as I said they might not want to in the first place, so there still is time. Bad thing though, multi tenancy is the hard part. So better start now.

Not everything is a web app

True, not everything is, but will be. With all the different devices (Smartphones, Tablets, Desktops, Notebooks, Netbooks, etc.) the web is the least common denominator. It’s definitely going to be exciting to see this evolve in the future.

Automatically Scaling Out in PaaS

Die Überlegungen dahinter sind so simpel wie logisch. Mit einer App Lösung muss man verschiedene Plattformen unterstützen. D.h. mehrfacher Aufwand bei Weiterentwicklung und Wartung der Applikationen. Dazu darf man sich dann je nachdem noch mit den teilweise willkürlichen Zulassungsbeschränkungen der jeweiligen Marktplätze rumschlagen. Und alles für ein Angebot, dass bestenfalls eine Übergangslösung sein kann.

Über kurz oder lang, da bin ich mir sicher, werden die nativen Applikationen für die verschiedenen mobilen Plattformen vollständig durch HTML5/CSS3 und Javascript basierte Applikationen abgelöst werden. Mag sein, dass die Marktplätze als Distributions- und Vertriebskanal überleben und man sich dann gegen Geld kleine Icons auf den Homescreen oder ins Hauptmenü kaufen kann, aber mit den vielen Neuerungen gerade in HTML5 kann man Webapplikationen entwickeln die sich auf einer Vielzahl an Geräten gleich anfühlen und man keinen Unterschied zu einer nativen Applikation mehr feststellen kann.

Natürlich ist HTML5 eine neue Technik und die Unterstützung ist noch nicht auf allen Geräten optimal, aber zumindest iPhone und Android mit der Webkit Engine sollten da bestens vorbereitet sein. Bei Blackberry scheint es sich auch in diese Richtung zu entwickeln und bei Nokia setzt man ja schon länger ebenfalls auf Webkit. Alles in allem also absolut die richtige Entscheidung, weil die ganzen SaaS-Vorteile ebenfalls für mobile Geräte gelten. Wenn wir uns also auf dem Desktop weg von lokal installierte Software bewegen, weil wir erkannt haben, dass es eine bessere Lösung gibt. Warum machen wir dann auf mobilen Geräten den selben schwachsinnigen Zwischenschritt?

Doch seit jeher sind Cookies die einzige Möglichkeit Informationen im Browser abzuspeichern. Aber da die Daten in der Cloud von Zeit zu Zeit nicht, oder nur eingeschränkt, erreichbar sind erscheint es durchaus sinnvoll hin und wieder einige Informationen lokal vorzuhalten.

Mit HTML5 wird zu den auf 4K begrenzten Cookies endlich eine zeitgemäßere Möglichkeit eingeführt die bereits jetzt von allen großen Browsern unterstützt wird. Ja richtig, ich musste es auch zweimal lesen bevor ich es geglaubt habe.

Wie man das ganze nutzen kann und wie man sogar im Notfall (vollautomatisch) auf ältere Techniken zurückfallen kann erklärt Jens in seinem Blog.

Don’t use Cookies!

Von der Wirklichkeit eines besseren belehrt, hat ja auch eine ganze Weile gedauert, öffnet man jetzt die Azure Plattform auch für andere Sprachen. Eine davon ist Ruby. Simon Davies beschreibt in seinem Blog wie dies möglich ist.

Im Grunde genommen basiert das ganze auf der allgemeinen Möglichkeit die Worker über http, https oder tcp anzusprechen. Das ganze sowohl von intern als auch von extern. So sollen auch bereits andere Technologien wie MySQL, Mediawiki, Tomcat und Memcached möglich sein.

Alles was man über Azure wissen muss habe ich bereits vor einiger Zeit einmal zusammengefasst.

via heise.de

via DataCenterKnowledge

Hier noch mehr Buzzwords im Überblick:

• Dokumentenbasiert
• Skalierbar, dezentralisiert
• Standart get, put, and delete Methoden
• Verteilte, fehlertolerante Speicherlösung
• Konsistenz, Verfügbarkeit und Partitionstolerenz konfigurierbar
• Unterstützt Erlang, Ruby, PHP, Javascript, Java, Python, HTTP
• open source und NoSQL
• Modulare backends
• Event system
• Überwachung
• Clusterübergreifende Replikation
• “verschiebbare” Links zwischen Daten
• Map/Reduce Funktionen die auf den Datanodes ausgeführt werden

via HighAvailability

Weil es aber schlichtweg nur lästig ist, immer und immer wieder Apache, MySQL und Konsorten einrichten zu müssen nur um ein Drupal CMS zu hosten hat sich das Projekt Pantheon Projekt geformt. Dass verschiedene Softwarepakete miteinander kombiniert um daraus Amazon EC2 Images zu formen, die perfekt darauf vorbereitet sind Drupal zu hosten.

Viel besser als ich kann das allerdings der Drupal Voices Podcast erklären.

Was natürlich niemanden davon abhält Untersuchungen an- und Vermutung aufzustellen.

Amazon EC2 erlaubt es Kunden stundenweise virtuelle Instanzen zu mieten. Soweit so kurz zur Einführung. Diese Instanzen bekommen einzigartige IDs zugewiesen. Guy Rosen ist bei den IDs die er zugewiesen bekommen hat ein Schema aufgefallen. Neugierig hat er daraufhin ein paar Versuche gestartet und kam dabei zu dem Ergebnis, dass Amazon in einer Verfügbarkeitszone an einem Tag im September 2009 50.000 neue Instanzen gespawnt hat.

Insgesamt müsste Amazon seit dem EC2 Start 8.4 Millionen Instanzen gestartet haben.

Beeindruckende Zahlen. Alle Details, wie Guy auf die Zahlen gekommen ist finden sich in seinem Blog:

Anatomy of an Amazon EC2 Resource ID