14 ms·

I see so often developers state something along the lines of, "We need to go with AWS!" (sometimes substituting AWS with GCP or Azure) and the reason they alway

I see so often developers state something along the lines of, "We need to go with AWS!" (sometimes substituting AWS with GCP or Azure) and the reason they always give is "scalability". 99% of the time, what they're building not only doesn't need to scale to that degree but they somehow seem to think that it's always inherently cheaper. Meanwhile, when I build something for a client my first go-to is something like DigitalOcean or Amazon LightSail. I know, LightSail is still AWS. But it's not going to automatically increase the bill by 300% because someone accidentally toggled something in AWS's byzantine admin console. When ("if" is more often the case) that client starts to see the kinds of traffic that necessitates a full-scale AWS build out then I'll advise them of their options. By that point, they're actually generating real revenue and, as importantly, they didn't pay me to prematurely optimize a product that wasn't yet generating any revenue, which helped them succeed.

hangonhn 6y ago
I think your sort of thinking requires a certain level of maturity and experience. I see the opposite with with some engineers who always have this illusion that the first or even second version of their project will be the final one for all times so they build it to scale (which actually doesn't even really scale because they don't know where the real bottlenecks are) and highly configurable. I've seen way, way more projects bite the dust because of poor product design or product market fit than the inability to scale. I've definitely seen projects that can't scale but at least from an engineering point of view, those problems are way more tractable than people not wanting or needing what you've created. As I've gotten more experienced, I've realized one of the great skills a good engineer has is the ability to change/fix/scale a project once it is up and running and while people are using it.
- bob1029 6y ago
  > I've realized one of the great skills a good engineer has is the ability to change/fix/scale a project once it is up and running and while people are using it. This is by far the most important lesson I have learned this decade. Anyone can pull the rug out on iteration 1 and start a completely new attempt in a 2nd iteration bucket. It takes determined engineering efforts and talent to iterate on top of the existing code base while not impacting the ability to deliver ongoing feature support to production. We have historically tried to do complete rewrites with bombastic claims like "We can do it right this time". Well, we did it "right" 3 times until we decided that restarting from zero every time is a bad way to make forward progress. I will advocate for a clean restart if you are just beginning or it is clear you have totally missed the domain model target. If you have been in production for 3 years, maybe consider a more conservative iteration approach. The best analogy I can come up with is the Ship of Theseus thought experiment. Rebuilding the ship from the inside while you are sailing it to the new world will get you there much faster than if you have to restart in Spain every time someone is in a bad mood or doesn't like how the sails on the boat are arranged.
nicoburns 6y ago
The system I inherited at my current job was built with "scalability" in mind. That meant use of the Firebase databases and splitting everything out into lots of microservices. Ironically this actually caused scaling issues (even with the very small scale we have at the moment) because the lack of query flexibility in the database meant downloading entire collections in order to provide the necessary functionality. We've since moved (almost) everything over to postgres and merged a lot of the microservice together. And while we're still running on heroku, we could probably run on Raspberry Pi if we needed to.
- tnolet 6y ago
  Sadly, I’ve seen this at more misguided startups. Microservices solve a problem no startup has until they go series B and grow like bananas. When they actually scale.
  - jayd16 6y ago
    Sounds like it has nothing to do with microservices and more that they just blew everything up instead of fixing their firebase schema. But hey, sometimes that's way simpler.
    - nicoburns 6y ago
      Microservices didn't particularly cause technical issues. Just unnecessary operational overhead. While I'd probably go with a monolith if I was building for scratch, in this case we've stuck with ~5 microservices (we did have over 10) as it works well enough. Firebase is fundamentally limited though. You simply cannot do things like joins and even filtering and updating is very limited compared to a SQL database. Of course you can implement these things in code, and precompute them and store them denormalised. But at that point you're implementing your own database and it's much less work to move the data to a different database platform. We did a gradual migration which made it relatively painless, although it was still a lot of work. And we're able to move much faster on new features now we have the flexibility of a fully-featured database.
- 6y ago
draw_down 6y ago
Really? You often see developers saying "we need to go with AWS"?
drchopchop 6y ago
Also, when it comes time to scale, it's a lot easier to bring up a relatively simple (but scalable) infrastructure on AWS than deal with: colo location, buying servers, buying spares, replacing failing hardware, imaging, setting up backups, etc etc. Those typically become concerns once you're at big scale where the cost savings are significant.
- Zelphyr 6y ago
  For what it's worth; unlike OP, I'm not suggesting Co-Lo over cloud. Co-Lo still has its place but for most projects that I'm involved with, low-cost services like DigitalOcean, Linode, or LightSail is the best option.
- jacobsenscott 6y ago
  But for most companies it never "comes time to scale". Especially if you have 100% dedicated hardware and you can start out with a 64 core db server with 120GB of memory and a matching web server pretty much for free. You need to "scale" early in a cloud environment because you are allocated a fraction of the hardware and someone else on that same hardware is using all the resources. AWS/DO etc boost their margins by packing as many vps's onto one physical box as they can. That's why on a VPS your 95th percentile response time is 1000x your 50% response time. All you can do is "scale" and pray enough of your connections are hitting the boxes that nobody else is using right now.
  - fomine3 6y ago
    VPS packs but EC2?
- ldng 6y ago
  I love how AWS fanboys make it a back-or-white issue. OVH,Hetzner and others are providing bare metal server that are provionnable by API. The choice is not between full-AWS vs full-On-Premises-By-Hand.
