Platform Advantage: Velocity
Snap was one of the first large companies built almost entirely on a high-level cloud platform, Google's App Engine. Snap was founded in July 2011 - years before Google Cloud and Microsoft Azure were even a thing. Snap's choice gives us some interesting data on the future of Platforms as a Service (PaaS), which is what App Engine qualifies as (to be contrasted with a lower-level, Infrastructure as a Service, IaaS). Even before then, CEOs and managers have debated how much technology COGs to outsource for decades. Now, the answers to some questions are obvious, but new choices arose.
Culture: Snap needed fewer engineers to scale. Instead, using a PaaS, Snap outsourced much of the work to the platform (both technological and white-glove Google Cloud engineers). How did this affect the culture? On the one hand, it let Snap stay lean and focus more on other functions - product and design. On the other hand, institutional knowledge was lost - systems reliability and debugging, technical architecture, and the skills needed to evolve the technology.
Innovation: Innovation often requires dipping into a lower level of abstraction. As problems and requirements change, the previous level of abstraction may no longer be appropriate. The level of abstraction is fixed when a PaaS is used. Did this prevent Snap from exploring innovation pathways that might have been enabled by working at a different layer? Snap has also been focusing on machine learning and augmented reality applications. While those areas may seem separate from outsourcing technical infrastructure, much of the difficulty is just putting these models into production.
The Choice: Managers face a strategic choice: what level of abstraction to choose in the cloud? There is raw storage and compute at the lowest level (and lowest margin for the cloud provider). Services now live at almost all levels of abstraction: managed compute (Kubernetes) and application platforms (containers, functions, and everything in between).
Snap has been moving off App Engine for the last few years. Transitioning is difficult and costly. How fast could have Snap gone if they made different choices early on? Would Snap even have been able to launch and scale as quickly without App Engine? The tension between speed and correctness is the same tension I covered in Getting to Market with Rails. I suspect that the better answer leans heavier on correctness. This choice has a higher upfront cost but can move quickly (more significant returns) at scale, akin to the SaaS J-curve. It wasn't an infrastructure framework in that story but rather a software framework that companies chose to go fast. With infrastructure, the stakes are higher.