Full Stack Web Performance

Introduction

We are in the midst of another tidal change in the software engineering and IT industries. This has been going on for a number of years already, but like the frog in the pot that doesn’t notice the water slowly beginning to boil around him, some of us might not have noticed the transitions in our environment. We’ve overlooked these transitions because there have been many smaller ones that we just adjusted to, that accumulated to be a big significant change. Or maybe it’s just that the ideas behind these changes have been talked about for quite some time, but it’s only relatively recently that they have coalesced into actionable patterns that are easy to implement and reproduce.

I was reminded of this recently because some of my teams—specifically those that are working on products that we made three or more years ago—are migrating their products from physical datacenters to cloud platforms.

Think about that for a minute: three or four years ago we were starting new projects first by requesting nodes—in some cases, virtual machines (VMs) on a hypervisor, and in other cases actual physical boxes—and IP blocks, waiting days, or in most cases, even weeks for the boxes to be configured. Today, of course, we run a script and our cloud platform of choice spins up nodes preconfigured with the image that we want nearly instantaneously.

Our notions of web performance and capacity planning, too, have changed. Now if we need to scale a cloud web-native application to handle spikes in usage, it’s a matter of only selecting a checkbox and paying for the scale that we need. There are also new challenges in the field that we are just now discovering, and coming up with workarounds for, like the appropriate use of availability zones (think about the Amazon Web Services outage of 2017 that brought down a significant portion of the web) or even how to use multiple cloud service providers to serve a single property.

Even our organizational identities are changing. If someone is a web developer, why can’t they learn to request and configure VMs from their cloud provider? And if they are setting up the machines on which their code resides, and maybe even the firewall rules, why not then set up their own log consumption flow, then at that point are they still just a web developer, or are they maybe a full-stack developer or even a DevOps engineer?

These are just a few examples of how a concept like DevOps has changed the day-to-day activities of our work routines.

Who This Book Is For

DevOps encapsulates different things to different groups. Some interpret it as an integrating of traditional infrastructure or Ops roles into a development team, whereas others bundle security in there and call it DevSecOps. Maybe some groups have different interpretations of what Ops means, defining it as incorporating not just infrastructure but also production support roles.

As such, this book is for anyone who needs to think about and deal with performance in a DevOps environment. From web developer, to DevOps engineer, to engineering manager and architect, this book is intended for you.

This book has set out to address how web performance fits into this modern landscape of the all-encompassing cross-functional DevOps team. You’ll find the topics organized into three high-level areas of focus in a product development group:

Client-side

This is the user-facing piece of the application. It will generally run on the user’s hardware.

Infrastructure

This consists of the facilitating pieces of your application, specifically the content delivery network (CDN) and cloud service.

Operations

These are the practices you put in place to monitor and alert on the health of your applications

This book also presents significant but quick wins throughout. That is a relative term, but the way that I have approached this is to take advantage of existing tools and libraries that are fast to integrate with but have huge payoffs. Depending on your architecture and team makeup, the level of effort for each of these solutions or recommendations should be measured only in days and weeks, not months for the most part (at least from my reckoning; your mileage may vary).