Startups should run on cloud providers
increment.com
increment.com
Once you get to the point where your cat photo sharing startup cannot be offline for more than 1 minute and so needs geographic failover with scaling load balancing your making enough money to pay for it.
Makes no sense to pay thousands of dollars to handle one request a minute and save you running "apt-get install mysql nginx" + spending half a day configuring it
Back up your stuff. Probably good to have two servers and have backup versions of your service ready to go on there in event of a disaster + a place to restore your S3 backups in to.
Using hosted solutions (can we please stop saying cloud?) can save a lot of initial costs.
The important thing is you need to devops from the start. You need to design your base so it can be easily ported to another provider or your own. Resist the urge to use AWS or Google specific offerings.
Every large shop I've worked at has been in the process of moving off hosted solutions to save money. But they typically got to where they were thanks to being able to quickly stand up servers.
There are tools like Terraform that are suppose to make this easier, but often I ended up fighting it so much I started writing my own:
http://penguindreams.org/blog/bee2-wrestling-with-the-vultr-...
Hiring one dev ops person who can build infrastructure with code can get you really far when trying to save hosting costs early in a startup, plus it will cut down on technical debt later.
Before I moved into security, doing devops as a day gig and consulting, I heard this repeatedly from clients who would bring me in after they already had 8, 10, 12 developers; "we wish we had hired for devops sooner".
You wouldn't not provide your devs with a solid workstation, development tooling, etc. Why would you not provide them with an efficient CICD pipeline to enable them to have the highest development velocity possible?
4 cores 8GB RAM 160TB disk
for ~$36/mo.
Here are the places I'm talking about: INIZ (iniz.com) (I currently use them, but they don't have the bes tprice)
https://cc.delimiter.com/cart/dedicatedcore-vps/
The last two I am thinking of switching to soon.
Intel Core i7-2600 2x3TB HD 16GB DDR3
Right now for $40/mo you could get: Intel Core i7-4770 2x240GB SSD 32GB DDR3
[0] https://robot.your-server.de/order/market
Edit: Just a note with my server and I expect most if they have 2 hard drives you have the option of running in RAID1 or Raw (Maybe RAID0 was an option but I can't remember)
OVH's SoYouStart has 4c/8t (Xeon E5-1620v2) + 16GB DDR3 ECC + 2x2TB HDD and unmetered 250Mbps bandwidth for $34.99/mo: https://www.soyoustart.com/us/essential-servers/ (and there are a bunch of other options if you're wiling to go to $42).
Online.net has a Xeon D-1531 (6c/12t) + 32GB DDR4 ECC + 2x250GB SSD and unmetered 300Mbps bandwidth for 29.99 EUR/mo: https://www.online.net/en/dedicated-server/dedibox-classic (and again, more options slightly higher)
Hetzner's serverbidding has a Xeon E3-1245v2 + 16GB DDR3 ECC + 2x3TB HDD and unmetered gigabit for 33.61 EUR/mo: https://robot.your-server.de/order/market
There are other options around too, these are just the big, well known ones.
I had no idea renting entire dedicated servers was so cheap (and came with all those other things as well) -- makes me wonder why VPS is even a thing since if you go the KVM route you have to set up everything yourself anyway... What am I missing?
That's an odd kind of colocation. Typically you'd buy a machine outright, colocate it and maybe sell it when you're done.
> makes me wonder why VPS is even a thing since if you go the KVM route you have to set up everything yourself anyway... What am I missing?
VPS are much smaller and are typically used by people buying on the very low end of the market, people who won't pay $40/mo for a server. They're also much easier to find in places like the US. There aren't many budget dedicated server providers in the US like there are in Europe.
Typically cost efficiency looks something like this: owning DC < colocation < dedicated server < VPS < Cloud
But also, the speed and ease with which you can change your infrastructure looks something like this: Cloud > VPS > dedicated server > colocation > owning DC. There's a tradeoff to be made.
I'd say it makes no sense to buy your 32gb, 16-core single point of fail, waste $40/mo and half a day setting it up and then have to keep it running yourself when you can easily spin up an API in API Gateway/Lambda that dumps data into dynamo/simpledb and front it with a static site in S3. That setup scales well enough to be mentioned on HN without getting hugged to death and is kept running by someone else. And if it is, literally, free for the first year, how is that not a no brainer?
You make a valid point about credits, but after one year you are hit with a huge bill. Hiding the costs of your infrastructure isn't always a good idea.
Why not buy 3 servers in different data centers for $120 a month. Is that enough redundancy for your infant startup? Why do you need to pay $100 month for a single 4gb, 4 core VPS from Amazon when you can get 38 cores, 120gb and 16tb disk dedicated servers for the same price?
That's the thing, it's really not much of a bill if you do it right. Aside from possibly the S3 bandwidth bill, which could easily be avoided by using something like Netlify, nothing in that setup I described will get prohibitively expensive until you reach significant scale. Yes, EC2 is expensive compared to other providers. So don't use EC2. You can build a startup on Amazon's managed services for a lot less and you can build in a way that's pretty easy to get off when the time comes. Just make sure to build in the proper adapters around your business logic. It's not hard to write code that works equally well under Lambda and Express and I assume you can do likewise for Java, C# and Python if you'd prefer to use those runtimes.
There are certain classes of startup that don't make sense in the cloud...as others have mentioned, if you've got heavy storage or egress requirements, cloud quickly gets very expensive. But for the majority of startups, particularly B2B, that's not the case and there's ways to build in the cloud that are damn close to free, both in dollars and ops resources. There's a group of technically-minded people who I believe are addicted to managing their own boxes. They got comfortable with doing it back when it was required and now don't want to learn a new way of doing things. But that new way really is faster and cheaper for most small businesses. And if people take some time to experiment with Serverless, Apex or some of the other tools that have sprung up around Lambda/Cloud Functions/Azure Functions, I believe most will see the virtue in moving on from self-managed servers for most workloads.
- a very large amount of storage
- a lot of data transfer
- a lot of computation (for instance, on GPUs)
Then it could be a very worthwhile exercise to figure out what the trade-off in cost vs convenience will be if you decide to roll your own. For some projects the cloud absolutely makes sense, if you have just a few servers and the total cloud hosting bill would be a small fraction of what you'd pay a team of sysadmins to keep things up and running you are probably fine going with the cloud.
But if you are going to spend thousands or 10's of thousands of $ per month on cloud hosting then make sure that your resources are allocated properly.
As many of people said here in the comments: 1. cloud is expensive as hell. Its much faster and cheaper to rent some dedicated server. Sure, it can fail since there's no failover/scaleout, but startups should fail fast, right? With good backup and acceptable downtime in case of failed hardware, dedicated hw is good enough for this stage of company development, imho
2. article assumes that building distributed system takes equal amount of time and knowledge as building one monolithic app.
3. you replaced one sys admin with dev ops. Sure, dev is dev ops, as I was dev and sys admin before, so don't see any difference there.
4. vendor lock in. Looks like at the end of the day, only AWS profits here (gold rush and seller of shovels 100+ y ago, anyone?)
5. let me just add this one; unpredictable cloud behaviour. Basically cloud providers forces you to scale out from beginning, since services can go down anytime, network can drop, etc. So instead of delivering features you're deep in aws metrics and logs, trying to understand why DynamoDb lost some random writes.
With right team, amount of money and resources, cloud makes sense. Same like running on your own rented dedicated/vm machines makes sense.
Assuming you need to pay someone at least 10k/month fully-loaded (and this is hard in SF) to manage all of this, I wouldn't bat an eye at staying on a PaaS until I got to 10-20k/month in expenses. Maybe even 30k. Managing operating systems, networking switches, datacenter contracts, linux distros, provisioning scripts, etc? No thanks.
I guess if you're worried about single dollars or tens of dollars/month you're just in a completely different place/situation than I am. With dev salaries being what they are today, the market is clearly signaling you need to optimize to use as little of it as possible.
Another thing, this article doesn't talk about serverless at all, where there isn't even compute to provision.
Deploying a server without some type of scripted process is like deploying a codebase without version control. You're just crossing your fingers and jumping off the bridge with a hope and prayer that something that happened in the background sometime in the past makes it all work, and no way to track what's really happening.
This is even more precarious with servers than with code because servers have tons of little highly-specific config changes that are much more difficult to transfer than copying and pasting `BOBS_PROGRAM_v2017-08-04.EXE`.
-----
A small shop should be able to manage their own servers as long as they remain reasonable with it (i.e., don't "scale out" to an infrastructure with 40 microservices running 8 instances each). You don't need to pay a guy $10k/mo to admin the 4-6 boxes that may actually be needed.
If people are the key to a good startup, why forward the equivalent of 2 coders' pay to Amazon?
The frequently-unacknowledged reality behind AWS et al is that many devs aren't what they're cracked up to be.
> Why spend days messing around with your own infrastructure, when you can get what you need out the door as soon as it’s ready?
If you have to spend days to make your product online it is not a problem of hosting. Stop pretending that copying lines of bash commands over ssh is too complicated.
Yes cloud can be convenient, but it is not essential at all
But comparing cloud flare to nginx cache is apples to oranges. Linode nginx cache cannot sink a modern DDOS attack
I disagree. I don't know what Amazon is using but it could be nginx.
> Linode nginx cache cannot sink a modern DDOS attack
Which are we talking about here? linode or nginx? Linode has 40 Gbps network in, with an API to spin up more servers (implement your own auto scaling). With AWS they absorb the attack & bill me thousands of dollars. That DDOS attack will shut you down financially, but yes you will stay online. With Linode I can not only stay online, but I can afford the hosting bill after the fact.
is exactly why I'm on dedicated Hetzner hardware rather than AWS.
The price difference between Hetzner and AWS is large enough that it could pay for 4x as much computational power (as much redundancy as you'd ever need), three full time system admins (not that you'd ever need them), and our office lease... with plenty of money left over!
And it's not like AWS is any easier to use than Hetzner - they both take just as much time to setup and Hetzner is at least as intuitive as AWS.
I'm always surprised when resource scarce startups are paying ridiculous amounts for AWS instances. It is a huge waste of money and I have a hard time telling if it is laziness, following the herd, or ignorance as to how expensive cloud hosting is.
Note: I did move back to Linode because the traffic all went away, and now I just run it on a fairly-small node there.
Cloud has a role, but mostly it just tricks you into leaking a lot of unnecessary cash with nickels and dimes, so you don't really realize how much you're spending.
There are multiple pros of those setups:
1. They are cheap: $10-$20/month will be ok for smallish scale/b2b application. (You can always add more nodes later if you want).
2. As your application grows, it is much easier to migrate to another VPS or dedicated HW.
3. It is much easier to switch to cloud platform like AWS than trying to change provider or migrate into your hardware. Platform lock is real.
I do hear that managing your own servers is hard, but you can totally do it after reading couple of articles or paying couple hundred dollars to some competent sysadmin.
Stick with what you are good at and pay for everything else.
With a caveat: don't tie yourself to that cloud provider, so if you want/need to make a move you can without re-building your entire stack. Most providers only make financial sense at scale if your load is wildly variable.
There's also something to be said for still being online when the rest of the internet is dark because of an AWS outage - for being able to take action when something goes wrong.
Kinesis is a great example. Sure, on paper it looks cheap - fractions of a penny per hour and per million put operations. But just to handle logs for a dozen servers, you're looking at spinning up over 8 shards (for the read capacity mostly), an equal number of lambda aggregators, and a storage service (like managed elasticsearch). This alone can end up costing several hundred dollars a month. And you still want/need a specialist for managing elasticsearch!
I've worked for two companies now where they pay out more money for their infrastructure than they do for their entire payroll. There's something that rubs me very wrong with that.
* Buy 75k hardware. * Two colos <= 30k yearly + full managed support. * One PT SA 45K.
That AWS budget doesn't touch scaling like the ability to scale across two sites and physical hardware for multiple years.
Would probably work just fine if they don't do anything heavyweight but just some CRUD/form processing with a billing integration and a few extras, like many websites/webapps essentially are. ;)
In this sense it's probably a reasonable to not bother about the initial infrastructure before you actually need it. Just don't tie yourself to the cloud, because it'll bite very painfully.
1. Over provisioning
2. Under provisioning, burstability
3. Prefers capex to opex
4. Requires hiring SA / IT forever
5. Changes in architecture become prohibitive
#4 is FUD. You'll hire them or some devops guy(s) anyway. $5 Architecture changes that require stack wide redesign are maybe common in your world but they aren't in mine. If you need to do this you probably need to be entirely month by month anyway.
1. Makes use of the skillset I already have (sysadmin managing servers), rather than requiring me to learn something new
2. Doesn't allow developers to build and iterate quickly without my permission / allowance
3. Allows me to be paid a salary and benefits that I will never factor into the costs when comparing to cloud infrastructure
4. Allows me to manage my own backups, deal with vendor finger-pointing, respond to and handle any hardware failures, amortize and replace hardware on some schedule, etc.
5. Allows me to pat myself on the back for ensuring the company theoretically avoids platform lock-in, which unsurprisingly results in more lowest-common-denominator architecture (servers needing managing, which of course, I'll manage), even if it greatly increases time to our minimum viable product