 All right, well, we are about at time here. Welcome to Agency Workflows at Pantheon. My name is Steve Perche. I'm an agency and community engineer at Pantheon. You can find me on the internet as Steve Vector on Twitter, Drupal.org, GitHub. I'm also Drupal Haikus on Twitter, though I haven't been tweeting many Haikus lately. Agency and community engineer means I come from a background of working as an agency developer. I started as a freelancer making WordPress and Drupal websites. Eventually just started working with larger and larger companies. I spent about half of my career at Palantir.net, Drupal-focused agency in the Chicago area. Now in my role at Pantheon, I get to work with agencies that are adopting Pantheon, either for all their projects or for some of their projects. And in that work, I get to talk with them about their development workflows, find out what their pain points are, and then get their processes translated over to Pantheon's tooling. And then I also get to do a lot of travel to community events like this, both in the Drupal and WordPress community. And I still get to do some coding, which is always fun. Yesterday, we had a presentation from our CTO, David Strauss, about L-Cache module, a new caching layer that has a Drupal 7 implementation. And I'm getting to work on the Drupal 8 implementation. And we're hoping to get into Drupal 8 core now. So regardless of whether or not you're hosting your sites on Pantheon, L-Cache could be a good module for making your sites a little bit faster. I'm curious of the people here today who here is using Pantheon at all for any paid sites. Great, a couple of people. And who here works for a web development agency? Just about everybody? OK, great. Because that's what we'll be talking about. A lot of this applies to people outside of web agencies, but this really is focused on web agencies. And again, just to get a sense of where people are at, who's building sites in Drupal 8 yet? Great, about half the room. Who's launched a real client site on Drupal 8? OK, all right, great. Well, let's talk a little bit about Pantheon and background. Not sure where that noise is coming from. Anyway, so Pantheon at this point is running over 100,000 websites. Billions of page views every month. We've got over 1,000 allied agencies working with us. Thousands of web developers every day are using our platform. And we see standardization really as the key to our success. Our founders come from the agency world. Our founders were running Four Kitchens and Chapter 3 in the United States. And like just about every web development agency, they had to look at the hosting market and pick from different solutions. They're shared hosting, where multiple websites are all put on the same server. And when you're using this model, you're optimizing for cost. You can host websites really cheaply on shared hosting. But you have the problem of sites sharing resources. One site getting a traffic spike can bring down everything. With single VMs, this is a step up. You're getting better isolation of resources. Yet you may have difficulty scaling. With clusters, you can build out custom cluster infrastructures with a load balancer, scaled to really big traffic levels. And this is what the Pantheon founders really specialized in as they were working at Chapter 3 and Four Kitchens, building larger and larger cluster infrastructures for bigger and bigger clients. Of course, in practice, it can start to feel like this, though, where you have multiple hosting options all on different servers, each with slightly different release procedures, even if you're trying to use the same conceptual best practices across the board. There are different passwords to remember, different Git branches to keep track of. And Pantheon takes a different approach. We like to think that, regardless of the size of the site, conceptually, the developers are working should be able to keep the same mental model in their heads for the infrastructure underneath the site. So if you have a very large site, you're still going to have a load balancer out in front, that's where you can do caching, PHP containers behind that, and basically a container per service, database, Redis, et cetera. And if you're working on a small site, again, each service is running in its own container and you don't have to change your mental model as you move between small and big sites. To talk a little bit more in depth about this technical level, and really what we're getting up to is the workflows that this technology enables. So I think this technology is interesting, but mostly what this presentation will be about is the workflows that get enabled when the technology is solid. So at our edge layer, we've got varnish, again, HTTPS termination also happens here. If a request isn't living in your varnish cache, well then it's going to get passed off to our runtime matrix of PHP containers. If it's a small site, all traffic is probably just going to be sent to one PHP container. If it's a really big site, maybe there are up to, well, really no limit, but maybe a dozen containers are splitting the traffic. MariaDB, again, is living in its own container, so MySQL just works. Redis is there as well as an object cache, though we're hoping Lcache, that the module I was just talking about, could replace Redis for a lot of sites. Apache Solar, again, is there, and the Drupal 8 module is it in progress for doing solar search. Valhalla is our custom file system that is extremely fast, can sync between Pantheon's environments in an extremely fast way and just works. So when we do this kind of standardization, we find that agencies can benefit from the customizations we've made specific to WordPress and Drupal. You get the benefit of the same console tools, the same command line interfaces being used for every single project. If you're putting all of your projects on Pantheon, you can write the same kinds of automation scripts if you're wanting to host your repositories themselves on GitHub or Bitbucket, you can use the same automation scripts for all of your sites, and if you don't want to do version control outside of Pantheon, well, every single site has its own Git repository and you can do all of your version control just on Pantheon. So the basic idea that Pantheon started with, the basic technological idea that we're enabling and providing for every single site on Pantheon is that in addition to a live environment, you should have at least two other environments, a test environment basically to simulate deployments before a set of code changes goes to live, you should simulate that deployment in your test environment. In addition to the test environment, you should have a development environment where code probably isn't going to be considered stable, where you may even be editing on that development environment. If you've got a large team of developers, maybe you're going to need multiple development environments. So as changes get made in development environments, get committed to Git, those changes get pushed up, test and live, all the while content lives canonically in your live environment and the database files can get cloned down from the live environment to test or dev. So just a brief detour over to the Pantheon dashboard. So for those who haven't seen it, the Pantheon dashboard is really the way you interact with Pantheon most commonly. So I'm signed in here to my Pantheon dashboard. First, my user dashboard gives me an overview of all the individual sites that I'm connected to with my login. These could be my personal sites, these could be client sites, any sites that I'm connected to on Pantheon I'll first see here first and foremost. Having a test account doing a lot of demos, I've got a ton of sites connected to my user. We also have this concept of organizational dashboards. So here's an organization that we made specific to this Dublin conference and what we have here is a list of all the sites connected to this organization. So if you're working at a web development agency, you're probably going to have an organization for your agency on Pantheon. There, you can see all the sites for your organization. You can filter those sites by the upstreams that they're connected to, basically versions of Core, Drupal 8, WordPress, custom distributions if you use them. You can also filter by things like tags if you're separating out the sites that are in active development compared to the sites that are perhaps in long-term maintenance or really whatever tagging you want. We also have this concept of people being connected to an organization with different permission levels. And this is really just the same concept that you have in Drupal Core of people having different permission levels. So the administrator role gives you the highest level of access, basically the ability to add more users, to remove users from the organization. The team member is more of a default role that probably would be given to the majority of the people within your agency. And then if you're using outside contractors, you can give them a restricted developer role that will give them access to development environments but not access to due deployments. Also, we've got the individual site dashboard. So the most important thing with the individual site dashboard is that idea I was just talking about of dev, test, and live environments. So what we're looking at right here is the dashboard for the dev environment. Right now I'm in SFTP mode. I could copy this connection information and open up an SFTP view of this site. I could get cloned this site. I could connect directly to the MySQL environment for this specific environment. And I can see the code that's present on my test environment and the code that's present on my live environment. So that's the basic idea from a technology standpoint. And what I want to spend the bulk of the time here talking about is what this means for an agency day to day. What this changes for an agency in the way you do your work. So we're going to talk about a number of items in the project lifecycle, the common lifecycle that you're going through, building sites for clients and how Pantheon can improve each step. So just the spin up of new projects in the first place. So one of our basic offerings is that you don't have to manage the hardware anymore or you don't have to manage the detailed configuration of AWS anymore. So I'll be pulling a number of quotes here from a lot of our case studies. So this was a case study from a site of University of Texas alumni who got referred to us from Four Kitchens. And basically they were most satisfied with the fact that they didn't have to manage the hardware anymore. So we give you this dashboard that gives you the ability to spin up new projects really in just a very small number of clicks. You can have a brand new Drupal 7, Drupal 8 site running in a very small number of minutes. Basically three minutes you've got a new site. Another workflow that we enable is the sharing of code across a large number of projects. A lot of agencies want a common starting point. Maybe you're building a large number of nearly identical sites. This is particularly common in the university use case. So we have Arizona State University running on Pantheon. They basically have a team of web developers within the university that to a certain extent acts like an agency, a web development agency within the university. And they're running now over 2,000 websites on Pantheon. And the way they're able to do that is with our model of custom upstreams. So we give them the tools that let them focus on the thing they care about, making these websites as good as they can be. Whereas before Pantheon, they were most focused. They were spending too much time managing the infrastructure itself. As you get to that high number of websites, as you're managing websites in the thousands, it's easy to lose time just to the maintenance of the servers themselves. So basically, we took that concept of distributions. That's been a concept that Drupal developers have been comfortable with for years and years. Panopoly, Open Atrium, this concept of a flavor of Drupal core, possibly with some contrived modules thrown in, and we put that in a product that we call custom upstreams. So you may do what Arizona State does and use this concept to spin up a large number of identical sites. I was recently working with an agency that builds a lot of websites for individual independent schools, so grade schools, high schools, and they use this concept of custom upstreams to basically make all of these sites nearly identical. The customization they do on the per site level is in child themes, it's in configuration to views, but largely the code is identical across the board. Some agencies use this just as a starting point. So you may use this for your version of core and the 12 contrived modules you use on every single project. A starting point, a common place where you can update views, update C tools, update those modules that get used everywhere, and then deploy those security updates as they get made to core and your common modules all at once. Let's also talk about the need for multiple development environments. A lot of agencies want a development environment per developer, maybe an environment per Git branch. And when you have a strong tool like that, you can get to a really large scale. So this is a quote from patch.com, it's one of the largest sites on the internet. Millions of page views, they have very strict uptime requirements, millions of URLs, they're handling a huge amount of files, and they only have four developers, and they would not be able to do what they do without Pantheon. Pantheon is able to give them the tools they need, so one tool they use a lot is Multinev. Again, this is basically the idea of an environment per Git branch. With only four developers, they wouldn't be able to work on a site as complex as patch.com without making sure that every change that they're doing to their code base is truly tested. So with Multinev, you can have a higher level of confidence that what you're working on is stable before it's getting merged into master. The very last thing we want to happen is for you to be finding bugs in your live environment. So we want to make it as easy as possible for you to find bugs, find performance problems as early as possible in your development lifecycle. And if you're just doing DevTest live and you have multiple developers, there may be a pressure on your development team pushing you to get code out before it's really ready. With Multinev environments, with the ability to keep your work separate, you can have a higher level of confidence that each feature is truly ready to go before it gets merged in. That new complex feature can stay in a Multinev until it's truly ready. You can spin these up at any time. You can spin these up with continuous integration scripts. You can spin these up with the click of a button. You can spin these up with our command line tool. Additionally, patch.com benefits a whole lot from our performant infrastructure. A lot of agencies spend the time of their best developers doing things that aren't billable for clients, like doing things like spinning up servers, spinning up Redis. And that has an effect on your bottom line both for your agency and for your clients. So if you don't have to spend hours and hours of your best developer's time setting up servers, managing servers, then benefits you, benefits your clients. So again, we're providing varnish out of the box. I always got nervous before I was working at Pantheon when it came to varnish things, because I didn't know where my responsibility started and ended with varnish. Maybe I was working at a team where someone else was at least on paper responsible for varnish, but I didn't know if I could fully trust that varnish was set up correctly. We have the same varnish running on over 100,000 websites. So you know what you're responsible for. You're responsible that for your Drupal website. We're responsible for making sure that we've provided the fastest infrastructure possible. Especially when you're working on issues of performance, you may have to pull in a specialized developer. Maybe your CTO is the person who knows the most about tweaking performance. In those situations, you may just wanna add one person to one project. You can do that as easily as adding their email address. You can also involve your project managers so that a company in residence, this is the company that builds a large number of individual school websites. So they're doing a very large number of projects for their team size. It's only a dozen or so developers, designers, project managers, maybe even less than a dozen. And they're working with a whole lot of clients, more than I would expect. They're able to do that because they're not customizing each site a whole lot. And now with Pantheon, even their project managers can spin up sites. Before they were on Pantheon, just the spin up of environments was a huge bottleneck. They would need their project managers to ask for the time of the one person who knew how to run the shell scripts that did server provisioning days in advance. Now they just find, oh, the project managers are on Pantheon. If a new project is coming in, click, click, click. Suddenly they have the environments for that new project and they're not wasting time bottlenecking on their most experienced developers who themselves wanna be doing things other than running shell scripts that set up sim links on a shared server. Of course, then you've got to get to that state of launching a website. You're building the site. Of course, what you're aiming for is launching it. And I feel with Pantheon, you can be so much more confident in launching. Often when I was developing without Pantheon, I felt like I was building a bridge from one side of a river and another team is building the hosting infrastructure on the other side of the river and we're hoping that we meet in the middle by the time the thing needs to go live. And that's extremely stressful. I don't wanna feel like that. I wanna feel like the hosting bridge, the platform is already there. I just need to make a site, send it over the bridge and trust that the hosting infrastructure is there that I'm not going to have to delay my launch because at the last minute, we find some conflict between what the developers have been building and the hosting infrastructure that's getting created, perhaps by a different team. So, White Views Media is able to trust that the live infrastructure is there. It's there for when their clients are ready to launch. They're able to tell their clients, just give us the word that you wanna go live and we can get you launched really, really quickly. With that DevTest live pipeline, you can be using all three of these environments from the very beginning of a project. And this is really your choice. The first time I used Pantheon for a real client project, for the first couple of weeks, we only used the Dev environment because we didn't really have a canonical database yet. It felt a little bit like overkill to be pushing every single change. DevTest live, so for the first couple of weeks, we only used Dev. And then as we got a little bit closer to launch, we thought, okay, we should just make sure we can get these all across DevTest live. Okay, fine. The earlier you get to that workflow that you'll use post launch, that's one less thing you have to worry about during site development. The last thing you wanna worry about in that final sprint is that your post launch process is going to work. So one of the things you have to do post launch is apply updates, apply core updates, apply security updates to core, to contrib modules. You have to do all kinds of work. So in Residence, that same company that does those school websites, they found that Pantheon just saved them a ton of time over the long life of a project. They were spending a ton of time doing security updates in different environments. So one thing we provide for every single site is one click core updates. So anytime Drupal 7.50 comes out, it's there in the dashboard, you click a button, it gets applied. That's, in my opinion, much easier to use than the process recommended on Drupal.org, which is literally a 12-step process of download an archive file extracted in a very specific way, run update.php. You can, with one click, apply the updates from core in the dev environment, make sure they work in the dev environment, make sure they work in the test environment before sending them out to live. Connecting continuous integration processes. This is something I spend a lot of time talking about with agencies. Agencies often come to Pantheon because they're looking to level up their continuous integration processes, and they don't know exactly where to start. So Jisadi was one such agency, and they're now starting to use what we call our Quicksilver tools to automate with testing, automate more continuous integration processes. What I like about Pantheon when it comes to continuous integration is that we're a stable base. Continuous integration enables a lot of iterative development practices. I think if you're trying to work in an agile mindset, you should be using continuous integration to verify where are we right now. With Pantheon, you know you are starting from a stable base. If you want to do things like automatic compilation of SAS through CircleCI with a GitHub repository and run automated tests on every single push, and you don't have any of that right now, that can feel overwhelming. And a lot of the agencies I talk to don't know quite where do they start. And what I like is that with Pantheon, they're at least starting from a stable base. They know that if they keep their site on Pantheon, the site itself is going to continue to work, and they can step by step introduce whatever automation they want on top of it. So notifying external systems. A lot of continuous integration processes that people use with Pantheon have to do with pointing instructions at Pantheon itself. Sometimes you need Pantheon to talk back out to external systems. What I've got here is something that you can see down at our demo booth. What I wanted to show in our demo booth downstairs is that we can verify with New Relic that PHP 5.6 is faster than PHP 7, and I want those stats to be live all the time. So all we're looking at here is the response time of a site stretched out over 12 hours, and every half hour I'm running the same script that switches from PHP 5.6 to PHP 7. The reason I'm showing this here is because as we're adding more and more integration points, I'm finding that I can think much more creatively about the kinds of workflows I want to set up. Without Pantheon, it wouldn't be particularly practical for me to set up an environment whose only purpose is to switch from PHP 5.6 to PHP 7 every 15 minutes. That's not a very practical thing, but it's the kind of thing that I like to do in a demo just to demonstrate the kinds of flexibility that you get with Pantheon. As we're adding more and more integration points, you can script instructions through our command line tool. You can have Pantheon talk back out to external systems with our Quicksilver hooks. You can have Pantheon kind of talk to itself, which is part of what we're seeing here. Each of these vertical lines is Pantheon sending a notification to its own New Relic agent saying I've deployed another change. So each of these vertical lines that we see here is either switching to PHP 5.6 or PHP 7, and we see big spikes up and down, accordingly, as we switch from PHP 5.6 to PHP 7. So I hope this is a bit of inspiration to show you the kinds of automation you can do with Pantheon with all of our different tools. These platform hooks give you the ability to script responses to Pantheon level events. So if you want to do something like every time you deploy your Drupal 7 site to test or live, if you want to revert all of your features, we have an example for how you can do that. If you want to do a config import with Drupal 8 any time you deploy to test or live, if you want to notify your Slack channel every time you deploy to live, these are the kinds of things you can do with Pantheon and do in exactly the same way for every single site. These small bits of automation we find when added up over time really save you time and money and save mental overhead, which in my opinion is our most important resource. Often what we're really selling to our clients is our undivided attention. And when our attention is getting pulled onto, wait, did I revert that feature correctly? Did I do that deployment exactly correctly? We don't have as much mental energy for our clients. The more you can automate, the more you can standardize, the more time, the more energy, the more focus you have for your clients. And then you don't have to reorient on every new project. So a lot of agencies find that they do have more time and energy to focus on their company, to focus on the things that they really care about. I find a lot of what Pantheon does exciting. I'm excited by what I can show with New Relic. I'm excited by our varnish integration. But before I worked at Pantheon, when I was a Pantheon customer, what I liked most was how boring it felt. It was a hosting solution that just worked. All I had to do was send Pantheon a working Drupal site and I could trust that it worked and not worry about it. I could focus on what my client really wanted. I didn't have to reinvent the wheel every time I started a new project. I didn't have to figure out how I was going to do each workflow step. So these are the kinds of things that you can do on Pantheon. We hope that you find yourselves able to deliver more value to your clients, try and experiment with new things amongst your development team, and move your company forward. So I think we've got quite a few minutes here for questions. I'm hoping I've inspired some thought. I'm here to answer any questions at all. Hello. Hello. Yeah. They are in Chicago. We have one data center on Rackspace in Chicago. And yeah, every time we come to Drupalcon Europe, we're asked about that. So it's not a fixed point on our roadmap right now, but it's the kind of thing we certainly do think about and hope to have a more concrete answer in the future. Sure. So we find that the further you get from the data center, the speed of light starts to matter just a little bit. So we do recommend CDNs, especially for high traffic sites or when performance is extremely important. If your audience is primarily in the US, CDNs are still a good idea. The further your primary audience gets from Chicago, the more important a CDN gets. Yes. Sure. So first in Drupal 7, if you're patching core, then either the next core update has that patch included, in which case you may have to resolve a merge conflict. Or if it's exactly the same patch, then it may just work because it could see that your local is identical to the change set coming in. If the patch you're using is not in the next release of Drupal 7 and that file hasn't changed at all, then the merge should work cleanly. If that's not the case, if the same file is getting edited or the same place in the same file is getting edited, then you might have a merge conflict, in which case you would have to manually resolve a merge conflict. So our copy of Drupal 7 is on a GitHub repository. So that one-click dashboard update is basically doing a git merge behind the scenes. It may fail if you've put a patch into core. If it does, you can do the merge locally basically by connecting up a local repo to that version of our version of Drupal core, manually resolve the merge conflict push-up and you're good to go. Okay, thank you. Sure. Another test to be infrastructure. Sure, so just for the recording, the question is about additional infrastructure. And in short, we see ourselves as specializing on web hosting. So there are some limitations. So for instance, for guaranteed email delivery, we recommend using a third-party service like SendGrid or MailGun. There are a bunch of different services that we would recommend. Basically, because of our containerized infrastructure, the IP address of your actual container could shift around at any moment. And especially if a spammer signs up for a Pantheon account, which they do occasionally and we have scripts to detect them. But basically, what one pattern we see is a spammer signs up for a free Pantheon account. I should mention that everything you saw today is free. You don't have to pay for Pantheon until you sign up on a custom domain and take that site live. Until then, you can use all these tools for free. But to stay on the answer to your question, there are some things that we do recommend offloading to third-party services like email. Another thing I should point out is really large files. So our file system is optimized to be as performant as possible for the types of files that commonly get served over websites. If you go above 50 megabytes for an uploaded file, then our file system gets really slow. And we have a hard cap at 100 megabytes. So if you are doing video hosting, then a video streaming service is just going to be better for any number of reasons than hosting the file directly on Pantheon. Even other things like we get asked sometimes about Node.js. It's just PHP on our services. So some people will choose to set up custom infrastructure inside that same Rackspace Chicago infrastructure. So at least their Node.js application is living inside the same data center. And then they don't have to worry about latency between the Drupal site living on Pantheon and a custom Node.js application living in a different Rackspace account. So for contrib modules, our own copies of Drupal Core don't contain any contrib modules. So you wouldn't get any merge conflicts there. If you're doing a custom upstream, it is possible that, say for instance, your custom upstream is providing views and C tools and maybe some features modules for default views. No, we don't. But we do have plenty of examples for, say, using our command line tool to auto-update. So one of the things one of my coworkers just did for a WordPress site was set up a continuous integration script that, I think, every day checks for updates to core or plugins. And if any updates are available, spins up a multi-dev environment automatically. And because these are just security updates, they shouldn't result in any visual differences between the two sites. So he runs a screenshot or against the live site and the new multi-dev environment. And if there's no difference in the pixels between the screenshots, we can safely assume, we think, that the security updates have applied and not broken anything and then automatically send that change set as far as you want. You could send it to dev. You could send it to test and then have a human click deploy to live, or you could automatically deploy to live as well. So there's not a Pantheon product level button for updating, contributing in an automated way. But there are plenty of people doing it with their own custom scripts. Anything else? Yeah? Sure. So the pricing is done per site. So our pricing starts at $25 a month per site and goes up from there. So that's the personal plan. The professional plan is $100 a month per site, $400 a month per site for the business plan and then for really large sites. Give us a call and we'll set up a contract. And with that contract, you'll get things like guaranteed uptime and such. I should point out as well that these guidelines that you're seeing here on page views are simply guidelines. These aren't hard caps. It's not as if we're even counting the page views to your one site. These are just rough guidelines in our experience. This is roughly where the breaks happen. If you have a site with a ton of anonymous traffic, then you can probably stay on one of the lower plans because if it's anonymous traffic, you should just be getting all cashed hits. If you have a small site with low traffic but all of your traffic is authenticated, then perhaps you would experience either some slowness or a need to move up to a higher plan. All right, well, thanks, everyone. Thank you. Yeah, feel free to stop by the Pantheon booth if you have any more questions. Thanks.