CS Tech

The future of the PHP PaaS is here: Our journey to Platform.sh

In our team we’re very confident in our ability to produce high quality software. For the past decade or so we have constantly improved our skills, our tool stack, our working methods and consequently our products. We can’t say the same about our sysadmin skills. By a long shot. 

Sysadmins - because even developers need heroes

For many software developers, sysadmin is a mystery at best, a nightmare more often than not. When you frequently find yourself solving server problems by copy-pasting a series of commands you don’t fully understand, you know you’re not up to the task. This type of server maintenance is definitely not what anyone’s customer deserves, but neither do companies of our size have the resources to hire good system administrators. 

The DevOps illusion

Fully managed server solutions aren’t cheap either and don’t provide a lot of flexibility. For a long time we have solved the hosting problem by operating a small number of flexibly scalable VPS instances by ServerGrove who provide unique support so that we could always fall back on their knowledge when needed.

But we arrived at a point where we wanted to be able to spin up individual server instances for each project and each environment and in order for this to be replicable and robust it needed to be automatic. We wanted to be sure that our servers had exactly the dependencies we needed and that we could spin up as many instances as we needed whenever we needed them.

At the same time virtual machines and server provisioning systems started to gain popularity among developers. Everyone and their cat started talking about technologies like Vagrant, Puppet, Ansible, or Docker. There was the promise of a better world where devs would be able to have repeatable server instances and whole infrastructures up in no time and without problems. That, of course, turned out to be an illusion. Server provisioning and containerization are incredibly powerful technologies contributing hugely to the quality of web services and software, but they’re not a replacement for a sysadmin. Quite the contrary actually, in order to build quality containers with a stable and robust provisioning infrastructure, you need, you guessed it, a good system administrator. 

PaaS to the rescue?

So, with the sobering realization that Docker and Ansible weren’t going to solve our problem, our attention was drawn to another relatively new phenomenon, the PaaS. Platforms which promise to do a lot of the sysadmin for you by providing preconfigured managed container systems for deploying applications. This was exactly what we and many others needed. So we started looking into these services, specifically those targeting the modern PHP ecosystem like PhpFog, Pagoda Box, Fortrabbit, etc.

We tested, observed and evaluated. A lot of times we thought we’d found a satisfying solution with one of the providers. Always something ruined the fun. Instability, lack of flexibility, no writable folders, still in beta, too expensive, you name it. We found a quantum of solace in the fact that others, including prominent members of the PHP community like Phil Sturgeon, felt the same pain. We concluded that it was too early for the PaaS and went into observation mode. Then Platform.sh came along.

PaaS 2.0

Checking them out was more or less routine along the lines of „Oh, yet another new PHP PaaS product, let’s go see how THEY screwed up.“. The promises on the website looked similar to what other providers say, but somewhat more assertive. Who doesn’t like to hear this?

High-availability PHP cloud hosting platform that is fast and simple to use. Stop reinventing DevOps and wasting time on tedious admin chores.

At first I was taken aback by the strong Symfony/Drupal orientation, but reading some of the documentation it all just sounded too good to give up on it already. It seemed like many of the problems of the competition had been solved. I started to get the feeling that Platform.sh might be just what we had been looking for and decided to give it a serious try. The result: Minds blown. We realized that Platform.sh had taken the PHP PaaS idea to a whole new level, hopefully spearheading a new generation of PaaS.

A few months later we’re using Platform.sh for all our new projects and are migrating older projects over there too. Phil Sturgeon is right, once you’ve tried a hover-car, you just don’t want to drive a normal car anymore.

What we love about our new deployment and hosting solution

So let me introduce a few of the things we’re most thrilled about when working with Platform.sh.

Literally 0 sysadmin

We’re completely freed of any kind of sysadmin work but we still have all the control we need over our servers. As with most of the PaaS solutions, everything is configured in a file that belongs to your project. With Platform.sh this file is called .platform.app.yaml. Here’s an example:

name: „example app“
type: php:7.0
    flavor: composer
timezone: Europe/Zurich
    database: "mysql:mysql"
    redis: "rediscache:redis"
