Cloud Operating Systems and Reconstituting the Monolith. tweet responses: https://twitter.com/swyx/status/1226257539886669825?s=20

cloudos.md

Update

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

Cloud Operating Systems

• 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.

Reconstituting the Monolith

• 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

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.

Reading this while enjoying lately Seed (which truly is a wonderful addition to the Serverless framework stack) but also wondering if that scale as presented on their site.

chris biscardi's AWS+Netlify mapping:

static fileserving: Netlify
functions: Lambda
gateway: API Gateway
socket management: API Gateway
jobrunners: ECS/Fargate
queue: Kinesis/DYnamo streams
scheduler: ??
object/cold storage: S3
database/hot storage: Dynamo/S3/Athena

---

unrelatedly, today I spotted this chart at @heitorlessa's reinvent talk which maps out where AWS positions itself https://www.youtube.com/watch?v=DcrtvgaVdCU

@madiodio i have added CI/CD under "metajobs" :) aka jobs that happen before/after the "real" job, jobs that aren't user facing

@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:

• Extreme commoditization of hardware and even virtualized hardware
• Near global adoption of collaborative source control technologies
• Emergence of the Microservice paradigm and alternative isolation mechanisms such as containers
• Infrastructure as code and what I call the "infrastructure meta'

"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.

Khan Academy has essentially run for 10 years on a serverless monolith. I don't think App Engine gets enough credit for just how easy it makes it to deploy and scale a monolith.

@rylandg, you're right that i do have a bias. i feel like how we experience the cloud is like the blind men describing the elephant. Nobody sees the whole thing. I guess except Andy Jassy and co haha. but i do hear you loud and clear on the dominance of EC2, S3, and Java Lambdas, I don't interact with that space at all and could do a better job of making clear that I don't speak to that market.

Heroku, Firebase and Meteor are of a different generation, yes. I've actually used them all, heh. I think what you're hitting on is the reason I felt I had to publish this as a gist rather than a blogpost - I haven't been able to FULLY articulate what the new generation is doing differently from the older generation yet so this thesis is certainly half formed. But I will update when i feel i have really nailed it. May take a few years...

@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

1. Widen the top of the funnel
2. Increase revenue per user

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 haven't been able to FULLY articulate what the new generation is doing differently from the older generation yet so this thesis is certainly half formed. But I will update when i feel i have really nailed it. May take a few years...

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 🙃

naw not at all, this is the whole reason i put up my half formed thoughts in the first place. better open discussion than bottling it up in my head with no feedback. thats how people only grow linearly with their years of experience.

I can't exactly discuss Netlify or Zeit strategy openly. but would say I quite agree on Netlify's heavy bet on Git. Would also say that AWS hasn't really been a threat to anyone they've tried to clone, altho they may make more overall $ from the OSS than the original host of the OSS 😂 (i am referring to reports that they make more from MongoDB than MongoDB).

I'm not really trying to even talk about any one company's future, really. just thinking, as you say, for the web app development niche: what do devs really want to use, and then working backwards from there to figure out what MUST exist for that to happen. hence the top line of "Serverless cannot proclaim total victory until we can recreate DHH's demo from 2005 in 15 minutes.". call it a "regression test" for any tech stack transition. (i think @dabit3 is gonna try to prove he can do it with Amplify 😄 ) with the evident benefit of course that it is pay-per-use and now we never have to think about horizontal/vertical scaling again.

Wow, what a great discussion!

AWS has definitely been a threat to people they clone, they just do it so well you forget the other guy existed. I think Spotinst is a great example there. Seemingly great product with no real competition, out of nowhere AWS releases parity in-ecosystem alternative and essentially vaporizes Spotinst offering off the map. Of course Spotinst the company still exists they just had to pivot entirely.

I'll respond to the rest later.

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:

Of course Spotinst the company still exists they just had to pivot entirely.

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.

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.

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.

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.

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? ;)

I think this is partially why the Heroku acquisition was priced at a surprisingly (at least to me) low ~200m.

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 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 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:

• Time to market - Git to Cloud with Ease & be able to iterate, hotfix, and update multiple times per day to users /w zero interruption
• Cost - Don't have me sell my big right toe on the black market to fund this thing
• Power - Be able to handle an influx of traffic without downtime using technologies that I know

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 or go.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 think docker-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 ;)

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 or go.mod file.

