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
@madiodio seed is awesome and the tutorial series ServerlessStack makes is also wonderful.
It seems like what you're really describing is just different granularities of system integrators.
20 years ago, Monoliths were a necessity. Virtualization technology was not commonplace (at least on a developer machine) and obviously containerization technology was not adopted. There have been so many fundamental changes since that time:
"Cloud operating system" is also an inherently flawed concept. It's too dynamic and wishy washy and will continuously change to reflect the current needs of the market. If someone in 2000 saw the 2020 version of AWS I have zero doubt they would consider it a "Cloud operating system" (and probably a remarkable one at that). What it seems like you're really describing are integration platforms that serve the specific needs of a sub/niche market. Context is also important here, the cloud OS you're describing is really a cloud OS for building a specific type of application, web apps and web sites. While AWS does care about this market (because they always like more money) it's wrong to pretend that it has short-term impact on business. Remember, the majority of AWS profit/revenue comes from two services EC2 and S3. That's to say that the majority of the money in the cloud space is not going towards webapp hosting and services, it's going to enterprise ETL workloads running on Java. This is true even within a progressive cloud niche like Lambda. I don't have a source unfortunately but when I went to SLS conference in 2018 the AWS guys said that while there were 10x more JavaScript Lambdas deployed compared to other languages, 90+% of the cycles were for Java Lambdas. This is inline with the numbers I saw when I was lead architect of a low-latency Lambda competitor.
I also think the "Reconstituting the Monolith" section suffers a bit from your bias. From the little I know about you, much of your time is spent focused on the cutting edge of one niche part of the larger cloud market. Don't get me wrong, the integration play you describe in that section may very well be a viable and lucrative product offering. The problem is that it's just one of MANY integration platforms being demanded by different sectors of the market constantly. The website/webapp services integration does happen to be one of the more well defined cloud sub-markets, which is exactly why you see AWS coming out with stuff like Amplify. They weren't in a particular rush, which may seem surprising considering that Heroku and Firebase are Amplify competitors and have been around for a long time. I assume AWS understands that the threat is minimal because both Heroku and Firebase fail at enterprise scale (which is where the actual money is). Once you reach that point with Heroku or Firebase, where are you going to go? You will probably move to AWS (at least if you're like 50% of the market lol).
I'm also a bit confused by your selections (or maybe moreso omissions). As an example, I personally think Firebase has become a garbage product with horrible UX but it seems to fit the exact criteria you describe in your profile. How is it less of an integrator than Amplify? What need do you have in building a fullstack webapp that is underserved by Firebase (I'm not saying it's well implemented)?
Sorry if this is a bit all over the place, it's a really big topic so obviously I missed a ton of stuff. I've spent the last 4 years operating at different levels and areas of this market so this topic really interests me. If this was helpful/interesting I don't mind writing more, just lmk!
Edit: I also think it's very hard for one of the smaller players to provide the integration layer you're describing long term, just look at what happened to Meteor.