disk: 2048
    "/temp": "shared:files/temp"
    "/sessions": "shared:files/sessions"
      sass: "3.4.17"
      gulp: "3.9.0"
      bower: "1.7.1"
        - redis
    build: |
        set -e
        vendor/bin/phing deploy-db-migrations
        npm install
        bower update
    deploy: |
        set -e
        vendor/bin/phinx migrate --configuration phinx-platform.php
      spec: "0 2 * * *"
      cmd: "cd /app/httpdocs ; php index.php cron offsite-backup"
  document_root: "/httpdocs"
  passthru: "/index.php"
      # CSS and Javascript.
      - \.css$
      - \.js$

      # image/* types.
      - \.gif$
      - \.jpe?g$
      - \.png$

The guys at Platform.sh take care of running high quality containers for all recent versions of PHP as well as HHVM. We just indicate what php extensions, ruby gems or npm packages we need and that's it. As you can see we can also do a lot of other stuff like mounting writable folders, running scripts during build or deployment, setting up cron jobs, or whitelisting files for public access. No need to think about sysadmin at any point.

Plus of course: All of this is under version control, so you'll know the exact server state at every revision of your software, how cool is that.

Push to deploy with 0 downtime deployment

On Platform.sh the master branch of your git repository is the live site. Whenever you have an update to your application run git push platform master and the platform will attempt to build and deploy your project. If anything goes wrong during the build, the app will not be deployed. During deployment all requests to your app will be buffered. This means 0 downtime deployments in any case. If the app can be successfully deployed, the buffered requests will be resumed against the updated app, if not, they will be resumed against the status quo.

Git branch = fully independent app instance

This is one of the most awesome features. You can push any branch of your app to platform and you'll instantly get a completely independent instance of your whole app with all it's containers (PHP, DB, Redis, ...).

Imagine you have an older PHP 5.5 app and you want to run it on PHP 7.0 to see what happens. With Platform.sh this is mindblowingly easy. All you need to do is:

  • make a dev branch of your repository, e.g. php-7-dev.
  • change type: php:5.5 to type: php:7.0 in your .platform.app.yaml.
  • commit and push the branch to platform.

Here you go, you'll have an instance of your app with an web URL and read only shell access running on PHP 7.0.

What's more, you can branch and merge directly in the Platform.sh GUI if you wish to.

No add-ons needed

If you know your way around Heroku you're familiar with add-ons. Heroku's approach is distributed, using a marketplace of services, while Platform.sh foresees combining all required elements within a single testable and consistent environment. This means Platform.sh provides a growing number of services like MySQL, PostgreSQL, Redis, MongoDB, Elastic search, and more out of the box, ready and optimally integrated, running in separate containers. *Batteries included*, as the guys at Platform.sh like to call it.

Obviously, when you create a new branch (= instance of your app) all service containers you're using will be cloned as well.

What about Heroku?

Heroku is one of the pioneers if not the mother of mainstream PaaS and they surely know what they're doing. They only added dedicated support for PHP in 2014 but were still the only serious alternative to Platform.sh for us. We're convinced we could have arrived at a satisfying solution using Heroku as well. For us, Platform.sh wins. It provides storage and data management by means of its "batteries included" approach, on a level that Heroku can't. While technical skills are required to set up Platform.sh we think their approach is simpler, as well as being more consistent and robust.


Additionally to all the described advantages of using a good PaaS like Platform.sh, this migration has forced us to significantly advance and fully automatize our build and deployment. We're thrilled with the monumental improvement of our deployment and hosting quality, the productivity boost as well as the peace of mind this new approach is giving us.

Veröffentlicht von am in CS Tech
Die PHP Revolution

PHP ist ursprünglich als Script-Sprache entstanden und wurde nicht als Programmier-Sprache entworfen. In der Folgezeit hatte sich PHP dann in die Richtung einer Programmiersprache weiterentwickelt, aber hatte in diesem Bereich lange Zeit einen schlechten Ruf, welcher teilweise immer noch anhält, z. T. auch begründet.

Dabei hat sich PHP in den letzten Jahren schrittweise revolutioniert und verbessert, so dass sich die Situation mittlerweile ganz anders darstellt. PHP hat seine Anfänge als ''lingua franca” für Script-Kiddies längst hinter sich gelassen und findet sich als ernstzunehmende Programmiersprache verstärkt wieder, so beispielsweise auch im Enterprise Bereich.