busterarm 6y ago
Scalability itself isn't the selling point. It's freedom. It's the freedom to get things wrong, iterate and try again. It's the freedom to move resources around. It's the freedom of not having to wait for your procurement process and approval from a purchasing department. It's the freedom of not having to wait for your operations team to plug in and configure bare metal. And all of these freedoms have compounding interest. For most organizations, what I just talked about equates to man years of work wasted and I think a lot of people nitpicking about cloud being expensive have lost sight of this. Sure it costs more, but it's from money you've already saved. You'll have loads of saved money left to spend on more developers too.
- Zelphyr 6y ago
  It sounds to me like you're describing a corporate environment with all the bureaucracy that comes with such an environment. That scenario likely has the traffic and revenue to justify a full AWS build out. I'm talking about new projects at much smaller companies, or much smaller departments within the company that don't yet know if the product they're building is going to even work. Not to mention; I have the same freedoms to try things out with a $10/mo DigitalOcean droplet as I do EC2/Lambda/ELB/RDS/S3/etc... If something doesn't work, delete the droplet and start over. To that degree, it's even easier, cheaper, and more free to just test something out in Docker containers on my laptop. So, respectfully, I'm not buying the "freedom" argument. That's not even the selling point AWS is pitching.
  - WrtCdEvrydy 6y ago
    Yeah, AWS isn't for a smaller company. When you have a real finance department that vets each third party or have some governmental requirement to get three quotes for each new service (part of requirements set out to minimize grift in sourcing), having a single bill that can be expanded to include new projects and services makes it a little simple. This causes a problem during cost cutting because unless it's a priority your bill will spiral out of control.
    - candiodari 6y ago
nickthemagicman 6y ago
If you can somehow finagle your application as a docker container, It makes it super easy to transfer too.
vmception 6y ago
> my first go-to is something like DigitalOcean or Amazon LightSail I look at compute instance providers by how they charge and for what project. Sometimes I need more RAM, sometimes I need a faster CPU, sometimes I need more storage space accessed as a normal filesystem. Sometimes I need all of the above. So it might be DigitalOcean, it might be Linode, it might be some fly-by-night bare metal provider.
- Zelphyr 6y ago
  Yes, this is the right way to approach it in my opinion. Use the right tool for the job. So many people in this industry see everything as a nail and the hammer they know is all that is needed for it.
tnolet 6y ago
You don’t go for AWS for EC2. You go for AWS because in half a day you can whip up a secure, managed and auto scaling app using their proprietary services like SQS, S3, Lambda, Kinesis, Dynamo etc.
- Zelphyr 6y ago
  Right, but my argument is that most products--especially when the company is a startup--doesn't need that kind of scalability and won't for quite some time, if ever. They all start out starry-eyed thinking they're the next unicorn and oh-my-gawd what if we start getting the kind of traffic Facebook gets tomorrow?! That's just not a reality. Facebook themselves didn't get that traffic for several years.
  - z6 6y ago
    I think you're missing the benefits outside of scalability. There are a lot of native AWS services that help you to quickly prototype and build reliable solutions. A startup saves a lot of money (and time) by not needing to hire a whole devops team to manage various service clusters.
  - merb 6y ago
    the biggest thing in the cloud is storage and managed databases. replacing a dead server with s3 is super easy. managing a database server can be challening aswell. if you have one node you still need to do backups and s3 is just way easier. also when you abstract your storage your application has a way better structure. I already refactored tons of applications where System.IO or java.io were all over the place. with object storage from the start, you barely run into that problem.
umvi 6y ago
Well for me it's more like... why should I pay $5/month for the cheapest DO droplet for a little utility web app that gets less than one hit per day? Seems like a waste to pay for a month of VM time when only a few milliseconds are actually used. I like the idea of FaaS where I'm not being charged when my code isn't running.
- Zelphyr 6y ago
  For me it's because I don't want to spend more time configuring a hosting environment than it took to write the utility web app. I can spin up a DigitalOcean droplet in two minutes and spend the other 58 minutes writing the code.
