8 ms·
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 traff
by 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 agoYeah, 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 agoAnd yet, AWS isn't for a really larger company either. At some point the bills become so huge that running your own IT and datacenters is cheaper. Usually a lot. Even when it means building some AWS services yourself. https://www.bmc.com/blogs/dropbox-aws/ https://www.bmc.com/blogs/dropbox-aws/
- oblio 6y ago> These large companies rely on these established solutions, paying much bigger bills than Dropbox – surely, there must be a good reason for it. Maybe the answer is this: the cloud isn’t the answer for everyone, but it probably is for most companies.
- ldng 6y agoYes, it really is a curve bell but I get deride every time I say it ... the power of marketing.
- apple4ever 6y agoA bell curve is a great way to describe it.
- taylodl 6y agoWorker at Fortune 200 company here having multiple datacenters and the operations staff to go with that. So far, every single application we've ported over to AWS has resulted in reduced costs. I'm not even talking about total costs, i.e. datacenter power costs, real estate taxes, staffing costs - I'm only talking about server costs, networking costs, storage costs and software licensing costs. So far AWS has beat on-premise every single time. Is it cheap? Compared to running on-premise Hell Yeah! Our average savings has been 60% (and like I said we're not even looking at total cost, so the actual average savings is even higher). It's ridiculous.
- busterarm 6y agoIf you know how to build in AWS cost-effectively (and really to cost-effectively use compute in general), I would still pick cloud over buying any hardware. For my last gig I was hosting the web infrastructure for a 5B/yr enterprise with a low-5 digit Alexa Rank on roughly $100/mo in EC2 instances. That was after converting the property to a static site built with jekyll (you can do pretty amazing, magical-looking things with front end JS calling out to apis and nginx SSI while still serving static conntent) and a hosted wordpress ($25/mo) for the content editors (and CircleCI's free tier for builds -- woop woop). And we were insanely over-provisioned with those t2.smalls. Procurement sucks. Having to test out new systems when you need to buy new hardware 2 years later also sucks. Having to wait behind much larger customers when Intel has a Xeon supply shortage sucks (2018 sucked if you had to buy servers).
- Zelphyr 6y agoI've mentioned this elsewhere but; I'm not arguing co-location over cloud. I'm arguing inexpensive cloud like DigitalOcean, Linode, or LightSail over a complex AWS configuration designed to scale with near infinite flexibility. Why does a product that gets 100 visitors a day need that? $5-10/month serves them just fine.
- busterarm 6y agoLightSail isn't any cheaper than the EC2 instance types backing it. Everything else (VPCs, IAM roles, etc) doesn't have a cost associated. What you're missing is that cost/complexity-wise, LightSail and EC2 are equivalent. The only difference between them is your interface to it. LightSail doesn't give you some pretty necessary knobs to kick things into a working state when the EC2 instances are having a burger. In fact, the last time I used LightSail and had a problem with unavailable instances, I just ran the ec2 api commands against the lightsail instance IDs to solve my problem. DigitalOcean has some networking properties that make it extremely undesirable for some use cases and Linode is frequently the target of massive global DDOS. I remember well a few years ago the Christmas Eve Linode DDOS because I had to work 20 hours that day. Thankfully it was only 20 hours because we were already in the process of moving off of Linode and we just decided to flip all of the switches to serve out of AWS. Most of the time was spent waiting on DNS TTLs. Instance costs across all of the cloud providers are pretty competitive. Where AWS and Google Cloud and Azure are more expensive are in those "extra" services where you would be paying people to run infrastructure (elasticsearch, sql databases, etc). DO, Linode, etc, don't give you that option -- it's not an apples-to-apples comparison....and in most cases you shouldn't use some of these things. Definitely no service where you can't just pick up and go use some other hosting tomorrow. Cloud vendor lock-in is real.
- busterarm 6y agoI didn't even mention the best part about hosting projects in cloud providers. You can generalize the infrastructure to run 99% of businesses needs and write that Terraform code only once. You can bring that with you everywhere and take care of the basics in seconds and you can sleep at night easily without a pager going off.
- calvinmorrison 6y agoWe used this with Azure. We contracted a firm to write a stack for eCommerce sites we were spinning up left and right. It passed through ITIL and was approved all over the chain. After that - security was happy, ops was happy, everyone was happy. Everything was just deploying an application - be it an application making millions of dollars per instance across many brands. It enabled the branding/marketing teams to launch sites without waiting for months of tech backlog. it was beautiful
- mattmanser 6y agoWhat on earth has this got to do with the scenario being discussed? You have a mature product, with a proven market and known scalability demands. The exact opposite of how this thread started and somehow this is a good anecdote refuting it!
- calvinmorrison 6y ago> You can generalize the infrastructure to run 99% of businesses needs and write that Terraform code only once. You can bring that with you everywhere and take care of the basics in seconds and you can sleep at night easily without a pager going off. To quote my parent. That's what we did and it worked for us.
- busterarm 6y agoIt was in an almost exactly similar situation to yours where I learned to do this and I've been able to scale it up to companies with 1000x more demanding infrastructure. The funnier thing in my case was that three years after I left, the infrastructure was humming along fine with nobody actively looking at it. They never hired anyone to look after it because it never gave them any problems and they would have been fine to keep paying me to be there and do little/nothing. I've staked my whole career on this way of doing things and I'm never looking back.
- cortesoft 6y agoI am confused how DigitalOcean is different than AWS? Why is a $10/mo DO droplet different than a small EC2 instance?
- mlboss 6y agoCompute wise they may be same but configuration wise EC2 instance is a super complex.
- tracker1 6y agoI have to agree... I think DO is pretty good as a starter ground... found dokku because of the DO startup option, and it's pretty much my go to for spinning something up to play with and/or tear down. Create an app with a Dockerfile in the root of the project, and it's a git push away from deployed. The LE extension adds https, and it pretty much just works. Connecting to DO hosted databases and object storage is pretty smooth as well. It doesn't auto-scale like FaaS options, or offer a lot of the other bits one may want/need, but it does good for a lot of the one-off things I'll play with.
- User23 6y agoAmazon itself used to be that environment. Before AWS was adopted internally, which it wasn't for some time, to say nothing of the many years before it was created, getting capacity involved a weeks or even months long political game with the infrastructure team. Even infrastructure devs had to struggle to find resources. Hiring managers would literally horse trade their spare capacity.
- rualca 6y ago> Amazon itself used to be that environment. Before AWS was adopted internally, which it wasn't for some time, to say nothing of the many years before it was created, getting capacity involved a weeks or even months long political game with the infrastructure team. It's my understanding that you're describing how Amazon worked in the 90s. It's my understanding that Amazon afterwards moved to an internal cloud provider, and afterwards spun off AWS which worked in parallel with Amazon's internal cloud provider.
- busterarm 6y ago> It's my understanding that you're describing how Amazon worked in the 90s. It's my understanding that Amazon afterwards moved to an internal cloud provider, and afterwards spun off AWS which worked in parallel with Amazon's internal cloud provider. Not at all. Amazon's transformation took years. Up until last year, amazon.com was Oracle's biggest customer. AWS development far outpaced their actual use of it.
- User23 6y agoThe website platform itself started migrating to AWS, in a crude but reasonably effective way, in 2009. Various other service owners migrated sooner though. Also there had already long been a directive to build services as though they were going to be used by external customers since the early 2000s. It's not wrong to view AWS as just another step in Amazon's long services journey, although that elides many significant events.