 Hello, everybody. My name is Jonathan Pickard, and I manage the Cloud Infrastructure Engineering Team at PayPal. Sorry, I skipped ahead. It's my pleasure to share some unique insights into the transformation that we made to support Cloud at PayPal. So a little bit about PayPal before we start. Let's quickly run through some key details on what PayPal is and what we do. We're a payments company. You can think of PayPal as a digital wallet, where there's one convenient, secure location for you to make purchases in store or online. With payment innovations like that, we continue to grow. And as these numbers show, 137 million active users, $300,000 worth of payments processed each minute. Nearly 200 markets over 20 currencies. We are the world's most widely used digital market. And now that you know about PayPal, you should also know about PayPal Cloud Infrastructure Engineering. We manage all non-development aspects of Cloud at PayPal. And we have a sister team that handles development. Our work includes infrastructure and cloud deployments in multiple data centers across multiple regions. It also includes CI CD to support our development team in producing and propagating quality code and features. We have an intense focus on creating and maintaining reliability within the cloud in order to fix and break things ourselves before our end users do. And we certainly can break. And we've got thousands of compute nodes and thousands more VMs taking production traffic today. We're constantly adding both to support our continued growth. And now that you know about my team, I'll tell you what we've done. We've done more with less. We have a very small team of four staff, yet we deploy and manage cloud at a very large scale. Thousands of compute nodes, multiple data centers. We've reduced what used to take months to mere minutes. This is real, and this is happening. And we're leveraging these cutting-edge technologies and methodologies to enable success. We've engineered our cloud platform to enable ourselves to solve complex business problems and reduce time to market. And we've been able to implement development testing and deployment automation that leads to higher quality cloud products and services, and ultimately, happier cloud customers. And we did this by embracing OpenStack and Agile. And this is how we did it. So to tell this transformation story, we've got to jump back a bit because we first had to build a strong foundation. We started by revamping our operating system using a customized version of Linux that met the requirements of our use cases. We upgraded that OS in place on thousands of physical boxes. With our workloads now running on an OS that could be virtualized, we then validated that those workloads were suitable for virtualization themselves. Again, we're talking about production workloads, real applications taking real payments. We then built and deployed our apps onto VMs and measured their performance while taking real traffic. We fine-tuned requirements to ensure that we had the right amount of CPU, RAM, and disk base for those workloads so that we didn't waste resources. We proved that our applications would thrive in a virtualized environment. And we knew that we could now leverage OpenStack to enable infrastructure as a service. We then repurposed existing teams to support cloud, and we placed our top resources on this critical program. And it was then that the PayPal Cloud was born. The technology was decided. That's OpenStack. The staff was in place. But the old methods of task and resource assignment wouldn't work for this transformation. We knew we would be running at a very fast pace with many moving parts and very high expectations, getting even faster and even more complex as we scaled out. So we embraced Agile, and we did it without anyone mandating that we do so. And we did it without fully understanding how traditional engineering work could be done in an agile way. Siran Mandar, the director of Cloud at PayPal, presented at the last OpenStack summit in Portland, Oregon. And one of his themes was agility, agility, agility. And that theme remains true now. And we continue to realize a very real decrease in time to market for customer-facing services, a very real decrease in getting services deployed, and our ability to now utilize the engineering culture of PayPal to deliver specialized cloud services where needed. So agile was identified as a means to enable team transformation. This is from a business level. And the goals are very clear. And the processes are outlined for implementation. But taking traditional infrastructure engineers and throwing agile at them isn't easy. You're talking about a set of processes and a business mindset and applying that to engineers. You have to make it real to them with value presented at the personal level. And you have to phase it in. This is not an overnight change. One of our saving graces was that we were all new to agile. So we all had to learn together. And the pace naturally set itself. We didn't know enough to bite off more than we could chew. So looking at this at the personal level, it becomes about embracing change. Some accept change without question. Others accept struggle to embrace. Some refuse to accept or embrace. This is expected, it's normal, and patience is required. The strategy on embracing this massive change to how engineers have worked for their entire careers is to showcase the success throughout the transition, let everyone see for themselves that the new processes and mindsets are working, that their peers are delivering, and that the business needs are being met on time and with quality. In our first six months on this journey, my entire team bought in and embraced agile. We all began working on things that didn't directly align against past skills. We quickly learned OpenStack, and we continue learning new things about OpenStack in agile every day. And we're thinking past the Ops side now, and we're getting deeper into the stack. And we're not quite DevOps, but we're definitely Ops Dev. So in addition, with daily attention to ensure that we're on track, we feel stronger as a team overall. We're definitely closer as a team, and we're doing more with less. Now I want to talk deeper on the agile tools and the processes that we use to engineer OpenStack at PayPal. Our only constant is change, and we keep saying by finding consistently in a constantly changing world. Our book of work tells us what the business needs us to do and when to do it. This is extremely valuable in enabling our success. If you don't have a book of work, make one. Talk with your team, your peers, understand what they need you to deliver, and prioritize all that work. Balance it out between the amount of work to do versus the amount of people you have to work. We use JIRA to track against our book of work. We take our work items and stories, assign owners, and create estimates, and we define milestones. We use Kanban as our methodology for enabling agility. Kanban prescribes that a resource work on their highest priority item and only that item until they're completely blocked or until they're completed or blocked. JIRA contains very nice capabilities to enable story prioritization and Kanban board visualization. So now we've got the stories created and assigned. People are working on the highest priority stories, and now we need to track it to not only ensure that milestones are being met, but more importantly, to know when milestones are not being met, understanding why, and clearing those blockers to resume progress. I'll run through some of the larger themes from our learned lessons in the transformation. Agile turnaround was not overnight. Three months in, we eliminated ad hoc work patterns with frequent reminders. This was a lot of repeating, don't work on anything that isn't a JIRA story, and only work on the highest priority story until you're done with it or blocked. Six months in, we began tracking work on a per-subtask basis rather than just on a generic JIRA story. This is a very deep understanding of the steps required to accomplish each step. Outline them all as unique subtasks and checking them off as they were completed. One example of this is a new cloud deployment that we did in a production data center. We had a master story in JIRA that had 53 subtasks. As each was completed, we closed it out and we tracked status against each subtask during our daily standup. Nine months in, we enabled individual autonomy by tracking work on a per-milestone basis rather than on a per-subtask basis. The per-subtask tracking let the team know the level of detail needed to ensure on-time deliveries. But it was very hands-on and appeared as micromanagement. This was something we knew we had to get the importance of on-time task milestones, on-time task execution, ingrained in the mindset, and we followed it up with a shared understanding that the better way is to track milestones and not every individual subtask. Each team member is now enabled to execute work as they please, identifying their own subtasks and executing against the defined milestones. Now looking back at my previous example of our production data center deployment, all 53 subtasks, our next production data center deployment was tracked by milestones, four of them, that aggregated each of those subtasks and gave autonomy to the executor to do what was needed in the order that they deemed appropriate. Engineers like this autonomy, and it was critical in our journey in ongoing success. Another thing we found out is that sprints didn't work for us. We ran a couple of months of two-week sprints. This resulted in more items than not spilling into the next sprint, and the cycle repeated. We found Kanban, and it works well for us. We aren't artificially restrained on time, and we don't have to artificially group unrelated deliverables together. Our engineers have a very clear understanding of what to work on and when to work on it, when their due dates are, and what else is in their pipeline. Even with Kanban, we came across times where we had fires to put out, and resources got pulled into this without prioritization, without scheduling or tracking. Our solution to this was the liaison role, essentially a daytime on-call position that we rotate our engineers through on a weekly basis. During that liaison week, the liaisons work outside of Agile and handle any inbound support requests and escalations. When doing Book of Work task assignments, we take liaison into account and don't schedule work for that week or deliverables do that week. With these tweaks to Kanban, while we don't hit, when we don't hit our due dates, it's usually because of external blockers. Another thing we learned was in order to maintain a breakneck pace, came with it some big responsibilities that we didn't prioritize as high as we should have. Of all of our core infrastructure and open-stack services that we engineer, each one of them was missing at least one important requirement. So we did a gap analysis and asked ourselves these questions. Is it highly available and resilient? Is it able to be consistently deployed and managed? Is it documented? Is it secure and current? Is it monitored? So ask yourself these questions for each technology or service. Find the gaps, look for them, and be thorough and fix them. And when you do that, you'll eliminate technical debt. You'll get ahead, and more importantly, you'll stay ahead. That's the story. We built the foundation to support cloud at PayPal and executed on the vision with Agile. Comparing where we were before our foundation was laid versus where we are now, it only takes hours now to do what it previously took months for. The open-stack cloud that we developed at PayPal recently enabled the business to build thousands of VMs in just hours and support our peak holiday traffic expectations. And that isn't just virtualization. This is carefully crafted orchestration with DNS, load balancers, monitoring, and other services to allow for end-to-end single-button press deployments. This is why we've eagerly taken on this journey, why we've transformed, we've embraced open-stack, we've embraced Agile, we contribute to open-stack development, and PayPal's better off. And best of all, we're having fun doing it. Thank you for your time.