- welterde 6y ago
  Classical web hosting still exists. Probably even has less vendor lock-in and is less likely to bankrupt you if someone posts the small utility web app on HN.
  - umvi 6y ago
    Lambda is $0.20 per 1M requests, + $0.0000000021 per ms of runtime (assuming the "small utility" takes 128 MB RAM or less). So by my estimates, even if the small utility is #1 on HN for a whole day, it's not going to cost more than a dollar. Maybe there are more hidden costs, or maybe the small utility uses a lot of runtime though, so you could be right in the right circumstances.
    - welterde 6y ago
      Really depends on how long the page rendering time is. And you also didn't account for any traffic yet - that's another 0.09$/GB on top. Taking the statistics from some old Ask HN thread [0] (which is probably an underestimate?) you would need to render your site in less than 2ms to stay below 1$ for that day. And serve less than 51kB of data per page view to stay in the free 1GB of traffic region (this part should be pretty doable if you don't include any large images). Of course assuming you don't have any existing VM or web hosting you could reuse for that. Edit: Ups.. Used per-second billing instead of per-ms by accident. So even up to >1s per request it's below 1$ for that actually. So only leaves significant more traffic and lots of bandwidth usage as possible sore points for tiny web services. [0] https://news.ycombinator.com/item?id=8107658 https://news.ycombinator.com/item?id=8107658
tobyjsullivan 6y ago
Is it safe to assume these are nascent startups that need scale to succeed? If that's the case, then you are probably right that most will never need to scale. You can build them a solution that can't scale and it'll be the correct solution for the 90% that fail. And it'll be the wrong solution for the 10% that succeed.
- Zelphyr 6y ago
  The 10% that succeed won't need that kind of scale on the day they launch though. Probably not even the first 12-24 months after they launch. There will be plenty of time to see what kinds of traffic they really can expect and then plan for that. In other words; I can build them something for $10,000 that gets them to market in a month that may not be what they need in five years or I can build them something for $100,000 that gets them to market in a year, meanwhile, their scrappy competitor launched 11 months before them.
dcolkitt 6y ago
> 99% of the time, what they're building not only doesn't need to scale to that degree but they somehow seem to think that it's always inherently cheaper. Here's the thing though. For most startups, 99% of the value comes from the long right-tail of that 1% chance of explosive viral growth out of left-field. You're right, most companies aren't ever going to need that kind of overnight scalability. But most of those startups will wind up failing anyway. At the end of the day, everyone's betting that they'll be the exception that makes it big. Without that possibility it's not worth showing up at the table. And if it does come, you need to be ready to move fast. Like, "we hit the front-page of Reddit and we have 5 minutes to scale up our traffic by 5000%" fast. If you take your time to collect some revenue and circle back, the ship has likely sailed. I'm not saying thinking this way is sensible for every org. But it's definitely sensible for at least some business models. In particular within the hyper-growth SV startup scene. Foregoing scalability because most startups don't go viral, would be like an aspiring actor foregoing headshots because most auditions don't get callbacks.
- deleted 6y ago
  [deleted]
- yellowapple 6y ago
  > Without that possibility it's not worth showing up at the table. I'd argue this mentality is exactly why so many startups fail, and fail hard. They over-optimize for being one of the "lucky few" and under-optimize for actual sustainability.
  - dcolkitt 6y ago
    I agree with this, but not every startup's business model has the luxury of operating under that calculus. Particularly in markets with network effects or other winner-take-all dynamics. You're either first or you're dead. And at least one of your competitors will be investing big on VC-powered hyper growth. Slow and sustainable growth may increase short-term survival chances, but guarantees that you lose in the long-term. If Instagram or AirBnb didn't plan for rapid scalability, and focused on short-term sustainability instead, they'd almost certainly be footnotes. It doesn't mean that a startup pursuing an expensive hyper-growth scalability strategy is a good investment. But a startup building a social network or B2C marketplace will never conquer the network effects without that ingredient.
dheera 6y ago
Self hosting being cheaper is obvious. It's just a nightmare to manage reliability. With AWS or any other IaaS provider you're paying to outsource shifts of people around the clock that will work to keep servers and network connections up and running. Colocation isn't that much better either because there are still situations (like corrupt filesystems or malfunctioning power supplies) that would require physical access to the machine. With an IaaS provider you're free to go live wherever you want and focus on your business and not need to schedule shifts of people within driving distance of the colocation facility on-call. Ultimately you're paying to reclaim time, which in almost all cases for startups is a worthwhile trade. Outsource everything that isn't your core business.
- tpxl 6y ago
  >With AWS or any other IaaS provider you're paying to outsource shifts of people around the clock that will work to keep servers and network connections up and running. This is so often repeated, but at my previous company, the amount of internal outages was smaller than the amount of outages on AWS or GCP. We then migrated to AWS for some stupid reason (we didn't need scalability, that's for sure) and we had a problem with redis nodes: the instances they were running on were too small and an upgrade went wrong. We waited until the next shift for the fix. The irony.
  - dheera 6y ago
    That's great, but when you're a startup and your only option is Comcast, outages are a very real thing. Our first real office also had internet access run by these 2 dudes in the basement and outages every few weeks for a couple hours.
    - HideousKojima 6y ago
      >That's great, but when you're a startup and your only option is Comcast, outages are a very real thing. Then send your hardware to a colo for a fraction of the cost of AWS
- doublerabbit 6y ago
didibus 6y ago
When you say AWS? You mean EC2? Cause when I think AWS, I think of using Lambda, Fargate, DynamoDB, RDS, SQS, SNS, S3, Kinesis, Redshift, Elastic search, etc. All these managed services arn't just about cost or scale, a lot of it is about convenience and development speed and flexibility, as well as reduced maintainance and operational burden.
- joana035 6y ago
  "maintenance and operational burden" in the cloud is way higher than renting a box somewhere and forgetting about it. I can't understand why people keep using this as an argument against anything else other than cloud while playing catch-up with the rain of changes and suffering from fomo of last week's new stuff from cloud. Heck, when did infrastructure became like js landscape?
  - philliphaydon 6y ago
    Renting a box and forgetting about it is how you get hacked. There is more maintenance and operational burden with self hosting vs cloud. But going cloud doesn't mean there's no longer any burden.
    - joana035 6y ago
      > Renting a box and forgetting about it is how you get hacked. You get hacked in any compute model if you don't know what you doing. > There is more maintenance and operational burden with self hosting vs cloud. Renting a box is closer to dedicated hosts than to self hosting, which are two very different things. > But going cloud doesn't mean there's no longer any burden. Exactly, and it starts with the complexity and confusion that the cloud became. Then with vendor specific stuff that you don't need, such IAM, and then when you think everything is alright, you notice your bandwidth is caped after 1 hour running your ec2, that your port 25 is magically broken (docs were updated years later after much complains), everything is a slow black box. Cloud is like chopping your both legs and being happy with it.
      - 6y ago
throwaway894345 6y ago
I agree that scalability is rarely an appropriate reason to go in on AWS; however, “managed services” is a really good reason. You don’t have to operate your own equivalent services, but rather you pay for Amazon engineers to operate them on your behalf. Of course, there are some people for whom running their own services is the more appropriate scenario, but I think this is not a good default for anything more complex than a Rails app. Someone will snarkily mention that Amazon services go down from time to time across an availability zone or even a whole region, and presumably this never happens on prem (I guess the idea is that Amazon engineers are well-below average?) simply because you rarely hear about it when $MomAndPopCRUDShop goes down. On that note, in my experience, customers are really sympathetic when an Amazon outage brings you down (because half of the Internet is also down) but not very sympathetic when it’s just your site that’s down.
- ocdtrekkie 6y ago
  It's not that Amazon has worse engineers: They have great engineers. The difference is they are Amazon's engineers, not your engineers. My IT team is not going to break something on the most important day of the month for my business. Sometimes even when I want to do something mundane on the network, it's "eh, let's wait until not (insert key date here), just in case". Amazon does not care what day is important to my business, they're Amazon and they do what they want. You are going to pay IT staff either way, if it's your own hires (or an MSP), or you are paying via AWS fees. If you're going to pay for IT, why wouldn't you pay for IT that takes orders from you and cares about your business? The other thing is, Amazon's maintenance and upgrades is based around Amazon's need to remain competitive and turn a profit, and to support businesses other than yours which may have larger needs. (The rollout of a new feature that causes an outage for you might not have any benefit to you anyways.) Similarly, a single patched Exchange server running on a single VM on a VM host with a UPS backup on it is generally speaking, more reliable and has better uptime than Office 365. Hilariously, Office 365 also costs a lot more.
  - throwaway894345 6y ago
    > You are going to pay IT staff either way, if it's your own hires (or an MSP), or you are paying via AWS fees. If you're going to pay for IT, why wouldn't you pay for IT that takes orders from you and cares about your business? Because my IT staff budget would go up if they have all of the additional responsibilities that we currently outsource to Amazon by considerably more than what we would save on our AWS bill by doing it in house. This makes sense because Amazon has a lot more customers besides just me paying for their engineers to manage a given service. So I would be paying a premium "for IT that takes orders from me and cares about my business" and that premium is rarely worthwhile. In the worst case, I have an important customer demo and an Amazon outage occurs--I just explain to my customer that we're affected by the same Amazon outage that's affecting all of their other vendors and half of the rest of the Internet and I forward them the Amazon post-mortem. This has never been a problem for me to date, and I doubt there are many people who have lost deals on account of Amazon in excess of their savings for using Amazon (no doubt there are a few companies for whom this doesn't hold and they should seriously consider on prem). > Similarly, a single patched Exchange server running on a single VM on a VM host with a UPS backup on it is generally speaking, more reliable and has better uptime than Office 365. Hilariously, Office 365 also costs a lot more. If I had claimed that every managed service was worth its price for every user, then you'd have successfully refuted me. :) No doubt there are some managed services that aren't worth the price, and even an individual managed AWS service probably doesn't justify the cost of integrating with AWS; however, if you're going to be needing analogs for IAM, Lambda, EKS, SQS, CloudWatch, etc, you're probably going to be spending more on balance (and incurring more downtime) by doing it in house (consider also the difficulty in finding engineers with experience in your exact matrix of tech choices versus general AWS experience).