Oftmals als Teil des LAMP-Stacks (Linux, Apache, MySQL, PHP) spielt PHP eine dominierende Rolle im Internet. Ca. 80% aller Webseiten basieren auf PHP und grundsätzlich ist PHP die am meist benutzte Programmiersprache für Web-Seiten und Web-Applikationen.


Entwicklungsschritte der Sprache PHP

Einen wichtigen Meilenstein in dieser Entwicklung stellte 2004 die Einführung eines neuen Object-Models dar, welches mit der PHP Version 5.0 Einzug gehalten hat und einen grossen Schritt hinsichtlich OOP (Object Oriented Programming) bedeutete. Ausserdem wurde PHP signifikant modernisiert z.B. durch die Einführung von Namespaces, Anonymous functions und Closures (PHP 5.3) sowie Traits, einem integrierten Webserver (PHP 5.4) und Generators (PHP 5.5). Darüber hinaus hat sich die Performance von PHP beträchtlich verbessert und für die nächste Version PHP 7 ist nochmal mit einem deutlichen Geschwindigkeitsschub zu rechnen. Zudem wird PHP 7 lange vermisste Konzepte wie Scalar Type Hints und Return Types einführen.


Git und Composer

Git ist das am weit verbreitetste Source-Code Management Tool, welches von einer Vielzahl von PHP Projekten sowie auch von PHP selbst verwendet wird. Dazu haben sich mit GitHub und ähnlichen Diensten einfache und beliebte Plattformen etabliert, dank denen Teams gemeinsam an Software arbeiten können.

Composer ist der lange überfällige Packet-Manager für PHP und ist für PHP, was Gem für Ruby oder npm für Node sind. Das funktionale Zusammenspiel von Git und Composer bildet eine sehr praktische, flexible und mächtige Grundlage für eine fortschrittliche Software-Entwicklung mit PHP. Dieses Zusammenspiel ist auch einer der wichtigsten Gründe, für die drastisch steigende Qualität vieler PHP Frameworks und Libraries in letzter Zeit und führt zum neuen aufblühen des PHP Ecosystems.


PHP Ecosystem und Community

Einzelne PHP Frameworks, Libraries oder Applikationen sind heutzutage näher zusammengerückt, während es früher eher isolierte Inseln waren. Diese verschiedenen Projekte profitieren nun oftmals voneinander, ergänzen sich und es findet eine enorme Verbesserung der Software-Qualität und Anpassung an Software-Standards (wie PSR der PHP Framework Interop Group) statt.

So können neue Projekte entstehen, die auf ein bestehendes Framework aufbauen und zusätzlich benötigte Libraries, welche sich bereits bewährt haben, können automatisch mit Hilfe von Composer eingebunden werden. Dadurch werden auch die einzelnen Projekte gestärkt, welche eine grössere Verbreitung finden, was nicht zuletzt der PHP Community im Allgemeinen als auch den Communities der einzelnen Projekte einen Aufschwung gibt. Diese sind sich wiederum gegenseitig von Nutzen. Insgesamt gibt es eine grosse und dynamische Community, welche etwa die League of Extraordinary Packages hervorgebracht hat, die sich dem Sammeln von guten und modernen PHP Libraries verschrieben hat.

Im PHP Umfeld finden sich auch eine Menge von prominenten Projekten wieder. So basieren beispielsweise die drei am häufigsten eingesetzten CMS (Content Management Systeme), WordPress, Joomla und Drupal alle auf PHP. Des Weiteren gibt es eine grosse Auswahl an Frameworks wie Zend Framework, Symfony oder Laravel, welche dazu beigetragen haben, dass PHP vermehrt im Enterprise Bereich eingesetzt wird. Einige bekannte Firmen wie Facebook, Google und Yahoo setzen PHP erfolgreich ein.


PHP hat die letzten Jahre eine revolutionäre Entwicklung durchgemacht und das gesamte Umfeld hat sich verändert. Die angebrochene neue Ära bietet weiterhin grosses Potential für PHP und dessen fortwährende Verbesserungen. Mit PHP kann qualitativ hochwertige Software erstellt werden und viele Probleme der Webentwicklung können auf elegante Weise gelöst werden.

From Excel to Javascript - Implementing Spreadsheets in the Browser

Why we moved our spreadsheet to the web

