4 ms·
As a developer at a big company, if I try to buy a server, then I have to deal with my IT department. I don’t get to buy what I want, have to deal with particul
by jonstewart 6y ago
As a developer at a big company, if I try to buy a server, then I have to deal with my IT department. I don’t get to buy what I want, have to deal with particular overpriced vendors, and the process slows to a crawl.
If I want to use AWS, however, I get instant gratification. And of course I can experiment with different models and then refine into cheaper service mixes as scale increases. As base load emerges, I can use reserved instance pricing and shift that onto our capital budget. And of course I can control everything with code using AWS CDK.
At a smaller company where I was able to control the IT process more, it might be worthwhile. But the speed and optionality I get with AWS is vastly more cost effective than dealing with legacy enterprise IT processes.
- MrBuddyCasino 6y ago> As a developer at a big company, if I try to buy a server, then I have to deal with my IT department. This. AWS is a way to put control back into the hands of developers and work around the internal IT mafia. People are quick to forget how that was like. For startups, AWS is either a really dumb idea or a valuable tool to go faster than the competition, depending on funding and growth rate.
- user5994461 6y ago>>> People are quick to forget how that was like. I would postulate that the author of the article has no idea what's it like. The stories are happening in small companies that are too small to have an IT mafia or any sort of procurement process.
- someguydave 6y agoThis is probably the real reason for bundled cloud provider popularity. It’s way easier for competent engineers to cut out the brigade of uninformed and cheap managers of the IT budget when you distill your specs into an AWS credit card charge. For a small startup of competent people this is unneeded, but those companies typically succeed or fail into mediocrity eventually.
- user5994461 6y agoIt's only 80% of the reason. The other 80% is all the time wasted dealing in the physical world, moving and plugging servers. You could have the most competent engineer fully backed by the company, it's still going to take weeks to procure a goddamn server because it takes time to fight DELL and ship to the colo and have remote hands put it in place and set it up and a thousand more things.
- someguydave 6y agofor sure, the friction of managing physical servers is much higher. it would be worthwhile if a company commits to managing those physical assets well, which very few would commit to doing
- krab 6y agoThat's why I prefer renting servers. The company manages networking gear, guarantees having spare parts and someone on call to replace things. If your requirements aren't too exotic, you can get the server in place in a day. Compared to big cloud, you get much better CPU and RAM for your money and usually unmetered gigabit connection.
- 013a 6y agoI think your core argument is in the right place, but: What Big Company enables typical developers personal provisioning on their cloud accounts? I've never seen this before. Its always handled through an operations team. The cloud definitely simplifies the operations team's job, and you may be able to get something more specific faster than whatever gray box the IT Of Years Past has available, but I don't think you're getting around the Cloud Boilerplate of worrying about IAM, CloudFormation/IaC, repeatability, security, granting access, cleaning up... I think this position is missing the bigger picture; it shouldn't matter where you've got something deployed. That's the Operations Team's problem. Instead, we need to talk about, lets call them, Functional Primitives. For example: If you want a docker image deployed w/ x vCPU y memory z replicas etc, behind a URL. That's a functional primitive. It shouldn't matter whether its in ECS or in Kubernetes in the closet or wherever. That's on the operations team, and its also on them to get that provisioned quickly for you. In other words, you're still thinking that its the operations team's job to provide servers, so of course the quickest way to get a server is the Cloud. But that should not be their role; their role should be to provide capacity at a higher level of abstraction.
- jonstewart 6y agoMine?
- 013a 6y agoThe correct answer to "What company would provide developers direct access to raw compute resources in the cloud" is "one that is deeply misguided." At the most simple level, it seems like progress. Now every developer can get their own server and push their code, test it, do whatever, think of the agility. But, realistically, all that's happened is the creation of hundreds of silos, each configured differently, possibly being abused, possibly containing restricted data, mis-configurations leading to breach, denial of service, running up the company card, all sorts of bad things. In other words, it doesn't matter whether those raw compute resources are available in the cloud or in a company data center. The cloud enables developers broader access to provisioning, but there's substantial evidence that may not be a good thing. A company data center is a 1780s-era musket; the cloud is a M249 machine gun. That's why we need to talk in abstract functional primitives. Developers shouldn't worry about which TLS algorithms are accepted, or that the storage bucket they want has proper read/write access; not just because a ton of this stuff is very arcane and domain specific, but also because humans will ALWAYS get it wrong unless its managed at a higher, centralized, and totally automated level. And at that point, raw access to AWS doesn't make sense. Developers don't actually want an EC2 instance; they want their app running on a server. Let Operations (or Heroku, or whoever) handle that for you.