Buying Workflows Not Cloud Parts
Diving deeper into
Jason Lengstorf, VP of Developer Experience at Netlify, on Jamstack's anti-monolith approach
we're looking for the next layer of abstraction
Analyzed 5 sources
Reviewing context
This points to Netlify trying to own the safe default for modern web deployment, not raw infrastructure. The product is meant to make shipping a site feel like pushing code and getting previews, rollbacks, CDN delivery, and serverless functions without ever touching the underlying AWS machinery. That matters because cloud complexity had become a tax on frontend teams, and the winning abstraction was the one that removed cost and ops mistakes from everyday work.
-
The practical shift is from renting cloud parts to buying a finished workflow. Instead of wiring S3, CloudFront, DNS, functions, and deployment scripts, teams connect a Git repo and get deploy previews, atomic deploys, rollback, and production hosting as built in defaults.
-
This is why Netlify and Vercel were often compared to Heroku. They wrapped commodity cloud services in a much simpler interface for frontend developers, then competed on which platform made common jobs, like shipping a marketing site or docs update, feel almost risk free.
-
The deeper implication is that abstraction becomes the main product until the edge cases pile up. Netlify positioned itself as broad and framework agnostic, while AWS tools like Amplify could work well on the paved road but expose users to underlying service complexity once they went off script.
The category keeps moving upward. The next winners will package even more of the cloud into fixed workflows, tighter spending guardrails, and cross framework portability, so developers can ship faster while thinking less about infrastructure, not more.