Fastly

Serverless comes with its own set of challenges. Cold start times* — the several hundred milliseconds of latency required to execute an inactive serverless function — cause delays in the user experience that too often have a major impact on conversion rates. Add in limited observability and resource contention, as well as emerging security concerns about side-channel attacks, and it becomes clear why organizations hesitate to move business-critical workloads to serverless. What’s needed is a different approach to serverless that’s highly performant, developer friendly, and secure.

Ticketmaster, a global leader in event ticket sales, faced a significant challenge in modernizing their tech stack to improve user experience and stay ahead of the competition. With over 40 years in the business and having acquired numerous ticketing businesses, Ticketmaster had 30-40 different ticketing platforms, each with its unique inventory and customer base. The company had been using a legacy Content Delivery Network (CDN) provider for over 15 years, which had become increasingly challenging to manage due to its complexity and the undocumented rules built over the years. The cost of delivery on their CDN provider was expanding, and the black-box nature of their legacy CDN required many professional services hours to configure, update, and manage. This made it difficult for the team to implement changes quickly and efficiently. Furthermore, the company had to support the needs of 16 different product teams within Ticketmaster, making the situation even more complex.

Andrew Barba, an engineer and iOS developer, was faced with the challenge of running Swift, a programming language developed by Apple and the open-source community, on servers. Despite the popularity of Swift in the Apple ecosystem, there was no clear pathway for its use on servers. The Swift community had been laying the groundwork for this, including adding support for compiling code to WebAssembly, but there was little traction. Barba found the development experience of writing JavaScript on Node.js to be lacking compared to building native applications in Swift. He also found the process of getting Swift packages into AWS to be too complex, requiring extensive knowledge about cloud architecture and Docker files.