Why Section?
We have built websites and served websites for customers. We have helped customers accelerate websites and provided them with additional capacity to push through major traffic events. We have tested tried and broken many of the technologies available today to help websites deliver content optimally on a global scale.
Two recurring themes we have found through this experience, are;
- Developers of web applications and operations teams which run them are frustrated with the clunky bolt on process for all Content Delivery Networks available;
- Money is being wasted on CDN features which are never used or turned off because they can’t be tested properly.
We wanted to solve these problems.
We have worked in and with some of the best agile web application development and operations teams around. Some of these teams can cut and deploy code at will in a continuous application delivery loop on vertically sliced applications. Testing is automated and metrics provide immediate feedback on code performance in all environments.
Without fail, the one exception to the agile nature of even these most advanced development and operations teams is the content delivery layer which sits over the top of the application in production (and possibly staging).
Modern CDNs have awesome features which manipulate the web code at the edge of the internet. Code which developers cut locally and operations teams deploy globally is being modified by the CDNs.
The test process for checking developed code against these CDNs may involve setting up a whole new CDN config for staging or test environments. Teams of developers never get to test their new code against the CDN until they have deployed to test or staging at the very best.
Operations teams managing CDN config tend to touch the CDN as little as possible. Making a change in directly in production is risky even if it is copying across config from the staging environment. If it involves manual steps, the risk of human error is always present.
When problems are found in production, we have seen development and operations teams reach first for the “off button” on the CDN feature rather than reworking the application code. Why? It’s a cheaper, easier and more immediate fix. However, the end result is CDNs are steadily reduced in active feature set to the barest essentials.
So we figure it would be better if the CDN was integrated with the development process.
In the same way developers want to run equivalent web server config and code locally as runs in production, we should be seeking the same CDN config. If the CDN manipulates the code, headers or web assets at the edge, then those manipulations should be tested and experienced and optimised as early as possible in the development process.
So we built Section which takes advantage of Docker containers to allow development and operations teams to pull merge and deploy a CDN in an automated fashion.
It’s a completely new way of thinking about CDNs coming at the problem of content delivery from the perspective of website engineers. We are excited to improve the software development and delivery process for ops and dev teams everywhere. Delivering to those dev and ops teams, more power, control and flexibility over their content delivery.
