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.

Ohne weitere schamlose Selbstbeweihräucherung überlasse ich jetzt Jan das Wort:

Jan ‘luckyduck’ Brinkmann …Linux, PHP, luckyduck

Automatically Scaling Out in PaaS

• deutsche-startups.de
• gründerszene.de
• netzwertig.com
• secondflush.de
• t3n.de

Natürlich bedanken wir uns auch für die vielen Twitternachrichten und Retweets. Verständlicherweise kann ich die nicht alle einzeln aufzählen.

Startup Lessons Learned

Eric Ries begann seine Begrüssung frei übersetzt mit der Erkenntnis, dass es keine bessere Zeit für Gründer gibt als unsere. Ries weiss, Software und das Internet haben eine unglaubliche  Macht bestehende Industrien und Geschäftsmodelle zu revolutionieren.

Weiter im cloudControl Blog >>

Meinen Kommentar dazu will das Blog allerdings nicht annehmen. Bekomme immer die Meldung ich müsse das Kommentarfeld ausfüllen… achso.

Mein Kommentar zu Pay as you use ist tot! deshalb hier:

Wenn man es ganz genau nimmt hast Du natürlich Recht.

Ich finde aber durchaus, dass im SaaS Bereich pro User und Monat zu zahlen ein verbrauchsabhängiges Abrechnungsmodell ist. Denn auch wenn der User gerade nicht eingeloggt ist, muss der Anbieter ja seine Dienstleistung oder Teile davon weiter erbringen. E-Mails entgegen nehmen, und überhaupt alle bisherigen Daten weiter abspeichern, sichern etc.

Das Google bei Google Apps pro User und Jahr abrechnet finde ich allerdings auch etwas lang. So verliere ich eben die Möglichkeit für die E-Mailkonten auch wirklich nur so lange zu zahlen wie der Mitarbeiter im Unternehmen ist. Stichwort: Praktikanten.

Deshalb “pay as you use”, so lange man eben die Dienstleitung in Anspruch nimmt. Gerne pro User und Monat.

Über die Zeiteinheit kann man sich dann auch im PaaS oder IaaS Bereich nochmal unterhalten. Aber häufig wird durch Abrechnung kürzerer Zeiteinheiten der Aufwand für den Anbieter steigen. Wenn dies wiederrum die Preise in die Höhe treibt, fährt man als Nutzer vielleicht mit Parkuhreffekt besser.

Deshalb frei nach bekanntem Schema: “Pay as you use” ist tot, es lebe “pay as you use”.

Für weitere Informationen auch zu den Preisen verweise ich auf meinen älteren Artikel “Alles was man über Azure wissen muss“.

Meine persönlich kurzeinschätzung zur Arbeit mit der Azure Plattform findet sich hier.

via @glemnitz

Man schien etwas verwundert über die Anmeldung vom Jura Studenten, war aber so nett mich mitmachen zu lassen. Los ging es erstmal mit einer Einführung in Visual Studio und C#. Visual Studio, dass muss ich gestehen ist wirklich sehr schön integriert. Für die Entwicklung mit Microsoft Lösungen sicher eine gute Wahl. C# schien mir in den paar Stunden die ich heute damit gearbeitet habe auch relativ brauchbar zu sein. Die Syntax ist ähnlich der von Java, was mir persönlich nicht gefällt, aber das ist nunmal Geschmackssache. Der kurze Einblick den ich hatte erlaubt natürlich kein endgültiges Urteil. Es kann also gut sein, dass ich hier völlig daneben liege und C# und Visual Studio hassen würde, müsste ich länger damit arbeiten. Sei es drum, ich werde es wahrscheinlich nie erfahren, weil ich wohl niemals länger damit arbeiten werde.

Jetzt aber zu Azure. Die Microsoft Cloud Computing Plattform war ja der Hauptgrund warum ich am Workshop teilgenommen habe. Was mir bereits während der Einführung des Referenten übel aufgestossen ist: Microsoft lebt immernoch in seiner eigenen Welt. Von Authentifizierung bis Datenbank überall kocht man irgendwie sein eigenes Süppchen. Aber nun gut, dafür ist das ganze im Zweifel aber auch schön in die IDE integriert und man muss sich nicht lange informieren, was man denn jetzt am besten verwendet. Mit allen Vor- und Nachteilen die das so mit sich bringt.

Innerhalb von Visual Studio kann man dann auch direkt ein Projekt anlegen, was alle Vorraussetzungen für einen Betrieb in der Azure Cloud direkt mitbringt. Verzeichnisstrukturen, Konfigurationsdateien etc. Um alles kümmert sich Visual Studio.