At CS we use spreadsheets to break down paper questionnaires into logical tabular entities, such as intro texts, items, skip conditions, pages and many more. The resulting relational data can then be imported into a relational database and used in SurveyLab projects. SurveyLab is our RAD framework for building complex online survey systems. For a number of years we used Excel to accomplish this task, however for reasons that will be detailed below, we found this not to be the optimal choice.


If you have ever had the need to collaborate on an Excel file, you know how problematic this can become. There is virtually no way of concurrently editing an Excel file, meaning time lost, as the various collaborators add their changes in series. At times you end up with several versions of the same file, only to realize that integrating these is near impossible or at least very error-prone. But wait - isn’t that why we have version control systems? Supposedly yes, however Excel uses binary file formats and therefore to diff and merge conflicting changes becomes infinitely more difficult.

Data portability and availability

If you want to move your spreadsheet data to a database or need to serve other applications with it, you must export it into appropriate formats and have these apps import the data again. If you still want to be able to change this data easily via spreadsheet editor, you have to repeat this process every time changes are made. Clearly, there are better, more centralized ways of handling this.

Limited functionality

Excel obviously has many built-in functions. Yet, what to do when you need to implement your very own specialised validator? How about if you have to check for occurrences of foreign keys on another sheet? You can attempt this in Excel, but as you’ll find, it’s messy and hard to maintain.

Getting rid of technical debt

Realizing the technical debt we were accumulating with our Excel solution, we started looking into a way of dealing with the above problems. This initiative was also given wings by the fact that we started working on an advanced GUI for editing surveys. Since this advanced GUI will employ the exact same data that is manipulated via spreadsheet, we needed an accessible, extensible and portable format. Such problems can easily be solved by using a standardized data format like JSON and be automatized via an API. We therefore, decided on building our own browser-based spreadsheet editor. As we did not want to succumb to the “not invented here” syndrome, we had a look at available open source and commercial spreadsheet solutions based on Javascript.

spreadJS by Wijmo

The Excel-like demo by Wijmo seemed very promising, so we committed some time to evaluating it. It has almost all the functions of Excel and provides an API for customization. However, in addition to being too expensive, there were other problems we discovered.


  • It can basically replicate full Excel functionality 
  • It is in ongoing development
  • Good support and fast forum responses by the community and Wijmo


  • Expensive ( ~800€ )
  • Requires Excel I/O service or client side software for some functionality like creating a basetemplate from an Excel file
  • Doubtful code quality, e.g. CSS styles inside the HTML and Javascript code, which makes customizing difficult. Large overhead and storage needs because of the way meta information is handled. Our base template with few default data converted to a spreadJS JSON file had about 4-5 million characters. Our plan was to use localStorage for storing data while editing, which is limited to only a few MB (depending on the browser) and would not be sufficient to store several projects.

Google Docs Spreadsheets

We also looked into using Google Spreadsheets, but that would have meant building a spreadsheet editor from scratch, due to the fact that we cannot implement our own functionality. So we could “just” have used the Google Spreadsheet API to store and read data, however, we wanted to host the editor ourselves, as our projects tend to contain sensitive data. Moreover, we like to stay independent.

jQuery plugins

We looked at some of the many smaller jQuery spreadsheet plugins that are out there, like flexigrid, jQuery.sheet and some others. Yet, most of them didn’t fulfil our prerequisites, which included not being in active development or having bad documentation, or being too limited in scope. 

Our choice: handsontable

We decided to go with handsontable (hot), as it is cleanly and elegantly written, readily extensible, well-documented and updates are frequently released. The one troublesome thing is the large number of open issues on github, which may indicate a lack of contributors. So far we have been able to build clean workarounds for every problem we have encountered.

