As at today I’ve been working with Section for two years. When I joined the company it provided a fully-managed service to its clients. For many this was the ideal arrangement: by leaving web performance to the people with the skills and the tools our customers were free to focus on building new features.
My professional background before I joined Section involved providing consulting services in the Application Lifecycle Management space. This included agile training and tooling and helping teams adopt Continuous Delivery and Infrastructure-as-Code practices and to realise the benefits.
Wrong way, go back
It was clear with my past experience that the fully-managed service approach was in conflict with the agile practices I had encouraged in previous teams and were being used internally at Section.
Our fully-managed service was only in front of our customers’ production websites and rarely one pre-production test environment too. Much of the service was a black box to the customers, not intentionally, but the way the system worked wasn’t immediately visible to those dependent upon it. We would always happily share details of the configuration, it wasn’t a secret but it became a barrier.
Even for the few customers who had opted to run our service in front of their pre-production, this was far too late in the delivery cycle to be discovering bugs due to assumptions made about every browser request reaching the origin web server during development - an assumption that could not be more wrong behind a caching service. In fact, these are the kind of bugs that are often best fixed through a different design, and changing the design when you reach pre-production, or worse production, is very expensive.
But it wasn’t just about assumptions made at the origin. Our own process of configuring the Section platform to achieve the best results for a customer’s website required us to analyse and essentially reverse-engineer the intent of various requests just from the network traffic and browser interactions. And while the Section team know web performance well, we just can’t know each customer’s website as well as the people building it.
Empower the users
The customer knows best what their site it supposed to do and we want to enable them to ensure their site is fast by giving them the tools to when it takes too long, and where it takes too long, and why, and help them to change both their origin website behaviour and their CDN configuration to work together for the best possible outcome.
By combining the tools and the data offered by Section with agile development practices, great web performance can be built-in to a website from the beginning instead of tacked-on at the end. With the ability to work with the CDN during the early stages of development, our customers can go beyond just caching static resources and realize the wins of offloading the dynamic HTML resources too.
This is what Section is providing today and will continue to improve upon and it makes me very happy to working for this company, knowing that it is solving one of the web’s biggest challenges to shipping quality websites frequently - a CDN market stuck with Production-only deployments, poor visibility, and slow to respond to change.
