 Yeah, coming to more like a customer story from my public, I'm talking about what we are as a company, then looking a bit in the past and the present and in the future. My public, as most of you will know, is a Singapore company, a fibre broadband provider in Singapore. We have our headquarters in Singapore, then weaponry expanded to New Zealand, Indonesia and then also in Australia. So we are delivering internet access to the customers. In the past, we actually had like our local domains, like for example in Singapore, we had our mypublic.com SG and for simplicity, I just included Australia, mypublic.com AU. So we have our user base in the country, then we had like cloud-based infrastructure. So for example, local answers in AWS and then our region, which were Apache two web instances. So pretty simple with country-based domains. Then looking into a bit more unified user experience would be that we have like providing one domain, and not country domains anymore, so we did actually move to mypublic.net. So the same concept as like for example, Apple, where in the US you visit apple.com, then you automatically get redirected to our apple.com SG. If you're visiting it within Singapore, it's actually going to apple.com SG. So the same concept we wanted to implement. So we went to AWS, get our GOD and set up in world 53. So the same concept, the user in Singapore will be identified as Singapore user going to the region based in Singapore. So that's the past. Okay. So then the edge case would be that a user from Australia for example is travelling to Singapore and still wants to order their fibrebop and internet. So how is this going to work if my user is in Singapore, goes to my region in Singapore, and then sees the Singapore website. So our solution was to have Modproxy implemented. So the user is still getting to our local end on Singapore, goes to the Apache, which then proxied back to Australia. And then the region will be in Australia serving actually the slash AU request, which is not a very pretty solution, but it somehow worked. So just a quick overview about the solution at this whole. We have a rewrite rule for slash AU to make sure that it's always with a trailing slash. So you have slash AU slash, then you configure proxy path based on slash AU slash, redirecting it to the local answer that we just saw within Australia with slash AU slash. Then you define the proxy path reverse. And you also said proxy preserve host so that mypublic.net will always be preserved along the proxying. Now the question is obviously what's the disadvantage. And somehow you have overhead now proxying between countries. You also have a single point of failure. So what happens if the user is in Singapore, the Singapore site fails, and then it can't be proxied to Australia. You're adding latency, and then it's also kind of hard to troubleshoot. And the other big, big disadvantage is the whole SSL proxy engine, because now you have two Apache instances need to trust somehow each other. So how's the trust going to work? Are you a certificate pinning for SSL? Or are you allowing only certain CAs? Are you trusting based on the certificate lifetime? So a lot of questions you have to figure out with this proxy engine. But the advantage is it works, I guess. So where we are now, so now we're having our users in different countries. We have the big black box from Cloudflare. Then we still have our origin set up based on the local lenses on Amazon and then our Apache instances, one or multiple, of course. So now we're looking a bit more into the black box of Cloudflare. I'm not listing all the services we are using as my public, but I'm using just for example a few. So one important one, obviously, we're still having the GOD NAS to identify our customers from which country they are actually accessing. We are using all the pretty, pretty edge locations that John previously talked about to identify where the request is coming from. Then we're using page rules, which is actually pretty cool because it's completely web server-less. So we don't have any load on our web server anymore. Now it's all handled by Cloudflare. So what we saw previously with a slash AU, goes to a slash AU slash, that's the forwarding rule. On the edge location and then doing a simple resolve over wide, which is actually replacing the DNS answer packet, which is a pretty convenient solution for us. Then of course we're using the web application firewall, wait limiting for example if you have a content management platform and want to somehow protect them, your login page from various bad guys, so that's what the wait limiting is for. Also the zone lockdown pages that are not supposed to be public and only reachable from certain IP blocks, can be configured by a zone lockdown. And then the obvious caching and speed, what the whole CDN portion is actually for. You want your answers to be fast delivered from Cloudflare and also improving the speed in making your CSS smart, optimizing your JavaScript, compressing your images, so all the pretty CDN portions. Talking a bit about web security, and I think that's the most important one in our days where we are currently living in and starting a bit from the DNS portion. So what happens after you port your zone over to a CDN provider like Cloudflare for example, so it's really easy to get DNS enabled. So before you had really to configure like zone keys and all the stuff in your DNS and your bind or whatever. So that's really becoming easy. You just one click, you copy and paste it to your register and then it's like done and you're forever protected for DNS poisoning, cache poisoning and all the stuff. That's really easy. The other thing is always use HTTPS. It's pretty convenient as well. Before you had like writing rewrite rules to actually replace all your HTTP queries to then get a 301 or 302 to HTTPS. So that's all being done on the edge locations already so you don't need to take care of this part anymore. And the other cool stuff is also to automatic HTTPS rewrite. So actually the CDN goes in all your HTTP responses and just plainly replace HTTP to HTTPS. So it's already in your source code replaced. And then of course the whole HSTS setup. So some of you might know what HSTS is. Some of you might not. So HSTS is basically the domain is telling you to never downgrade the security. So if you ever go into an environment where the middle could actually intercept your HTTPS traffic and then downgrade your HTTP, then all your traffic would be vulnerable, for example in a typical hotspot environment where you don't really trust the provider. So that's really bad. So with Cloudflare it's just a click and then they're actually taking care that HSTS are set and your client will then never allow HTTP anymore. So then you can also set the max age. So for how long will your client remember that it's not downgrading connection? You can say if it's applicable for subdomains or not, you can opt in for the preload list within Chrome and the other browsers, for example, and also set the no snuff adder so that the Internet Explorer, sorry, is not mind sniffing away from your content anymore. Then the other really cool features are actually that Cloudflare is providing a lot of beta features. So if you just want to try it out and give your clients the latest TLS, for example, and this example of 1.3, and then you're just even more secure and providing your client something that, again, you don't even have to configure on your end or compile open as I'll link it. You don't even need to take care of this part anymore. A bit looking into the future. So one of the newest projects Cloudflare is actually working at is Spectrum. So where they came from was actually just looking at HTTP and HTTPS and then doing all their DDS prevention and all the funny, funny stuff. But now they're also looking at plain TCP connections which are not terminated, just proxied playing through Cloudflare and then doing all the DDS prevention on their edges again. So that's something we definitely are evaluating currently and looking into. The other thing is really at the moment, Cloudflare is having cooperation, I guess, with Komodo to provide Komodo certifications at their edges for all the hosted sites. And for the future, we really look forward, actually, for them to implement a bit more of Let's Encrypt. So I think I'm talking a bit about Let's Encrypt. Some of you might know what Let's Encrypt is. Some of you might not know. So actually, Let's Encrypt is really cool because it provides your shorter certificate lifetime. There's one thing. So all certificates have a default lifespan of 90 days. And that's important if ever your private key is getting compromised or lost or anything, at least with a shorter lifespan. You're not relying on revocation lists or anything like this. And the other thing that is fully optimized who will issue a process and renew a process based on ACME standard, it's an open certificate authority. So it's actually a non-profit organization behind Let's Encrypt, highly funded by the EFF. And yesterday, I looked it up, it was like more than 70 million active sites. So, and there's no known breach or whatsoever on Let's Encrypt rather compared to providers like Komodo where we knew that they actually lost some private keys here and there in the past. The automation part for what we saw previously we were using like Amazon throughout 53 together with elastic load planters and there's actually a project on GitHub provisioning the whole certificates to the load planters and doing the ACME challenge via DNS. So actually you're just providing your Amazon API keys to the Let's Encrypt AWS binary and then the whole challenge, renewal, everything is like fully automated with this project. Because we moved our DNS from R53 to Cloudflare we actually contributed to this project and one of my teammates actually forked it and did a Cloudflare implementation. So now we are able to have with our Cloudflare API key the same seamless certificate issuing so that the ACME DNS challenge is being provided via Cloudflare the DNS keys are being generated then the certificate is being retrieved by Let's Encrypt, deployed and issued and after the DNS keys will be removed so if someone has like a similar setup and don't really know how to optimize then those are definitely the links you want to check out. That's a good slide of cooperation between Cloudflare and my public going forward if you have business in Asia Pacific and looking for a bit more growth then of course Cloudflare can like scale for you guys and I guess they have more edge locations in Asia Pacific on their work map as well so that's something exciting we're looking forward to to serve our customers even better more towards their homes as that scalability is one thing and then the same user experience you have just one unified dashboard and then it's just being provisioned in your edge location and you don't really care about yes that's my presentation Thank you very much Sebastian for that and now we would like to invite John back