The first post has been published: https://www.swyx.io/writing/cloud-distros
The second post has been adapted for Temporal: https://www.swyx.io/why-temporal/
these are bullet points of a blogpost on a topic i know very little about but i feel like there is something there that is happening as we speak
this might be better as two blog posts
- the Big 3 Cloud Providers are mostly (not exclusively) racing each other towards providing good cloud primitives.
- arguably this is not the best way to perceive their strategy as it seems GCP/Azure are verticalizing rather than matching AWS horizontally, but that's not relevant here
- Applications were originally envisioned to be run directly on these clouds, but, increasingly, intermediate providers are rising up to provide a better developer experience and enforce opinionated architectures (like JAMstack)
- Netlify
- Zeit
- Repl.it
- Begin.com
- Glitch
- Render.com
- Amplify
- Binaris
- Stackery
- ???
- The working name for this new generation of cloud providers, used by Martin Casado, Amjad Masad, and Guillermo Rauch, is "second layer" or "higher level" cloud providers.
- Nobody loves these names. It doesn't tell you the value add. Also the name implies that more layers atop these layers will happen, and that is doubtful.
- In the first (serverful) wave of Cloud, the abstraction from hardware to software was often explained as a 3 layer model: IaaS -> PaaS -> SaaS
- But all the big clouds are essentially PaaSes now - OSes are increasingly being abstracted away. So maybe we can use "second layer PaaS"?
- if we view the Big 3 as providing new "cloud primitives", then maybe a better name for "second layer clouds" is "Cloud Operating Systems". especially if the premise (if not the current reality) is your application seamlessly running across multiple clouds.
- Serverless cannot proclaim total victory until we can recreate DHH's demo from 2005 in 15 minutes.
- The plain fact is that has been hard to break up with the monolith - it is simply too handy to have everything in one place.
- Serverless functions (Lambda) are nice, but not nearly enough to replace everything we used to do in a single runtime.
- We can piece back everything with services and APIs, but this architecture is still far too bespoke and brittle and slow and leaky. (altho in theory we still get the benefits of everything being distributed, not worrying about horiz/vertical scaling, and pay-per-use pricing)
- the jobs that monoliths do that we have to reconstitute in serverless-land:
- static fileserving: often relegated to CDNs anyway
- functions: marginal compute
- gateway: for auth/sessions/rate limiting, etc
- auth is a hard enough problem on its own that it is offered as a standalone service, altho really it is made up of other elements
- socket management: for live subscriptions, maybe part of the gateway
- jobrunners: for long running compute (aka batch processing?)
- queue: for not dropping messages and jobs (aka stream processing?)
- scheduler: for coordinating functions and jobrunners. at most basic level this is a cronjob, but you will eventually want a smarter scheduler for prioritizing work across limited allocated resources.
- object/cold storage: slower, immutable, large, (long lived ?) persistence
- database/hot storage: fast, mutable, small, (short lived ?) persistence
- related jobs: searching, caching
- (metajobs: error logging, usage logging, dashboarding, CI/CD)
- (unique to cloud: latency aka edge computing. see victor bahl at msft)
- each has to be able to talk to and make use of each other EASILY to match the DX of monoliths
- keeping up with this stuff is a fulltime job, the media company covering this is literally called The New Stack
- infinite scalability is nice, but not at the expense of infinite potential cost. a good cost cap + failover story is also important to DX. Users understand "sorry our service is temporarily down because of a sudden surge in demand", but the opposite of "sorry your bill this month is $1m because of a sudden surge in usage and it's up to you to figure out why" is less well accepted by developers and their employers
- so maybe the answer to breaking the monolith up is to reconstitute the monolith inside the application framework - standard APIs that expose the various functions of a monolith.
- the Serverless Framework is an early pioneer of this, but seems focused on the IaaC job rather than the unified interface job (and doesn't have as good an answer for non serverless stuff)
- Zeit and Next.js take the monorepo -> microservices split rather seriously and have vertically aligned themselves all the way down to the frontend library layer - is there more to do here?
- Redwood is TPW and team's effort to do this atop Netlify, but the db layer is currently on Heroku.
- i think Cloud Operating Systems are well positioned to offer and coordinate these jobs and expose a good DX layer for users.
- Binaris and Repl.it focus on functions
- Zeit and Netlify combine static fileserving with functions
- Begin combines data with the above
- Amplify adds storage with the above (and, for some reason, XR?!)
- what about the other jobs of the monolith? currently, we are told to spin up services the regular old way. or duct tape together a bunch of solutions not designed for this task and not integrated with anything else.
- not. good. enough.
I think the Cloud OS that reconsititutes the monolith earliest, will be a natural aggregator of every application developer moving to a serverless first world.
note - kevit scott - reprogramming the american dream, AI given infinite compute. the guy who built a supercomputer on aws.
again the mega caveat to all of the above is that i am a novice in this industry and am ignorant of both how hard it is to do all of this and the full capabilities of every platform
Loving the deets here. Curious if I can pick everyone's brain on this since I'm working to build the "next layer" solution. But not sure if it's a layer or an extension in the near-term, so very curious.
Few questions first:
How did they pivot? Been watching them (and was a customer) for a while. AWS isn't the only cloud, they've got tons of services and a PaaS of their own and the offering they have in k8s (Ocean) in how they evolved their technology to dynamically generate node pools based on usage (not perfect, but still amazing) would be an evolution more than a pivot IMO. But curious what if you saw something more here.
Heroku's success was based on Github + ruby as well, so github (and git ecosystem) is fueling the world here. I think netlify making it dead simple for web devs to get their code in git to the cloud globally is the key to their adoption. I spoke to a web dev last week and they told me my product is too hard (it is) to use because there are no options for their react app to be hosted. Right now my platform says "Website" and you have to choose "Nodejs" and your node version versus "React" and it's version. BIG DX DIFFERENCE This is how Netlify has kicked ass IMO.
This is interesting. It took me 7 years to convince a Java dev to get out of their comfort zone and try node so. So I think we're waiting on all the java devs to get old and retire? ;)
You'd be surprised at how low the revenue was when it was acquired. This acquisition was a huge bet on adoption versus revenue and salesforce through sales at it to make it a 100M+ ARR business. I don't know the inside deets on Firebase though, but guessing similar story.
I think people leave Heroku for more control and cost optimizations and they ditch the DX, or try to home-grow their own. I'm finding companies are winning better if they focus on dev/staging for enterprise and take the final artifacts/images and throw them at a devops team to handle. Merging the line in giving DX for faster development but near-same or identical cloud environments so to lessen the dev to prod insanity is the problem. But you're totally right - I'd leave heroku because I'm stuck with mlab.
This concept of simplifying the cloud or a layer on the cloud may be getting old. We're all really good at abstracting stuff all the time (especially people working on frameworks, dev tools, SaaS/PaaS/IaaS). I just listened in on this podcast which talks about how Kubernetes (k8s) will not be a thing in 5 years. Sounds controversial, but the conversation takes it to k8s will be a layer under the layers and just not be the big buzz anymore. At the end of the day, k8s is massively supercharging Docker which was another short buzz that has become the norm in next-gen infra. But no one says they will spawn a container on k8s, they said they will spawn a pod - (same thing for people who don't know k8s).
I like the concept of simplifying the cloud, but as an architect, it usually scares me (background - serious developer architecting platforms that scale in the > 100M users, with apps transacting > $1B USD /annum) and losing "control" of my app with "magic" under the hood. The target audience of enterprise (who cares that much about control/security/scale) versus developer/SME/individual/startup (who may sacrifice control for power/cost/get $h1t done) is two very different audiences.
Curious what you guys think but Cloud DX to me for the next-gen of businesses starting now or recently are caring about:
Instead of a Cloud OS, What about a Cloud Package Manager with the goal to make every git repo build + deployable + operatable as simple as a
package.json
orgo.mod
file. Well you know, that file making a baby with a Dockerfile of some sort. (An open-source pitch I'm working on) I guess thinkdocker-compose
for github? Try not to compare to docker-swarm because it's not downloading/referencing git repos, and swarm is dead (IMO). Of course, this file is more devops/k8s friendly, but a sweet DX dashboard experience can be thrown on top ;)Overall I think Web Dev / Static Site (JAM) has reached enough platforms and success with the list you have above. I think Serverless functions and using a framework or needing to change the way you code hinders DX and is a big jump that may be unnecessary / requires too much thinking for PoC/MVP products. My thoughts are that we need to continue to simplify any cloud backend (with no toilet paper required) and no limits to what technology you can use in dev/prod (ie: mongo, kafka, memchached, minio, sidekiq, anything). This would come with cost saving instances (serverless containers) and enable them as always on in prod if you don't like cold starts. Once this is dead simple, we can introduce ways to take MVP/POC and extend them to functions.
As much as I don't love monoliths, I firmly believe starting in one is better. Coming from the gaming industry, I loved how Hearthstone was built in Flash then ported to Unity when they <3'd the PoC. Why? Because they didn't want to reuse ANY logic and wanted to code as if it was gonna be thrown away when after reaching MVP. I think new ideas should adopt this thought because the time it takes to learn and deliver serverless functions today isn't worth the time to throwing up some logic on the cloud and bootstrapping a frontend and having the world quickly judge it to iterate further or fail fast.
I wouldn't put tasks/scheduled jobs in a monolith though =p So the conversation of today's generation of monoliths should probably be defined. But I think this is enough of a wall of text for now ;)