311–320 of 343 posts
Earlier quoted context omitted.
I feel almost the opposite. The AWS console seems so chaotic and needlessly complex to me compared to the simple familiarity of plugging in a hardware server. Maybe I'm an old geezer already but I'm not even that old!
Terraform is love. Terraform is life.
Earlier quoted context omitted.
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 int…
I know corps and teams where they need approvals for each cloud resource they instantiate. That is a culture problem. On other hand, when we were using simple VPSes at various companies, at some companies, I could just send email saying I provisioned a new server and at the others, they wanted a ticket with justification for it. But we always had enough test servers to try out and experiment. Cloud is great in many w…
I've seen this at my current employer. Like so many, got hooked via first-hit-is-free Azure credits. It doesn't even run end user facing services, just does software development, yet somehow after a few years of being a startup the cloud bill was millions of dollars a year. Why: because engineers would create a fresh VM from scratch rather than just logging in and using their accounts on pre-existing VMs. They'd forget to delete resources. They'd use expensive services like managed Kubernetes because why not.
There was also a more subtle cost harder to account for: Azure machines are dog slow so significant engineering time was wasted trying to work around that problem.
There has to be some friction to push people into using pre-existing hardware instead of acquiring more. If there isn't you end up with an absurd IT footprint well beyond anything justifiable in engineering terms.
Earlier quoted context omitted.
> "they give you rope to hang yourself with." That's not a triviality - C++ has the same problem, if you have a single ezpert individual it's great, but if you have a team, and some are very green, it will be a nightmare.
Here we are in agreement. Thing is though, people who well-understand AWS/Azure/Google are plentiful (but expensive) in the industry at this point. Small startups can't afford to have junior talent.
So they pay far more for the mess/waste/damage, but that somehow doesn't matter to them. Not just startups, some big corporates too.
Earlier quoted context omitted.
Even for that kind of small-scale business: what happens when that server has hardware trouble? Are they testing their backups regularly? Something like Heroku might cost them much more in an average month, but it eliminates a huge range of worst case scenarios.
They have a contract with an IT professional to handle that sort of thing for them, same as they would have a contract with someone who uses Heroku or Amazon to fill their IT needs if they were using those servers instead.
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 Di…
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 int…
With bare metal it's 100% predictable. Where to book the sudden spike in costs in April? Why did it happen? We had €3000 booked for this project in April, why do we have to pay €5000? And so on.
Sure, if you have too much money to burn and the financial department is lax with controlling the costs, AWS feels great, but not everybody has this luxury.
Earlier quoted context omitted.
They have a contract with an IT professional to handle that sort of thing for them, same as they would have a contract with someone who uses Heroku or Amazon to fill their IT needs if they were using those servers instead.
If they've got an in-house sysadmin, you can get a lot of PaaS time for that price. If they've got an agency tasked with looking after their servers, in my experience that's not a great situation; you might get a little more personal attention than you would from a PaaS vendor, but you're always a client rather than a colleague, and you're pretty much paying for the same product that a PaaS would sell you; they might…
Earlier quoted context omitted.
firebase is probably the most hyped and overused tech I've seen. I've run into far too many startups that went to firebase because they wanted to scale fast and didn't realize how limited firebase was for queries. If you're starting a startup, use postgres for your database. it will handle damn near anything and you can spawn off functionality into microservices as they become bottle necks as you scale. Hell, postgre…
Two reasons I use Firebase for my app (although with an admittedly trivial schema/data): a) I have a thousand things to do that are higher priority than configuring/hosting a Postgres server. b) Integration with Firebase Auth is a godsend. I doubt people choose Firebase for technical or scaling reasons. More likely they choose it because it's trivial to integrate, so you can spend the limited hours you have in each d…
Earlier quoted context omitted.
"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?
Doing OS updates, configuring load balancers, DB backups, setting up firewall rules and OS user accounts, ssh access, archiving logs, configuring monitoring and alarms, assigning DNS, handling deployments, etc. I don't know, as an application developer, I'd rather not waste my time with stuff like that if I can avoid it.
> I don't know, as an application developer, I'd rather not waste my time with stuff like that if I can avoid it.
Believe or not there are other roles besides "developer" within technology related jobs.
The problem of cloud is that the heavy majority of supporters just echo the usual "scale", "maintenance" arguments without even willing to learn what those things are to the fundamental level.
"You have to scale", said the developer that switch his ec2 from one type into the next, more expensive one, "now I have two vCPU, great!"
And the people who knows how the real world of infrastructure is doesn't buy this cheap arguments, but are outnumbered by the louder major group.
That is freaking depressing!
Earlier quoted context omitted.
"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?
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.
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.
Earlier quoted context omitted.
I’m not sure what point you’re making exactly, but Stripe and AirBnB (not sure about Shopify) are all on AWS. > A year after Airbnb launched, the company decided to migrate nearly all of its cloud computing functions to Amazon Web Services (AWS) because of service administration challenges experienced with its original provider. Nathan Blecharczyk, Co-founder & CTO of Airbnb says, “Initially, the appeal of AWS was th…
I was referring more to the throw-away reference to Rails apps being small potatoes.