Reasons why we chose handsontable:

  • Easily extensible
  • Two way data binding: If the text inside a cell is changed, the data-object gets updated right away. It works the other way too - if new data is pushed to the editor the change is reflected in the UI after a re-render.
  • Good documentation and active development 
  • Good API: hot supports a ton of functions you can call, and in addition defines a lot of hooks (events) which makes customizing the editor much easier. E.g. it has events, which are fired before and after data is changed inside a cell and also for failed validations.
  • It is fast: except for the scrolling performance, which can be slow at times, editing, validation, importing and exporting work rapidly.

  • Small overhead for project files: the JSON data hot exports is pretty straightforward, with one array per table, which contains the rows represented by objects. This made it very easy to adjust our Surveylab importer to allow us to read those files.
  • Custom cell types: hot comes with a lot of predefined cell types, such as dropdowns, numeric, text only etc.
  • Cell validators: hot allows us to write custom cell validators. That was an important factor in the decision to use this program, as we needed to implement a foreign key check that would look for the existence of a key in other table instances.
  • Context menu: hot has an build in context menu on right mouse click, which can be extended and customized with your own functionality

So far we are fairly happy with the decision to move to an online spreadsheet editor. By far and away, the biggest improvement is in the ability to use git for our project templates, as we have now switched from Excel files to JSON and can merge changes without problems. Working with the editor is also more user-friendly, because we can highlight tables with failed validations or use hyperlinks to navigate directly from a foreign key to the corresponding table. In addition, the editor is future proof, because it is written in Javascript. If we need a new function or require a part of the UI to behave differently, we can now just build it.

Below you see an image of the current version of the editor. Red buttons indicate sheets with failed validations.





Formen der Anwendungsentwicklung: Was sind native, hybride und web Apps?

Manches Software Start-Up oder Projektteam hat sich bereits in einer Situation wie der folgenden wieder gefunden: Man hat eine tolle Idee für eine Anwendung, die Investoren sind überzeugt, das Team ready und die Büroräume eingerichtet. Eigentlich könnte man sofort mit der Umsetzung beginnen. Doch bevor die ersten Zeilen Code geschrieben werden können, muss man sich für eine Umsetzungsform entscheiden. Keine einfache Wahl. Soll die Anwendung als responsive Web-Applikation umgesetzt werden, wie das immer häufiger getan wird oder sind die besonderen Funktionen von mobilen Geräten zentral für das vorliegende Problem?

Dieser Artikel gibt eine kurz Einführung in die drei Hauptvarianten der App-Entwicklung.

1. Webanwendung

Die Anwendung wird wie eine Internetseite zentral auf einem Server gehostet, auf die von allen Usern zugegriffen wird. Hierbei dient der Browser als Anwendungsumgebung und als Schnittstelle zum Betriebssystem. Der Entwickler kann deswegen davon ausgehen, dass die Webseite auf verschiedenen Betriebssystemen funktioniert, ohne dass spezielle Anpassungen nötig sind. Beispiele für Webanwendungen sind Google DocsToggl oder Facebook.


  • Webanwendungen sind Plattform übergreifend, da über jedes Gerät mit Internetbrowsern darauf zugegriffen werden kann, dadurch entsteht weit weniger Entwicklungsaufwand im Vergleich zu nativen Anwendungen.
  • Updates der Applikation müssen nicht installiert werden sonder sind sofort für alle Nutzer verfügbar.
  • Bei Verkauf muss keine Provision an App-Stores gezahlt werden.
  • Keine Limitierungen bei Design oder Funktionalität durch strenge Vorgaben der App-Stores (besonders Apple und Microsoft).


  • Es wird eine permanente Internetverbindung benötigt.
  • Aus Sicherheitsgründen wenig oder gar kein Zugriff auf Hardware und Features des Betriebssystems möglich (Kamera, Mikrofon, Speicherverwaltung,...).
  • Längere Reaktionszeiten als bei nativen Anwendungen, diese sind vor allem bei Touch-Eingaben bemerkbar.
  • Schlechtere Performance im Vergleich zu nativen Anwendungen.
  • Kein Verkauf über App-Stores möglich.
  • Browserkonformität kann problematisch sein, vor allem wenn ältere Versionen des Internet-Explorers oder verschiedene mobile Browser unterstützt werden sollen.

2. Hybride Anwendung

Eine hybride Anwendung vereint Vorteile der Web App und der nativen Anwendung. Bei hybriden Anwendungen wird eine native Hülle (engl. “wrapper”) erstellt, welche als Schnittstelle zum Betriebssystem dient und den Zugriff auf die Hardware des Geräts und auf Funktionen des Betriebssystems ermöglicht, wie zum Beispiel auf den Beschleunigungssensor, das GPS oder die Speicherverwaltung. Diese Hülle ist in einer für die Zielplattform verständlichen Sprache geschrieben. In diese Hülle wird anschließend eine Webseite gelegt, welche aus HTML, CSS und Javascript besteht. Vereinfacht kann gesagt werden, dass die Hülle ein Browser ist, bei dem alle Navigationselemente und Menüpunkte ausgeblendet wurden.

