[HN Gopher] Ask HN: Beyond AWS/Azure/GCP, what cloud providers s...
___________________________________________________________________
Ask HN: Beyond AWS/Azure/GCP, what cloud providers should I know
more about?
If you were to advise someone starting to build a SaaS product from
an idea, what cloud providers would you recommend knowing more
about beyond the bigger three?
Author : tomrod
Score : 44 points
Date : 2022-04-30 18:54 UTC (4 hours ago)
| PaywallBuster wrote:
| Oracle Cloud - good alternative for bandwidth heavy products
| (used by Zoom)
|
| Heroku - For a more "abstracted" cloud that just works
|
| Vultr/DigitalOcean - Cheap VMs, additionaly some services like
| managed DB and K8s
|
| Hetzner/OVH - Cheap dedicated hosts
|
| Netlify/Cloudflare Pages/etc - for static websites +
| functions/3rd party services for dynamic stuff
| eigenvalue wrote:
| Hetzner is shockingly cheaper than vultr now. Also Contabo is
| very cheap.
| dijit wrote:
| > Oracle Cloud - good alternative for bandwidth heavy products
| (used by Zoom)
|
| please don't.
|
| I have nothing but the worst experiences with Oracle Cloud.
| Granted, I was always a little biased against Oracle as a
| company; but I have a friend working on OCI and assumed that
| since what I needed was really basic it would be fine.
|
| It really wasn't, it was awful, confusing and opaquely and
| egregiously expensive.
| deepspace wrote:
| > It really wasn't, it was awful, confusing and opaquely and
| egregiously expensive.
|
| That is true, but it is also very much an understatement of
| just how miserable every step of the OC experience is.
|
| I was once forced by a customer to endure the torture that is
| OC, and the only thing that saved me was when Oracle's
| terrible management software just deleted our entire account
| and deployment one weekend. Gone without a trace, could not
| even log in anymore. Luckily, that was enough to persuade the
| client to move to Azure.
| threatofrain wrote:
| https://fly.io
|
| https://render.com
|
| https://digitalocean.com
| dijit wrote:
| For simple compute there's many options; everything depends on
| what you want.
|
| Been using Tilaa (if you can tolerate being hosted in
| Netherlands) for nearly 10 years, I'm quite happy with them.
|
| Vultr is not as good, but it's decent enough.
|
| But what separates a cloud provider from a VPS/Hosting provider?
|
| I might argue some kind of object storage, as that's the
| differentiating feature AWS had when it came out. In which case,
| I'm not sure what there is outside of AWS and GCP, sadly.
| pxeger1 wrote:
| If you want to stick to the same type of platform as AWS, Azure,
| and GCP:
|
| - Oracle Cloud - IBM Cloud - Alibaba Cloud
| spiffytech wrote:
| I'll toss out another vote for Fly.io. They make it super easy to
| deploy containers. No K8s, no leaky abstraction to an underlying
| traditional compute service.
|
| You get internal networking out of the box with per-app-region
| internal DNS entries, and with their CLI tool it's one command to
| SSH into your container or connect your laptop to the internal
| network.
|
| As a nice bonus, their pricing is very competitive. You pay about
| as much as you would for the same size Linode or droplet (minimum
| is 256 MB RAM for $1.94/mo), which is a welcome relief vs other
| providers. Great free plan, too - 3 apps at 256MB RAM running
| 24/7 in perpetuity.
| oneplane wrote:
| tl;dr: Starting out with containers that have no own state,
| running on x86 on Linux has the highest chance of success I'd
| say, and when you grow, you have the capability to flow between
| IaaS, PaaS and SaaS and all-in-one clouds as you wish. That means
| that your 'first' service provider is irrelevant if you don't
| have pre-existing knowledge or affinity. If you can produce good
| container images, you can run anywhere.
|
| At some point 'the other clouds' aren't as relevant.
|
| Think about the following interactions instead: -
| CNCF compatibility (interpret as deep and as wide as you like)
| - Infrastructure vs. Platforms vs. Services - Legal
| boundaries - Locality (can interact with legal limits, but
| also latency, transfer costs) - Scope of services vs. scope
| of what you actually need
|
| A lot of providers are good at a thing, and bad at everything
| they tack on to it. Some providers are reasonably good at many
| things, but win on integration between those things. Others are
| simply too dissimilar to orchestrate, so either you'll have to
| bring your own orchestration or not use it in orchestrated
| scenarios.
|
| Instead of knowing about the clouds, know about requirements
| engineering. Fitting your needs and the services you pay for is
| way more important than the details of those needs and services.
|
| If you just need some random compute (read: a shell into an OS, a
| complete VM, a container, things like that) and nothing else, do
| NOT use some cloud. It will require you to do a lot of other
| things as a side-effect of using those services at all, and will
| cost a lot for what you need.
|
| On the other hand, if you need to be highly elastic, have
| completely managed RDBMs on-demand available and orchestrate
| networking, IAM, object storage, block storage, compute and
| ingress, do start out with a cloud.
|
| Regardless of what you are building, make sure you know ahead of
| time if: - What your scaling is going to depend
| on (usage, work hours peaking, seasonal peaking, tenants) -
| What your scaling is going to be like (horizontally scale and
| spread the load? vertically scale for a few weeks until you reach
| the scaling limit and then rebuild the application the right way
| instead? deploy one instance per customer?) - What
| availability rules are you going to have? (downtime? data loss?
| time to recover?) - what legal limits will it have?
|
| Example for a MVP SaaS: say you want to manage shopping lists for
| consumers, you might call it Shoppr and build a PWA and a app-
| wrapped PWA so you get immense reach. You mostly have front-end
| engineers, but you do know a bit about metrics and scaling.
|
| I'd say that means: - Downtime for a few hours
| unlikely to tank the business - Legal limits are basically
| just generic data protection - Scaling is likely linear
| - Since your data is mostly basic CRUD, any read-replicated
| system will do
|
| This can be built using any stack, and as long as your
| persistence can keep up you're golden. Don't fuck it up with an
| ORM that doesn't know how to create the proper indexing rules on
| tables and you can easily get a couple of million customers on an
| IaaS-only provider that just has virtual machines or containers,
| and only has one flavour of persistence store. Plonk Cloudflare
| in front of it and done.
|
| You can make this infinitely more complicated, but as an example
| add this feature to make this entire setup suck and the entire
| infrastructure incompatible with the needs of the application:
| international receipt scanning to recommend/autocomplete shopping
| lists for customers. Suddenly your requirements are expanded
| with: - Incoming upload queue - Object
| storage for image blobs - OCR or ML pipeline to process
| images - ML or Analysis pipeline to make sense of the
| contents of the now processed/read images - Instances or
| expansion for all of the above per region
|
| To make your traffic bill not suck you'll need endpoints in most
| major regions, and you'll probably want to prevent cross-region
| transfers so you'll want multi-region compute. Since you don't
| really have to do the processing realtime, you'll be doing some
| queue work and perhaps have a DLQ that needs human intervention
| or QA analysis for product improvement. All that stuff also needs
| a 'control panel' for lack of a better word so you'll be adding
| backoffice systems too, and those will have a workflow that
| doesn't compare to consumers at all and should never share any
| interaction with them, so now your application tenancy
| requirements change as well, which flows down into infrastructure
| requirements. At the same time you'll also need training data or
| validation data, and you'll want to be able to do all of that
| elastically to not go bankrupt for paying for 100% of capacity
| that you'll use 50% of the time at best. Suddenly 99% of the
| vendors are unable to provide what you need and the 'big three'
| remain (well, not exactly, but for illustrative purposes this
| will do).
|
| Considering a good SaaS might grow, make revenue and be sold or
| be valuable etc. there will be requirements stacked on top of
| everything else about redundancy, durability and availability and
| those will be increasingly hard to guarantee in an IaaS-only
| provider or PaaS-only provider scenario.
|
| When you 'start' with a SaaS, you'll need to know what you need
| now, and what you might need in the near future, and make sure
| that whatever you do now doesn't paint you into a corner within
| weeks. That means that setting up IIS on a Windows desktop by
| hand on a VPS at some IaaS hosting provider is highly unlikely to
| be a good place to start. On the other hand, an equally janky
| setup with a random Ubuntu VM where you manually install Docker
| and say, Nomad might actually not paint you into a corner too
| much since a container can easily be run on a container-PaaS and
| Kubernetes beyond that.
| adventured wrote:
| Obviously depends on what you need.
|
| If you need many of their services, AWS is very difficult to
| beat. Nobody else quite matches up with them on breadth
| offerings. If you don't, do not use AWS due to the cost and the
| mental overhead of management.
|
| If you just need to spin up some servers and want them to be fast
| and cost effective, Hetzner is the current champ in the US market
| (their new US datacenter). DigitalOcean, Linode and Vultr are
| entirely reasonable options after Hetzner.
|
| If you have a $50-$100 / month or less budget, know how to set up
| and secure a linux server, and want to stretch your dollars as
| far as you can with a top notch cloud provider, Hetzner wins at
| present. And then throw Cloudflare out in front of it until or
| unless you can justify paying for a service. Keep your costs low,
| keep your infrastructure simple, keep your runway long, focus on
| selling selling selling (customers).
| simonw wrote:
| DigitalOcean and https://fly.io/
| thekonqueror wrote:
| If you are considering Vultr or DigitalOcean, try UpCloud as
| well. They have really robust network and the VMs are faster than
| AWS C6G instances in almost every test we run.
| mellosouls wrote:
| Polite request for people to give explanations for their
| suggestions, otherwise the value is questionable.
| adamcharnock wrote:
| I think it is really worth being aware of Hetzner's Dedicated
| server offerings. What you get isn't that dissimilar to what a
| cloud provider would offer, but you get about an order of
| magnitude more compute resources for the same price.
|
| Plus you get better disk access speed (NVMe) than something like
| an AWS EBS-backed instance. You can also order new instances
| within a matter of minutes.
|
| You don't have to use them, but being aware of what is available
| there would be a really good idea. I think some workloads could
| easily be deployed there at a fraction of the cost of a cloud
| provider.
| yjftsjthsd-h wrote:
| Definitely Hetzner; cheap bare metal with ease of use approaching
| Cloud(tm), plus actual cloud VMs.
| whitepoplar wrote:
| If only Hetzner would bring bare metal to the U.S....
| mardix wrote:
| That would be it. People would flood them.
| yjftsjthsd-h wrote:
| I'm hoping that their cloud VM work in the states is a
| precursor to that:)
| verdverm wrote:
| None, it is not important at the early stage you are at, if ever,
| but it depends on the SaaS model you follow.
|
| Why do you think it's important to know more than the one you run
| on?
| tomrod wrote:
| Fair question.
|
| We don't run on one yet -- we are at the stage where we are
| expanding my understanding of the cloud service offerings and
| am curious what is available with good reputation.
|
| SaaS is at whiteboard phase; where we invest our engineering
| time will be important as we recognize the issues of lock-in
| for something like AWS.
| moondev wrote:
| Kubernetes + Cluster API. This unlocks the ability to use one or
| multiple providers: https://cluster-
| api.sigs.k8s.io/reference/providers.html
|
| * Alibaba Cloud
|
| * AWS
|
| * Azure
|
| * Azure Stack HCI
|
| * Baidu Cloud
|
| * BYOH
|
| * Metal3
|
| * DigitalOcean
|
| * Exoscale
|
| * GCP
|
| * Hetzner
|
| * IBM Cloud
|
| * KubeVirt
|
| * MAAS
|
| * Nested
|
| * Nutanix
|
| * OpenStack
|
| * Equinix Metal (formerly Packet)
|
| * Sidero
|
| * Tencent Cloud
|
| * vSphere
| jaytaylor wrote:
| Also Oracle OCI has OKE, which is Oracle Kubernetes Engine. It
| works nicely and the quality of service has been very good in
| my experience over the past four years.
|
| Disclaimer: I currently work at Oracle.
| arccy wrote:
| If multicloud is anywhere on your radar, kubernetes. Most decent
| cloud providers offer a managed instance and targeting that
| common platform is so much nicer.
| jeffrallen wrote:
| If you need Swiss-only for regulatory reasons, then you might
| like Exoscale.com. I do.
| Shadonototra wrote:
| Scaleway - if you are from EU, they are great and pretty cheap
| Otek wrote:
| Alibaba Cloud if company you work for thinks about providing a
| service for China customers
| crummy wrote:
| That or Tencent.
| smackeyacky wrote:
| Alibaba Cloud.
|
| Although, my dealings with them have been entirely negative.
| Their strategy is to make a clone of every service AWS has,
| except the billing system which hides a lot of majorly expensive
| pitfalls.
|
| Also, if you choose one of their mainland hosted zones, trying to
| get your data out is even more expensive than the other zones.
|
| So in this case, "knowing more about" is really "tread
| carefully".
| memset wrote:
| We're building https://www.tasker.sh (YC S21) to handle ask
| things async - cron jobs and a must less restrictive version of
| Lambdas
| kkielhofner wrote:
| Cloudflare. Between Pages, Speed, Access, Workers, durable
| objects, KV store, R2, Images, etc they're maybe a small handful
| of product releases away from being able to replace the providers
| you mentioned for many users and applications. Plus I'd wager
| that many applications can be built 100% on Cloudflare today (and
| are). Benefits? - Pricing. Compare pricing on Workers to
| functions across those platforms as one example. For many use
| cases you can use the Bundled pricing model. It's insanely cheap.
| Crazy cheap. Then start looking at pricing on bandwidth
| (ESPECIALLY BANDWIDTH), KV, R2, DO, etc. You'll be pleased. -
| Pace and market disruption. AWS is 20 years old. That makes them
| essentially the IBM of cloud. No one ever got fired for buying
| AWS but seriously compare uptime, pricing, etc. - Speed, uptime,
| performance. Cloudflare's edge network and architecture is truly
| impressive. KV store? Workers? R2? Durable objects? Forget
| worrying about regions, etc. All of this and more runs at their
| edge in more than 270 cities worldwide. - Less vendor lock-in,
| more standards. R2 is S3 compatible. Workers are actually
| WebWorkers. Pages is Jamstack. I'm not exaggerating when I say
| that Workers (as one example) have 2x the performance at 1/4 the
| cost compared to Lambda. Then start looking at bandwidth... In my
| mind where AWS truly shines is exactly why they're the IBM of
| cloud. Support for enterprise, government, etc. Really
| complicated access and management, regulatory requirements,
| extensive customer requirements, an entire cottage industry and
| ecosystem of consultants for everything you can imagine, various
| supplemental SaaS offerings, the list goes on. Everyone likes to
| think you can't go wrong even just starting out with AWS. I don't
| like to crush dreams but the reality is most efforts fail in a
| year or less and only what, maybe 1/10,00,000 projects/companies
| will ever need the full scale of what I just listed. Not shilling
| Cloudflare - just a happy customer who's truly baffled why
| Cloudflare's full product suite isn't leveraged more often and
| more fully.
|
| Also forgot to mention - for compute providers, other storage,
| bandwidth, etc look at their bandwidth alliance. Free bandwidth
| to/from any of the members.
| jeffrallen wrote:
| Also: really nice employees that also post here from time to
| time.
| booi wrote:
| That's all great and amazing for the edge but not for general
| compute which the majority of applications still need. Yes you
| probably could design it with just workers but most popular
| frameworks just don't lend themselves well to that and using
| things like accessing private databases from workers is still
| hairy at best and almost certainly not certifiable.
| stunt wrote:
| I promised myself that I would never try to learn Cloudflare
| until it made its pricing clearer and easier to calculate. How
| do they expect someone to use their services when no one can do
| a simple math without contacting their sales team?
|
| How hard is for them to build something similar to
| https://calculator.aws ?
| altdataseller wrote:
| How can I store my distributed business data on Cloudflare and
| run regular SQL queries on it?
|
| How can I get a message queue on Cloudflare and have hundreds
| of servers read and write to it?
|
| How can I get run a Lucene search index on Cloudflare and
| search against it?
|
| Also R2 is still in beta development
| kkielhofner wrote:
| If it's not a good fit it's not a good fit, we have choice!
|
| However, as I said the vast majority of applications don't
| involve message queues for hundreds of servers or Lucene.
| Many not even SQL.
|
| I also pointed to compute and bandwidth alliance members that
| augment Cloudflare very well so you can build whatever you
| want while still taking advantage of the Cloudflare edge.
|
| Or put Cloudflare as a CDN or augment with what they do have
| in front of whatever cloud you want. Azure and GCP are
| limited members of the alliance that offer reduced pricing
| egress to Cloudflare.
| jpcapdevila wrote:
| https://fly.io It let's you run containers on the edge (close to
| your users)
| laurent123456 wrote:
| Not sure why you wouldn't want to go for one of the bigger three.
| The advantage of using them is that you can find help online very
| easily. Also easier to hire an aws or azure specialist.
| bombcar wrote:
| Depending on your architecture and use cases you can save much
| more than a few salaries by moving to another provider.l,
| especially if outgoing bandwidth is involved and not
| compensated for.
| ehPReth wrote:
| Any with really high/unlimited outgoing data one would recommend?
| chocolatkey wrote:
| I'm surprised there's been many mentions of DigitalOcean, but
| none of Linode, which I think of as occupying almost the exact
| same space in terms of offerings.
| jkaplowitz wrote:
| Linode's future is very hard to predict with them very newly
| part of Akamai. I wish them the best, of course. and I
| currently use them for my personal VPS. But it would be a risky
| time to pick them as the platform on top of which to build a
| new business.
| bombcar wrote:
| Linode is great and I'd recommend it especially for those doing
| more "vps++".
| fuball63 wrote:
| No one has mentioned Linode yet, I had a good experience with
| them around 10 years ago, seems like they have more cloud product
| offerings now.
| lukeqsee wrote:
| Linode.
|
| - no nonsense prices
|
| - solid hardware, with good, consistent performance & low steal
| (even on shared nodes, but dedicated is there if you need it)
|
| - great support (humans you can call)
|
| - adding more and more managed services over the last few years
| jkaplowitz wrote:
| And now part of Akamai as of March 21:
|
| https://www.akamai.com/newsroom/press-release/akamai-complet...
|
| Whether the future is consistent with the past on the points
| you listed is hard to predict so soon after they got acquired,
| but I suspect it will increasingly diverge over time.
| foreigner wrote:
| Twilio, Stripe, Notion
| mark_l_watson wrote:
| I have used Hetzner on several occasions - incredibly good value
| for the money.
|
| For ease of use, I like GCP.
| Jamie9912 wrote:
| Vultr
|
| Hetzner
| notamy wrote:
| https://railway.app (disclaimer: used to work here, now just a
| fan ^^)
| daviddever23box wrote:
| Actually, I'd start with the assumption that the application may
| not (or should not) know anything about the underlying cloud
| infrastructure.
| nousermane wrote:
| Unless you consider it essential for your product to scale by few
| orders of magnitude on a dime, it would be sensible to add "non-
| cloud" hosting into consideration - Hetzner, OVH, Scaleway, ...
|
| Those are considerably cheaper, suffer less from unpredictable
| performance, a.k.a. "loud neighbour" problem, and are less likely
| to make you lock into some API/feature that would become a huge
| headache if you ever decide to move.
| jpgvm wrote:
| You can also make them feel pretty cloud-like by running k8s on
| them.
| jhugo wrote:
| We had a lot of noisy neighbour issues on Hetzner's VPSes, to
| the point that we stopped using them entirely. Their bare metal
| is a great offer though. And fully agreed about lock-in. If you
| can, design cloud-agnostic from the start. You get a lot more
| flexibility and you're in a much better negotiating position as
| you grow. Not realistic or necessarily sensible for every
| company/team though.
| Pandabob wrote:
| Supabase.
| andrew_ wrote:
| Came here to say this. Up and comer, adding new services every
| quarter, while attempting to innovate.
| exikyut wrote:
| This question potentially lacks the situational context necessary
| to provide the answer/insight it's really looking for.
|
| What's the SaaS going to look like technically? Lots of compute
| processing? Or maybe large volumes of data? Perhaps machine
| learning? Or is it just a simple website and app deal?
|
| Then there's the question of the technical competence on the
| ground (and the opinions that tag along for the ride). On the one
| hand, what's the expertise level? On the other hand, what do
| people prefer using? (And separately, what to people have
| experience with?)
|
| I wonder (I don't have enough context to competently move the
| slider to "proper accusation") if somewhere along the way a
| general search for un-turned-over rocks got specialized/narrowed
| into "the overhead's all in the sheet metal benders" (the
| hardware). If this *is* the case, the only correct course of
| action (IMO) is to wind the train of thought backwards (oohc
| oohc) back to that frame of reference, then apply
| https://en.wikipedia.org/wiki/Five_whys until you're somewhere
| alien and interesting.
|
| (Reiterating the caveat at the start of the previous paragraph,
| this is all massive conjecture and just-in-case assumption.)
|
| If there was in fact a point at which hardware was specifically
| called out as a primary focus of optimization, I would loudly
| note that this type of hyperfocus leaves space for entire
| forests' worth of trees to fall over without ever being noticed,
| in this case _for all of the software_. Not just certain bits of
| it but like the whole kit and caboodle, unnoticed.
|
| A related alternate possibility is that hardware optimization
| might be being treated like an axis point to orbit around, which
| can contribute to seeing things like immovable Mt Everests, and
| the construction of great and confusing Rube Goldberg machines to
| work around... perceived resistance that isn't really there.
|
| To offer a 180-degree counterpoint that sorta flies in the face
| of the abstraction-away you _might_ be trying to do here, if you
| want to look at different providers, I would suggest adopting a
| pat-answer strategy of keeping the architecture cloud-agnostic *
| _where reasonable to do so_ *, and further suggest trying
| multiple providers - how does their support help out when it's
| 3am and you have no attention span and you accidentally something
| ridiculously straightforward? What's the performance like
| relative to the workload? What do all the engineers that are
| going to be headdesking against this stuff every day think about
| different options? Etc.
|
| It's quite possible this reply is entirely misguided, in which
| case please ignore. I'm still learning the art of reading intent
| through text, I have a long way to go.
| tomrod wrote:
| > It's quite possible this reply is entirely misguided, in
| which case please ignore. I'm still learning the art of reading
| intent through text, I have a long way to go.
|
| Your mindfulness is quite appreciated and your answer is on
| point!
|
| We are at the design phase at this point. Fairly data intensive
| and will definitely have ML components (but that could be
| centralized and managed with standard MLOps practices). But the
| data is more on the backend, forward facing components are
| pretty standard CRUD/API calls against pre-computed and quickly
| updating data stores.
|
| User-facing data payloads are in design, but expected to be
| low-to-mid volume.
___________________________________________________________________
(page generated 2022-04-30 23:01 UTC)