Baeocystin 6y ago
I work with small businesses, and 90% of the time, they are better served by running a few VMs in a 1U Xeon-powered rackmount Synology or the like. Does it have a lot of compute power? No. Is it dirt-simple to admin, and have enough horsepower to do the simple things like run a QuickBooks server on a Windows VM, Fileshare on another, test on a third, etc that is all they usually need? Absolutely! It isn't uncommon at all that I make my initial IT inventory at a new client's business and find that they are spending hundreds to thousands/month unnecessarily in overblown costs, and AWS is a primary driver of that. A few kilobucks in to owned hardware, and the problem is essentially solved for a few years, and paid for in a few months. Everybody wins.
- jariel 6y ago
  "Is it dirt-simple to admin," Often it's not though. It's a pain to admin for someone who knows nothing about it, and it's also a pain to have to do anything at all! The power of the cloud for smaller shops is that the don't have to know what Synology is, or even give it a thought. That you click point-click and set up an EC2 with some S3 and get rid of most admin knowledge/know-how is like magic. That's the best reason to use it, even it costs 1-3x as much. Once there is A) stability and predictability in requirements and B) sufficient scale - then - we can hire smart people such as yourself who know better, to set up something relatively simple, that will be relatively low maintenance (i.e. whatever you bill) and save some $. Think Development vs. Operations cost. If in dev, we have to wait for, mess with, configure things, it's very expensive, delays etc. and we don't want that. Once there's enough predictability to determine 'unit cost' on the services side ... then you can 'cut costs' by moving to a slow-changing, custom solution, that is hopefully 'simple', as you say.
  - Baeocystin 6y ago
    The (vast) majority of small businesses are not out to grow as fast as possible, seeking that big money valley exit. Most are family operations that seek to stay at whatever size that might encompass. FWIW.
    - 6y ago
