I think that npmjs uses colors too much to the point of irrelevance. Why are links in the README red? Why is the code tab red? Why is the download graph purple?
Compare your npmx link to vue to https://npmx.dev/package/node-red-contrib-rtc-alert-node . This package uses deprecated and vulnerable deps and npmx correctly uses color to draw attention to it. And because the npmx page is normally monotone, the use of color actually draws your attention.
The implied question was what OP's idea of "the cloud" is, where they draw the line between "cloud" and server host. It's possible they simply aren't familiar with the Iaas/PaaS terminology.
I posted a link to what most cloud-native developers understand to be "cloud" a few times already. If IaaS is the only offering on the table, it's not cloud.
It's one thing to say that a lot of AWS/Azure/Google users take advantage of many managed services.
But saying something is not a cloud provider because they don't provide a specific SaaS is kinda weird, especially if you read the NIST definition of cloud computing or when you consider that not every AWS user is using more than a handful of services (does that make AWS a cloud provider only for more "advanced" users?).
Sure, smaller cloud providers don't usually have all those services, but this doesn't mean they are not cloud providers. They cannot attract users who are more familiar with specific managed services, but they can probably satisfy the needs of other users who are more than happy with a smaller feature set.
Also, limiting yourself to a smaller portion of AWS/Azure/GCP services can facilitate migrations to other cloud platforms (think AWS -> Azure or viceversa), because you're less tied to specific proprietary tooling.
> because they don't provide a specific SaaS is kinda weird
I think for most business stakeholders it's not about the number of services but rather the coverage of business-critical needs. When you have access to Azure Entra, you know that you can cover 90%+ of your auth needs with that service. If you have access to AWS S3, you know that your various storage needs would be possible to cover with that. If a managed Postgres is available, you know that most of the IT systems you run would be able to take advantage of that. You look at Azure their IAM/audit/observability offerings and it's the same.
When you look at Hetzner as a business stakeholder, all you see are bare servers and and one object storage service that you are not sure of how battle-tested it is. And then you start thinking: "okay, I will need to run k8s or some other workload orchestration approach, my IT systems need Postgres/MySQL/SQL Server etc, I need auth, I need audit, I will need to build, operate, maintain all of that in-house". I am not saying that this is a wrong path for everyone, but Hetzner essentially leaves you no choice. And many business stakeholders who have been operating their own own-prem infra or colocated or rented IaaS plus a large dev team for decades and have since switched to one of the hyperscalers and reduced their dev/IT headcount - may not want to go back to the old model.
> limiting yourself to a smaller portion of AWS/Azure/GCP services can facilitate migrations to other cloud platforms.
Yes, which is why you insist (where possible/reasonable) on Postgres-compatible DBMS offerings, IdP solutions based on OIDC, observability on OpenTelemetry.
> Sure, smaller cloud providers don't usually have all those services, but this doesn't mean they are not cloud providers
Yes, it could mean that they are not cloud providers.
> but they can probably satisfy the needs of other users who are more than happy with a smaller feature set
Please see the linked article. This is essentially "users who are happy to build some of the furniture themselves".
I agree that there is a difference between "wood" and "furniture".
Although maybe a more apt comparison is IKEA vs another furniture store.
With IKEA you have a relatively basic "style". You'd be hard to pressed a 1800 style table, for example, but if you are a student or someone who just wants to live in a new place, it's a pretty solid store to go. However, they give you the pieces (not just basic wood, already pre-made pieces) and you have to put them together.
Other furnitures have a lot more choices in terms of styles and they allow you to just buy stuff without any DIY needed.
Different offerings in the same space (no one in IKEA is asking you to cut wood and make your own chair legs or whatever), both valid.
Furniture metaphores aside, what I'm saying is that there is a subset of users which is completely fine with those services, which are still provided in a self-service, pay-per-use way without the need to have admin rights over the entire platform. That's a cloud provider. A more limited one, sure, but it can still be a cloud provider.
And when it comes to business stakeholders, coverage is important, but so are other concerns, including the ability to move out when needed (which still requires some sensible technical choice, because if you go "all in" you're complicating your exit strategy), or even concerns like the ones mentioned in the OP.
Obviously, each company has its own risk aversion and its own decision making process, and so far market share heavily favors the Big Three even outside of the US, but this doesn't mean alternative options should be dismissed as "not cloud providers" just because they don't provide all those services.
I'm not sure it will convince the "haters" nor they'll get it, but I'll keep it close to share with some people that are confused but open enough to understand the nuance.
I would say the November 2015 look would be the one to go back to.* [1] This one seems to be from 2015 before the iconic redesign that makes it instantly recognizable as Github.
> why do we invent these formal languages except to be more semantically precise than natural language
To be... more precise?
On a more serious note, cannot recommend enough "Exactly: How Precision Engineers Created the Modern World" by Winchester. While the book talks mostly about the precision in mechanical engineering, it made me appreciate _precision_ itself to a greater degree.
Rhetorical sentence? My point is that back-translation into natural langauge is translating into a less precise form. How is that going to help? No number of additional abstraction layers are going to solve human confusion.
Nothing, because I want this for open source projects that I give away for free. That doesn't work if I have to tell my users to go pay a license fee for one of the components.
reply