by edtech_dev on 5/1/24, 2:36 AM with 57 comments
My main requirement is that I don't want any lock in; if something goes wrong, I want to be able to easily move providers and spin up my deployment there.
My contenders so far are Hetzner and Linode. What are you guys using and how has your experience been?
by __d on 5/1/24, 3:35 AM
That said: I don't know enough about your situation, but ... what are you optimizing for?
AWS/GCP/Azure have each got a platform that provides a heap of functionality. Using that will save you time-to-delivery and engineer-hours. All the clouds have startup programs that will mean it's basically free until you get some traction.
If you're looking for investment, using AWS/etc means you instantly avoid all the questions about CapEx and risk that follow from self-hosting.
Don't underestimate the upside of not dealing with a bunch of cobbled-together service providers (hosting, billing, SMS for 2FA, email, monitoring, etc, etc). Having a single provider and a single bill simplifies your admin a lot.
And if you need to scale in a hurry, it's a whole lot easier if you've adopted a cloud platform.
Is avoiding lock-in really a big problem? In your software, you can either use a third-party abstraction, or build a shim layer that sits above the services you use that would allow you to migrate (even to self-hosting) if you had to. For the most common services, there's not even really a need for this: the AWS API is widely supported anyway. The devops/sysadm side is harder though.
Some of this won't apply if you're bootstrapping: it's more work, but vastly cheaper to do a lot of stuff yourself, and renting a half-cabinet colo and stuffing it with off-lease servers will cost you engineer-hours, but saves a heap of cash. Augmenting that with a PC at home for backup, and cheap VMs from Digital Ocean, Vultr, Hetzner, Linode, etc for scale might work out well. But it's hard to beat the free plans from the clouds.
by goralph on 5/1/24, 5:20 AM
To be reductionist ... I'd rather have to deal with vendor lock in a growing successful startup, then have cloud agnostic infrastructure and be out of runway.
Even then, I think people generally over-engineer this problem. I've worked at multiple unicorns who have been 'locked' in to AWS/GCP/Azure.
Think in terms of risk, and opportunity cost.
by noop_joe on 5/1/24, 1:25 PM
At a very high level, when using the big 3 and hosting that's raw infra you're going to find ways to pay for _keeping things running smoothly_. At least the big three have happy paths to avoid some of the operational burden (hidden among many many foot guns).
Full disclosure I work at noop.dev [1], a hosting provider trying to shift the focus of developers from infra-level abstractions to application-level abstractions.
I'm probably biased, but my instinct is that concerns over lock-in are totally valid, but the cost of avoiding is higher than the penalty of embracing.
by toast0 on 5/1/24, 5:21 AM
Locations, bandwidth, number of machines, orchestration capabilities, etc?
Avoiding lock in is 'easy'; avoid using specialized services and features that aren't universal. Avoid bundling services that need not be bundled. Your hosting provider should not also be your domain registrar, and maybe shouldn't be your DNS provider, nor your email provider. Big cloud has high outbound bandwidth rates, so avoid collecting a large amount of state that would need to be copied in a move. (Easier said than done)
by rgrmrts on 5/1/24, 2:33 PM
I used Fly as a modern successor to Heroku (I know Heroku is still around). Features are good, scaling to 0 is great, their networking stuff is solid, and pricing is fair. I generally use it to host application backends.
Vultr for when I want a long lived server or build my own infrastructure platforms. I use it as just a VPS provider for larger machines at reasonable costs. Caveat being I’m managing my own infrastructure with all the trade-offs that come with it.
by ActorNightly on 5/1/24, 9:37 AM
2. Self host through Cloudflare tunnels. Works fine enough for little traffic as long as you are not maxing out bandwidth for data transmission.
3. When you grow, easy enough to move the containers to the cloud.
by jasonvorhe on 5/1/24, 11:43 AM
If you're already running container workloads, DigitalOcean has a managed Kubernetes offering that's quite decent. If you're only using VMs so far, I don't think you'll gain anything by introducing the complexity of the bigger cloud providers (managing VPC, subnets, firewalling).
Of course you can use a cloud provider and just stick with a common stack that can be easily moved to different providers or hosted on metal/on-prem once the need arises.
In order to provide a more useful answer, I'd like to know your current tech stack and a rough estimate of traffic/users.
I've done consulting for various clients who wanted to move from on-prem to cloud and vice versa and as long as you stay clear of the proprietary products you shouldn't worry that much about cloud lock-in. Stick with Postgres/MySQL, redis, containers/VMs and try to have as much of your infra in code, if possible.
by joshagilend on 5/1/24, 4:43 AM
- Cloudflare [1] scales easily and has a lot of easy to use services like databases and storage buckets, JAM Stack front end pages, and CDN services for images and videos.
- Render [2] has been great for us to spin up Python services quickly. I haven't worked with a production load on Render, but I hear good things :)
by CM30 on 5/1/24, 6:02 PM
But you may want to provide a bit more detail as to what you're after here. What languages/frameworks do you plan to use, how much support do you need and what kind of pricing are you looking for?
by 0xBDB on 5/1/24, 3:17 PM
by atmosx on 5/1/24, 8:28 PM
DigitalOcean is okay-ish although, I don’t feel like their services can handle high amounts of traffic. Their offering is rather complete though as they have an object store with free CDN support, managed DBs, managed app deployment platform (or nodes you can manage or kubernetes distribution) to run apps.
by mdean on 5/1/24, 2:50 AM
Feel free to check them out. If you want I can send you my referral link.
by JSDevOps on 5/1/24, 7:56 AM
by _akhe on 5/2/24, 1:51 AM
No need for anything else. Vercel covers most front-end use cases, and when I need persistence/backend I have my home server. In a couple things I'll use Vercel + MongoDB Atlas so it's fully cloud, but still free. If it's something that wouldn't be free I move it to the Pi.
by karmakaze on 5/1/24, 12:08 PM
I agree with others that it's not a good idea for an actual company building a real product. You'll likely soon get into a situation where a using an available cloud service/feature will simply solve something avoiding a lot of infrastructure/development work for trade-off in paying the price for a service. Cloud-agnostic isn't a worthwhile goal for a 'true' startup, where calendar time and developer time should me things to optimize for more than cloud bills. The idea is to iterate/pivot quickly and using services to try stuff is the advantage. If this doesn't match your 'startup', that's fine and you can choose based on your criteria.
by flybayer on 5/1/24, 3:03 PM
But of course AWS is a nightmare on it's own.
So you might like Flightcontrol [1] which provides a PaaS user experience on your own AWS, thereby giving you the best of both worlds.
by mekster on 5/2/24, 12:26 AM
Their backup is not at a block level just because they can optimize it for their benefit which limits the partition be formatted only in unencrypted ext3 or ext4 to be able to use their backup service.
https://www.linode.com/docs/products/storage/backups/#additi...
I don't like them sweeping through list of files daily and their backup service choked having millions of files a few years ago while I was still with them. Backing up at a block level will never impose such limitations.
So, their backup service which is one of the reason to use a cloud with hefty 20% added charge, is pretty much meaningless if you're using zfs. Haven't checked all but a provider taking backup at a file system level should be totally the minority.
by gperkins978 on 5/1/24, 5:11 PM
I say this because the rest of the world either does AWS/Azure, or still does it all onsite. Just my two cents.
by FKFnwL on 5/1/24, 11:28 AM
It should work with other languages through Docker and their Python API, but I can't speak to the ease of deployment in that case.
by logotype on 5/1/24, 9:39 PM
by ao98 on 5/1/24, 2:52 AM
by speedgoose on 5/1/24, 6:57 AM
Why do you want to avoid the main cloud providers? Is it needed for your startup or you want to add extra risk and complexity?
by throwaway38375 on 5/1/24, 8:43 AM
I'm going to use the LAMP stack for example, because everyone is familiar with it.
For example, if you choose MySQL (rather than AWS Aurora) you can:
1. Run that locally during development
2. Install it yourself on a VPS
3. Or migrate to any of the big clouds quite easily
Same goes for your stack. Rather than using PHP with AWS Lambda, provision VMs and install PHP yourself (probably using some sort of shell script).
All cloud providers offer a VM in one form or another, so you're free to swap to another one when you choose.
by serguzest on 5/1/24, 7:43 PM
܁ DigitalOcean droplet(s) with Docker service preinstalled.
܁ All services are running with docker-compose.
܁ Managed Postgresql and spaces for storage.
܁ Cloudflare free tier and their `tunnel` product as a reverse proxy into your docker-compose network is super useful.
܁ Github actions and container registry to compile and sync container images. We have staging/production environments. Some GitHub actions run idempotent Bash scripts to prepare droplets.
܁ Shameless plug, I am up for hire.
by syndicatedjelly on 5/1/24, 5:52 AM
by serjester on 5/1/24, 12:57 PM
by KomoD on 5/1/24, 5:24 PM
primary: co-located server running Proxmox
also cloudflare workers, cloudflare pages, github pages
by iamflimflam1 on 5/1/24, 4:37 AM
You are going to burn through a lot of time and resources worrying about cloud lock in and being cloud agnostic.
That’s energy that should go into building your product and finding customers.
by quintes on 5/1/24, 5:51 AM
Pick one and get going
by aprdm on 5/3/24, 9:20 PM
by Froedlich on 5/1/24, 2:15 PM
by tobinfekkes on 5/1/24, 3:24 AM