Yea i think everyone is moving toward IaaC. Netlify has netlify.toml, Render has Render.yml, Amplify has Amplify.yml. Your open source pitch looks like Serverless.yml.

As much as I don't love monoliths, I firmly believe starting in one is better.

i think this depends on what you're building. I do think that everyone so nostalgic for a "Rails of JS" would probably be better off just learning Django or Rails instead. :)

I wouldn't put tasks/scheduled jobs in a monolith though =p

Wait why? isnt Sidekiq exactly for that?

Wait why? isnt Sidekiq exactly for that?

I'm more talking about using Threads, Task.Run in C# or Goroutines in Go, to schedule a task to happen in X time. Using 3rd party services like Sidekiq and Celery is definitely fine because it will guarantee that stuff runs. But if you literally coded your jobs/tasks within the same service and don't use 3rd parties like that, you'd have a lot of fun coding it or find a lot of bugs :).

Yea i think everyone is moving toward IaaC. Netlify has netlify.toml, Render has Render.yml, Amplify has Amplify.yml. Your open source pitch looks like Serverless.yml.

Aiming for more closer to Render.toml, except open source & cloud-agnostic via k8s - taking any git repository and launching it into the cloud.

cool cool. overall, yeah I agree that devs care about Time to market, Cost, and Power. I'm interested in framing it as "Infra team as a service" - Cloud OSes (or to use your words, Cloud Package Manager) democratize infra. I always hear about the kind of stuff that Uber Airbnb etc have entire teams to set up for the rest of their devs, so this is a good "bring this cutting edge cloud tech to the masses" type story to sell and invest in.

I find it funny that people are already looking at a "post Kubernetes world" (not your words, i just hear it more and more now). everybody is being enabled by k8s - so really are we just talking about different forms of "k8s as a service" here? (i'm not a k8s person at all)

I get you with the open source angle, and I like that. Begin.com also has a good angle on that with arc.codes.

I think in 2020 the idea of "cloud agnostic" or "multicloud" has really soured. Everyone understands that diff clouds have different strengths and if you try to be agnostic you're by definition only making use of lowest common denominator stuff (or reimplementing abstractions expensively). In fact it is one way in which my "OS" analogy really fails, Cloud OSes likely won't actually work equally well on different "hardware". but happy to be proven wrong.

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.

IIRC Spotinst initial value prop was basically the spot instances feature from AWS. AWS didn't have that feature at the time of Spotinst launch. Now AWS has, spot instances, spot fleet, Fargate and various improvements to scaling across other services especially ASG's. "AWS isn't the only cloud" is also a bit hyperbolic. I doubt there are many cases in history where anyone was truly the "only player" in a market. AWS holds 40-50% marketshare which is absolutely unreal in a space like cloud computing.

Heroku's success was based on Github + ruby as well, so github (and git ecosystem) is fueling the world here.

How was Heroku successful because of Github? I wasn't really around at the time but the timelines don't really line up. By 2010 Heroku was already being acquired by Salesforce and GitHub had O(100k) users and wasn't widely adopted. The ruby part is definitely true, but Heroku was specifically targeting rails.

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.

While I generally agree, the example with your site is way more than just a UI change. Especially with modern CDN's, developers will very rarely serve web-content from an explicitly provisioned NodeJS server. I guess I'm trying to say that it's the open-ended potential of NodeJS that scares people, not ignorance to NodeJS itself. I think a lot of developers see NodeJS and translate it to "not managed for me".

Netlify's strategy was great because they not only understood the pain of their users, but also where the users are when they most often feel that pain.

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? ;)

I wouldn't bet my life on this prediction, but I don't think Java is being primarily used because a bunch of boomers are still around. You have to understand that from a corporate management perspective, Java is a perfect tool:

• Widely taught at most U.S. universities (it was taught at University of Washington when I went ~5 years ago)
• Relatively beginner friendly abstracts away harder comp sci fundamentals
• Runs on any device (maybe not embedded/IOT because JVM, but there are solutions)
• Faster CPU perf than most other popular languages, "Java is performant enough" (obviously C/C++/Rust might be better, but we're not in a bubble here)
• Your developers can't fuck things up

If your job is managing thousands of developers (or controlling any large number of resources honestly), the name of the game is minimizing risk. Java is the ultimate corporate risk minimizer.

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 was actually fairly aware of the revenue. Just to be clear, I think Salesforce paid the correct price. That being said, paying the correct price wasn't commonplace in 2010 🤣

I think people leave Heroku for more control and cost optimizations and they ditch the DX, or try to home-grow their own.

I think the only people that Heroku cares about leaving the platform are the ones who scale out of it. It may sound harsh but its a numbers game and the rest of the users don't add up to much.

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.

Good observation. Mostly just seems like another manifestation of risk management. Being "ops aware" in terms of productization will be really advantageous (at least until devops is optimized out).

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).