Mittels Rechtsklick auf das Projekt und Publish soll man das Ganze dann auch in die Cloud schieben können. Aber weit gefehlt. Anstelle einer Authentifizerungsabfrage oder ähnlichem wirft Visual Studio zwei Dateien in ein Verzeichnis auf der lokalen Festplatte, startet den Internet Explorer (war der Standardbrowser in der bereitgestellten Windows 7 VM) und öffnet zusätzlich das Verzeichnis mit den Dateien im Windows Explorer. Dann muss man sich über verschiedene Webseiten klicken und über ein HTML Formular per Durchsuchen die zwei Dateien auswählen und hochladen. Die eine Datei beinhaltet dabei das Projekt und die zweite scheint eine Konfigurationsdatei zu sein.

Über diesen Umstand war ich doch sehr erstaunt. Ob das jetzt der einzige Weg ist, ob es vielleicht daran lag, dass in den VMs “nur” Visual Studio Web Developer Edition lief oder ob der Referent uns den “falschen” Weg gezeigt hat weiss ich nicht. Aber wenn es wirklich der einzige Weg ist ein Projekt aus der hauseigenen IDE in die hauseigene Cloud zu laden, ist das bestenfalls lächerlich.

Weiter gab es keine Versionsverwaltung. Es gab die Möglichkeit zwei verschiedene Versionen über das Webinterface hochzuladen und als “Production” und “Staging” zu deployen. Aber um eine neue Version zu deployen musste man erneut die Dateien über das Webinterface hochladen und dann über das Webinterface deployen.

Sowohl das Webinterface als auch Azure selber haben sich dabei nicht gerade von der performantesten Seite gezeigt. Das deployen eines Projekts oder neuer Versionen hat für meine Verhältnisse ziemlich lange gedauert. Es kam immer die Meldung, es würde für 90% der Projekte nur 79 Sekunden dauern. Aber gefühlt war das ziemlich langsam, bzw. viel langsamer. An meinem Projekt kann es eigentlich nicht gelegen haben. Das übliche “Hello World!” war jetzt nicht gerade ein Quelltextmonster.

Alles in allem bietet Azure was man grundsätzlich erwarten darf. Eine Cloud speziell für die verschiedenen Microsoft Technologien. Alles hat für mich als Open Source Jünger eigenartige Namen und hinterlässt das Gefühl bei Microsoft würde man bestraft wenn man für ein Produkt bestehende Technologien nutzt anstelle das Rad jedesmal neu zu erfinden. Das ist aber jetzt als subjektive Kritik meinerseits zu verstehen. Man mag diese Ansicht teilen oder nicht.

Technisch war mein Einblick durch die kürze des Workshops und die relativ lange Zeit die auf die Einführung in Visual Studio, .NET und C# eingeplant war, relativ dürftig. Dementsprechend werde ich auch kein endgültiges Urteil fällen. Der Referent hat allerdings von sich aus eingeräumt, dass bei Azure noch nicht alles Rund läuft. Insbesondere hatte er sich wohl lange mit dem “Service Bus” beschäftigt und sein Urteil war da, es sei schade, dass nur 9 von 10 Nachrichten ankommen. Alles in allem war er aber zuversichtlich man würde das noch in den Griff bekommen. Ausserdem hat er für die Zukunft bessere Integration in Visual Studio angekündigt. Dies sei wohl bei Microsoft immer so, dass die Integration mit kommenden Visual Studio Versionen immer besser werde. Kann ich jetzt nicht beurteilen, gebe ich einfach mal so weiter.

Vielleicht “repariert” Microsoft ja dann auch den Deploymentprozess…

Wie seht ihr das ganze, liege ich mit meinem ersten Eindruck völlig daneben? Was sind eure Erfahrungen mit Microsoft Azure.

Dies lag hauptsächlich daran, dass ich mit den Vorbereitungen für den Alpha Start alle Hände voll zu tun hatte. Insbesondere hat das Schreiben der Dokumentation und des Tutorials alle meine Wörter “verbraucht”.

Jetzt ist das ganze online und wir freuen uns natürlich über jeden Tester. Auf Grund der begrenzten Kapazitäten können wir nicht wild jeden sofort freischalten. Mutige können sich aber mittels des Kommandozeilen Clients einen Account verschaffen, und werden auch zeitig freigeschaltet.

Achtung, der Alphatest ist genau wie der Name sagt ein Test mit Software im Alphastadium. Wir gehen davon aus, dass die Software Fehler hat und es sind auch einige Funktionen noch nicht verfügbar. So ist momentan ausschliesslich PHP als Programmiersprache freigeschaltet. Java, Python und Ruby werden aber in kürze folgen.

Kleiner Hinweis noch, die Beta Vorregistrierung auf der Seite hat mit dem Alphatest nichts zu tun, die Betatester werden wir erst behelligen, wenn die ersten Wogen geglättet sind.

In diesem Sinne, wir freuen uns über jedes Feedback und legen den mutigen das Tutorial ans Herz. Jetzt aber genug Eigenwerbung.