Bei hybriden Applikationen kann zusätzlich zwischen der Off- und der Onlinevariante unterschieden werden. Bei der Offline-Version wird die Internetseite direkt auf dem Gerät gespeichert. Bei der Online-Version muss bei dem Öffnen der App eine Internetverbindung bestehen, um die Webseite abrufen zu können.

Die hybride Form wird eher für die Entwicklung von mobilen Applikationen verwendet als für die Umsetzung einer klassischen Desktopanwendung. In Windows 8 gibt es aber bereits die Möglichkeit, hybride Desktopanwendungen zu realisieren.

Frameworks, welche den Entwickler dabei unterstützen, eine hybride Anwendung für verschiedene Betriebssysteme zu Verfügung zu stellen sind zum Beispiel titanium oder phonegap.


  • Verkauf in App-Stores ist möglich.
  • Haben das Aussehen einer nativen Anwendung, da Menüpunkte und die URL-Leiste des Browsers entfallen.
  • Zugriff auf Geräte- und Betriebssystemspezifische Funktionen ist möglich.
  • Sind im Vergleich zu Webanwendungen auch offline benutzbar, so lange die Anwendung keine permanente Datenverbindung benötigt.
  • Es entsteht weniger Entwicklungsaufwand als bei nativen Anwendungen.
  • Updates gelten sofort für alle Nutzer, sobald diese mit dem Gerät online gehen.


  • Schlechtere Performance im Vergleich zu nativen Anwendungen.
  • Längere Reaktionszeiten als bei nativen Anwendungen, vor allem bei Touch-Eingaben.
    Browserkonformität kann problematisch sein.
  • Verkauf bei mobilen Anwendungen meist nur über App-Stores möglich, dadurch auch Bindung an Shoprichtlinien.
  • Bugfixing kann problematisch sein wenn kein Framework verwendet wird, da die Wrapper  sich zum Teil anders verhalten als “normale” Browser.
  • App-Stores sind Wrappern gegenüber eher skeptisch.



3. Native Anwendung

Dies ist die “edelste” Form der Umsetzung. Hierbei wird die Anwendung speziell für die jeweilige Zielplattform (daher nativ) zugeschnitten und umgesetzt. Dadurch können über die Anwendung Funktionen und spezielle Software des Betriebssystems direkt angesteuert werden, wie zum Beispiel die Kamera, die Speicherverwaltung oder der Fingerabdrucksensor. Außerdem sind native Anwendungen potentiell sehr performant und eignen sich besonders für rechenintensive Applikationen, etwa für 3D Computer Spiele oder Aufgaben im Forschungsbereich.

Dies setzt jedoch voraus, dass die Anwendung in einer für das Betriebssystem verständlichen (“nativen”) Sprache geschrieben wurde. Für iOS, welches auf iPhone und iPads läuft, wäre das zum Beispiel Objective-C und für Android-Geräte Java. Für Windows 8 können Apps gleich in mehreren Sprachen umgesetzt werden - in C++.NET und sogar mit HTML, CSS und Javascript.

Die Umsetzung als native Anwendung ist daher oftmals die aufwändigste, da viele Funktionen selbst geschrieben werden müssen, die bei Webseiten der Browser bereitstellt (zum Beispiel die Arbeitsspeicherverwaltung).


  • Sehr Performant.
  • Verkauf in App-Stores möglich.
  • Zugriff auf alle Geräte- und Betriebssystemspezifische Funktionen.


  • Hoher Entwicklungsaufwand, vor allem bei Umsetzungen für mehrere Plattformen.
  • Verkauf bei mobilen Anwendungen meist nur über App-Stores möglich, dadurch auch Bindung an Shoprichtlinien.
  • Updates aufwändig.

