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
@sw-yx I really hope my response didn't come off harsh. You're obviously smart and self aware, but as you said nobody is without blind spots. I approached the problem from the larger cloud ecosystem angle because from my perspective, sub-markets are usually at the mercy of the larger market they are part of. Web development is an even more interesting case in this sense, because in addition to being a fixture of the larger cloud market, there's almost an expected progression from the web-development space to the larger cloud space (assuming your software succeeds and grows and therefore needs to scale). From my point of view, there's only two practical ways a platform like Heroku can increase their revenue/profit
Considering that Heroku basically positions itself as the "easy to use cloud" (and specifically directed at web development), I think it's obvious that their main strategy is to widen the top of the funnel. While this can give you some absolutely great initial growth, there are obviously diminishing returns as the market becomes saturated. The second method (increasing revenue per user) is actually very difficult for Heroku, as it's very difficult to release features that increase revenue per user without positioning yourself next to AWS. I think this is partially why the Heroku acquisition was priced at a surprisingly (at least to me) low amount. Salesforce knew that the biggest growth vector for an offering like Heroku would pit them against AWS (which has not turned out well for others). I would also wager that Firebase was acquired for ~O(200m) for similar reasons, although from what I've heard Google was also very interested in the "brand" of Firebase (which is why they still remain separate, even if artificially).
As for Heroku, Firebase and Meteor being of a different generation, it's an interesting thought but I'm not so sure. I use a lot of different cloud services (across providers) and I think Heroku is still the only one filling it's niche (a simple but decently featured cloud vendor with a bias towards web dev). I do think the Salesforce acquisition marked the initial decline of Heroku (similar to Firebase).
I don't know if might seem odd from everything I wrote so far, but I'm actually an avid Netlify user. I would actually go as far to say that it's the "cloud" product I use that I'm most happy with. Up until recently I was also the lead PM building a fullstack CRA framework/platform (sort of like Meteor) so I've spent a lot of time analyzing this (Netlify, surge, Heroku, cloud) space.
If I had to place a bet, I would say the biggest factor which contributed to Netlify's success is the positioning of the product in conjunction with the insane adoption of Github. Obviously the growth of SPA/SSG and specifically Gatsby also contributed, but when I really think about what "sold" me on Netlify, it was the way it positioned itself in the git ecosystem. The reality is that most developers (even good ones) do not understand the cloud. I actually think cloud understanding has almost regressed as the cloud has grown, because it's become complex enough for many devs to consider a separate field entirely (sort of like ML I guess). From my experience this is true even for the average web developer. To be super clear, I'm not implying these developers are stupid or anything, it's just not something they learn in school, or are required to do at work so they don't pick it up. What developers do understand is their project and Github, and that's exactly where Netlify put itself. I remember the first time I saw a Github repo with the "Deploy on Netlify" button, even as someone who was a "cloud expert" (probably have used almost every AWS service) I was immediately blown away. It's not just that Netlify integrated with Github (I doubt they were first but probably one of the first), it's that Netlify understood that Github is where life is centered as a web developer. Netlify basically said, "Keep doing things exactly the same way you have been, just click a few buttons and we're going to handle the exact parts you don't want to. Oh and btw it's free". FTR I think Heroku and Firebase had very similar value propositions (in a generic sense obviously) in the sense that they brought the cloud down to the level of users who were being underserved by the existing cloud.
I say all of this because I think it ties back to your original question. I think the next 2-3 years of the cloud will be defined by products that offer very similar value that Netlify does, ie: bringing the cloud down to the level of the niche/ecosystem which is currently underserved. Zeit is a perfect example of this. While some may see Zeit as a direct Netlify competitor, I think that short term it's definitely not the case. Zeit is catering to a much different (and far more advanced from my experienced) group of users. I'm 100% sure that there are probably 10's if not 100's of similar underserved niches, and I hope Netlify will try and bringing a "whole product" offering to those users like they have with Github based web developers. Obviously you guys have done this already to a degree with the addition of +1 features such as forms, functions and identity. I just think it's important to understand that in the process of doing this (adding one-off features to attack a new market) Netlify can accidentally position itself in the crosshairs of AWS.
If you can't tell I really enjoy this topic, and I've been interested to hear your opinion about it for a while now. I appreciated the reply to my previous wall of text 🙃