A couple of weeks ago we launched the website of a service we have been working on hard for over half a year. The project started as a SAAS about performance and hence the internal project name was “ProjectPAAS”. As it goes with internal project names, it became the name of the service it self.

12 seconds start now

I still have problems explaining what the service is doing in an elevator pitch. But basicaly one installs a module on a to be tested staging site from d.o with the funky URL /project/paas, configures the service on the portal of projectpaas.com and then wait an hour or two. We start a service to measure your site from the outside and from the inside, analyse the data, make a report and when you check your mail you get an in depth report on all the elements of the chain that are relevant to the performance of the website.

We measure from one or more selectable (EC2) locations in the world with over 150 metrics and we only report on real data, no yslow wisdom. We know what influence speed, we see how it is configured at your site (with the module or from the outisde) and we simulate to find the the optimal value would be for your use case.

The cliché for example that one needs parallel download (images[1-4].example.com) to bypass the maximumum connection a browser can have to a host, is just that, a cliché. When one takes DNS lookup,TCP slow start and the sliding window in to account, for certain usecase, having images[x].example.com might actually be slower. So we are opinionated, we measure, we analyse, we report, you gain speed.

Easteregg

I really like retro future so we used this for a theme around the site and facebook. But since easter (Dutch "pasen" is coming up,
do check the projectpaas.com website, find the easteregg and twitter about it. :-)

This posting isn't as much about the service of ProjectPAAS as it is about why we made the service. To share our experience and to get feedback from you. There are two reasons we made it, one is internally driven and one is externally.

The internal reason is that we have been building some of the most visited sites and webapps in Drupal in the Netherlands. So after some time we got good at performance, we understood what to do and what not to do for the complete stack of elements that define speed, HTML, CSS, Linux, Apache, MySQL and yes, Drupal. Word got out that we were good and siteowners that have been building their site at another company, came to us for advice on how to get more speed in their site.
Once we had done a dozen of these reports, we wanted to make the reports more easily accessible for the site owners and website builders. This is part of why westarted the Performance Reporting

Land here

The external reason might be more interesting for you. We made the SAAS because we think that the CMS landscape will change and our business will change.

The landscape will change. 10 years ago everybody had his/her own CMS, there were more CMS-es then websites it seemed. 5 yeas ago it was clear who were going to be the winners in the consolidation, 80% of the proprietary "solutions" were gone and open source was no longer a dirty word in enterprises. Within the open CMS-es, the global top 5 was visible though especially in Europe there were still many local open source CMS-es. This consolidation perse was good open source and especially for Drupal shops.

However, the market won't stop here. Most of the Drupal websites are not complex, they don't have any connections to backend systems, less than 10k pageviews per day and are relatively expensive to build and most of all expensive to maintain. Here is the business case for open source SAAS, solutions based on open source software like Aqcuia and Wordpress.com offer. These solutions with standard modules and a customisable template is good enough right now for 20% of the Drupal sites out there and will cost a fraction of what building it "by hand" will cost.

The users of these open source SAAS hosting solutions will only grow. Good for the parties offering these services, bad for the Drupal shops that have been building relatively simple portfolio sites. By itself, this trend might have a big impact those coding Drupal core, modules or working in for example the security team. This is not meant in a bad way, but with most of the sites going towards a smaler group of SAAS companies, the number of "independent" individuals adding to core or writing modules might actually get lower, they might have another itch. It will be very interesting to see how this will develop, I might be completely wrong here.

Performance takes time

Traditionally most Drupal shops do projects, do maintenance and do consulting. Some have found a nice niche, a place geographically apart, a specific vertical or a certain service like migration from another CMS. However, most Drupal shops build relatively simple websites for SOHO plus. I know there are many shops that work for high end enterprises. But not all the 280.000 Drupal sites fit in the Alexa top 100.000. So I do think that if you are a Drupal shop, you have to find your sweet spot the next couple of month. On the one hand we have operational excellence (a SAAS to host sites like gardens or a service like ProjectPAAS itself) and on the other hand customer intimacy (the complex sites with lots of integration with backend systems and complex workflow). There might be space between these two, but the portfolio site area will get very crowded and Drupal will not be the best tool to serve this in my opinion. This is part of the reason why we build our first SAAS around a product we understand and is close to our core business. We are already planning next services that might still be build in Drupal but will target a broader audience.

For the moment, if you are intersted in our product, dont be shy and talk to us on twitter or faces us. Potential resellers or users are welcome to fill out our form. We really do hope that our product can help you build faster websites and thereby push Drupal even more ahead of the curve.

Let your webservers accesslog be the source of a game of pong :-)

If you are a brew OSX user, a oneliner to install :-)

see logstalgia

