As a critical care paramedic I attend the more high-acuity jobs, the patients who are life-threatening, who are sick, dying, medical, trauma, our range goes across the board. Those memories cloud across a whole heap of different jobs at the same time and so Christmas Day I guess you remember because it was Christmas Day and we shouldn't be unwrapping a body, that's just not what we're there for. But on those times that you have to you know any number of the jobs that we go to where you've got patients and trapped in vehicles or dying or you know deceased on the side of the road it's horrific, it's traumatic and we feel it the same as everybody else feels it. Every one of them will stay with me like every one of those patients and again it doesn't you know matter whether they're old or young you're still exposed to it and to put someone in that position it's just horrific. So the worst day imaginable for them for their family and then wants to come afterwards if they survive. The toll it takes on anybody it's it's lifelong memories it's that constant exposure to that and some people have resilience and some people learn resilience and doing the job for 27 years I've developed a level of resilience where you focus you do your job you fall apart later you know and I don't think there's any one of us that hasn't fallen apart because of the job or over a job or you know a trigger you know you'll smell something and that will trigger that complete memory to come back. My message for people at Easter at any time drive safe remember the fatal five I say it's not worth killing for it's not worth dying for get there safely another minute another five minutes on the road it's not worth being dead.


So, good morning and good afternoon everyone, and welcome to GitHub Commit at the QCon. My name is Icy Gigan Baruch. I'm a Senior Technical Marketing Manager here at GitHub, and I'm based in Israel, and I will be happy. This is my LinkedIn here, my LinkedIn account. Feel free to connect with me, and I will be happy to speak with you about anything CI and DevOps, and in today's session we will see a few demos. I will start first with the GitHub CI overview demo, and then my colleague Cesar will continue the next step, which is GitHub CD, continuous delivery and continuous deployment demo, and then Fern will complete with the DevSecOps demo. So, we will get three very, very cool demos. So, we will start with the first one, which is GitHub CI overview demo. So, in this demo, I will present three uses and three demo flows. One is for the developer, developer flow, the second day life of DevOps engineer, and the dev team needs. So, I chose those three personas in order to demonstrate a little bit about how GitHub can edit those three personas and how we can do how we do DevOps with GitHub. Once every day when you wake up in the morning and go to the office, you want to write this code. He likes to write code. This is what he knows, and he wants to make his application and releases as soon as possible into production. In order to achieve that, he wants that this code will be built and tested and get feedback as soon as possible, feedback on some bugs or feedback on some vulnerabilities that maybe he entered into the code or any compliance issues. So, if there are some issues, the developer will want to know that in advance they're not waiting a few weeks or sometimes even want to get a security, long security report with many things, while he even doesn't understand what it is, and he already working on another version of the code, and now we need to go back to the original code. So, this is what the developer wants, and let's see how the GitHub flow in this case and how the developer makes that. So, you see the GitHub screen, and I will create a new branch, and I will give it a name, and this is now my feature branch, and this is my source code. As you know, GitHub is a single application for CI, and version control, and CD, and monitor, and security building, everything in one application. So, currently we see the source code of my feature, and now if I return something, it will change only my feature branch, and I will not impact anything on the share repository, where is the main branch that goes to production. So, I will open from here my source code, and this is the file that I will want to change in this demonstration, and I will open the building web ID for that, and I will change this string to something else, and actually this is all the change that I do today, and I will commit this change into my branch, and I will add a commit message, and I want to commit it to a page up, and this is the branch we just created. GitHub offers me, by default, to start a new merge request, so I will accept that offer, and I will push the commit button, and the new merge request just opens for me, and by default the title is my commit message. I can assign the merge request to myself, and I will submit the merge request. So, what is this merge request? So, now I'm requesting to merge my feature branch into the main branch, and this will go to production, to our end users, and so merge request is like a form, requesting something, to merge something into the main, and in order to make sure that there are no vulnerabilities in it, or no compliance in it, we can treat the merge request as the quality security and compliance gate into production. So, via the merge request we will validate via other reviewers or stakeholders that what gets into the production should they get into the production, and if there are problems we will not merge into production. And if you notice here, this icon means that a new pipeline already started because I just committed the change, and this is the main thing of CI. For any change you will run a CI pipeline, so in GitHub it automatically you don't need to configure anything, as long as you when you commit a change, you push a change, the CI pipeline automatically will be started. I will click on that and it will open for me the pipeline graph of my CI, and the CI first will build my code and then create a document image in it, and push it to build in container registry. I will open the container registry and we can see the new image for my code that already pushed in the container registry. I click in and I can see the image tags of my change. I will go back to the pipeline to see what else we have here. So, we build the code and then I added a stage and a job to build for me a testing environment, and then another job to ping this environment just to validate that the environment is great. And then I added many tests, like quality tests, container scanning, functional tests, license scanning, mobile tests, impressions, and more tests in that. The next stage is the review. The review is to really deploy my feature branch, my code into Kubernetes, and then I will have a live preview of my code. In this preview, I will be able to send to my stakeholders, like designers, product manager, QA, everyone that are part of the review process will be able to see live instance of my changes before it goes to production. And because we have this review application, we have live instances, we don't have to just do static scans on the code. We're also running dynamic application security testing and even performance testing on the live preview of my feature branch. So, as you see, I just pushed the change and I will get all of that after a short time. It can be minutes, maybe a few minutes or 10 minutes. I can get feedback of my change. And this is the idea. For every change that you will make and commit, you will get such feedback. Now, I made my change via the default Web IDE, but developers usually like to work with their local IDE, which is great. And in that case, you will get a notification in email about the pipeline status. In this case, my pipeline is green. And I got the notification on that. But if I would get the error, I could see here a red pipeline. And I can from here click and get into the pipeline graph and see what is the failing job. I'm going back to GitLab. And I will go back to my mail request. And as you can see, the pipeline passed. On the right side, you see all of the pipeline stages, which is great. All of them are green. All of my jobs are passed. So I'm great. I'm in good shape. On the bottom of the page, you can see in the mail request, all of the test results, you see there are no changes to the quality, to the quality, which is great. You see the result of the browser performance test metrics can expand those reports, those results and see some metrics about the performance, according to what I defined in the test. I can see that there is some security vulnerabilities in my code. It's not because of dust change, because previous changes, we have some vulnerability in this Java code. And also, we got the license compliance. We didn't add any library, but the license scan scans all of the external libraries that we add and make sure that the license that developers adding in their code doesn't bring licenses, introduce licenses that are not approved by the company policy. And you can define it in GitLab, which license are approved and which licenses are rejected. You can see here, click here to see from here. You can see here a full report of the licenses detected in my code. All right. And so the last nice thing here, this button, which is very useful, we use it from GitLab always. This is the review application. So this is also in my mail request. I click here and I can see the preview of my application, which is deployed to Kubernetes. The link is external. I can send it to anyone. So after I've seen that everything is okay in my test, I reviewed the application. Usually, the best practice is to assign a reviewer that will review your code before you click this button, the merge button. And then other tabs, interesting tabs in the merge request is the commit tab, the pipeline and the changes. The changes shows you all of the code changes and the reviewer used that to edit their comments in the merge request in this tab. So once the review process passed, the developer can click the merge button and now it's called those into the main branch. And with the continuous delivery, hopefully it will go to staging environment and at some point it will deploy to production and deliver it to the end users. The developer now, happy can go for a break, for a coffee break, or he can go to the next feature that he wants to deliver. And so this was the developer of flow and the main flow of the developer. And now the CI helps him to make it very easy. Without context, which to other applications, we need to enter another logins, everything comes in a single flow and flow for the developer. So with that, I return to my colleague, the DevOps engineer. And the DevOps engineer's job is to make sure that everything is working. All of the CI is working, the organization, the developers can do their job to develop to develop application and they don't have any CI blockers and they're responsible for the cloud. So they're lucky they're using GitLab. And GitLab is a DevOps platform that built design for doing DevOps and CI CD. I will start with the CI CD configuration. So by clicking here, we see the CI CD ML file. So in GitLab, the CI CD configuration is done via code, which has a lot of benefits. And this is the example of a CI configuration file. So let's see what's existing. First, it starts with the global image. So this image will be used globally in each job, unless a specific job, in its definition, specify other image. And those are global variables that we can define for all jobs. And the definition of the stages and the order of the stages. So this will be the order of the stages and you can add or remove any stages that you need. And here you can include some templates. So in this example, those are built-in templates that they shipped in GitLab with templates for build, test, code quality, deploy, dust, container scanning, some of them used in the example of the developer. But you can also define your CI template and then users will be able to include them on their ML file. And those are some examples of jobs. Let's together add a job. And the job name is test26. And here I define the different image of it. That's mean that the runner machine, when it starts this job, first it will go to the Docker Hub. We download this image and that also we download this service and then it will run this script inside the image. So all of the jobs isolated. And the other benefit is that I don't have to install any build tools on my build machines because everything is inside the image. So the job is clean and when the job completes, the image removed from the runner machine and this way it's secured. We allow permissions to developers to change these configuration files. Of course, we can define a limited to specific people. But in our organization, if we want that we want the developers to be able to change this code in order to, for example, to add a test environment or change something in the CI configuration. So they will not be dependent on DevOps engineer or a specific person that will make those changes. So they can make the changes themselves and I'm as a DevOps engineer because it's on the code can track those changes by going to the commits and see all of the changes and the changes and when and what was the change. And if there is any configuration issue, it will be easy for me as a DevOps engineer to fix that and bring the system again quickly. So we discussed about the CI configuration, but how the jobs run. So I will open the CI CD settings and the runner configuration. So the build machines in GitLab, we call them GitLab runners and we have a few types of runners. We have specific runners that you can install on your prem locally and then you can enable them for your project. So for example, if you have you have in it for a Windows runner that connected to a mobile device, for example, so you can install this system and define it as a specific runner. And also you can add tags to those runners and then in the YAML file, you want to specify those tags and the job we pick only this runner. There is another option also to use shared runner on GitLab.com. So the runners will be on the cloud and it will pick a runner machine for you. Another benefit of the GitLab runners is the support auto scale mode, which means that this is the elastic way that we provision build machines on demand and we'll make sure that always developers will have a build machine available. So they will not have to wait in the queue for free build machines. So whenever there is a demand for machines, the system will provision machines with runners and then after a while, if there are no other jobs, they depend on the idle time they define in the configuration, the machine will be removed in order to save resources. So we a little bit understand how we configure the jobs and how the jobs run via the runners and for me as a DevOps engineer is the upgrade of the system because GitLab comes with a single application, single installation for all of the components, issue tracking, version control, CI, CD monitor. So when I need to upgrade something, I will just need to check if it's, if I'm using the Docker installation, for example, I need to place two Docker images and that's it. And once I replace those images, upgrade those images, it will upgrade the entire system. I will not have to handle the different applications and the integrations and to worry that something will break after I upgrade the one component and upgrade one is a single installation that everything, it will upgrade everything from it. And by the way, GitLab release, new version every month, every 20 seconds of a month we have a release and you can Google GitLab releases and see what is about all of those releases, which release comes with a post about all of the features. So and with that I will both to give the honor to my colleague, the dev team leader. So as a dev team leader, my job is to make sure that the team is productive. There are no any blockers and if there are any blockers, I will make sure to address them. So I will show you some reports, some analytics that I'm using. So what we see is the pipeline charts. And this shows me the productivity of the team. It shows me overall pipeline, what is the successful pipeline and the failed pipeline and the success ratio. And I can see pipelines for last week, for last month or even for last year. This report helps me to understand how the team is doing. And I see that the success ratio is good. Most of the pipeline are green, which is great. I hope the team will continue this way. Another useful report is the value stream analytics. Every organization wants to make the cycle time shorter to release the code to production to the end user as soon as possible. With the value stream analytics model in GitLab, we can show how much time took for each of the table stages, like planning, coding, testing, reviewing and staging. Because in GitLab, everything is a single application, we have this data. So we can analyze that how much time it took and you can even drill down and see which issues or mail requests were involved in each stage and if you find any bottleneck, you can understand where it is and try to fix that. Once you fix a specific stage, it will impact the global cycle time. So this is the value stream analytics. So the last report that I want to highlight and later on will deep dive into security, but I want to complete because as a dev team lead, we want to release fast, but we want to release without risk, without any vulnerabilities. So I will be using the security compliance dashboard to make sure that there are no any vulnerability in my dependencies and also make sure that the license compliance and all of the compliance issues are addressed so we are good and we don't do something that we are not enough. So with that, I conclude my part and just to quick recap before we move to the second part. So we've seen here three personas using GitLab. The first was the developer that created the code change and run CI pipeline, got all of the results into the merge request, reviewed the application with these colleagues and merged this code and was very happy to merge it to these users. Then we met the DevOps engineer that showed us the CI ML file where we can configure in a code all of the configuration of the CI CD. Also, we learned a little bit about the runners and that the upgrade of all of this system is very easy and we will get every month a new version of GitLab. And last we met the dev team lead and he used some analytics to measure and make sure the team is successful. So I hope you learned something new about GitLab and try it yourself and with that I will stop and try to stop sharing. Please share your screen. Thank you and have a wonderful QtCon and commit GitLab commit. Have a great day. Bye-bye. Hello, can you hear me? I think I'm next, right? I cannot hear you. Loud and, yeah, you're loud and clear. Okay, good. So I can start my portion. Very good. So thank you, Isik. Can you, I'm going to share my screen first right here and you should see a slide with my face on it. Can you confirm, Fern? Yeah, you're good. Okay, good. Thanks. All right. So I want to start my timer. Thank you for joining this portion of the presentation. My name is Cesar Saavedra and I'm a senior technical marketing manager here at GitLab. If you need to get a hold of me after this presentation, you can reach me on Twitter on my GitLab handle or through LinkedIn if you want. If there are any questions that you don't have time to ask during my portion of the presentation. So what I'm going to be covering is just like Isik covered the CI portion. The main focus of that presentation was the CI portion of the pipeline. I'm going to be covering the CD portion of the pipeline. So that's a continuous delivery portion. And specifically, I'm going to be talking about and showing you progressive delivery through feature flags, which is a feature within GitLab. So as you saw some pipeline examples already that Isik showed you, there were many jobs in each of the stages. And I will be focusing, like I said, on the latter part of it, which is the CD portion of the pipeline. And it's basically all about and all the jobs and tasks related to how to release software to production at any time. Whether it's VMs, virtual machines, whether it's Kubernetes, whether it's bare metal machines, or any other type of platform that you have. So what is progressive delivery? Progressive delivery is a continuous delivery with fine grain control over the blast radius. This is a quote from James Govner from Redmonk. And it basically means deploying something to production in a very controlled fashion. And with the ability to control also who the audience is going to be for that specific feature, for that specific functionality that you want to try out in production. Not too many years ago, testing in production was a big no-no. The production or the system administrators will not let developers touch the production machines. That has changed in the last few years. With the introduction of DevOps practices, best practices also developers are allowed, not allowed, but are comfortable now to do some testing in production. And to be able to deploy to production, there are many different strategies. For example, there are deployment techniques called, for example, AD testing. There is blue-green deployment. There is rolling upgrades. There's also canary deployment. And in this demo, I'm going to be showing you feature flags. So feature flags is basically, this is before doing an after picture of what production will look like. But basically the before picture is showing that there's an application with version one that is running in production. And you want to include a feature. You want to roll out a feature to production, feature A and feature B. And during the rollout, these features will be introduced in a B2 version of the application. And then after you feel comfortable and after doing some testing possibly and some validation of the feature is working well, you can actually make it permanent and get rid of the feature flag so that the feature is available to everyone. And that's basically the after picture that you see there. There are many ways to roll out features within GitLab. One of them is based on percent rollout. So the idea here is that you want to roll out the feature to a small group of users or basically to a small segment of the audience. And then as you feel more comfortable with it, you can increase it all the way up to 100%. This is a screen snapshot. We're going to go through this in the demo on what feature flags look like. The definition of them looks like in GitLab. All right. So let's jump into the demo. So here I have a project called product manager spring. This is similar to an inventory. So you have basically a table that is going to have products in it. And many people will be able to access that table. And they'll be able to delete and add line items to it. And each line item is basically a product. That's what it's called product manager. And let me show you first the feature flags in action. And then we'll go back and review how you set them up and how you define them. So let's see what they look like in action. So this is where you would define the feature flags. There is a feature flag here called products in alphabetical order feature flag. Okay. As the description says, it's going to list the products in alphabetical order. And here it says that in production, so we're going to have now two environments in this project. We have a staging environment and a production environment. And we're able to define two strategies. In fact, let's just go into it and show you what it looks like here. So this feature flag has two strategies. The first one is going to be applied to production. And in production, what it says here is it's going to be a percent rollout. So and it says 50% of the users using this application will see this specific feature. And it's based on a available ID. And then in the staging environment, only the users listed in this list will see this feature, no one else. And the way to define this list here of users is you go back to the previous page and you would say view feature lists. And here I've created a feature list, which is called products in alphabetical order user list. Excuse me. And there are two users there, Michael at CFLR.com and Mary at CFLR.com. So only these two users will be seeing the feature in the staging environment, like it was defined right here. Okay. All right. So let's now see, let's see how this works in the staging product and the staging environment and production environment. So let's just go back to there. So here I have the environments for this project, product manager spring. This is the production environment and staging environment. So let's review the staging. We can do staging first. So in staging, if I remember correctly, only two people could see the feature. And the feature is going to consist on the products being listed in alphabetical order. And you'll see what I mean when you see the product list. So I think it was Michael and Mary were the only ones that could see the feature. So let's log in as Michael. Okay. Here, as you can see here, the product ID, and there's a misspelling or misspell word there, sorry, is, is the product number four is listed first. And the reason is that this name is, this list is sorted alphabetical order. So graphics card happens to be the first, the first one in the order. And then the rest of them come after that. So this confirms to me that Michael is can actually see the feature in production. So let's log in as someone that cannot. Let's log in as Peter. And as you can see, Peter doesn't see this feature. And we can tell that he's not seeing the feature because the products are not listed in alphabetical order. They are listed by product ID number. Okay. And just to make sure the other person was Mary, right? Okay. That could see this feature. Mary, like Michael, she's getting the the feature, which is the products are ordered by name. Very good. So that's in staging. So let's see now production. In production, the strategy was a little different in production. We have 50% of available IDs. Okay. So half of the users should get the feature and or see the feature and half should not. So let's go to production. And I've created six users. So let's quickly log into the six users and see who gets the feature and who doesn't. So the first one is Peter. I remember this is a different environment. This is a production environment. So Peter does not get the feature. Let's see magic. Magic gets a feature. Let's look at as Michael next. Michael gets a feature. Let's look in as Henry and Rita's not get it. And we have two left. Let's look in as Mary. Mary does not get it. And let's look in as Thomas and Thomas got it. All right. So just to recap, if you've been taking notes like I have Peter got it. Henry got it. And Mary got it. That's three out of six. And then I'm sorry, Peter, Henry and Mary did not get it. So that's three out of six. And magic. Michael and Thomas got the feature. So that's three out of six. So 50 got it. 50 saw the feature and 50 did not. Very good. So now let's go behind the scenes. Let me do a quick time check. Okay. Let's go behind the scenes. So how do you define a feature? You saw how this was defined. But what's let's look at behind the scenes. What do we need to do before you can define one of these or declare one of these? So what needs to happen is number one, you need to instrument the feature flag within your code. So here is the source code of this application. And if we go into application controller Java, you will see here some logic to set up the feature flag APIs. And then here we're using this open source project called unleash. We're basically instantiating an unleash instance here. And then here, this is the important part. Because we are doing, we need authentication and session replication because we're keeping track of the user IDs. So this application has that. And here we're setting up, we're getting the username here that is logged on. And then we are checking here if this feature is enabled, which is the feature that we, this is a string that we used to define that feature flag earlier that you saw, then the list of products in alphabetical order. Okay. And this is basically is doing list all sorted sorted. Else, if the feature is basically not enabled, just list the products in or basically by the way that they are entered in the database, which is in not alphabetical order. So you need to do this first. And then the second thing you need to do is you need to go to, actually, let's just go back here. You need to come here. And you need to click on configure. And then you need to copy this URL and this instance ID, which happens to be the unleashed server. Think of it as a service basically, as a service. This is the way to get to the unleashed service that is running for this specific project. And you could declare two variables with those two values that you would copy somewhere. And the variables are defined here. Please ignore these other variables that I turn off so that my pipeline would run faster. Basically, you would define two variables here. This is where you would put in the instance ID of the unleashed server or service. And this is the unleashed URL, which are the basically the variables or the two values that came from this pop-up dialogue. And then after you've done that, you can actually define or configure a feature flag here by using the, you have to use this feature flag name has to match the string in the code that you saw. Lastly, I would like to invite you to visit. There is this project that is public called CD Labs instructions. And there's a variety of CD related labs listed in this project. The one that we just just showed you is called feature flags. And this basically takes you through all the steps that you need to do to be able to recreate what you just saw in this demo. Just like feature flags, there are other labs related to continuous delivery, about DevOps, about incremental rollouts, canary deployments, GitOps, auto deploy releases, et cetera, and rollbacks. So that's all I have for you today. Thank you very much. And at this moment, I'm going to pass it on to my colleague, Farn. Thank you. Awesome. Thanks, Cesar. So I'm here and I'm going to talk a little bit about security. So hope everyone's doing well. Hope you all had a good breakfast. And let me get started with sharing my screen. So I am going to share. And crazy news is happening. So I'm going to go out over there. And here we go. So my presentation is going to be on DevSecOps with GitLab. And my name is Fernando. I'm a technical marketing manager here. And just to say a little bit about me, like different animals, I worked a lot on security, Kubernetes, OpenStack in the past. I come from a software engineering background. And now I prepare these demos and kind of help all of other different security solutions and really show the value of them. And that's me with a goat. And that goat is trying to eat my paper. So before we get into it, let's just talk a little bit about the software developer life cycle. So initially, you'd create an issue and then developers would work on that issue. So there'd be a feature request or some type of bug. And then developers would work and they'd make a feature branch off of the default branch, commit the changes, then the CI will run, unit tasks, building the container. And then we have a whole set of different security scans that run. So these security scans run on that feature branch. Then there's a review app, which is once these scans run, we'll get all the vulnerabilities that were detected. And then there'll be a review app and then not included here. There's also additional security scanning that goes ahead and checks the running application. So we'll send a bunch of requests to try to break the running application. And we'll get all those results. And then there can be discussion and code reviews. And there'll be approval. So we can set for merge requests to need specific reviews from security team or legal if there's any vulnerable code or incompatible licenses detected. So we can add further restrictions on that. That's part of our security guardrail solution. Then once the issue is merged, it gets merged into the, or once the branch is merged on the issues closed, the continuous delivery pipeline runs. And we deploy that into either our staging environment and we can run for the test or we can have that deployed to production, depending on how we like to set that up. And then we'll have the security scans run again just to validate that they're not detected again and that there's nothing further within the default branch. And then we can analyze everything through the security dashboard and triage any vulnerabilities and go through anything that we had to release because it was a critical hot fix, but we still want to know that it's there to work on fixing that later. So what scans were actually run? What security scans were run? So there was SAST, which scans the static source code. There's dependency scanning, which scans all of our software dependencies. So that would be, for example, in Python, it would be the requirements.txt file, we'd check the versions and see if there's any vulnerabilities in those and we'd report that. Same thing with container scanning. We look at the different versions of your Docker container images and see, and all the items within it and see what's vulnerable or not. And we use a vulnerability database. So we use the CVE database. We use our own, we have our own security researchers as well that add to our own database. And we go from there to detect these different issues for all of our vulnerabilities. We also detect secrets, licenses, instead of just only, so these are all static analyzers that check our static source code. But we also want to check the running application just in case there's something like a, like bad authentication practices or cross-site scripting vulnerabilities that we can't really find within the static code. And we've also added fuzz testing for static code.  So it's kind of like an extended form of unit testing to find where we're not just writing the unit test ourselves, we have random data being passed into our functions. And there's also web API fuzzing, which will send a bunch of random requests to our APIs. So that's our security scans. And we continuously enhance different things and add to our security scans. But you can check out that within the GitLab documentation. So now let's add the AppSec engineers or the security team and see what their role is within the software developer lifecycle. So the security team's role is to view the vulnerability dashboard, triage and assess vulnerabilities and see what their criteria is and what their, like how vulnerable the system is and how, if there are high, severe, critical vulnerability, we'll assess all of that. And we can triage and see what developers need to work on. And we can really collaborate. Developers can leave messages to the security team. The security team can approve or deny these messages, and they can really keep track of everything going on within a project or even a group of projects. So I'm going to give you a live demo of this, but just to kind of just give you an overview. There will be a merge request and you'll be able to see the eligible approvers. You'll be able to see the security scans and licenses detected. And you'll be able to have a license policy. It's like, went over this briefly. I'll go over this in more detail. And you can kind of see a developer can see everything within the merge request and be able to continuously push onto that feature branch, resolving vulnerabilities before they have a final product. So this doesn't need so many reviews and codes to see where the vulnerabilities are. We tell you where they are. And the security team can validate that, but your developers will be able to continuously push code until they're resolved and see the results. And once you see the vulnerabilities, you can actually click on them and see a lot more details. And you'll be able to dismiss them or create an issue on them further to work on it within the future. And the AppSec engineer workflow, you'll see that they can actually see the security dashboard and they can triage vulnerabilities.  They can change the status and also create issues to work on it later. And then I also want to note that these are confidential issues that only those with access can see. And the reason why that's something important is because we won't allude to any malicious actors that this is a vulnerability. We can fix it and then give an update on, hey, this is vulnerable, make sure you update your system. And then we also have the security dashboard to assess the security posture of a particular project or group of projects. So they get different ratings and this is something that we can show to the executive team, hey, we had this hackathon and we lowered the vulnerabilities. Maybe we should have this more often or we had to refactor all this code or to introduce these vulnerabilities so you can actually see events and what may have caused, what may have introduced vulnerabilities on the system. So now let's get to the fun part, the demo and check in my time. Okay, I got about five minutes or so. So here's a project that I have with all this, all these security scans set up and it's very easy to set up. Pretty much I'm including templates and then I can either configure these templates via variables or I can configure them with their own job. Like my first target will tell the fuzzer what to do. So here I'm pretty much building the container image. I'm doing coverage based buzzing, running my unit tests and security scans, deploying staging, then running my DAST and API fuzz testing. And you see that like SAS is just added with this template being included. And I'm also enabling scan Kubernetes manifest the truth so I can scan all my YAML files as well. And I'm adding extra information for the fuzzer and for DAST here. And that looks like this. So build stage, coverage fuzzing, all of our scanner tests and so SAS is per language. So you'll have a different SAS tests per language running, but they'll all aggregate into one place within the merge request. And then you see all the point of staging, then we run DAST on that staging environment and we run the API fuzzer. So if in a merge request, I added a new route. And first thing we see is that it requires two or more approvals for license check and vulnerability check. So you can see that we have, let's say, a lawyer here that's going to check our licenses to make sure they're compatible. And we have members of the security team here to make sure that if we detect something vulnerable or critical or high of vulnerability, then we can block it and one of these two members most approved before it can be merged. Same thing if we detect an incompatible license. So these scans as of recently, these vulnerability check and license check can be configured to anything like what branch vulnerabilities are detected on, what severity, what types. So you can fully configure this. And once we expand, we can see all the vulnerabilities. And I'm just going to show you when you click on the one, depending on the scanner that's used, there'll be different information like this one's Python bandit. So we'll have access to where in the file the vulnerability is. So here you can see that I'm giving too much permissions to the database file. So there's global permissions on this file. That's a bad practice. And I know that here. And why is that a bad practice? Well, I can go here to find out more information. And it's a bad practice because it's too permissive. And anyone can edit it and perform malicious activities on it. So there's more information on that. And that enhances developer education. So once I go on here, as a developer, I can actually dismiss this and say, hey, this is actually a test ID and need to need access for this particular reason. So I can add comment and dismiss it. And you see that there's a dismiss label here with information on it. So once this is merged, it'll actually go into the vulnerability dash of the vulnerability reports. And the security team can actually see this note. And they can approve it and say, oh, yeah, that is the test database. So let's go ahead and approve this because it's not really a vulnerability because of that. So that's one way that they collaborate. You see different information on, you know, Kubernetes manifests. And you can see like dependency scanning looks different. And you can see what the solution is. You can see links to the CDEs and details. And you can see a description. And different things like container scanning do the same thing. They give you lots of links and solutions, descriptions. And in DAFs, you'll actually be able to see the request that was sent and the actual response. And it'll provide you evidence to what happened. And the solution as well. So we also have coverage-based fuzzing exception. So we can see the stack trace and see that there was a not implemented error that came out when we were trying to fuzz something. And API fuzzing, you'll see the same thing. They sent a really weird request here to the API that we set up. And we received the 500 internal error. And this was our actual response. So we know that there's a problem there because it's a 500. And I did click on the create button issue on this one. And you can see that it did create an issue that's confidential to actually look deeper into this. And we can also create a confidential merge request to work on a fix without letting anyone know except those that need to know. So now let's go into security and compliance. Let's go into the vulnerability report. And this is everything within the default branch that was vulnerable. So we can see all of that. And we can actually click on one. And we see it's detected. It was detected five days ago. We can see the exact pipeline it was detected. And we can say, well, we know that this is a vulnerability. We've actually tested it. And what we can do is we can go ahead and confirm that, change the status, refresh the page. And you can see it was confirmed just now by being. And so everyone on the security team will be able to see this and they can add a bunch of different comments and it go through there. There's also the security dashboard. And this is what I was talking about when, you know, different vulnerabilities that were introduced over time. So you can see that there was 24 info introduced at this point and there was two mediums. So we can see why were they introduced and go to the date of the merger question and the commits and see when things were introduced. So it seems like we are out of time. So I'd like to leave y'all with that. And thank you for attending. I really hope you enjoyed this. And, you know, this was a great session. I really enjoyed being here with y'all and going over these security features. So for more information about that get lab.com is a great resource. And you can see all of our security features within there. And just be sure to access that. So I thank y'all for attending us.