Es wird leicht klar, dass es nicht eine beste Umsetzungsform gibt, sondern dass die Wahl stark von der jeweiligen Anwendung abhängt. Ist eine einfache ToDo-Liste für Mobilgeräte geplant, welche auch offline verfügbar sein soll, macht eine Umsetzung als hybride Anwendung Sinn. Möchte man ein Spiel entwickeln, bei dem es auf schnelle Reaktionen ankommt oder welches grafisch anspruchsvoll ist, sollte man nativ entwickeln. Und für eine Social Media Anwendung mit einer großen Nutzerbasis und vielen Kollaborationsmöglichkeiten macht es wahrscheinlich Sinn, diese sowohl als Webapplikation als auch als hybride Anwendung umzusetzen, um den Nutzern auch unterwegs eine bestmögliche Anwendungserfahrung zu ermöglichen.


Veröffentlicht von am in CS Tech
Sicherheit und Geschwindigkeit mit CloudFlare & Co

Sicherheit und Geschwindigkeit. Zwei der wichtigsten Eigenschaften jeder Website und zwei Gebiete mit hohem Spezialisierungsgrad. Um jederzeit den neusten Stand der Technik bieten zu können, benutzen wir seit einiger Zeit den Service CloudFlare. CloudFlare ermöglicht es uns, Webseiten sicherer und schneller laufen zu lassen, ohne selbst die dazu nötige Infrastruktur bereitstellen zu müssen. Es gibt eine ganze Reihe von ähnlichen Services wie z.B. Incapsula, Myracloud, MaxCDNCloudFront und etliche mehr.

Grundsätzlich operieren solche Dienste zwischen einer gehosteten Webseite und dem End-Nutzer, der die Webseite besucht. An dieser Stelle können von den Diensten verschiedene Features angeboten werden, welche schwerpunktmässig aber alle in die zwei Kategorien Sicherheit und Geschwindigkeit fallen.

Im Weiteren werden einige der Features näher beschrieben. Die nachstehenden Beschreibungen beziehen sich vorrangig auf das Beispiel von CloudFlare, die Überlappung mit ähnlichen Anbietern ist aber gross.

Content Delivery Network (CDN)

Ein Content Delivery Network (CDN) ist ein Netzwerk von Servern, welches Inhalte auf optimierte Weise an den End-Nutzer liefert. Mit Hilfe der global verteilten Servern eines CDN, wird in diesem Fall eine Webseite möglichst schnell – das heisst auf kürzestem Wege - an den Besucher der Seite übermittelt, was Antwortzeiten enorm verringern kann.

Abbildung: Veranschaulichung eines CDN

Die Server des CDN halten statische Daten (wie z.B. JavaScript, CSS und Bilder) der Webseite vorrätig und übertragen beim Aufruf der Webseite diese Daten direkt von einem der Server an den Besucher. Abhängig davon wo sich der End-Nutzer geographisch aufhält, liefert der am nächsten gelegene CDN Server die entsprechenden Daten.

Der dynamische Inhalt wird weiterhin direkt vom eigentlichen Hauptserver bereitgestellt, während alle statischen Inhalte durch das CDN zum Nutzer gelangen. Laut Cloudflare werden hierdurch Webseiten im Durchschnitt doppelt so schnell für Benutzer geladen.

Abbildung: Die Datenzentren des CloudFlare CDN

Web Content Optimization (WCO)

Wie gerade beschrieben, begründen sich die Vorteile eines CDN darauf, dass eine Webseite mittels der Infrastruktur näher an die End-Nutzer gebracht wird. Die Web Content Optimization (WCO) hingegen befasst sich nicht damit wie die Daten geliefert werden, sondern mit der Optimierung der zu liefernden Daten selbst. Mit unterschiedlichen Ansätzen führt also sowohl CDN als auch WCO zu einer schnelleren Webseite. Somit komplementieren sich beide gegenseitig für diesen Einsatz.
Web Content Optimization wird unter anderem durch folgende Massnahmen erreicht:

  • Bündeln von JavaScript-Dateien: Mehrere JavaScript-Dateien werden automatisch gebündelt damit sämtliche JavaScript-Dateien innerhalb eines Aufrufes übertragen werden. Hierdurch wird der Mehraufwand eingespart, der für mehrere Aufrufe nötig wäre, um jede Datei separat zu übertragen.
  • Asynchrones Laden: Durch asynchrones Laden von Ressourcen wie CSS- oder JavaScript-Dateien kann eine Webseite effektiv schneller laden und wird z.B. nicht durch das synchrone Laden eines grossen Scripts unnötig verzögert.
  • Komprimierung: Die Komprimierung der zu übertragenen Daten findet an dieser Stelle ebenso Anwendung. Bei einer Komprimierungsrate von beispielsweise 30%, beträgt der Geschwindigkeitsgewinn dieser Daten gleichermassen 30%, wegen der entsprechend geringeren Datenmenge.
  • Cache Header: Es werden automatisch die Einstellungen für den Cache Header dahingehend optimiert, damit das Caching des Browser eines Seitenbesuchers vorteilhaft genutzt wird, und damit unnötige neue Aufrufe vermieden werden.