Lol I wish Kubernetes would not be a thing now. I agree, and as you said, it's nothing to do with Kubernetes and moreso the continuous squashing and integrating that happens in tech. At least for now people only care about if their code runs (that includes scaling etc).

I'll respond to the other stuff after work :)

I think in 2020 the idea of "cloud agnostic" or "multicloud" has really soured. Everyone understands that diff clouds have different strengths and if you try to be agnostic you're by definition only making use of lowest common denominator stuff (or reimplementing abstractions expensively). In fact it is one way in which my "OS" analogy really fails, Cloud OSes likely won't actually work equally well on different "hardware". but happy to be proven wrong.

Many businesses want this, but can't do it. I know several enterprises that built it (in years) and are now going backwards because it's not working. Data + Multicloud problem is not easy for anyone, especially depending on the amount of data. I wish I could just add multi-cloud to KintoHub for everything, but then you might get the idea that you can spawn a mysql DB multi-cloud block and realize quickly that it doesn't work like that :).

---

IIRC Spotinst initial value prop was basically the spot instances feature from AWS. AWS didn't have that feature at the time of Spotinst launch. Now AWS has, spot instances, spot fleet, Fargate and various improvements to scaling across other services especially ASG's. "AWS isn't the only cloud" is also a bit hyperbolic. I doubt there are many cases in history where anyone was truly the "only player" in a market. AWS holds 40-50% marketshare which is absolutely unreal in a space like cloud computing.

Gotcha - I was more wondering if there was a story like Discord coming from Gaming Apps => Gaming Chat which is a significant pivot in the business model.

How was Heroku successful because of Github? I wasn't really around at the time but the timelines don't really line up. By 2010 Heroku was already being acquired by Salesforce and GitHub had O(100k) users and wasn't widely adopted. The ruby part is definitely true, but Heroku was specifically targeting rails.

After Heroku was bought by Salesforce, the relationship didn't end there. They started < 12 months apart in the same city, 1M users on Heroku and a majority of users on GitHub were Heroku users. If Github users are talking about heroku and heroku users are talking about GitHub, it's a big deal in developer mindshare in terms of growing a new dev tool, especially in the first 100K users. This information is more from directly picking James Lindbaumen and Jason Warren's brains on their story for my current venture. Jason recently told me node was a huge player in the later-stages of Heroku as well which blew my mind. Long story short, bet on technology companies that are not popular yet allow you to really be heard by 100% of that community before they blow up. IE: If I shout out about graphql today, 0.01% of people might hear me and talk about me. If I shout out about Hasura today (subset in graphql), 15% of my users are from Hasura and > 50% of their community hears me.

While I generally agree, the example with your site is way more than just a UI change. Especially with modern CDN's, developers will very rarely serve web-content from an explicitly provisioned NodeJS server. I guess I'm trying to say that it's the open-ended potential of NodeJS that scares people, not ignorance to NodeJS itself. I think a lot of developers see NodeJS and translate it to "not managed for me". Netlify's strategy was great because they not only understood the pain of their users, but also where the users are when they most often feel that pain.

Totally agree - but this user, in particular, didn't know nodejs translates to react ;). The more I speak to the open-source and dev tool leaders, the more they keep telling me that the KISS principle for every keystroke of content and every idea put in motion towards the vision - things need to be so dead simple, it's laughable - but for new users, especially people learning technologies - it's important and critical for adoption. Thanks to Shawn's feedback - removing cloud-native from the front page of KintoHub already went in motion.

If your job is managing thousands of developers (or controlling any large number of resources honestly), the name of the game is minimizing risk. Java is the ultimate corporate risk minimizer.

Was joking ;) But informative!

somewhat relevant to this topic (?) i just discovered this term Hyperconvergence: https://en.wikipedia.org/wiki/Hyper-converged_infrastructure which seems to be a bit of a faded meme (which i wasnt around for) but i wonder if all im doing is rediscovering the promises and problems of the old hyperconvergence debate (which again i wasnt around for so i dont really know how it panned out, i assume it was largely correct but also overhyped by vendors)