Hey guys Jeremy here, and this is my review for Supernatural season 13 I noticed particularly after the midway mark I noticed a lot of you guys kind of stopped watching what I was saying mainly because of my criticism of the season And but actually looking at it doing all the numbers and everything the season actually wasn't that bad up until The halfway point for that. There was only two bad episodes being eight and three There actually was some decent episodes in this.  I didn't like her too much when she was first introduced although seasons back But now she's really coming to being one of my favorite characters on this show And that's rare to say because usually when a character is awful like catch they stay awful like catch But Rowena has actually really turned herself around and she's definitely one of the best characters in this show Castiel's Revival was eh, but admittedly that episode with the empty was actually a really cool episode Visually and just in terms of a very interesting aspect. They didn't explain everything about what that was that that's Cool mystery writing you don't have to lay it all out Like an Ikea book and terms of how to construct it. You don't need that and that's what they did They left it as a mystery.  I actually forgot a bunch one of them being those weird Tremor Demon things that as Medea's wanted Jack to open up at the very beginning of the season Do you any y'all remember that?  You know seen by the UPS guy or at least very well well-smelled also the bad place was wasted another Narrative aspect that was ruined that just dropped because like they ended the the mid-season finale with that look like they were gonna fight dinosaurs And they're boom they're gone However, that did introduce the wayward sisters group, which I actually did like that episode I did not mind it and the fact that it's not gonna get picked up is Admittedly disappointing because there's a much better spin-off idea than the original spin-off idea They tried to make him like season nine or something episode 15 had that really cool LA Noir Sort of story because they're trying to get the blood of a holy man and there was that Italian priest character who's really good. He was probably one of the best one-off characters that they ever introduced I really hope he comes back, but I know he won't but really he was one of the best one episode characters If the show has had in a long time Then they ruined it with that really really cheesy kind of Shoot-out and really bad editing, but otherwise that episode was actually really good And in terms of how the narrative was progressing while the episodes were definitely getting lower ratings in the Final half of the season the least the narrative was still going in good direction Even if that Gabriel craft was bullshit Now I've talked about it many a time, but really that Gabriel retconning was not good.  Oh, he's the trickster. He's like, no guys. That's what emotional weight that's what emotional loss is supposed to mean to this show and This show just keeps on erasing that because it's sad. I don't understand like you This isn't how things are you should have to deal with loss and shows should be able to work around that are Just and on a good note. So I'm never going to be happy with that Gabriel retconning I'm never going to Forgive that because it was really bad writing and in the end. What did they do they kill them Which is funny because they eventually killed Lucifer, which by the way that fight is still one of the cheesiest fucking fights of all time It was a cool setup But admittedly there's a lot of plot holes in that season finale that I didn't really notice until thinking about it later Michael's from a different dimension So why is Dean his vessel and how does he even know about it because date Sam and Dean never existed in this alternative universe when they fought each other was supposed to be this battle of immense chaos and immense Destruction and all that was destroyed was a pew table and some people like wasn't exactly the right vessels Apparently this was super powered Lucifer because he had Jack's grace Who's pow more powerful than Lucifer? So no, no, I won't excuse how really silly that ending was but aside from all these negatives The episodes still flowed decently and like I said the first half of the season was actually really decent There was a lot of fives a lot of For there's even a few sixes There was not a single seven in this entire season and there was actually some sevens in twelve and I hated season twelve in Terms of its narrative they filler episodes actually weren't that bad But that's kind of bad when the main narrative is Second nature compared to the filler one-off episodes So in terms of its narrative weakness but with its narrative strengths as well as the one-off episodes being decent Well, or as not really being a cool filler episodes as previous seasons They're still decent episodes and while the narrative was weak it at least kept it going but now I've added up all the numbers and everything and The funny thing is I'm kind of in the same situation. I was was 12 and 12 Honestly, I would have given that season a lot less rating because I did not like that season at all And in terms of this season, it's not that much better really it just had a better narrative But that by much my there's not allowed to say to that So in the end, I'm actually just gonna go with the exact same thing I gave season 13 because while season 13 had a very better narrative structure The amount of retconning and absolutely lazy writing cannot be excused So I'm gonna give season 13 a three out of seven. It has some decent episodes here and there It had some really engaging Aspects it had some one-off things that were eventually dropped However, it had some retconning that had no purpose of being there and it just had a Really not that woo of a season finale again But that's the thing that seems pretty naturals had an issue with the last few seasons I think the last good season finale in my opinion is 10 Actually, yeah, I think it's 10 anyways guys. I hope you enjoyed this review I hope it didn't piss all of you off I will be having a video later on talking about just what I feel the mentality of the supernatural Universe is right now, but that's not gonna be for a little while Anyways, I hope you enjoyed this video if you did leave a like if you want to subscribe Possibly be continuing on with supernatural season 14. We'll see anyways guys. I hope you like this video. I'll see you next time