908B64B197 6y ago
It all depends on how your dev's compensation is structured. AWS has great reliability and a complete ecosystem of plug-and-play offerings that just work. And it's well documented. It sure is more expensive, but it's easier to achieve the same result. And faster. And keep in mind, the dev isn't footing the AWS bill. And isn't getting paid a penny extra for trimming down said AWS bill. Of course, if you add stocks to the compensation structure or a bonus based on cloud spending, that changes the incentives.
vmurthy 6y ago
>When ("if" is more often the case) that client starts to see the kinds of traffic that necessitates a full-scale AWS Bang on. The capex costs of BYO IT setup was the bugbear(real one FWIW) that AWS and other cloud providers were trying to avoid. But if a lot of folks are paying lots of money upfront preparing for "scale" that might never happen, they aren't really saving capex are they?
anthony_barker 6y ago
Main pro for me was free network gear. Servers are more expensive that self hosting - but I don't need to buy routers and switches or some expensive HP blade server that has internalized switches.

hangonhn 6y ago

I think your sort of thinking requires a certain level of maturity and experience. I see the opposite with with some engineers who always have this illusion that the first or even second version of their project will be the final one for all times so they build it to scale (which actually doesn't even really scale because they don't know where the real bottlenecks are) and highly configurable. I've seen way, way more projects bite the dust because of poor product design or product market fit than the inability to scale. I've definitely seen projects that can't scale but at least from an engineering point of view, those problems are way more tractable than people not wanting or needing what you've created. As I've gotten more experienced, I've realized one of the great skills a good engineer has is the ability to change/fix/scale a project once it is up and running and while people are using it.

bob1029 6y ago
> I've realized one of the great skills a good engineer has is the ability to change/fix/scale a project once it is up and running and while people are using it. This is by far the most important lesson I have learned this decade. Anyone can pull the rug out on iteration 1 and start a completely new attempt in a 2nd iteration bucket. It takes determined engineering efforts and talent to iterate on top of the existing code base while not impacting the ability to deliver ongoing feature support to production. We have historically tried to do complete rewrites with bombastic claims like "We can do it right this time". Well, we did it "right" 3 times until we decided that restarting from zero every time is a bad way to make forward progress. I will advocate for a clean restart if you are just beginning or it is clear you have totally missed the domain model target. If you have been in production for 3 years, maybe consider a more conservative iteration approach. The best analogy I can come up with is the Ship of Theseus thought experiment. Rebuilding the ship from the inside while you are sailing it to the new world will get you there much faster than if you have to restart in Spain every time someone is in a bad mood or doesn't like how the sails on the boat are arranged.

nicoburns 6y ago

The system I inherited at my current job was built with "scalability" in mind. That meant use of the Firebase databases and splitting everything out into lots of microservices. Ironically this actually caused scaling issues (even with the very small scale we have at the moment) because the lack of query flexibility in the database meant downloading entire collections in order to provide the necessary functionality. We've since moved (almost) everything over to postgres and merged a lot of the microservice together. And while we're still running on heroku, we could probably run on Raspberry Pi if we needed to.

tnolet 6y ago
Sadly, I’ve seen this at more misguided startups. Microservices solve a problem no startup has until they go series B and grow like bananas. When they actually scale.
- jayd16 6y ago
  Sounds like it has nothing to do with microservices and more that they just blew everything up instead of fixing their firebase schema. But hey, sometimes that's way simpler.
  - nicoburns 6y ago
    Microservices didn't particularly cause technical issues. Just unnecessary operational overhead. While I'd probably go with a monolith if I was building for scratch, in this case we've stuck with ~5 microservices (we did have over 10) as it works well enough. Firebase is fundamentally limited though. You simply cannot do things like joins and even filtering and updating is very limited compared to a SQL database. Of course you can implement these things in code, and precompute them and store them denormalised. But at that point you're implementing your own database and it's much less work to move the data to a different database platform. We did a gradual migration which made it relatively painless, although it was still a lot of work. And we're able to move much faster on new features now we have the flexibility of a fully-featured database.
6y ago

draw_down 6y ago

Really? You often see developers saying "we need to go with AWS"?

drchopchop 6y ago

Also, when it comes time to scale, it's a lot easier to bring up a relatively simple (but scalable) infrastructure on AWS than deal with: colo location, buying servers, buying spares, replacing failing hardware, imaging, setting up backups, etc etc. Those typically become concerns once you're at big scale where the cost savings are significant.

Zelphyr 6y ago
For what it's worth; unlike OP, I'm not suggesting Co-Lo over cloud. Co-Lo still has its place but for most projects that I'm involved with, low-cost services like DigitalOcean, Linode, or LightSail is the best option.
jacobsenscott 6y ago
But for most companies it never "comes time to scale". Especially if you have 100% dedicated hardware and you can start out with a 64 core db server with 120GB of memory and a matching web server pretty much for free. You need to "scale" early in a cloud environment because you are allocated a fraction of the hardware and someone else on that same hardware is using all the resources. AWS/DO etc boost their margins by packing as many vps's onto one physical box as they can. That's why on a VPS your 95th percentile response time is 1000x your 50% response time. All you can do is "scale" and pray enough of your connections are hitting the boxes that nobody else is using right now.
- fomine3 6y ago
  VPS packs but EC2?
ldng 6y ago
I love how AWS fanboys make it a back-or-white issue. OVH,Hetzner and others are providing bare metal server that are provionnable by API. The choice is not between full-AWS vs full-On-Premises-By-Hand.

busterarm 6y ago

Scalability itself isn't the selling point. It's freedom. It's the freedom to get things wrong, iterate and try again. It's the freedom to move resources around. It's the freedom of not having to wait for your procurement process and approval from a purchasing department. It's the freedom of not having to wait for your operations team to plug in and configure bare metal. And all of these freedoms have compounding interest. For most organizations, what I just talked about equates to man years of work wasted and I think a lot of people nitpicking about cloud being expensive have lost sight of this. Sure it costs more, but it's from money you've already saved. You'll have loads of saved money left to spend on more developers too.

