 Hello and welcome again from me at TU Berlin. We, the TU Berlin, are now next-clouders. Thank you. Sorry for those who saw my talk yesterday. Some slides are repeating, but this is just a smaller one here today. Just a lighting call to who is the one who are interested in the whole story. Just watched the movie from yesterday. To make it short, we started evaluating sync and share systems in March 2012 because we wanted to give an alternative to Dropbox and Co. We just learned the reasons why that is a good idea. And we made the role out of on-cloud 5 for about 40,000 users in May 2013. This is the architecture of our next-cloud infrastructure now. This is a normal big installation with several web front ends, with a Galera proxy and Galera cluster, and we are using GPFS as a cluster file system at the moment, and 5 big IPs, so you can imagine what we had to do for the migration. What we migrated were 22,000 users. 10% of these users are active daily, at least. We have 100 million file cache entries in our database at the moment. We have about 70 terabytes of data, and we have 100,000 file changes a day. We are hosting 17 other universities and institutes in the framework of the DFN cloud. It was not just Theo Berlin who migrated, but the whole hosted instances too. Our migration went from Apache 2.0 to 15.0 to NGNX 1.10.2. We upgraded the PHP versions. We migrated the Shibboleth module from the Apache 1.0 to the next-cloud app, which is really better for us to debug and so on. We migrated from NGNX 9.10.4 to NGNX 11.03. One of the results was a very low load on our database clusters. On NGNX 9, we had the loads on the left side here, and two weeks later, with the same users, the same circumstances on NGNX 11, we have much lower load on these databases here. My lessons for you, the developers, after this migration also have big installations in mind. That means test the scalability of your code. For example, we have 50,000 LDAP entries. I think it's just possible to test software with 50,000 LDAP entries. You can generate some random stuff in an open LDAP. That's not really a problem, but have a look at what happens to your app when you have this amount of entries there. For example, try to make larger file cache entries. We have 100 million at the moment. Maybe it's a little big for testing at home, but try bigger amounts of data and test this. If you make SQL queries, think about making them less and cheaper, because as you saw on my last slide, this is really important for big installations. Another important thing for us who make these big installations is the possibility of disabling functions. That means we need less dependencies in the modules, because first of all, we have to integrate this in our infrastructure. Sometimes it's not possible to duplicate some services, so we have to disable one part of Next Cloud to integrate it in our infrastructure. This is possible because it's open source and we have control of the code, but just make it easier. Sometimes it's not permitted by law to enable one or other feature, so it should be possible to switch it off. Sometimes you want to make combinations between different products, and again it is important to switch on or off the one or other feature. That are the lessons, and I thank you for the great code that is already running here and serving so many users here. Thank you.