Hi, everyone. Let's start with introductions. I'm Leon Bracard. I'm a sales engineer at Fastly. I'm David Strauss. I'm CTO at Pantheon. And I'm Rudi Grigar. I'm the infrastructure manager at the Drupal Association for Drupal Sites. And we are here to talk to you about the value of CDNs and caching and all the things that go beyond the origin, which, assuming based on the assumption of you being here at DrupalCon, is probably Drupal. A lot of you probably know that Drupal takes a long time to render pages, at least in terms of computer time. It takes even a great site. It takes a few hundred milliseconds to render pages. And a lot of caching is about avoiding that as much as possible, both to reduce the amount of time your users wait on pages as well as make your origin resources extend further, that if 99% of things are getting handled by your edge cache, then only 1% of your overall traffic needs to be handled by your origin. Did you have some topics to start us off? Sure. So I'll start on a website that all of you visited before, Drupal.org. That's hosted on Fastly. Why is that? Well, a couple of years ago, Drupal.org was experiencing all kinds of latency issues and slowdowns and basically got hired on by the Drupal Association full time to work on making it faster. So what I found was that our DLAN that we have outgoing with the origin servers for Drupal.org was hitting its 30 megabit cap every five minutes or so, which was coordinated with updates to Drupal.org and people's crons being on about every five minutes or so being a big spike on the hour, definitely a bigger spike and we're dropping packets. So kind of initially pulled out a CDN and saw some reduction in the number of like drop packets and things and things are getting better. But it was kind of like a quick like, oh, things are on fire. We need a CDN. We put one in place. But it was a time-based CDN. So every 30 minutes the CDN would purge whatever it had in its cache and we would recache and dig into the origin. So it was kind of a middle ground from where we ended up in this last year with Fastly. And with Fastly, we're doing basically that but a much better job of it. So all of the packaging that's happening on Drupal.org for new releases for updates like security data, that sort of thing. We're dynamically purging Fastly's API when we build and package releases so that those cache items are only dynamically purged when there's a new release available. So only new requests are hitting origins and existing requests stay cached for up to a year in Fastly's cache. And we've combined that with Fastly's origin shield feature which is some fancy varnish configurations. It's distributed varnish in a sense. So the VCL's there to do origin shielding and keeps the request fast. This is actually updates to Drupal.org and Fastly's dashboard that you're looking at right now. So if you wait until a five minute mark here, which will be any second now, you'll see a big spike and things will come through. But most of the hits are happening with a 99-ish percent hit ratio. So there's not a lot of requests actually hitting our origin and our origin bandwidth is only, I mean we're under 10 megabit or so at any given time with all of this happening right now. So that's sort of how we went down into the Fastly rabbit hole. We were already using varnish on Drupal.org for all the sites and services that we were running. So the move to Fastly was pretty natural. Like the VCL's there we can upload VCL that we have that's custom, that sort of thing. And overall it's been a really great experience just in being able to manage the service that way. On Pantheon we've mostly worked with Fastly for very large customers and networks of sites where they need to have points of presence. They need to be able to handle huge traffic spikes. Some of the sites on the platform are top 100 websites and when they get in the news or at the top of Google results they're just going to get a giant load of traffic and it's not an attack it's just legitimate traffic that people are trying to load. And then it also compounds with a lot of this situation of the modern web in 2016. How many of you have heard about Google's changes for page rank with HTTPS? Okay so a sizable amount of the crowd.  Every time you introduce a service like that, especially modern HTTPS and TLS negotiations, it's making multiple round trips to the server. And in a lot of cases if you're just implementing HTTPS on your origin boxes then if I'm pulling the site up on my mobile device it is going all the way back to the origin servers for multiple round trips before it even requests the page from the server. And now that HTTPS is pretty necessary for having sites max out their page rank and other analytics and even providing things like AMP pages to Google so that you get accelerated mobile rendering it becomes more and more important to optimize that. And we've done that for some of our customers with deploying CDNs including Fastly. And by having different points of presence around the world instead of a device that's visiting the site doing multiple round trips all the way to an origin in say Chicago or Virginia or something similar they just do it versus the local point of presence which Fastly has dozens around the world where it can do that negotiation and then Fastly can maintain a much more cached encrypted connection back to the origin so that mobile devices just have a much better experience in terms of latency for requests and ability to scale out that traffic without having the origin bear the brunt of it. And rather topically HenryTakinton.com which is all HTTPS was hosted on Fastly and was mentioned during during the debate last night and we had a huge spike on the network. It was very interesting. So I'd like to take a little step back. Does everyone know what a CDN is because we've mentioned before. So it's a cache. We have we cache your content close to the users around the world. So your request has to go less far. So if you're a user in Australia but your servers are in Frankfurt then you get a cache content from from this service in Australia and from Sydney for example rather than having to go all the way back to the origin. And we're based on open source software called Varnish. How many people have heard of Varnish before. Excellent. Well that's great. So Varnish is is open source for Espoxy. You can basically take your Varnish from from your home server and put it on to Fastly and within about three seconds we'll push it all the way worldwide so you can have all sorts of very clever configuration. But most of the time you don't need to do that. The Drupal plugin for Fastly is just the right thing especially for Drupal 8 with cache tags. Drupal 8 is much much clever at caching and deciding where dependencies are. So if you change one page then one object to one page then Drupal the plugin will send invalidation to Fastly and invalidate all the pages which have that piece of content on within around 150 milliseconds. So newspapers users like the independent in the UK because they want to have the up to date up to date news. And even if you have a highly interactive site there are lots of assets like CSS JavaScript images etc that are getting loaded on every page load even for the authenticated users and those are just not varying that much. And having a CDN for say a user in Australia is the difference between them hopping over the Pacific for every single one of those assets versus them loading 99% of the assets from the CDN and then only going back to the origin even for a signed in user for one request. And so you're only adding in the latency of those say Trans Pacific or Trans Atlantic cables for just that one request. And that actually provides a pretty good experience for users around the world because most of those requests are just for those assets that'll be cached close to them. And with things like HTTP to now, which is supported as an opt in system on fastly, it's possible for devices like mobile devices to roll up those requests into things where they basically are able to use a combined HTTP pipeline to efficiently batch those requests to the CDN and pull down all of those dependent assets much much faster. It actually takes care of at a lower level. A lot of the concerns that Drupal has has tried to solve historically through CSS and JavaScript aggregation by packing those into single files. HTTP to allows having those files all be pulled in batches. And even more than that, even if you are delivering custom content like that to users interacting with HTTP to you can actually advise the system that those assets are going to be used or necessary for the page load. And then the the CDN server can actually push those down to the client like a mobile phone. Before the client even realizes that they're totally necessary for rendering the page. And that means that you're even reducing latency that would normally be incurred with a mobile network because normally it would load the page would process it figure out what assets it needs. And then it's another round trip over the mobile network, even if you're going to a local point of presence. HTTP to allows the push to happen there. So you're just kind of axing away at latency everything from TLS negotiation asset pulling asset figuring out what assets are necessary for the page going over transatlantic and trans Pacific cables for pulling those assets. And you can you can knock off hundreds and hundreds of milliseconds from page load times this way. When did we want to open the floor. Sure, I think we can get questions. Yeah, like we mostly wanted to keep this as an open floor. I'm also I mean, I know this is a fastly session. I'm most of these concepts apply to most CDNs are going to be working with. So feel free to ask about stuff. And I can tell you at least how fastly handles the answers to some of these things. But they're general conceptual issues of web architecture as far as I'm concerned. We have a microphone because this session is getting recorded. So I would appreciate if people could use that for asking the questions, or at least I don't think it quite can get passed around. It's not wireless, but I think so. Absolutely, it can be so I could take this one. So then at that point, there's two, there's two connection paths. That's from the user to the CDN and from the CDN to the origin to your servers. And so you terminate if you terminate on the edge, then either you can use HTTP back to your origin or you can use HTTPS. Absolutely not because there's no overhead because you keep the connections open for as long as possible. So it's actually, it's actually not as bad as you might think. Yeah, it's not nearly as heavy as the device itself, the end user negotiating all the way back to origin. Because TLS, the way that the connection is structured, it happens in two phases. First is this asynchronous phase, which is really expensive for negotiating a shared secret. And then once you have a shared secret, almost any modern device, even a mobile phone is able to process the encryption at wire speed, once that negotiation occurs. But a CDN like Fastly is going to do that negotiation once, and it's going to either keep the connection open or cache the shared secret, so that it doesn't have to undergo the full setup every time it talks to the origin. Even more, moreover, Fastly has a neat option where you can put in your own client certificate to authenticate Fastly's connection back to your origin. So if you're really up on how things like X509 work, you can make it a very clean connection back to the origin where you have authenticated with 100% confidence that the connection is coming from Fastly and all the rules you've put in place at Fastly have been applied. So if you're doing things like mitigating an attack or trying to protect your origin, it provides a good facility for doing that that doesn't involve you constantly having to update IP lists, like the traditional way of validating that something came from a CDN. You'd like to ask a question, but the mic is far away. We can repeat it. What about authenticated users and the individual blocks on their pages that may have individual information on them? And what about searches? For example, like a complex solar search that is parsed in the stream of the URL? How would you use those? Okay, so the question is about, I guess, personalized content and yeah, personalized content. Pretty much. Do you want me to take it? Sure. Okay. So there are a few different ways of handling that sort of assembly of a page. There in Drupal 8, we now have something called big pipe that allows you to pump out that content through a streamed request, implementing the big pipe where you put ESI at the bottom of the page to basically pull the big pipe content with Fastly would allow you to have the initial page structure be cached, ship out to the client before Drupal even knows the request is coming in. And then Drupal can handle shipping the customized content through big pipe as an addendum to that request so that the client still sees it as just one big request where the initial data came in very fast and then the subsequent data comes from Drupal. Other ways of doing it would involve separate requests for that content where you could have some of the requests cached and some of them go back to the origin. I don't know if you can show the graph on there. You can actually see the hit ratio graph on here which is really showing, this is a particularly exceptional hit ratio because this is very, very, I'm sorry what? Yeah, to a more normal site. Yeah, this is a more typical site. It's still a very good hit ratio, at least in the hit ratio done there. The typical site is still going to have a pretty high one, but the reason to pay attention to that is you want to make sure that even with the customization of content that you're not skipping the cache. One of the common ways to accidentally skip the cache is once you've set up a session, that header comes in, you might have configured varnish with VCL to say any request coming in with a session ID bypasses the cache. That'll give you a poor hit rate, but you can put a rule into something like Fastly that says for all the static assets, ignore whether they have a session or not. You could do the same for certain block requests as well if they were dynamically added to the page. And ultimately, you just want to look at your hit ratio. Another thing you can do is you can configure Fastly to ship its log data out to another service for analysis. And then you can look at what's hitting and missing and depending on how you configure your VCL, you can even have it hint at why. And then that can help you optimize the experience for an authentication heavy site. And speaking of that log shipping, we use that pretty heavily on Dribble.org because we use those logs for downloads and for like project usage statistics. So all the traffic that's coming into updates tracks like what is being requested for updates. So that's how those statistics get generated and being able to ship those logs back to us for processing is a handy feature. Another thing I heard you mentioned was ESI. Does everyone know what that is? Yeah, ESI means edge side include. It's a tag you can put into a page that says at this point in the page, I want you to seamlessly integrate the response to this URL so that you can hit an initial page. And then what Varnish does is it'll ship out the data until it hits the ESI tag. And then it'll notice, oh, I need to pull this content now. But the rules for that content can be handled completely independently of the main content that it's delivering. So you can ship out a framework, a skeleton page, and then use that, I think I was talking to Fabian actually two days ago about using that for, to integrate with big pipe where even for authenticated traffic, the initial part of the page comes cached out of the CDN and then Drupal dynamically handles the subsequent customization of the page. I don't know of a lot of production sites that are doing this yet. It's not, I mean as if for people who are present for the keynote earlier today, big pipe is still in beta in Drupal 8, but it's assuming it continues to mature, it should enter a stable configuration in Drupal 8.3 or 8.4. So we use, we're on Drupal 7. Yes. And that does ESI, so that's basically the same principle as? Exactly. And you can totally use AuthCache with Fastly by using AuthCache's published VCL. And then that will properly handle the rule set that's necessary for AuthCache to determine which requests are keyed off of things based on user-to-user role. Regarding the caching mechanism that you said, how do you define which part of the page gets cached except the ESI algorithm? I mean, do you read the pop of the URL or something else? You can use anything you want in varnish and on Fastly. You can, there are two systems on Fastly for it. There's a rule system that has a GUI configuration where you can put in URL patterns, header patterns, cookie patterns, things like that and make a decision of whether you're bypassing the cache or trying to hit the cache or not. And then also you can go, and if you really need to, you can unlock full VCL, which allows you to really actually just write code that is literally has if statements in it to determine how to handle that request. You can use regex if you want to. Do you want to show the VCL? Sure, I can show the VCL for this. It's the point where you also state the... Well, you can. I would advise against it. I would encourage you to use standard HTTP headers where possible. And Fastly will properly parse things called cache control headers. And you also have the opportunity to use something that's called surrogate control headers, which are specifically consumed by something like a CDN, and then thrown away. So you can send in one cache control header that goes down to user browsers and Fastly won't touch it. And then you can set a surrogate control header to tell the CDN how long to keep the page if you want to do different timings. Drupal directly supports using cache control headers though, and Fastly will support those out of the box. So a good example of that would be a live blog where you want people to have the live information. So you make the cache control header for the browser to be very short, say a few seconds, and then you cache on the CDN for a week, but invalidates the page on CDN whenever there is new content. So the browsers will keep on getting back to the page. We'll keep on getting 304 not modified. But when there is new content, they'll get straight away. And when it comes to delivering things like 304 not modified, delivering something like Fastly is actually pretty essential to getting that right. Because if you just deploy your own fleet of varnish boxes, they're going to independently cache the content, and they're going to have different IDs for when the content was created, and the e-tag for the content, which is what the browser prefers to use for validating it. Fastly does request hashing at a higher level for requests, and I believe it's in the MasterBCL, where it determines what servers to send the content to, so that if you have a page and it's cached in Fastly, it will always hit that cache on that one, on the single system that is responsible for that piece of content. And that ensures that if you're distributing something out and you want to deliver something like 304 not modified, so browsers can revalidate their cache, they will efficiently revalidate, rather than if you have the fleet of boxes, they could randomly hit a different one, and then the browser will, that'll have a different e-tag, and then the browser will think, my stuff is too old, and it will have to pull the page down again. So a fleet of varnish boxes is still better than nothing, but the kind of hashing that a system like Fastly does, will get the hit rates to go even a whole level above that, for that sort of management. I was thinking about the blog example, so we have the option to use Fastly to invalidate dynamically if someone posts something, or in order for the page to be cached on Fastly servers, but in the dynamic you can say, get cached for as long as someone writes down and you post. So this is something that can be worked out with rules, or something like that. You don't even need, for invalidation you want to use the Fastly module for Drupal, and then that will talk to your Fastly API to invalidate the content, and then that way you can cache the content in the CDN for a long time, and then it hooks into Drupal's APIs, so that it knows when you create a new node, or update a node, and then it tells Fastly, expire this, and Fastly uses this asynchronous distribution model for caching validation that reaches around the globe in usually under a half second, to all the points of presence. I'd say a fifth of a second. Fifth of a second, okay. Yes. Would you say there will be no need for me to put another cache between Fastly and my Drupal site, or do I still need some other caching? Yeah. Repeat the question, though. The question was, if I'm using Fastly and our other CDN, and everyone accesses my site through that, do I need to have additional caching inside for the site? Specifically for Drupal 8. Specifically for Drupal 8. And I would say, no, outside of like for Drupal, Drupal still need to cache, and do all of its internal sort of caching, but as far as adding another layer of varnish, or something like that, for Drupal.org, we removed our internal varnish completely, removed our load balancers completely, and we're sticking with Fastly's Origin Shield system, and managing all of the edge from Fastly's interface and through Fastly. So all of the requests caching and logic gets handled at Fastly, all of the requests that are hitting Drupal.org from around the world flow through the Origin Shield, which is in Seattle, and then to our data center, with that Internet Exchange in Seattle to Oregon. So all of the requests funnel through a single Origin, that Origin probably has whatever is being requested. Does request collapsing, I believe, is a nice feature. So if there's requests for the same thing twice, like that only one request comes back to our Origin, and that has been working beautifully. So I would say, no, like you can remove your varnish that's running internally after using Fastly. This is not a general feature of CDNs, that most CDNs have their points of presence, and when the point of presence misses, it goes all the way back to your Origin. And so if you have traffic that's pretty distributed around the world, you might have a lot of traffic reaching your Origin still, and might want to run a cache there, but with Fastly and the Origin Shield, you actually have a cache that can hit all traffic before it hits your Origin, no matter where in the world it's coming from. So if you have something, which is a big event coming up and everyone requests the same page or the same object all at the same time, then you'll only get one request to your Origin for that, even though thousands of people around the world will fetch all those objects. And Fastly can even take it one step further than that with a header that sets an option called still while revalidate, which means that, let's say you have a page that's cached for five minutes, and it's five minutes and one second now, and it might let's say it's a heavy page in your website that takes a few seconds to generate, you can turn on this thing called still while revalidate, and what that'll do is Fastly will still deliver the old version of the content until the Origin has replaced it in the cache. So at that five minute and one second mark, it makes the request to the Origin to get a fresh copy of the page, but the customer or browser does not wait on that to happen. So it does, in addition to the request collapsing, you can even have your users never wait on a page to freshen if it's a high traffic page and getting a lot of traffic as the site. We have the VCL for that on screen right now. This is VCL, if anyone recognizes VCL, and that's the option. So for updates, we have 120 seconds still while revalidate, and if there's an error and it's cached we just let it serve whatever that update is. So if the Origin goes offline updates still are available to verbal science, you don't see that unable to connect to updates or error. Yes. If you have authenticated and non-authenticated traffic, and let's say that your server has gone down or you have to make update the page page something, and you won't have the non-authenticated traffic still working, but disable a couple of regions, something like the login page. You can't really handle custom dynamic pages with a CDN if the Origin is offline. And I'm not sure a way that you could safely do that. Not the dynamic page, the same page like the Drupal front page for example, that has a login block on the site. Use a login block. And when your server goes down maybe a way to disable this login block maybe interact programmatically something like that. Okay. So to repeat the question and the question is if you have authenticated traffic and the Origin goes down or it can't access it, could you fall back to having static content? And the answer is yes. You could do that with custom VCL by doing something where you detect you would initially detect that the user has a session and then you would say I want to pass this back to the backend and then what you would get the error or failure to connect. And then you could put request handling in there that says even if you had a session you could tell varnish to retry the request and mark it in a way where it basically says I got an error trying to handle this dynamic page from Origin and then when it goes back into the VCL to process it again you could have a rule in there where even if you had a session if the original Origin request failed you could say you could treat it as a cached request probably strip out the session and then they would get an anonymous page instead of an error. Can you also do that with that? I think there are thresholds set in the origin configurations. So the way we explain this is a very advanced feature of stale if error which is a proposed HTTP standard and the way it vastly does is so we'll check whether your Origin is responding within a defined time out. So I guess you could make the Origin fail health checks if it's not responding within a few seconds and then go through this error mechanism. Go to CDN for global sites and it works perfectly at possibly the fantastic program. I'm wondering how is it for business websites where the audience is geographically limited. In Europe whole countries were with busy websites where the audience stays within the sometimes you get hits from all of the world but most of the users come from that country because of language or something. Would you say that it's still useful in any way to use CDNs faster or faster? Absolutely it's for multiple reasons. One is unless you're deploying HTTP2 to your Origin servers it provides that for users which accelerates their page load times. It provides faster TLS negotiation because odds are fast these boxes are going to negotiate it faster than your Origin servers would. Three unless your Origin servers support IPv6 in a lot of regions mobile phones prefer IPv6 and there's usually 20 to 30% overhead for going through the carrier grade NAT for v4 to go to the website so if you can make your site available over IPv6 you can minimize load times and fastly can do that as well for you even if your Origin servers don't support it and also it's just infrastructure you don't have to manage then. The interesting thing about the Internet is it's changed quite a lot over the last 20 years and all our servers are hosted in or close to Internet connection points so all traffic in Netherlands goes through M6 for example there's D-Kicks in Germany so the Internet is very well connected especially for your Origins so it's less of a problem if you're in Germany then it's going to be fast if using that if you only have one pop node in Germany it's still going to be relatively fast and it will be infrastructure you don't have to manage. You also can choose your configuration with Fastly to only use certain regions of points of presence as well like if you just want to do Europe or just want to do North America however one reason that you might want to actually have advertised points of presence around the globe is for mitigating attacks because with any cast routing and GeoDNS it ensures that attackers that are trying to attack your website are still routed to their local point of presence so let's say you have a button in Russia and they are being used to try and attack your website they're all going to be targeted at points of presence that Fastly operates closer to the attackers and not on the points of presence that your customers are accessing the site through so then you can shut down the attack at a point that doesn't even exist in your normal traffic flow well before it touches your Origins systems well before it touches the actual caches that your customers are using so Fastly we're generally in internet exchanges but we pay with local providers so we'll have fast connections to big ISPs for example which is really what Akamai is probably doing they're probably a single appearing agreement with the ISP yeah most probably I went to avoid the getting out of the local network country, ethernet and using the backbone so is it something that firstly might add to the additional service that they already have it's already there we already appear and when we're always working on improving connections sometimes there are cable cuts on the internet we just think it's going a bit slower between different countries we have to root around and calculate the best the best part exactly but yeah it's in Fastly's interest it appears well because it reduces the cost of transport yeah they actually appeared with our ISP when they got added to the Seattle internet exchange and Fastly emailed Fastly support and was like hey do you guys have a peer would it be possible to peer with our provider and they were like yeah sure get us in contact with their knock and a week later we were peered there's usually a mutual incentive to peer because both parties don't have to pay for transport over the backbone at that point yeah sure I'll jump in there so you've seen some of the VCL already so VCL is kind of like a little programmatic language you can do if then else lots of rules look regular expressions and you can use that to either white list so this is how your rail stream is going to go only lets URLs and query parameters which match this to go through to the origin or to black list if you have some traffic which looks malicious you can match it with your code and that way you could block traffic at the edge and it wouldn't have to hit your origin and we could help you with that and there was a second question which I amazingly forgot it was about how it can help with authenticated users authenticated users it's quite tricky because it's a bit lower if you have lots of authenticated users but by using a CDN rather than going over the general internet it will still be faster if you have to go back to the origin because we optimize our reading over our network so your user will contact in Sydney, we'll contact our Sydney pop which will go over our network close to your origin and then back over the network so it will still be faster even if we don't have it cached and also for mitigating attacks fastly offers a platinum level of service you can add to a plan that they will help dive in and even help you write rules to trap attack traffic and then black hole well before it reaches your origin we don't like to say too much about DDoS attacks but last year there was a state level sponsored attack against github which you might want to google for videos and just it is VCL so any sort of regex that you want to do if you're able to kind of pin down some sort of pattern that you're seeing with your attack you can throw it in and then was it 5th or 2nd that walked the edge so very powerful for that another question regarding the VCL I heard earlier you spoke about master, can you explain a little bit how do you have a structure of how do you deploy each of your customers is plugged into the master how exactly are you doing with multiple VCLs right so the reference to master VCL was was kind of in depth about how fast these structures it's VCL which is we run a little bit of VCL before customers VCL runs but I guess you guys could talk about how you work on your VCL conflicts well the so I think the question is about how Fastly picks the right VCL to run against a site or I'm just trying to make sure I'm right answering the right question another question was rather if you have multiple customers well in their case they have multiple customers and I guess each of them has control of his own pieces of VCL how is this integrated in the whole because I heard master so I thought okay there is a master VCL and then through all the work has their own VCL probably another VCL for a different reason the master VCL is very small it's not at least my understanding of it is that it's not designed to do very much mostly Fastly is trying to route the request to your VCL which can happen I'm aware of at least two ways of doing that in Fastly the main way of doing it in Fastly as a general customer is you put in a domain name and you validate your control of the domain and then anytime traffic comes into Fastly's edge and matches the domains you control it will be handled by one of your services which a service on Fastly corresponds to a VCL or rules configuration the other way that's offered which is only used for a handful of customers is called IP pinning where if you handle lots and lots of domains you can get certain IP addresses that automatically go to your service and anytime traffic comes into that IP it's going to go to your VCL so the question was the question was the Fastly server cache nodes is the address list public it's like yes the address is public we have an API you can download it we update the IP address list way before we start using IP addresses so you can have a cron drop which updates your firewall to only allow accesses from Fastly for example alternatively you could use the TLS to origin where you put a certificate in for Fastly and then it validates that it's coming from Fastly cryptographically yes you can generate your own certificates between Fastly and your origin if you want to it needs to be signed and you would basically do something that's called you would create your own mini CA and you could sign one for Fastly and sign one for your origin and it's sort of self signed in that way and then you could tell the origin to trust things that you've signed and then give Fastly the certificate that you've signed and then every time Fastly connects to your origin like Nginx for example or Apache really almost every HTTP server supports this at this point then it can validate that it's coming from Fastly because Fastly has the certificate that you gave it can you actually go into origin configuration we can show this because there have been a few questions about timeouts for origin configuration monitoring for origin configuration production to origin yeah so here's that domain list that we were talking about this is the actual production so most of it is actually handled by start out your blood or here and as we're moving services over we're individually adding them but the wild card picks up most everything and then over here on the origin side we have our please be nice to these IPs you should validate that your traffic is coming from Fastly but yeah so here's that configuration this is the new interface that I'm not as familiar with but yeah you can set up in the screen the CI certificate the other way to do it to another thing you could implement if you wanted if you didn't care about validating that it's coming from Fastly but you just wanted to have the connection encrypted and trusted you could use let's encrypt on your origin servers you can it comes with a cron job that refreshes the certificate and then what will happen is that Fastly already has all of the major routes trusted for connecting to origin and so that would allow you to run your origin with an encrypted connection that would be resistant to man in the middle attacks yeah but fastly as well I mean once I refresh the certificate it's probably a little too in depth here to go into certificate hierarchies and client certificates and how the validation occurs but it is possible to do on here yes and then another thing that came up was the logging so here's an example we log to S3 and we also log to our own internal Arcist log server here so we can set the log format in a way that we want to accept and it will send the traffic over to our running log posts and that's encrypted as well yeah and this has actually a different that's what we verify there and then the custom BCL so maybe this will help shed some light on that question about how that works we have a main sort of production BCL that has additional includes of other BCLs that we have and I believe that gets sort of grounded by the master BCL that you were describing right so these get combined into one one BCL so when I view the actual BCL that gets compiled on Fastly's end that's the BCL we were working at before but this is the individual sort of I include an ACL we set up just kind of the production logic but it also includes things like redirecting this is the redirect logic that we have and some other like blocks that we have in place and ways to handle 5.3 and things like that Fastly versions the BCL so that as you go through iterations they're all on there so that if you ever need to fall back you can do that if you put in rules without writing custom BCL you can still see the BCL it generates so there's not a lot of vendor lock in either in terms of if you wanted to take your BCL and walk away you'd be able to mostly push it into varnish you might have to make a few tweaks for like more modern versions of varnish like varnish 4 but you can mostly the configuration over so for example this is the one sort of thing that we have in the UI here that gets translated into BCL if I look at the actual output it's just forcing SSL all the requests and so yeah then over here in the BCL there's a force SSL section it's also a great way to do SSL only for a site because it means that the redirect is generated by Fastly instead of your origin box so that you don't have a lot of delays there for redirecting to the same URL on HTTPS so it makes it easy to do that I think there's even prefab rules that you can even do for kind of like HTTPS only on Fastly now yeah I believe that's the force SSL so that sets this and that sets this area which is down here which moves things to HTTPS one of the most impressed you are always regarding redirects how do you handle those on Fastly does those come to the origin on the Apache server and then get the return code or you can do that directly to Fastly you can either create redirects to your origin and even cache them in Fastly if you want to as just normal responses or you can use varnish itself to generate the redirects if you know there are certain URL patterns that redirect in terms of redirects and traffic one other use case I wanted to go into that some of our customers use is for the sake of SEO search engine optimization some customers might say run one Drupal site for their blog and then a different Drupal site for their main website for their .com they might even run WordPress for their blog and Drupal for their main site and one thing that you want to do for SEO is you want to have it all on the same domain name so one thing you can do as a trick in the CDN is you can have in your rules say detect that someone's going to slash blog and then choose a different origin for that and even metal with the host name that it's sending to the origin so that you can simultaneously run multiple websites that are all in the same domain and all of the switching between the different origins can happen in the CDN and I've had customers which are moving date center or moving to the cloud and that way you can do parts of their website one by one rather than having one big bank switch and yeah that would be very useful for like a Drupal 8 migration of some kind on Google.org we can have parts of the website be routed by Fastly to the Drupal 8 site and integrate the Drupal 7 site or something like that so it could be useful for that sort of upgrade as well if you're looking at one of those so if you have more questions if you'd like to go to the floor here stand down and say get a nice Fastly T-shirt or a nice Pantheon T-shirt and you already should have Drupal T-shirts Thank you very much Thanks