Zelphyr 6y ago
It sounds to me like you're describing a corporate environment with all the bureaucracy that comes with such an environment. That scenario likely has the traffic and revenue to justify a full AWS build out. I'm talking about new projects at much smaller companies, or much smaller departments within the company that don't yet know if the product they're building is going to even work. Not to mention; I have the same freedoms to try things out with a $10/mo DigitalOcean droplet as I do EC2/Lambda/ELB/RDS/S3/etc... If something doesn't work, delete the droplet and start over. To that degree, it's even easier, cheaper, and more free to just test something out in Docker containers on my laptop. So, respectfully, I'm not buying the "freedom" argument. That's not even the selling point AWS is pitching.
- WrtCdEvrydy 6y ago
  Yeah, AWS isn't for a smaller company. When you have a real finance department that vets each third party or have some governmental requirement to get three quotes for each new service (part of requirements set out to minimize grift in sourcing), having a single bill that can be expanded to include new projects and services makes it a little simple. This causes a problem during cost cutting because unless it's a priority your bill will spiral out of control.
  - candiodari 6y ago

nickthemagicman 6y ago

If you can somehow finagle your application as a docker container, It makes it super easy to transfer too.

vmception 6y ago

> my first go-to is something like DigitalOcean or Amazon LightSail I look at compute instance providers by how they charge and for what project. Sometimes I need more RAM, sometimes I need a faster CPU, sometimes I need more storage space accessed as a normal filesystem. Sometimes I need all of the above. So it might be DigitalOcean, it might be Linode, it might be some fly-by-night bare metal provider.

Zelphyr 6y ago
Yes, this is the right way to approach it in my opinion. Use the right tool for the job. So many people in this industry see everything as a nail and the hammer they know is all that is needed for it.

tnolet 6y ago

You don’t go for AWS for EC2. You go for AWS because in half a day you can whip up a secure, managed and auto scaling app using their proprietary services like SQS, S3, Lambda, Kinesis, Dynamo etc.

Zelphyr 6y ago
Right, but my argument is that most products--especially when the company is a startup--doesn't need that kind of scalability and won't for quite some time, if ever. They all start out starry-eyed thinking they're the next unicorn and oh-my-gawd what if we start getting the kind of traffic Facebook gets tomorrow?! That's just not a reality. Facebook themselves didn't get that traffic for several years.
- z6 6y ago
  I think you're missing the benefits outside of scalability. There are a lot of native AWS services that help you to quickly prototype and build reliable solutions. A startup saves a lot of money (and time) by not needing to hire a whole devops team to manage various service clusters.
- merb 6y ago
  the biggest thing in the cloud is storage and managed databases. replacing a dead server with s3 is super easy. managing a database server can be challening aswell. if you have one node you still need to do backups and s3 is just way easier. also when you abstract your storage your application has a way better structure. I already refactored tons of applications where System.IO or java.io were all over the place. with object storage from the start, you barely run into that problem.

umvi 6y ago

Well for me it's more like... why should I pay $5/month for the cheapest DO droplet for a little utility web app that gets less than one hit per day? Seems like a waste to pay for a month of VM time when only a few milliseconds are actually used. I like the idea of FaaS where I'm not being charged when my code isn't running.

