7 ms·
Some of my colleagues and I were joking recently that the "AWS well architected" framework should've been named "AWS well paid" framework. It's like it's no lon
by sriku 6y ago
Some of my colleagues and I were joking recently that the "AWS well architected" framework should've been named "AWS well paid" framework. It's like it's no longer legit to run a small site serving a small community. It has to "scale", be secure against minions who want to usurp your machines, have backups, CI, CD, GitHub events, run on K8sa and be "cloud native", and on and on .. to show some HTML page when an end point is hit. I feel I can't even joke about this any more here.
The stacks run deep on both ends .. but I'm often not sure to what end.
- dvfjsdhgfv 6y agoIt's basically about money. As a tech guy, you choose the technologies with the largest margin. Companies who use AWS are either (1) rich enough to spend huge sums of money, (2) can't calculate or are gullible enough to believe it's the best solution for them. In either case, typically you're more likely to make money on AWS-related technologies than working for more cost-conscious clients who understand the cost structure of the overall infrastructure. That's why people code a Hello World as a React app on AWS, as ridiculous as it may seem.
- matthewmacleod 6y agoThis is absolute nonsense which reveals more about your ignorance of companies’ technology trade offs than it does anything else. Consider for a moment that other people might in fact not be idiots, and might have legitimate reasons for choosing particular technology stacks that your snarky attitude has missed.
- collyw 6y agoMy guess is that > 90% of people using Kubernetes will never need to scale elastically. My company uses it, cost a ton of developer time. It gives us high availability which is nice, but we have no need for the scaling in the foreseeable future, and that was what was used to sell Kubernetes to our founders.
- Guthur 6y agoYes, though the GP made no reference to Kubes at all and was talking more generally about AWS. AWS has an absolute tonne of great and not so great services but you can easily use the basic stuff to get quite simple and cost effective solutions. You can YOLO it on the console and not even worry about cloudformation if you want, and if you have no customers it will likely be free tier to boot.
- nilkn 6y agoI see this sentiment a lot online, but k8s for us has been quite simple to learn and use and, like you acknowledged here, solved a lot of availability issues out of the box for us that we previously had to deal with in more manual ways. Better yet, it’s a standardized platform that we can use company-wide and that every engineer understands, including potential hires — that’s very valuable. I feel it has become a common trope to claim k8s is complicated and overkill but we are quite glad we made the move to using it.
- weeboid 6y agoHave you ever considered the workforce aspect of technologies? Like, you'll still need devops, and if you aren't at least dabbling in containers and elasticity, you're going to get the luddites.
- matthewmacleod 6y agoKubernetes was not mentioned by the comment I replied to, which was about AWS. Even then, your founders might have made a bad business decision – which isn't unusual, and companies can often make bad business decisions, such as prioritising investment in scalability when it's not a required feature. They can equally make good business decisions – such as rolling out a relatively standard technology like Kubernetes to gain the workflow and availability features, even though scalability is not required. I agree that it is important to remember that sometimes "old-fashioned" approaches can be totally suitable for some use-cases, and they can be too often written off. But equally let's try not to assume that everyone who rolls out a particular modern technology stack is a gullible fool.
- dvfjsdhgfv 6y agoI haven't called anybody idiots. There are genuine reasons for using AWS specifically. I've been consulting to several companies helping them to manage their infrastructure, and more often than not it turned out that they chose AWS "because everybody is doing it", not because they understood the tradeoffs well. To be more specific: (1) they were not able to calculate the overall costs upfront. Yes there are many calculators, but you know the actual cost only when you receive the bill. Moreover, there is no hard cap on costs - people have been asking for it since 2006, and AWS was first saying they understand it's important and will take care of it, but in the end decided to ignore it.[0] Yes, you can set up alarms but that's not what people want. (2) AWS is marketed as saving on IT staff costs but it's ridiculous: you need competent staff to support it. The AWS infrastructure is huge, it's a whole ecosystem in itself, and it has its particular quirks. You definitely need smart people to run it and stay out of trouble. (3) Very often when you run a cost analysis of a particular aspect (like storage, processing etc.), it turns out the difference between AWS and, say, bare metal is enormous and, consequently, increases radically with the amount of resources used. There are several large companies who decided to move from AWS to bare metal just for this reason, saving enormous amounts of money. Now, there are several scenarios where it doesn't matter, or it matters but it makes sense to use AWS anyway, but in my personal experience this is minority of cases I had to deal with. I have nothing against AWS per se - also, there are some aspects of AWS infrastructure that are a pleasure to work with. Nevertheless, usually it makes more sense to use a whole ecosystem, and the more you get locked in, the more difficult is to get out, and the sunk cost fallacy is omnipresent among companies of all sizes. [0] https://forums.aws.amazon.com/thread.jspa?start=50&threadID=58127&tstart=0 https://forums.aws.amazon.com/thread.jspa?start=50&threadID=...
- commandlinefan 6y ago> Consider for a moment that other people might in fact not be idiots I've considered it many times, but I continuously find evidence to the contrary.
- le-mark 6y agoThis analysis is spot on, and well worth the time to consider.
- j45 6y agoLinux has far fewer networking and scaling issues as it once had, something that cloud helped with. VPS servers are more capable than ever, and the manageability might surprise some who know cloud as the only way. It's not the only way, but it can be valid now often than realized.
- vmception 6y agoIt actually doesn't have to. Serving a static site on S3 can make you hundreds of millions of dollars. Of course thats because you put a metamask plugin and cater to crypto people and don't even have to build a backend to do anything impressive there. But its scalable enough!
- busterarm 6y agoI built a static site served by S3 & cheap Lightsail boxes that serves a $5B/yr business. That was 4 years ago and beyond basic patching they've barely touched their infrastructure and it runs around $100/mo.
- Railsify 6y agoThis use case is about where AWS cost effective scalability ends, anything more complicated and you are into multiple thousands a month for a redundant solution for a critical web-app with a database. We used to run prod and stage envs in aws but as our stage environment grew we realized we could on-prem some pretty bad-a* hardware for the cost of a few months AWS billing. Now we run prod on aws, staging and dev locally.
- murukesh_s 6y agoSecond that.. and hardest thing is you don't really know where you are getting charged. i mean you can look at the billing but boy they do add up to 1000s before you know and you are so hooked into auto scaling, s3, rds with multi-az what not..
- monsieurbanana 6y agoThere's a cost maintaining a staging environment on-prem while prod is on a cloud. Slightly different versions of databases, different networking, etc... It could create issues. This does depend on how much you buy into the AWS ecosystem, if it's strictly EC2-only it's not as much of a problem. Not that I wouldn't do it, a lot of times it does make financial sense.
- 6y ago