 Okay, hello everybody, hope you had some coffee and ready for some more talks. So that is actually a two session session. So I will talk half an hour and then we switch over to the other guys, which is Rackspace, I guess. Yes, but first me, welcome. My presentation is about building a full site in Drupal 8 Alpha. Hello, or in Swiss German, we say, and to my talk, I'm Michael or on Drupal.org, I'm Schnitzel, I'm a head technology at Amazing Labs. Amazing Labs is a web agency that does only Drupal in Zurich and Austin, and we decided to build our new website in Drupal 8. Why? A lot of people ask me that, and the reasons are simple. We wanna learning by doing. We don't want when Drupal 8 is out, start our first project. We wanna be ahead, we wanna be one of the first ones. So we had that crazy idea end of last year to say, okay, let's give it a try. At that point, the first alpha just came out and we wanted to know if it's even possible. So we set our date and we said, okay, in April, end of April, we wanna go live with Drupal 8 Alpha. Also we wanted to research the status about D8 because a lot of things, and I'm one of the core, I'm also involved in core development, when you do like normal testing, you never actually test it for real. But when you build a whole website, you have a lot of additional cases that you never thought before that they couldn't come up. So we also wanted to know how is the status about it to give back to the community to say, hey, that is broken, that is broken. Maybe we should rethink that, et cetera. And also we like to be a bit crazy, so we did it also in terms of insanity. So we said, okay, let's try it out. Maybe it will work, maybe it won't work. What was the process? We started actually February 2013. So that's more like one and a half years ago where we discussed, okay, we wanna have a new website. And we designed that in Photoshop. So sometimes we do designing browser and sometimes we do designing Photoshop. And we constantly checked possibilities with the tech team because one of the really important things is that the designers design something that is even possible, especially now with Drupal 8 because we cannot do all the fanziness that we can do in Drupal 7 because none of the country modules that provide us with the fanziness are ready yet. So, and that actually took more than a year. We took a really long time to discuss about our new website, how we wanna show ourselves in the world. So we had some different ideas. We kind of went from the people that currently know our website. It has the old website. It had that background. So we added that a bit more but we thought it was too dark. So we changed it. We make it fancy with fancy fonts and we also didn't like that. So we went to a more way of adding new colors showing our new office. We also didn't like that. And then we went another crazy idea of like that long shadow. We added, yeah, but we were never really happy. And for the people that were in Prague, they maybe remember that our whole booth stuff got stolen because the car got broken in and all everything got stolen. Our whole booth was like empty. So we ended up in buying tape at the local store and taped our booth. So we wrote our name, our logo with like tape. And that was actually such a huge success. We said, okay, let's try that for the website. So we did the first mock-ups. We did this first thing and that's what came out. So our website is now dock taped. So it's like this all smiley, small, fancy, small tapes. And yeah, we actually have it in the office too. So we started to like now decorate our office with the same type. And that's what took us a whole year to figure out from different designs and what we really would like to do. So, and as I said, we said, okay, we want to do that in Triple 8. We have people in Austin and in Zurich and especially for this kind of projects where we don't know where we're going, we brought them over in Zurich. So we created our war room, which is what we see here. It's basically a wall and we printed all the designs that we have and we wrote on them. It was like a working environment. We wrote like, how do we do stuff? Is that, which field is that? Which view mode is that? So it was really like a working progress where everybody could there and we had discussions with the theme of Catherine and Boris was one of the site builders. So we were discussing like, how do we do stuff? Because as I said, in Drupal 7, almost everybody knows like how to do stuff. In Drupal 8, we had to figure out first a lot of things. And that took us like a month. So we did some specifications, we discussed with site builders, we went back, we discussed does it work, does it not work, et cetera. Then in April, we started theming and backend development. So we first do the site building and during that time we realized, okay, what is missing from backend? So the back enders helped us, implementing, porting some of the modules we needed to Drupal 8 and then the theming started, we implemented a theme with everything we've says and compass and stuff. And then we did testing end of April and I said we actually want to launch end of April because in May it had to be live. So this ended up in looking like that. So the red line is the amount of bugs and the green line is the amount that we fixed. So you see like in the last week before May we found a lot of bugs and we tried to fix them. We couldn't fix all of them because a lot of the stuff is actually broken by Drupal 8 alpha at that time. So we said, okay, the things that we cannot fix, we want just one fix and we accept some flaws on the website. And another thing is a lot of the bugs were actually depending on design because we have a really high design standard to ourselves, so there were like small things not perfectly ready, but we said, okay, we want a ship, we want to go out, we want to show that. So we launched on 29th of April, 2014. In the morning, everybody was sitting in the office and I hit the button which basically moved from the old Drupal 7 to the Drupal 8 and we launched and everywhere was happy. So what I want to do now is go a bit into deeper into the single parts because every website contains of single pieces like side building, backend and stuff and move Drupal 8 all of them change. So I'm going to go into there and tell you a bit what has changed there. So one thing that we use all the time is panels in Drupal 7 and the problem is it's currently completely missing. At that time, there was not even the page manager module which is now kind of there. So we had to find a way how do we build landing pages which is usually what we use panels for, like what are our services or what is our team? Of course, a single note like a blog post view a note that has a page, but a page like, okay, what is the team? So we figured out that with views, you can do pages and you can put now entities into headers and photos in views and as a view is now also an entity, you can put views in a view, in a view, in a view. So that's what we used. So that's the services page that we have and we see on top, we show our three main services and then at the bottom, we have some additional explanations but it's basically just a block of a lot of notes like a landing page. So what we're doing, we see the service page and you see here it has a path slash services and on top, we need an additional view of notes and you see that we say, okay, like is the content featured? No. And then we put in the header another view which shows all the featured services and that's how we build the site. It's honestly pretty ugly but it was the only way that we could do it at that time. So, and that's like an example. So why were we building the Drupal 8 with alpha? We had like no country module, there was nothing there. So we had to come up with really fancy ideas, okay, how can we do stuff? And that's where the War Room helped us a lot to like go in and discuss and paint and like draw and have ideas and scratch them again. We also use heavy view modes and it's really cool that now in Drupal 8 view modes are actually exposed. So in Drupal 7, there are view modes but you cannot add them. There is a module for that. In Drupal 8, you now finally can add them. So, and one of the conventions that we use in a Matelabs is that everything is done in view modes. What does it mean? We don't show any single fields inside of a view. So if we go back here, you see there is no field. When we actually show the content, we show a teaser. And we do that on different reasons because for us, a website is not a thing with different pages which look completely different. It's a set of building blocks. So a teaser on the homepage most probably looks the same like us on an interior page. So we built view modes for that teaser. We styled them based on the view mode so that it looks everywhere the same. And it's much easier and much faster to adapt and change things. And also the really good stuff is the designer don't need to design the sub page because it's actually just parts of the front page and maybe some other page reused. And that makes it much easier. And also especially with Drupal 8 caching. Drupal 8 now has a caching layer based on a view mode. So the view mode is rendered and whenever you use the exact same view mode of the exact same node somewhere else, it is loaded from the cache which makes it really, really fast. So whenever we try to use view modes when possible with building our layout. The problem is that we in Drupal 7 we use penalizer and that is finally also missing. As I said, there was no country module. And there was display suite which was partially already ported but not ready and they're partly broken. So we decided to not use that. But there is twig. And twig allows you to write your own template files as it does in Drupal 7 to build your site. So we did that. So usually in a twig file just the whole content is rendered and the order is depending on like how you set the order in the display settings of that content type. But we went a bit further and just showed each single field. And the process is that, that the site builder that knows how the field is called that knows a lot of other stuff. He just creates one twig file and just puts everything in there in the order that we saw in the design. But if the theme goes in he said, ah, that's not how I need. I need like a wrapper class there. I need some stuff there. So the theme goes in, takes that, sees all the field names so he doesn't have to figure out how the field name is called and we actually wrote the field names on the screens as well so he knew and then he can change it. So he said, hey, I need a section on top that is a class and you need a wrapper. So he just takes the existing fields and puts them a bit different. And that's like how we work in panelizer that he creates its own layout and then he can move them around. So beside of that viewing that in a UI in panelizer we just did it in the twig files and that actually worked really well. Of course you don't have all the flexibility of panelizer so it's not perfect but it worked out pretty well. So that's about the site building. Beside of that it's like we use it from Drupal 7 so the UI looks really same. It's probably the part where not a lot of changes have happened. What the user actually see of course in the backend there's crazy stuff happening. Theming, there are no base themes again. So on Drupal 7 we usually use Omega which just removes us on the necessary stuff which adds all the HTML5 functionality. So we use that as like a reset theme to build our own sub themes on top. The interesting thing is on Drupal 8 we didn't even need one because all the stuff that Omega does for us in Drupal 7 is in Drupal 8 core, yay. So like we have HTML5 in there, we have better classes like all the stuff is already there so we just build a plain theme and that is done with CSS and grids which are fully customized. So because we went really crazy with the design like every page actually has a different grid so we use 2C2 to create our own grids with Compass and SAS and yeah that worked out really well and that's actually what we use anyway already so there wasn't a big change we just usually use 2C and we try and say okay let's go in further and try a new grid systems with 2C2 and that worked also really well and one of the really big changes is Twig. So and a lot of people are scared of it and there is a less than three there because my themers told me I should put it in because they really like it. It's finally a language or a way for them to write stuff without being scared of PHP because every time a femur has to write PHP he hears about the stories that they backhand or tell them you're not allowed to write any PHP and they're confused and they're scared and now with Twig it's like the way they say okay good. I can do, I can write my Twig I know I cannot break anything. I cannot delete a Drupal database from the theme layer anymore and that's really great because in Drupal 7 it was possible. So and they're actually hidden superpowers in there so we have extends and blocks so if you are into Twig or look them up they're really cool so you can actually extend themes that you write like things that you need to write again and again and again you can extend them and that's really cool. So the question is yet how deep that this will be used in Drupal Core itself most probably not a lot because it is a bit confusing but after you get it it's really cool. Sometimes they're a bit strange stuff or strange stuff that's just how it is and we had to learn that. So we have a field title and we wanted to show that. If you just put the field title it actually has an H1 around it or an H3 but we wanted to have an H2. In penalizer I could just change that field template or I could override it or whatever. So what we had to do here is we had to figure out the way how to access only the value of the field and after some debugging stuff we figured out that's with a dot zero which is actually so the field title is an array and then you just access the first which is the zero element and that's worked. So that was a bit figuring out but actually it's used in core as well. So we went into core and checked like how is that done? Maybe and then you see the dot zero and you just use that and that worked. So yeah, so twig was a really big step for us to go from that HTML and I don't know if I should from the PHP and I don't know if I should give the theme access to it or not. Configuration management. Who has heard of configuration management in Drupal 8? Okay, who doesn't know at all what it is? Okay, so configuration management basically means that we split up the content from the configuration in the Drupal database. Drupal 7 has that really, really big issue that the content that your editors add, so like your node title, your node body is added to the database. Fine with every CMS like that. The configuration stuff like the view, like the view modes, the penalizer, all the stuff that is done by the site builder to build the site is also saved in the database. So now you have your launcher website and now you decide I would like to do additional things on my production website. Of course you wanna test them first. So you do them on your staging site or on your depth site, you change your front page and all that stuff and that's all fine. Now the question is how do I get that from my depth environment to my production environment? Usually we can say, okay, I just overwrite the database because that's where all the stuff is saved. The problem is at the same time while you were developing people added content, people created user accounts, people wrote comments on your site. So if you now put the database from your depth to the live, all that stuff is gone, not what we want. So configuration management goes in and generates one bucket where every configuration is saved. It's still in the database, but there are two additional things. It's only in one single table and it's exportable into files per default. So every configuration that is ever written by any module is exportable and importable. That means you can take your configuration that you changed on the depth site, export it, go to the production site, import it and Drupal will do whatever it needs that your site looks exactly the same as on the depth. It installs modules, it creates fields, it creates content types, everything, even like in multiple steps. So like if there is a new module in, it realizes, oh, maybe I should install the module first. So it installs the modules, runs again, does the later stuff. You can see differences as well. It shows you what has changed. So it's really, really, really nice to work with configuration management because it finally splits up. What it does not do, it does not deploy any content. So content is strictly out of the whole configuration management. So if you change something on your depth site because your front page now should not say, hello to my site. It should say hello to my awesome site. And that is done in an inside block or inside a node. And if you take everything out of configuration management and put in a production, it will still say hello to my site. There is no content deployment. There are, though, possibilities to do content deployment also in Drupal 8. They're currently involved and with all the rest stuff and things that's really nice. Okay, so configuration management, how did we use it? The problem is we had multiple people working on the site at the same time. So you need a system to make sure that when somebody changes this configuration on his local site and puts it on the depth that it does not override the changes that just somebody else did two minutes ago. And configuration is, when you export it, is all saved in YAML files. YAML files are just text files and they're really nice. And text files really work nice with Git. So the idea is that we put the configuration inside of Git. And when somebody else changes something, you just pull and your configuration is there and Git handles everything for you. The problem is there is no Git integration out of the box. There are ideas currently and that's what we used. I'm not sure if this is what we will use in the future. But basically what we do, we put the config directory somewhere where Git is in. Usually it's saved inside default files config something. And the site default files is defaultly excluded from Git because you don't want to put all the files in your Git repository. So we change that and say, okay, we want to save the config files inside my site's default which is already added to the Git. One important thing, if you do that, make sure nobody can access site's default config from the browser because he can read your configuration. Just as small slides. You can also put it somewhere else. We just decided to put it there. Anyway, so on your local dev after you change something, there is a drush command. And drush already has support for configuration management. So you can say drush config export inside my config directory. That is that. That is in here. And I want to add that and I want to say yes. Everything adding. So that will automatically Git add all the changes. So it will export the configuration management inside that folder and automatically Git add everything. So all the changes are there. I commit that with my config changes and I push that. And then on the dev side, I just make a Git pull. All the configuration changes coming. And now I have to import it again so I make drush config import config. And it will tell me that is was changed. Would you like to import that? So I can still see, oh, no, no, no, no, the view that I just created for a test on my local that should never go to production. You can still stop and go back and change the stuff. So that's really nice. It's just an additional step of running because if you do it wrong or if you do it the other way around, it could happen that configuration is gone. So that means every change you do on the dev side needs to be exported immediately. But what I think, because we now have all these fancy, cool stuff that we can export configurations really easily, there should not be a place where everybody does changes at the same time. Like everybody should do changes on its local where nobody else's can access. You can do all the side building stuff there and then you put it on the dev. Because currently we do side building changes directly on dev in Drupal 7 because it's really hard to feature them or like to put them from your local to the dev. So we said, okay, we do just do them directly on dev. But I guess that we have to change that to do everything local, take the configuration and put it there. Yes, that's about configuration management. But overall, it's like the best process that we ever had. It's so nice to work with it. It's installs everything you need and you just have to cite exactly the same updates. So luckily this morning, Drupal 8-beta-1 got released. And that means between beta updates, there will be an upgrade path. We don't know yet how exactly that will work but there will be parts of upgrading. In alpha, there was none. There is no way you can or there's no support for your upgrade. So I had to do it. I mean, we started before, we started in January and we had to like update in March and April and stuff. So how does it work? So first, you make a backup. You make another one because that's really important because upgrading can break your site. Then you take the newest version from Drupal 8. You get pulled out and you merge that probably in your branch, whatever you have. And then you visit the page and in 99.9% you get a widescreen because Drupal is like, ah, it's broken. So you may be clear caches and maybe you're happy. Maybe the cache clear was fine but most of the time it was not. So I see maybe some error or whatever. Sometimes I did not see any error at all. So you have a widescreen of that. So what you do, you start step debugging number five. I step debug and I go through and it all good. And then at one point maybe a function breaks or there's a function not found or something like that. So then you start to Google for that and you find change notices. Really nice, we have change notices now in Drupal 8. That means every change that is done since Drupal 7 is written down of like a small explanation function that has changed to that. But inside of Drupal 8 itself it also changes. So recently just we changed every L function is now your L function and stuff like that. So you need to find that things. So in change notices there and there. So you try to fix it. Maybe you do some DB adaptations because the structure of the configuration has changed or whatever. You step debug again, you read change notices again, you fix, you step debug, you read. It's an endless process. And one time it took me 16 hours to update from one side to the other. And actually, so it's, yeah, I think change notices are really important. So if you know the last time that you, that the version on the commit that your site was running before and now you can just scroll through all the change notices. And sometimes you see, well, that had changed, and then sometimes you also see. Step debugging is really important. So with Drupal 8 we all use now PHPStorm where we can step debug. Before it was easy to put the TPM somewhere, but now it's because of classes and overrides and all this stuff, it's just way too hard. And a really interesting one was comparing the database with a new installed site. So I installed Drupal vanilla 8, Drupal 8 fresh, and I compared the databases. And I saw, oh, there's a new table. Maybe I should add that. And also comparing stack traces. So like debugging both at the same time and realizing, oh, that new site goes there and my site goes there. So maybe I have to move that around. The best of all was that. So there was a change that changed some system.module, system.theme, and system.theme.disabled. So they added that that were like three configurations before into core.extension. And my site to run was running and no module was installed. And I just saw like some theming debug error. All right, okay, good. So the added was the error. It's a call to a defined function system region list in like themes. I said, oh, something changed in the theme. So I went into there. So I fixed it when I compared my conflict table from my side with a freshly installed Drupal 8 site. And I saw there, oh, there is one line missing. And it was that core.extension because it was missing. Drupal didn't even know which modules to install. And interestingly, the first time that it breaks, it's when it tries to load the function system region list because that's in one of the modules. But till there, like the whole Drupal boot strapped without problem and actually interesting thing. What I found then after searching and searching, searching, searching, searching, after that 16 hours, I saw Alex Potts saying, he committed that. And he said, I've debated whether or not change notices is necessary. I would say there is. But I think better change notices will be set of documentation how the .8.extension system works. So there was no change notice for that. So I couldn't even find it. So that's why I had to debug it, throw it, and figure it out myself. But I mean, at the end, I agree with him. It's not necessary. Why should you document craziness in yourself when the change notices should show like what have we changed from seven to eight and not like each single step? It just took me 16 hours and was fun, but yeah. Multilingual, one of my areas because I'm involved there as well. There are some issues currently we know about them. We try to fix them. So sometimes label translations are cash too hard or like entity references when it loads another entity. It does not pass the language in. So if you're in a German page and you load an English entity in there, it loads it in English because the loaded entity does not know that you're in a German page. So we try to fix that right now. So there are some things, but aside, we had to strip out stuff. So at one point we say, okay, good. There is sometimes, depending on the weather, sometimes on top right, there is some German in there. Well, okay, not super bad. But over that, multilingual worked really well. Migration, the migration module was at that point not yet ready. We're further now, but that was cool. So we built our own migration. So we installed on Drupal 7, we had a service module which exported everything to JSON. And on the D8 side, we built a custom module that was inspired by migrate that just reads that JSON, parses it and adds new nodes. Because the entity API inside of Drupal 8 is so nice to create new nodes, to create new entities. It was a matter of four hours programming. So that was the best. And we only migrate block posts and block post authors. So we said, okay, everything that we don't really need, we can create by hand, and we only migrate what we really, really, really need. And that's a block post. Back in development, the problem is that a lot of examples are broken. So everything that you Google around and like two or months old block post that somebody says like, that's how you do something is most probably broken. So the example module is sometimes also broken. So what we did, we took easy modules from core and looked at them, how do we build? And we take them over because they work mostly. So we took them, looked at them, figured out how they work and then figured out how our start should work. Yes, and there was a really interesting one. The debugging was super hard because the theme render cache which you can disable was not, that didn't work. So like every time you change something, I took like clear cache which took like really long but that's fixed now. So and yes, that was good. So overall, it works. We have a running website. We had it on Drupal's eight alpha. We had a lot of Drupal eight issues created. So we found a lot of stuff that I could never have found before even in multi-lingual where I'm really heavily involved. And my theme isn't backend developers don't wanna go back. So they say like, let's do all the sites nine Drupal eight and I have to tell them that's not possible. Because there are a lot of things missing but we are actually doing already some customer work for Drupal eight. I think it just depends on the size of the project that you wanna do. If you wanna do organic group stuff that's probably not gonna work but if you just need a normal website with like, hey, that's we are, we have a small block, that's really nice. And I also think you all should start, especially now with beta one. So you don't have to do that endless long 16 hour stuff. So I think go out there, try it out, figure it out, it's really nice. It's fun and it works. That's it. Yeah, I don't think we have time for questions or if the REC space is the REC space person, do you? Good, okay, I'll give you the stage. But if you have specific questions come to our booth, I should be around there. And yeah, just ask me, we'll be there. You can talk on yourself for a couple of minutes before I get this set up. Infrastructure, it shouldn't take too long. Okay, we're all set. So just by way of introduction, my name's Mike Bainbridge. I am a Solutions Architect from REC Space Hosting. I've been working in the IT industry for over 15 years and in the last three years in hosting with a particular focus on e-commerce and high performance website infrastructure. So one of our marketing guys put together a list of things I should talk to people about today for how you put together a high performance site, but I'm not gonna read all that out. I'm summarizing that into some short points. So today my short talk for you guys is really gonna be about understanding e-commerce and platform sites, how you can get the best from a hosting company and how you can deliver a rich customer experience through infrastructure to your end customers. So it's all about how hosting can deliver great customer outcomes and at the end I'm gonna talk a little bit about REC Space specifically what we do for our customers. So the takeaway I want you to all have from today is how to get what you want from a hosting company. So I do realize a lot of the focus here is developer based. Really hosting underpins everything you need to do to host your site. So is there anyone actually in here who has an infrastructure background or works in hosting or anything like that? Because there's a big secret, okay we've got one person, there's a big secret I wanna let you all know from people who work in the hosting industry. So before I go any further I wouldn't let you know hosting is boring unfortunately. So if you're here looking for a really interesting talk about infrastructure and deployment I'm afraid you're not gonna get it. I do have one caveat for that. Some of my colleagues are in the room so when it's done correctly you really shouldn't know that hosting is there. You really shouldn't be aware of what it does. So at REC Space people don't ring us up and go, thanks guys. Sorry, could you, okay. So yeah, as I was saying at REC Space no one rings us up and says thanks guys we had a great day of hosting today. Really good work, keep it up. So it's becoming a lot more and more commoditized. So like when you take a bath in the evening you don't ring up the water company and say thanks very much. The water was great today. People just expect it to work. People just expect it to happen. So who are the customers of hosting companies? And maybe I could just get a quick show of hands. Do we have business owners in the room? Any business owners, development partners, development houses, marketing departments? So all these people are customers of hosting companies. Hosting is really important for what you do. And when I was putting this deck together I was thinking to myself what do customers really want? You know, are they after SLAs, uptime guarantees, you know, performance metrics? And then I took that actually a step further and it's a lot more about in an online world getting your customers to spend more money, having a better customer experience and really having that customer stickiness. So particularly in e-commerce the key metric is conversions. Getting your browse customers to turn into paying customers to put things in the basket and make those transactions. And you know, in the content world it's the same. So getting browse customers to interact in your community and play an active role in that. And what's really the key that drives that is customer experience. Having happy customers is really important. And if you're hosting a content site or a brochure site as opposed to an e-commerce site people who visit your site are customers. So getting that mentality of what the internet is about and what these people really want from your site is really important. And I was doing some research. There's a really key statistic between the difference between new customers and existing customers. It makes this customer experience piece really important. And that is on average new customers cost five times more to market to get to your site than existing customers. So if you treat your existing customers really well there's a lower cost of getting them back to your site. It's really important. So there are four key points that I want to present today to help you have better conversations with hosting companies and really help you be able to deliver this great customer experience for your customers. So whether they are e-commerce customers or whether they're just taking services from you or viewing content. So the first one and the most important one perhaps is speed. Speed is the king. Performance is the ultimate goal of a website. So Google uses speed as a metric to rank how your site performs. They rank you against your competitors as well. So if you perform better than your competitors your search results are better. There's a correlation between PPC spend for marketing and a real return on investment for having a faster performing website. And if you have a faster performing website then it delivers a better customer experience means your customers will be more engaged with you. Whether that's putting things in the basket for an e-commerce customer or interacting with your community. So no one really likes to wait. And Google, one of the drivers for making these performance metrics is they want to make the internet a lot more relevant. So we have 4G mobile now, 95% of homes across Europe have this high speed broadband. People are much more likely to want that better customer experience. So I looked at a couple of statistics to show this. 40% of online customers or online audience expect a web page to load in less than two seconds. And of those people who come and visit your site 40% of them will abandon your site if your website doesn't load within three seconds. And by way of comparison I looked at what these statistics were around three years ago. And the numbers were double so of four seconds and six seconds. Customer expectation is increasing. People are getting, expecting this improved performance more and more. And I did some research into some of this conversion optimization, what it means in real world numbers. So I went on the ShopZilla website. They had a great case study about how they improved their page load time. So initially it was around a six second page load and they cut it down to 1.2 seconds. And I was on the site last night just to check these stats out and see if what they were saying were true. And I'd encourage you to go onto the ShopZilla site. It loads lightning fast. You can find what you want really quick and it's a great experience when you go on the site. In fact, I remember when you type in the webpage loads like wow that loads really quickly. And actually they've got some real world numbers that equate to how their increase in performance helped their site. So in real terms it meant a revenue increase of 12% and their page views increased by 25%. So there's a proper link between performance and this customer experience. And how can hosting companies help you deliver on this? So I use what I call the Bicycle Analogy to explain this. And it's about optimization, understanding the stack you're deploying and getting the hosting company to really understand what you can do. So deploying caching layers, understanding your bottlenecks between database and infrastructure. So the Bicycle Analogy I use, so this would be a standard hosting platform, unoptimized, it'll get you from A to B but it's not gonna be a very comfortable experience, it's probably not gonna be very quick. Whereas if you go on an optimized stack, something a lot more tuned to your application, then you get a much better performance. So the first takeaway I would really like you all to think about is speed. So performance is the key, remember that and I'm gonna cover it again the end in case I didn't get the message too enough. The second point, accidents happen, uptime. This is something hosting companies used to talk about a lot in the past but it is still really important. And what is the key underpinning of having a great uptime number, having your site online? It's a great solution. So if your site is online more, your customers can visit and you'll get, again, a much better customer experience. So designing a solution that understands your business requirements, no single points of failure throughout, you know, redundant hardware, load balance front ends, is also really important and your hosting company can help you have those conversations. Now, not everyone has huge budgets to spend on their infrastructure. So I've worked with large UK retailers in the past, companies like Debenhams, like Waitrose, like Harrods, who you would have heard of and these customers have huge budgets. They spend hundreds of thousands each month on their hosting infrastructure. They deploy across multiple data centers, they have no single points of failure, full redundancy and they test their DR plans, they test how this failover works. But not everyone can afford to do that. So when you have these conversations with your hosting company, they should help you be able to assess the risks. They should help you be able to understand that. Sometimes things will go wrong and you should also look at the support level you get from your hosting company. So I googled online server support last night and these chats popped up and having a great support team is really part of that as well. I mean, there's certainly the sort of people that I know we probably shouldn't say this, but we hire people like this at Rackspace. We have experts to deal with the infrastructure and deal with the support side of things. And I've got a really good example of this. I was working with an online retailer called Edinburgh Woolham Mill in the UK. So they had their first major online sale in 2012 just before Christmas and they really weren't prepared. They didn't know what they were doing and infrastructure wasn't sufficient for the traffic they were driving for their TV campaigns. And the day of the sale at 6pm when all the traffic came to their site, the site started performing badly, users dropped off, they were dropping sessions. It was a real disaster. So they got in touch with us and what would normally take three to five days to deploy additional hardware to do additional configuration to their site, the support team worked through the night, real pooled a 24 by 7 shift. So the following day that infrastructure was online and ready for them. So in your engagements with your hosting company not only is it about performance but uptime is vital as well. And think about if you can't deploy a fully redundant and scalable infrastructure what would happen if something goes wrong? What would happen if something does go wrong? What would it look like to replace a firewall? How long could you be back online for? This is the second important takeaway I want you to take. So thirdly, I want to talk about planning for growth. It's all very well designing infrastructure and having a site that will handle your traffic loads at the moment. But most traffic on the web, most e-commerce customers, most site platforms are taking more and more users every day. Everyone's growing. So to be able to handle that growth and provide a great customer experience you need to be prepared for it. And again, I was looking out some statistics around e-commerce and the Capgemini online retail sales index throws up this 18% growth figure. So this was just for December 2013 compared to December 2012. So the actual number grew from 9 billion euros to 11 billion euros in the space of one year. And that's across the whole retail industry. And actually if you talk to a lot of pure play sites people talk about 100% growth, 50% growth. And one of the development partners who we worked closely with I was talking with the other week and said, you know, what does growth of your customers look like for these online landscapes? They said most of our customers have 50% plus growth desires. They really want to grow at this level and they're hitting those and actually achieving them. So understanding what that growth looks like and how you can deploy that is really important. And no hosting presentation would be complete without someone putting up something about cloud or mentioning cloud. So we can leverage cloud products to really help that front end growth and really give you an environment that helps that growth. So the third takeaway I would really want you all to think about when you have discussions with your hosting provider is growth. Not what you're doing now, not what you're doing today, not what you're doing in six months time, what you're gonna do in 12 months time. And that there's a path for that growth and that the hosting company will understand and be with you for that growth path. So the fourth point I wanna talk about today is traffic peaks. What happens when you get the unforeseen surge of traffic? What happens when you get the celebrity mention on Twitter or when your product is featured on the Oprah Winfrey show? So understanding the traffic flow is really important and this is one of the key things that a hosting company should really be able to help with. So I work with an online golf retailer and they have four peaks every year and these are after the four major golf championships. So they retail the clothes, the clubs, the bag, everything that the winner used to win the golf championship and that's when they have their huge surge of traffic. Not everyone just has a surge around Christmas so understanding when the surge of traffic is gonna happen is vital. And the biggest enemy for all these online retailers really is themselves, the marketing department. The guys who decide it will be a great idea to run a TV advert without talking to the infrastructure team, without talking to the IT team. So a joined up discussion with the marketing department, with the IT department is really important and as a hosting provider we can help leverage that. And the other thing I like to talk about when I talk about traffic is really something we call hosting for the peak. So this is a typical Alexa traffic graph of an online retailer. I'm not gonna say who it is but this is a fairly typical surge just before the end of the year when it comes to Christmas, when it comes to sales. So typically you have to provide infrastructure to be able to host at this peak of traffic when in reality on a day to day basis the traffic's fairly low. So what we look to do or what a hosting company should look to do is to really provide ownership of this lower level of the hosting environment and then be able to rent the peak. So you're not spending additional cost on something you don't need all the time. So it's having that joined up discussion understanding when the peaks of traffic come and what you can do to do it. So at Rackspace we work with Domino's Pizza, they're one of our big cloud customers and it's a really interesting story. I mean they host twice a week sales on Tuesdays and Thursdays. They do a two for one offer with their customers and it looks exactly like this twice a week so they burst into the cloud for Tuesday and Thursday evenings and it really allows them to have that high performing content for their site, that great customer experience and it's a key part of their business being able to handle this additional traffic and not be able to pay for all the infrastructure at that time. So the fourth takeaway is really understanding peaks. So Rackspace are a sponsor at the event. They told me not to make this too salesy, this discussion about Rackspace products and services but it wouldn't really be fair. I think we're sponsoring one of the events later on today if I didn't talk a little bit about what we do at Rackspace and why we're better. And maybe this'll give you some understanding of what we're doing in the industry and if you have those discussions of your hosting company, maybe the sort of things you could expect for them. So I promise it's not gonna be too salesy. I do have a technical role at Rackspace so I'm not just a sales guy. So first of all, we share customer insights and this is a really important part of the thing we're doing in our digital and e-commerce practice areas. We understand what our customers do. We understand when their peaks are and we help solve those problems. We're active participants in the community so we really wanna understand what developers' difficulties are, what we can do to help commerce customers grown and we've developed these practice areas at Rackspace so there are three particular ones that are probably fairly relevant. So we have the digital and e-commerce practice area which really focuses on digital content management and e-commerce websites, very similar problems and very similar types of customers. We also have a data storage practice which focuses on the area of big data and we have a DevOps and automation practice who really engage with our customers and look about how they can do this great level of scaling and how they can plug in infrastructure requirements to business process to make sure sites perform as they should. So this participation in the community and really understanding what's going on is key and that's why maybe it's not a great story for infrastructure people to be at Drupal Con but we wanna understand what problems people are trying to solve with infrastructure. And one of the problems that we really wanna solve for our customers is around load testing. You talk to business owners about peaks of traffic for Christmas, for New Year, how many orders they're expecting. Everyone knows they're like, we're gonna double our turnover in December this year but then when you ask them how many customers can your website handle concurrently at peak? Checking out through your system, actually using the resources. It's surprising how many of them don't know and we're talking to my colleagues, we'll put the number around 90% that the head of e-commerce cannot tell you exactly how many customers they can handle. So what we look to do is have these joined up conversations with our customers before they launch the platform. Load test it, before you go live, put the code on the infrastructure, test it, see how many users you can handle. And then it's about deploying the right tool for the job. So I mean you probably, well I'd like to think as well, when you think of Rackspace and I'm sure you all do think of Rackspace on a fairly regular basis, you think to yourself, they're a great cloud provider. So we have infrastructure, we have cloud, we can deploy them in a hybrid model as well. So it's really about getting the right tool for the job for our customers. And then selecting experts. So we are infrastructure experts. We host over 200,000 different customers and across that it's over a million websites. So if you've got a problem with infrastructure, if there's a problem you're trying to solve, we've probably done it before. We can bring those customer insights and help solve your problems. This is what having these practice areas is really all about, having this joined up conversation and understanding how we can help solve business problems. So the best kind of customers who can come to us are ones who don't know what they need to do. They've got a business problem, but they don't know how that translates into infrastructure. And that's where we can really offer some great expertise by solving those problems. So you know, we're not just a company with a sales guy, with a solution engineer who would typically come out to understand what you do for your hosting. So you get these, this joined up team of people, so you get the service delivery manager and the engineer. But then behind the scenes at Rackspace, due to our scale, you know, we have all these other functions, all these other roles to help deliver the rich customer experience to our customers. And not only that, but it's really backed on some industry leading partnerships that we have across the community. And it wouldn't be a Rackspace presentation unless someone mentioned fanatical support. Fanatical support is something we do. It's very difficult to translate to people who haven't had a chance to experience it. So this is the point where I typically ask you if anyone's a Rackspace customer in the room, half a dozen people raise their hands and say, yeah, they're really happy with the service they get. But what does fanatical support really mean? So at Rackspace, we love to engage with our staff, make it a great working environment, and then we find they deliver great customer outcomes for our customers. People actually care about what our customers do. And that's really is a differentiator for us. And you'll see this message, it's on the slides there, the number one managed cloud company. So we're not just an infrastructure provider, like say Amazon or Microsoft Azure or Google, we provide the extra level of service around that. We'll support the application infrastructure. We'll do the OS patching and we'll really be with you every step of the way. So when I think about what fanatical support means and when I ask our customers what they think it means, it really is that we're in every step of the way, that we're there to make sure that your online platform performs the way it is and helps deliver these great customer experiences. So just to sum up then, I can see I've lost a little bit of interest from the people we're here earlier. So the takeaway I want you to get from this is, is how to get what you want from a hosting company. So the four main things, and if you're taking notes I'd really advise you to write these down, speed, uptime, growth and peak. If you have those four conversations around the things I've discussed today, then you won't go far wrong and maybe it doesn't really trip off the tongue so I put together a simple acronym that you can all remember, SUGPA. So I'd take a note, SUGPA, really important when you're having your conversations with the hosting companies. And then just by way of summary, it's not about being successful and I looked up a definition of success as getting what you want. Interactions with your hosting company should also give you that happy warm fuzzy feeling. This is what we want, this is what we want to try and deliver as an infrastructure provider. So it's not just being successful but it's also being happy and having those great customer outcomes. So that's pretty much it for me. Does anyone have any specific questions they like to ask around infrastructure? He said expecting the answer no. Yeah, so at Rackspace we really don't offer a platform for Drupal as a service. So there's other providers here who do a specific platform for Drupal. We really support up to the application infrastructure. So we'll support Apache, we'll support Nginx, we'll support Caching, we'll support Varnish, Memcache, Reddish, we'll support MySQL as well. We'll support the infrastructure that the application sits on but we're never gonna be developers. That's not our core business. We're never gonna develop the website or deploy the content and that's what you involve a digital agency for a solution integrator. And we work really closely with lots of partners to help deliver these solutions for customers. And a lot of the time we get customers come to us and ask us to make recommendations. So working with a large number of partners, Drupal partners, Magento e-commerce partners, Microsoft partners as well, we can really help make those introductions. Anyone else? Thank you very much.