This year the trip’s to LAAX in Switzerland – famed for having the longest half pipe in Europe and host to the fabled “Brits” it is shaping up to be a year to beat all others. We’re off from the 24th Feb for 4 days – with this season’s snow looking better than ever, just can’t wait to get out there. Unlike last year we wont have to put up with Austrian Sauna policies – we’re staying at the uber cool Signina hotel. Lets just hope they’re fully stocked with the Jaegermeister.

Also – our crazy European friends from the TYPO3 community will be there – looking forward to sharing a few beers with some vikings and demonstrating our professionalism on and off the piste! #T3board12

There will be more dates announced, we’re going to keep them small as then we’ll all get more out of it. Oh yes, our cloud operations are going under the guise of Brightcloud – because we’re from Brighton and we do cloud things… genius!

@danfrost so how do you propagate files without nfs??

I had mentioned that this was one of the stickier points, in my previous post and whether that’s what prompted this I don’t know but it is always an issue with CMS and blogging software. Every app saves stuff to the file system because… well, the file system is there just waiting to have images, PDFs and mp3s put on it.

Migrating legacy apps to the cloud and making them speak like natives isn’t just matter of making sure you can work around the way they were built. In the first instance, yes, it is – but beyond your first foray into the cloud you should aim to get more out of it by using the native cloud technologies.

Want to get into the cloud quickly? Sign up for our AWS training.

I call anything which is built, from the ground up to be scalable to very high traffic levels “native” cloud, not because that’s the right term but because it fits with the architecture we try to achieve in the cloud. SimpleDB, S3, CloudFiles (by Rackspace), MapReduce are all such technologies. They are, by design and implementation hugely scalable.

So back to the evil file system. NFS isn’t evil, but when you get into the cloud you have to ask one question: why does every server really have to see all these files? Most of the time it’s just the browser which requests the file – say, the image, the PDF or the zip file.

Many people use S3, CloudFiles or some other static hosting or CDN to solve this problem, which takes load away from each web server and does make the system scalable. If you’re using this, then you’re on the way to doing full-blown cloud hosting. It’s the first step. (Ok, there are a lot of step, but it’s the first.)

The next step is to make the CMS upload images to the static hosting rather than storing them locally. For our proposed talk at t3con11-sf we’re going to prototype such a system for TYPO3, similar to the WordPress plugin which uploads assets to S3.

This very, very simple tweak to any legacy system takes a noticable load off the web server and is the start of removing the single points of failure.

But – to backtrack on what I’ve just said – NFS is sometimes required and does work in the cloud. We use it in production on several sites, though there are more cloud-friendly systems which we’re going to cover soon.

Get in touch for consultancy and training on the cloud.

We’ve been running TYPO3 on the cloud since AWS released their API and we’ve recently become Amazon Web Services Partners. Back then there was less support and training so we had the happy time of working out how to do this from scratch. And we did it.

When Andrei and I were at T3CON10, the TYPO3 conference there were some talks on hosting TYPO3 in the cloud but not many people had actually done this so the talks were a little academic. We spoke to people in the bar, and decided we would share what we have learnt over the past few years.

This is the first of a few posts which explain how we’ve done this, in low-level nerdy terms. There will be jargon…

So, why bother with the cloud? Simple answer: it solves lots of old problems and presents better ways of dealing with hosting. There is no need these days to think about physical drives or even when you should replace them. Cloud hosting takes the physical problems away from you.

You can achieve greater resilience – far greater than you’d ever be able to afford – at a far lower price. All your hardware can be programmed, so your entire hosting environment can be recreated automatically. This is a rule if you’re in the cloud: automate everything.

Breaking up TYPO3

To scale, you have to split the site into ‘code’, ‘data’ and ‘assets’.

In TYPO3 the code is: index.php, typo3, t3lib, typo3conf and these files can sit on each server independently of all others. if you’re working on EC2, you can either bundle this code up into the image or copy it down to the server via a script.

The second item is ‘data’. This is simply MySQL data (or whichever DB you’re using), and simply needs to be loaded into the database.

The third thing is TYPO3’s achilles heal. ‘typo3temp’, ‘uploads’ and ‘fileadmin’ are problems. Common answers are to use NFS, so the files are shared over multiple machines but actually live on a single machine. (There are better solutions – watch this space for them…)