Ik weet niet of het express is of niet. Maar de DIV (zeg maar het kadopapier rondom de content) van denieuwe website van de Stentor is zo gekozen, dat banner blockers (links chrome met een default bannerblocker) de content blokken.

Rechts in een default safari zonder bannerblockers. Zie zelf op destentor.nl

Dit is OF heel slim (als je website wilt zien moet je bannerblocker uitzetten / gerconfigureren / site whitelisten) OF heel dom en website bouwer heeft geen bannerblocker :-)

(en ja, ik heb veel tabs open)

Hi. It’s Daniel. .. Daniel. Of the marketing department? We met.. Never mind.. Listen. Listen up. Are you listening? Sit down. Listen, I have a great idea. Great I tell you. You know we have 20 sites to run. Yep, twenty already. And we do this.. with. Eric counts as well.. 8 people. A staff of eight running twentie sites. And what is missing..? Well.. Yes? Indeed!

Our editors need to be able to work when they are in the field as well, on the road. Indeed. Yep, you guessed it right. A native App! Download from the AppStore. A native app I tell you, so our editors can write when they are in the field. Now listen, it is a great idea. John and Steven are on iOS.. yes, both using an iPhone. And Lisa always has an Android.. Don't know why.. And then we have Peter who has bad eyes and used the New iPad. Brian is still on Windows. Why can't we fire him..? Paul has a Mac. So we need to make.. Let me see, been a long day. Ooh, wait Eric is on that penguin thing.. Yes Linux is what he calls it. Well forget about Eric, we can't support everything.

So we have to make 20 apps, for every site one. Time two mobile OS-es, one optimized for the iPad. One windows and a mac. So 20 times 5. Say, we have to make 100 applications. Yes that is a lot. But think about the advantages. If they want to edit an article, all they have to do is open an application. Because -and this is the beauty of my concept- it is in fact using HTTP as a protocol from the application to the website. See? We just use what is already there; the protocol. Smart hu?

What. What? What you do mean we don't want to build and maintain 100 silos? Why are you calling it silos... It aren't silos? I think you don't understand. It are apps! APPS. Native Apps. Yes I know we will be launching 3 new websites. Ooh, Steven switched to Windows Mobile.. ?

Why do you keep calling this silos? You didn't call it “a silo” when we launched 20 apps for our Android users and 20 for our iOS use... You did? ooh, but still.. What do you mean can't support? What is this with change management you keep saying. Yes, I know our 20 websites have a CMS where you can change data and functionality live for all our users. So, what is so bad that we wait a month or two before Apple.. Yes, I listen.. There IS already an app for that? Great, why didn't you tell marketing? There is an app for using our websites on mobile. Now you tell me.... So, where can I download it... What already on my device? An app for that called.. a browser?

Naambellen. Kent u die uitdrukking nog? Ik moets daar aan denken toen ik laatst hoorde dat onze -volgens de GeenStijlGanzenGeneratie- “staatsomroep” NPO uit “uw belastingpoet” de postduiven voerde door NPO.nl te kopen.
Naambellen. Het eenvoudiger maken van een telefoon nummer door deze van “een naam” te voorzien. Op telefoons staond vroeger -in Amerika al sinds een halve eeuw. Op oude dial toestellen stonden per cijfer al 3 letters. In Nederland met de introductie van mobiele telefoons waarmee ge-sms-ed kan worden kortere tijd populair geweest. Zo is het landelijk oveheidsnummer 077 4656767 volgens phonespell het handig te onthouden 07-pi-OK-or-or.

Naambellen. Een vorige werkgever introduceerde een dienst waarbij je middels je computer -begin 2000- kon inbellen naar een speciaal nummer om een VPN te slaan naar een beveiligde infrastuctuur. Inbellen middels een modem LCDbuis vriendjes. Dat deden sommigen toen nog. Het nummer dat je op je computer moest intypen was netnummer (wellicht 0800 of zo) IKBELIN. Lekker handig, voelt u hem? Moest je dus op je nokia telefoon gaan kijken om te weten welk telefoon nummer je moest bellen op je PC. De zelfde mensen die hier voor kozen gingen ook -geen grap- met polonaise door de gangen toen bleek dat ze voor een grote telco klant een soort “portal” (het was 2000) mochten bouwen en het domain dat ze wouden gebruiken nog “vrij” was; whepp.nl. Ja met wh en dubbel pee... :-)

Naambellen. Domainen die je moet spellen. Ik denk dat deze mensen nu bij de Nederlandse Publieke Omroep werken en denken dat een drieletterige domain moesten kopen. Dat hoeft in 2012 dus echt niet meer, content is water, google de sluis. Maak de eerste en de tweede zorgt dat klanten je vinden. 2012... Een ton voor een domein.