Wie eingangs erwähnt, operiert ein Service wie CloudFlare zwischen der gehosteten Webseite und dem Seiten-Nutzer. Neben der besprochenen Geschwindigkeitsoptimierungen, können an dieser Stelle ausserdem wirksame Sicherheitsmassnahmen zum Einsatz kommen um Webseiten besser vor Gefahren im Netz zu schützen. Diese werden im Folgenden kurz vorgestellt:

  • Schutz vor DoS-Attacken: An diesem Punkt findet der Schutz vor Denial of Service (DoS) Attacken statt. Wird eine solche Attacke von der Infrastruktur erkannt, greifen die entsprechenden Abwehrmassnahmen, und der Angriff gelangt nicht bis zum Web-Server der zugrundeliegenden Webseite.
  • Web Application Firewall (WAF): Anhand einer Web Application Firewall können weitere Gefahren für eine Webseite abgewendet werden. So steht etwa ein automatischer Schutz für folgende typische Angriffe bereit:
    •     SQL Injection
    •     Spam in Kommentaren
    •     Cross-site scripting (XSS)
    •     Cross-site request forgery (CSRF)


Abbildung: Webseiten Analyse von CloudFlare mit Informationen zu erkannten Gefahren

Grundsätzlich ist jede Webseite diesen potentiellen Gefahren im Internet ausgesetzt. Anhand des Einsatzes von CloudFlare bzw. eines vergleichbaren Service können viele Gefahren bereits abgewehrt werden, bevor sie überhaupt bis zu der eigentlichen Webseite vordringen können.

Einzelne Webseiten können zusätzlich dadurch profitieren, dass diese Sicherheitsdienste auch für eine Vielzahl von weiteren Webseiten Anwendung finden, welche gleichfalls diesen Service benutzen. Auf dieser Grundlage muss sich die Gefahrenabwehr nicht auf eine individuelle Webseite beschränken, sondern kann all diese Webseiten umfassen. Wird zum Beispiel ein Angriff auf eine spezielle Webseite erkannt, so kann der Angreifer automatisch von sämtlichen Webseiten blockiert werden.


Wir sind bisher sehr zufrieden mit CloudFlare und die Benutzung hat sich in der Praxis gut bewährt. Unsere eigenen Server können sich häufiger ausruhen und wir profitieren von gepooltem Wissen und geteilter Hochleistungsinfrastruktur. Wie viele andere Services in der Cloud, bringt auch die Nutzung von CloudFlare & Co neue Probleme mit sich. Störungen von CloudFlare selbst können weitreichende Konsequenzen haben für die Erreichbarkeit von tausenden Seiten. Aus diesem Grund ist es wichtig, jederzeit eine funktionierende Fallback Lösung zu haben und sich damit nicht 100% abhängig zu machen.

Wir konnten bisher insgesamt signifikanten Nutzen aus den beschriebenen Vorteilen ziehen und unsere Infrastruktur wird durch diesen Service hervorragend ergänzt.

Show page in

Was Kunden
über uns sagen

Das Team von cloud solutions ist sehr kundenorientiert, hilfsbereit und arbeitet speditiv und exakt. Besonders praktisch war für uns die Kommunikation über Skype und Unfuddle, wo Anpassungswünsche für die Befragung online erfasst werden konnten.

Elisabeth Lauper
Interfakultäre Koordinationsstelle für Allgemeine Ökologie, Universität Bern, Schweiz

The future of the PHP PaaS is here: Our journey to Platform.sh
CS Tech
In our team we’re very confident in our ability to produce high quality software. For the past decad...