@sw-yx I've spent some time around around HCI and have worked with quite a few customers that were either actively using it or had used it. You were wondering if it's overhyped, the answer is yes. That being said, I can't think of a single emerging tech that hasn't been overhyped in recent years, it's a real problem in the industry/world IMO. Hype aside, I think HCI is a real indicator of where the market wants to go.

In your original post, you describe an offering that provides all of the individual building blocks needed to create a holistic product, while maintaining your ability to choose which of those blocks are actually used. Even though all of the blocks have been wrapped in a nice "whole product offering" for you (Heroku, Firebase, Amplify, Netlify even), you're still the one who ultimately makes decisions about what services are used. While HCI relates partially to this conversation, there is a key difference. The premise of HCI is that compute and storage are inseparable and if you want one you implicitly want the other. This usually means, that by using HCI you forfeit the ability to scale compute and storage independently.

HCI is really about simplifying things down to a single unit. Because of this, HCI offerings tend to manifest as Appliances (I've heard the term "datacenter in a box" before). It's easy to see why an appliance is the path of least resistance for HCI, if you understand the basic rationale for HCI in the first place (less moving parts). I've personally worked with two different HCI appliances before (albeit minimally), the Hyperflex from Cisco and Nutanix ??? (maybe AOS). I didn't use either solution enough to form a confident opinion, but anecdotally Nutanix was very user friendly and the customer seemed very happy with it. On the other side of the coin, the Hyperflex customer I worked with was in the process of moving away from the solution and was quite frustrated. While I think the appliance route is the most convenient manifestation of HCI, it suffers from a big problem. Generally speaking, large enterprises are the ones who tend to invest in appliances. Unfortunately, HCI is not a great use case for many enterprises who often need to have a strong devops team anyway and also have a cost-driven need to scale compute resources independently. OTOH HCI appliance might actually make sense to a smaller shop that wants a more hands off approach to scaling on-prem infrastructure. From my observations, smaller shops tend to not go the appliance route.

What you should really keep your eye on is vsan from VMWare. Someone might yell at me and tell me that vsan is not really an HCI, which is obviously true. In practice most people who want HCI would be just as served by vsan. With vsan, instead of going the appliance route, vmware offers a Virtualized San layer that allows you to access storage from any DAS across the nodes. This provides a lot of the benefits people are looking for with HCI, without needing to physically bundle your compute and storage into a single unit.

I hope I made things clearer!

whoa, you really did, thank you!! TIL you worked with Nutanix.. old coworker of mine was a senior sales person there and i confess i never really understood what they did until you explained it in terms of HCI (which, btw, to me stands for Human Computer Interaction, haha).

Glad it made sense. In my short time I've somehow been lucky enough to work with a lot of very diverse types of technology. Even then, I see at least 1 startup a day whose value prop completely goes over my head. When it happens it just excites me because its another reminder of how much new stuff there is to learn.

In regards to Nutanix, when I worked with their HCI offering I wasn't working directly with them (rather one of their customers). More recently my last company had a small engagement with Nutanix itself and while it didn't materialize, the Nutanix team members I worked with were incredibly intelligent and down to earth people. Left a good impression on me.

HCI used to mean human computer interfaces for me which I think is actually the same thing as human computer interaction. And although I do understand what Nutanix offers, I'm still waiting for someone to explain to me what ServiceNow does (10% joking 90% not lol).

tagging more info as i learn it - here's Joe Duffy of Pulumi talking about how the Cloud OS idea was first proposed by Dave Cutler (Windows NT architect)

(18 mins in) https://softwareengineeringdaily.com/2020/03/19/pulumi-infrastructure-as-code-with-joe-duffy/

and some links i found:

• https://www.cubesys.com.au/10-years-of-azure/
• https://www.zdnet.com/article/how-the-red-dog-dream-team-built-a-cloud-os-from-scratch/
• https://www.zdnet.com/article/red-dog-five-questions-with-microsoft-mystery-man-dave-cutler/

===

Terraform is kind of "self-rolled distros": https://www.youtube.com/watch?v=h970ZBgKINg

published first post as https://www.swyx.io/writing/cloud-distros

https://youtu.be/HlAXp0-M6SY

"we must treat the data center itself as one massive warehouse scale computer." urs holzle