Zelphyr 6y ago
For me it's because I don't want to spend more time configuring a hosting environment than it took to write the utility web app. I can spin up a DigitalOcean droplet in two minutes and spend the other 58 minutes writing the code.
welterde 6y ago
Classical web hosting still exists. Probably even has less vendor lock-in and is less likely to bankrupt you if someone posts the small utility web app on HN.
- umvi 6y ago
  Lambda is $0.20 per 1M requests, + $0.0000000021 per ms of runtime (assuming the "small utility" takes 128 MB RAM or less). So by my estimates, even if the small utility is #1 on HN for a whole day, it's not going to cost more than a dollar. Maybe there are more hidden costs, or maybe the small utility uses a lot of runtime though, so you could be right in the right circumstances.
  - welterde 6y ago
    Really depends on how long the page rendering time is. And you also didn't account for any traffic yet - that's another 0.09$/GB on top. Taking the statistics from some old Ask HN thread [0] (which is probably an underestimate?) you would need to render your site in less than 2ms to stay below 1$ for that day. And serve less than 51kB of data per page view to stay in the free 1GB of traffic region (this part should be pretty doable if you don't include any large images). Of course assuming you don't have any existing VM or web hosting you could reuse for that. Edit: Ups.. Used per-second billing instead of per-ms by accident. So even up to >1s per request it's below 1$ for that actually. So only leaves significant more traffic and lots of bandwidth usage as possible sore points for tiny web services. [0] https://news.ycombinator.com/item?id=8107658 https://news.ycombinator.com/item?id=8107658

tobyjsullivan 6y ago

Is it safe to assume these are nascent startups that need scale to succeed? If that's the case, then you are probably right that most will never need to scale. You can build them a solution that can't scale and it'll be the correct solution for the 90% that fail. And it'll be the wrong solution for the 10% that succeed.

Zelphyr 6y ago
The 10% that succeed won't need that kind of scale on the day they launch though. Probably not even the first 12-24 months after they launch. There will be plenty of time to see what kinds of traffic they really can expect and then plan for that. In other words; I can build them something for $10,000 that gets them to market in a month that may not be what they need in five years or I can build them something for $100,000 that gets them to market in a year, meanwhile, their scrappy competitor launched 11 months before them.

dcolkitt 6y ago

> 99% of the time, what they're building not only doesn't need to scale to that degree but they somehow seem to think that it's always inherently cheaper. Here's the thing though. For most startups, 99% of the value comes from the long right-tail of that 1% chance of explosive viral growth out of left-field. You're right, most companies aren't ever going to need that kind of overnight scalability. But most of those startups will wind up failing anyway. At the end of the day, everyone's betting that they'll be the exception that makes it big. Without that possibility it's not worth showing up at the table. And if it does come, you need to be ready to move fast. Like, "we hit the front-page of Reddit and we have 5 minutes to scale up our traffic by 5000%" fast. If you take your time to collect some revenue and circle back, the ship has likely sailed. I'm not saying thinking this way is sensible for every org. But it's definitely sensible for at least some business models. In particular within the hyper-growth SV startup scene. Foregoing scalability because most startups don't go viral, would be like an aspiring actor foregoing headshots because most auditions don't get callbacks.

deleted 6y ago
[deleted]
yellowapple 6y ago
> Without that possibility it's not worth showing up at the table. I'd argue this mentality is exactly why so many startups fail, and fail hard. They over-optimize for being one of the "lucky few" and under-optimize for actual sustainability.
- dcolkitt 6y ago
  I agree with this, but not every startup's business model has the luxury of operating under that calculus. Particularly in markets with network effects or other winner-take-all dynamics. You're either first or you're dead. And at least one of your competitors will be investing big on VC-powered hyper growth. Slow and sustainable growth may increase short-term survival chances, but guarantees that you lose in the long-term. If Instagram or AirBnb didn't plan for rapid scalability, and focused on short-term sustainability instead, they'd almost certainly be footnotes. It doesn't mean that a startup pursuing an expensive hyper-growth scalability strategy is a good investment. But a startup building a social network or B2C marketplace will never conquer the network effects without that ingredient.

dheera 6y ago

Self hosting being cheaper is obvious. It's just a nightmare to manage reliability. With AWS or any other IaaS provider you're paying to outsource shifts of people around the clock that will work to keep servers and network connections up and running. Colocation isn't that much better either because there are still situations (like corrupt filesystems or malfunctioning power supplies) that would require physical access to the machine. With an IaaS provider you're free to go live wherever you want and focus on your business and not need to schedule shifts of people within driving distance of the colocation facility on-call. Ultimately you're paying to reclaim time, which in almost all cases for startups is a worthwhile trade. Outsource everything that isn't your core business.

tpxl 6y ago
>With AWS or any other IaaS provider you're paying to outsource shifts of people around the clock that will work to keep servers and network connections up and running. This is so often repeated, but at my previous company, the amount of internal outages was smaller than the amount of outages on AWS or GCP. We then migrated to AWS for some stupid reason (we didn't need scalability, that's for sure) and we had a problem with redis nodes: the instances they were running on were too small and an upgrade went wrong. We waited until the next shift for the fix. The irony.
- dheera 6y ago
  That's great, but when you're a startup and your only option is Comcast, outages are a very real thing. Our first real office also had internet access run by these 2 dudes in the basement and outages every few weeks for a couple hours.
  - HideousKojima 6y ago
    >That's great, but when you're a startup and your only option is Comcast, outages are a very real thing. Then send your hardware to a colo for a fraction of the cost of AWS
doublerabbit 6y ago

didibus 6y ago

When you say AWS? You mean EC2? Cause when I think AWS, I think of using Lambda, Fargate, DynamoDB, RDS, SQS, SNS, S3, Kinesis, Redshift, Elastic search, etc. All these managed services arn't just about cost or scale, a lot of it is about convenience and development speed and flexibility, as well as reduced maintainance and operational burden.

joana035 6y ago
"maintenance and operational burden" in the cloud is way higher than renting a box somewhere and forgetting about it. I can't understand why people keep using this as an argument against anything else other than cloud while playing catch-up with the rain of changes and suffering from fomo of last week's new stuff from cloud. Heck, when did infrastructure became like js landscape?
- philliphaydon 6y ago
  Renting a box and forgetting about it is how you get hacked. There is more maintenance and operational burden with self hosting vs cloud. But going cloud doesn't mean there's no longer any burden.
  - joana035 6y ago
    > Renting a box and forgetting about it is how you get hacked. You get hacked in any compute model if you don't know what you doing. > There is more maintenance and operational burden with self hosting vs cloud. Renting a box is closer to dedicated hosts than to self hosting, which are two very different things. > But going cloud doesn't mean there's no longer any burden. Exactly, and it starts with the complexity and confusion that the cloud became. Then with vendor specific stuff that you don't need, such IAM, and then when you think everything is alright, you notice your bandwidth is caped after 1 hour running your ec2, that your port 25 is magically broken (docs were updated years later after much complains), everything is a slow black box. Cloud is like chopping your both legs and being happy with it.
    - 6y ago

throwaway894345 6y ago

I agree that scalability is rarely an appropriate reason to go in on AWS; however, “managed services” is a really good reason. You don’t have to operate your own equivalent services, but rather you pay for Amazon engineers to operate them on your behalf. Of course, there are some people for whom running their own services is the more appropriate scenario, but I think this is not a good default for anything more complex than a Rails app. Someone will snarkily mention that Amazon services go down from time to time across an availability zone or even a whole region, and presumably this never happens on prem (I guess the idea is that Amazon engineers are well-below average?) simply because you rarely hear about it when $MomAndPopCRUDShop goes down. On that note, in my experience, customers are really sympathetic when an Amazon outage brings you down (because half of the Internet is also down) but not very sympathetic when it’s just your site that’s down.

ocdtrekkie 6y ago
It's not that Amazon has worse engineers: They have great engineers. The difference is they are Amazon's engineers, not your engineers. My IT team is not going to break something on the most important day of the month for my business. Sometimes even when I want to do something mundane on the network, it's "eh, let's wait until not (insert key date here), just in case". Amazon does not care what day is important to my business, they're Amazon and they do what they want. You are going to pay IT staff either way, if it's your own hires (or an MSP), or you are paying via AWS fees. If you're going to pay for IT, why wouldn't you pay for IT that takes orders from you and cares about your business? The other thing is, Amazon's maintenance and upgrades is based around Amazon's need to remain competitive and turn a profit, and to support businesses other than yours which may have larger needs. (The rollout of a new feature that causes an outage for you might not have any benefit to you anyways.) Similarly, a single patched Exchange server running on a single VM on a VM host with a UPS backup on it is generally speaking, more reliable and has better uptime than Office 365. Hilariously, Office 365 also costs a lot more.
- throwaway894345 6y ago
  > You are going to pay IT staff either way, if it's your own hires (or an MSP), or you are paying via AWS fees. If you're going to pay for IT, why wouldn't you pay for IT that takes orders from you and cares about your business? Because my IT staff budget would go up if they have all of the additional responsibilities that we currently outsource to Amazon by considerably more than what we would save on our AWS bill by doing it in house. This makes sense because Amazon has a lot more customers besides just me paying for their engineers to manage a given service. So I would be paying a premium "for IT that takes orders from me and cares about my business" and that premium is rarely worthwhile. In the worst case, I have an important customer demo and an Amazon outage occurs--I just explain to my customer that we're affected by the same Amazon outage that's affecting all of their other vendors and half of the rest of the Internet and I forward them the Amazon post-mortem. This has never been a problem for me to date, and I doubt there are many people who have lost deals on account of Amazon in excess of their savings for using Amazon (no doubt there are a few companies for whom this doesn't hold and they should seriously consider on prem). > Similarly, a single patched Exchange server running on a single VM on a VM host with a UPS backup on it is generally speaking, more reliable and has better uptime than Office 365. Hilariously, Office 365 also costs a lot more. If I had claimed that every managed service was worth its price for every user, then you'd have successfully refuted me. :) No doubt there are some managed services that aren't worth the price, and even an individual managed AWS service probably doesn't justify the cost of integrating with AWS; however, if you're going to be needing analogs for IAM, Lambda, EKS, SQS, CloudWatch, etc, you're probably going to be spending more on balance (and incurring more downtime) by doing it in house (consider also the difficulty in finding engineers with experience in your exact matrix of tech choices versus general AWS experience).

