Re:Startups should run on cloud providers
by orf on Friday August 04, 2017 @11:05AM
(#14929208)
I'd say this is a terrible generalisation. Buy a dedicated server with 32gb ram, 16 cores and 4tb of disk for $40 a month and host it there to begin with. Same steps: pay with your card, set up the server and go.
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
Re:Startups should run on cloud providers
by djsumdog on Friday August 04, 2017 @11:51AM
(#14929585)
It depends on time, money and staff. At my last shop, we ran DC/OS and it worked great, but had an eleven person platform team behind it.
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:
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.
Re:Startups should run on cloud providers
by toomuchtodo on Friday August 04, 2017 @12:12PM
(#14929757)
> 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?
Re:Startups should run on cloud providers
by vosper on Friday August 04, 2017 @11:45AM
(#14929542)
Just make sure you're taking backups. Even if it's just a midnight MySQLdump + zip and upload to S3. Just do something. You can get your code back from Github if the disk on your one server crashes, your data maybe not so much.
Re:Startups should run on cloud providers
by twothamendment on Friday August 04, 2017 @12:08PM
(#14929721)
I worked at a place that was too cheap/cash strapped/stupid to care about backups. We did nightly backups, but then one day I decided to replicate to my own server. I had plenty of room and bandwidth. Why not? It made me sleep better.
Re:Startups should run on cloud providers
by 0xCMP on Friday August 04, 2017 @11:53AM
(#14929603)
Yes, just cause it has RAID 5 doesn't mean the processor can't die (happened), or the RAID card in the data center you've never been in can't die (happened), or an unclean shutdown of a VM causes your sparse LVM Volume to die (happened)....
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.
Re:Startups should run on cloud providers
by curun1r on Friday August 04, 2017 @03:40PM
(#14931441)
Your characterization of startup cloud costs is laughably outdated. With credits for startups and the ability to go serverless, I've known startups that didn't pay a dime for hosting their entire first year despite reaching the threshold of hundreds of customers and over $1m ARR. One of my friends actually started doing some ML stuff on AWS because he wanted to use his remaining credits before they expired and his production and staging workloads weren't going to get him there.
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?
Re:Startups should run on cloud providers
by orf on Friday August 04, 2017 @03:58PM
(#14931659)
If your 32gb, 12 core server can't handle the 10 requests a second hacker news frontpage generates then you are doing something wrong. That being said, if you want to handle that by just spinning up more servers then that's a valid strategy - but you have to weigh up the costs.
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?
Re:Startups should run on cloud providers
by curun1r on Friday August 04, 2017 @04:37PM
(#14932035)
> but after one year you are hit with a huge bill
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.
Re:Startups should run on cloud providers
by Veratyr on Friday August 04, 2017 @12:35PM
(#14929886)
VPS are not dedicated servers. A dedicated server is a physical hunk of metal for your sole use. You get the entire machine, not a slice of one. A VPS is a regular virtual machine in KVM or Xen or something like that.
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).
Re:Startups should run on cloud providers
by hardwaresofton on Friday August 04, 2017 @12:44PM
(#14929949)
Wow, thanks for the info, I thought you might have meant an actual physical server but you didn't mention rackspace rentals or bandwidth costs or whatever so I figured you must have meant VPS. I thought you were suggesting renting a physical machine and then putting it in a data center myself...
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?
Re:Startups should run on cloud providers
by Veratyr on Friday August 04, 2017 @01:16PM
(#14930197)
> I thought you were suggesting renting a physical machine and then putting it in a data center myself...
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.
Re:Startups should run on cloud providers
by orf on Friday August 04, 2017 @04:00PM
(#14931673)
Hetzner is my provider of choice. They are based in Germany (something I didn't consider when posting this), and their dedicated server costs are ridiculously cheap to the point of absurdity when compared to other providers.
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)
Re:Startups should run on cloud providers
by psadri on Friday August 04, 2017 @11:59AM
(#14929655)
I tend to agree with this approach specially given how much ram/cores you can get on a single box today. You can run what took a cluster of servers 10 years ago on a single box. Just make sure your code doesn't assume that everything is running on the same host. Use some logical names that map out to an actual host, db_write -> 127.0.01 and hopefully later db_write -> db123.cloudfoo.net
Re:Startups should run on cloud providers
by jacquesm on Friday August 04, 2017 @10:00AM
(#14928687)
Not all startups should run on cloud providers. For many it makes sense but as soon as you have
- 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.
Re:Startups should run on cloud providers
by hudo on Friday August 04, 2017 @11:39AM
(#14929494)
Don't really like the article. Like it's written by manager, for some upper manager.
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.
Re:Startups should run on cloud providers
by eldavido on Friday August 04, 2017 @11:10AM
(#14929245)
The biggest cost many young companies face is people, both salaries, and management/coordination overhead.
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.
Re:Startups should run on cloud providers
by cookiecaper on Friday August 04, 2017 @11:58AM
(#14929633)
You want "provisioning scripts" no matter what. That's what ensures your systems are uniform and that you can easily and semi-sanely maintain them.
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.
Re:Startups should run on cloud providers
by polote on Friday August 04, 2017 @09:30AM
(#14928488)
If you want to prove something is good for startups don't put Lyft and DoorDash names in your article, these are not startups, they have a valuation of more than $1bn ...
> 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
Re:Startups should run on cloud providers
by joshribakoff on Friday August 04, 2017 @11:28AM
(#14929405)
Linode is 40x cheaper for bandwidth than aws. It's also easier to setup an nginx cache than screw around with cloudlfare and the associated vendor lock in. I also found that my PDF files don't load in internet explorer if hosted on aws, but load fine when hosted on my linode. Apparently having a $1,000 aws bill doesn't qualify us to receive support. Be wary of the cloud and the associated hype and lock in.
Re:Startups should run on cloud providers
by joshribakoff on Monday August 14, 2017 @03:42PM
(#15012082)
> But comparing cloud flare to nginx cache is apples to oranges.
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.
Re:Startups should run on cloud providers
by cardine on Friday August 04, 2017 @10:56AM
(#14929128)
This is exactly what I'm doing as well.
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.
Re:Startups should run on cloud providers
by CSDude on Friday August 04, 2017 @09:38AM
(#14928536)
My 39 euro Hetzner dedicated server provisoned quicker than AWS EC2. Not an apples to oranges, but if all you need is basic Linux Servers, it can be a good choice, if you can manage some basic stuff on your own, but ofc AWS is not EC2 only. My 39 euro server ks faster than most ec2 instances at a fraction of the cost.
Re:Startups should run on cloud providers
by cookiecaper on Friday August 04, 2017 @11:48AM
(#14929565)
Moved from Linode to a dedicated rental. Half the monthly cost for 3x the specs, and a night and day difference in the site's performance. High-quality hardware is deeply underappreciated. Would've cost me $1k/mo to get something equivalent on AWS.
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.
Re:Startups should run on cloud providers
by dejv on Friday August 04, 2017 @10:11AM
(#14928772)
Most of small to mid sized applications are really happy running on VPS like Linode or Digital Ocean, especially if we are talking about CRUD apps.
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.
Re:Startups should run on cloud providers
by awinder on Friday August 04, 2017 @10:41AM
(#14928988)
The flip side of this is if you're only spending $10-20 on a vps setup you're probably going to be nicely covered by the free tier on AWS. Either for at least a year or possibly for the eternity of your account.
Re:Startups should run on cloud providers
by twunde on Friday August 04, 2017 @10:12AM
(#14928781)
Frankly cloud providers have become the default way to run startups and small to medium-sized companies but frankly they're significantly expensive. You do get about a year of runway, which may make sense if you're able to close a VC funding round, but frankly you can spend 10-20k/year vs most startups that are spending 100k+/year at their cloud provider
Re:Startups should run on cloud providers
by falcolas on Friday August 04, 2017 @10:43AM
(#14929000)
I'd say go for it.
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.
Re:Startups should run on cloud providers
by dabei on Friday August 04, 2017 @11:10AM
(#14929247)
Make sense however platform independence is very hard in reality. As a startup you have to try to squeeze the biggest bang for your buck. That means to fully exploit what the platform offers and stretch to its limit. Moving to another platform requires redesigning a lot of optimization or even architecture.
Re:Startups should run on cloud providers
by falcolas on Friday August 04, 2017 @12:04PM
(#14929695)
Perhaps I'm just a jaded sysadmin (wait, I AM a jaded sysadmin), but the bells and whistles are rarely worth the cost of those bells and whistles.
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.
Re:Startups should run on cloud providers
by drdaeman on Friday August 04, 2017 @10:57AM
(#14929141)
Well, one can probably set up a "that shit doesn't really do anything serious" MVP on something even awfully host-prohibitive like Heroku, while preparing for a real deployment. Just to show off "we have a product and working on improvements".
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.
Re:Startups should run on cloud providers
by moduspol on Friday August 04, 2017 @12:39PM
(#14929907)
It's got some great benefits, though:
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
Re:Startups should run on cloud providers
by fundabulousrIII on Friday August 04, 2017 @12:29PM
(#14929848)
Totally agree on 1-3. It then becomes experiential.
If you have _no_ experience with your architecture and can't design then: cloud.
#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.
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
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?
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.
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.
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/
https://www.delimiter.com/
The last two I am thinking of switching to soon.
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.
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)
- 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
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
#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.