Having split your site you simply write a script which places the code on each new web server, shoves the data in the database and mounts the NFS drive. Nothing new?.. No, not really. There are some tricks such as DynamicDNS or DNS Zones which are a must if you want your cloud to be self-healing. These allow servers to change their IP addresses without taking down your entire site, something that dedicated hosting doesn’t even have to consider.

For the most part, putting TYPO3 – or any CMS – in the cloud is down to sensible planning and splitting the concerns. While it is true that CMSs have their own bottlenecks, we’ve found that we can put most legacy apps in the cloud.

Why bother?

There are lots of subtle benefits in moving to the cloud, which I’ll cover in another post. Surprisingly, the best benefits are business benefits – even though using this stuff is incredible nerdy fun. If want to know more, talk to us.

Since my build tool of choice is Phing and usually I like having a build running just by running “phing” in the project root, I had to get the symlinks created during the build process. The Symlink task does just that.

Using it is pretty straight forward:

Until the next release, you will have to define it using taskdef:

<!-- Load the symlink task -->
<taskdef name="symlink" classname="phing.tasks.ext.SymlinkTask" />

Once defined, you can start symlinking (I’ll use the Typo3 example):

<target name="typo3:symlink" depends="needConfiguration" description="Generates the requried typo3 symlinks">
    <delete file="${build.public_dir}/${typo3.index_file}" />
    <delete file="${build.public_dir}/t3lib" />
    <delete file="${build.public_dir}/typo3" />
    <delete file="${build.public_dir}/typo3src" />
 
    <symlink target="/share/typo3_src-${typo3.source}" link="${build.public_dir}/typo3src" />
    <symlink target="${build.public_dir}/typo3src/index.php" link="${build.public_dir}/${typo3.index_file}" />
    <symlink target="${build.public_dir}/typo3src/t3lib" link="${build.public_dir}/t3lib" />
    <symlink target="${build.public_dir}/typo3src/typo3" link="${build.public_dir}/typo3" />
</target>

The variables used within the target are:

build.public_dir – points to the document root of the build
typo3.source – version of Typo3 we’re using (4.4.4 for example)
typo3.index_file – t3index.php, we usually have a Zend bootstrap as index.php which includes the Typo3 index file

It can also do multiple symlinks at the same time. Consider having a “library” directory somewhere in your project, that contains the sources of some shared libraries (zend, doctrine, etc), to symlink all of those into your build:

<symlink link="${build.path}/library">
    <fileset dir="/share/library">
        <include name="*" />
    </fileset>
</symlink>

If the contents of /share/library were “Zend, Doctrine”, then in your build you’d have:

library/Zend -> /share/library/Zend
library/Doctrine -> /share/library/Doctrine

To install Phing, please follow these instructions.

3ev were given the task of not only designing and building Leading Edge Design’s new website but also help develop their branding. The brief was to create a brand that was modern yet still familiar to existing clients. The colours and icon were an evolution of the existing logo whilst a new typographical style was introduced. Overall the form of the logo is now easier to work with.

That cool video was created using Gource (http://code.google.com/p/gource/). I’ve attached the actual command, just in case you want to show us your cool repository activity.


gource -s 0.01 --auto-skip-seconds 0.1 --file-idle-time 10 --disable-progress --stop-at-end --multi-sampling -1280x720 --stop-at-end --output-ppm-stream - | ffmpeg -y -b 12000K -r 50 -f image2pipe -vcodec ppm -i - -vcodec mpeg4 gource.mp4


The majority of designers are pretty good at recognising fonts but, like the rest of us, they do have limits and can’t remember every typeface created by every foundry since the Gutenberg press. Thankfully WhatTheFont! by MyFonts can help with any typographical recognition; just upload an image with the font that you’re trying to identify and WhatTheFont! finds the best match. Think of it as Shazam of typography.

When using Zend_Feed to create your RSS, don’t use:

pubDate => date('r', $item->timestamp)

This doesn’t work as you’d expect. You’ll only ever get the current time. If you want to change the date and time use:

latestDate => $item->timestamp

Zend_Feed expects a plain timestamp, not a RFC-822 format date (Fri, 09 Jul 2010 22:20:00 GMT). Why it takes the key as latestDate but outputs pubDate is beyond me…