Baeocystin 6y ago

I work with small businesses, and 90% of the time, they are better served by running a few VMs in a 1U Xeon-powered rackmount Synology or the like. Does it have a lot of compute power? No. Is it dirt-simple to admin, and have enough horsepower to do the simple things like run a QuickBooks server on a Windows VM, Fileshare on another, test on a third, etc that is all they usually need? Absolutely! It isn't uncommon at all that I make my initial IT inventory at a new client's business and find that they are spending hundreds to thousands/month unnecessarily in overblown costs, and AWS is a primary driver of that. A few kilobucks in to owned hardware, and the problem is essentially solved for a few years, and paid for in a few months. Everybody wins.

jariel 6y ago
"Is it dirt-simple to admin," Often it's not though. It's a pain to admin for someone who knows nothing about it, and it's also a pain to have to do anything at all! The power of the cloud for smaller shops is that the don't have to know what Synology is, or even give it a thought. That you click point-click and set up an EC2 with some S3 and get rid of most admin knowledge/know-how is like magic. That's the best reason to use it, even it costs 1-3x as much. Once there is A) stability and predictability in requirements and B) sufficient scale - then - we can hire smart people such as yourself who know better, to set up something relatively simple, that will be relatively low maintenance (i.e. whatever you bill) and save some $. Think Development vs. Operations cost. If in dev, we have to wait for, mess with, configure things, it's very expensive, delays etc. and we don't want that. Once there's enough predictability to determine 'unit cost' on the services side ... then you can 'cut costs' by moving to a slow-changing, custom solution, that is hopefully 'simple', as you say.
- Baeocystin 6y ago
  The (vast) majority of small businesses are not out to grow as fast as possible, seeking that big money valley exit. Most are family operations that seek to stay at whatever size that might encompass. FWIW.
  - 6y ago

908B64B197 6y ago

It all depends on how your dev's compensation is structured. AWS has great reliability and a complete ecosystem of plug-and-play offerings that just work. And it's well documented. It sure is more expensive, but it's easier to achieve the same result. And faster. And keep in mind, the dev isn't footing the AWS bill. And isn't getting paid a penny extra for trimming down said AWS bill. Of course, if you add stocks to the compensation structure or a bonus based on cloud spending, that changes the incentives.

vmurthy 6y ago

>When ("if" is more often the case) that client starts to see the kinds of traffic that necessitates a full-scale AWS Bang on. The capex costs of BYO IT setup was the bugbear(real one FWIW) that AWS and other cloud providers were trying to avoid. But if a lot of folks are paying lots of money upfront preparing for "scale" that might never happen, they aren't really saving capex are they?

anthony_barker 6y ago

Main pro for me was free network gear. Servers are more expensive that self hosting - but I don't need to buy routers and switches or some expensive HP blade server that has internalized switches.