Why do none of OpenAI announcements have an author attributed to them? Are people that ashamed of working there, they don't even want to attach their name to the work? I guess I would be, too.
Why assume any of the information in this article is factual? Is there any indication any of it was verified by anyone who does not have a financial interest in "proving" a foregone conclusion? The principal author of this does not even have the courage to attach their name to it.
Yikes, you can't attack another user like this on HN, regardless of how wrong they are or you feel they are. We ban accounts that post like this, so please don't.
Fortunately, a quick skim through your recent comments didn't turn up anything else like this, so it should be easy to fix. But if you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site to heart, we'd be grateful.
Meanwhile, 30k Amazon-minded individuals are unleashed on to other tech companies to evangelize Amazon products and services. The design of it all is really apparent.
Ex-Amazonians aren't the best boosters of Amazon. What really happens is that everyone at other big-corps start complaining about new people managers and product/project managers coming in with a culture that is a bit more toxic than normal.
Is this how it plays out, or does it backfire with the former employees being bitter about the layoff and not wanting to be free evangelists for the company didn’t show them any loyalty.
> They might be bitter but evangelize Amazon products are their most marketable skills.
I think you are talking out of ignorance and spite. Most of the services used by Amazon employees are internal services that may or may not be on par with the state of the art. Apparently a big chunk of Amazon doesn't even use AWS at all, and instead use proto-cloud computer services that are a throwback from the 90s take on cloud computing.
> Apparently a big chunk of Amazon doesn't even use AWS at all, and instead use proto-cloud computer services that are a throwback from the 90s take on cloud computing.
Is there more information on this somewhere. I had leadership telling me and a few others that we needed to replicate something on-par with AWS for internal use (with about 10 devs and less than a year timeline). I thought this sounded crazy, and it would be interesting if Amazon themselves didn’t even have what was being asked of us.
> I thought this sounded crazy, and it would be interesting if Amazon themselves didn’t even have what was being asked of us.
Amazon has multiple incantations of this. As legend would have it, AWS was an offshoot of Amazon's internal cloud infrastructure designed to monetize it to amortize their investment on bare metal infrastructure. They partitioned their networks for security reasons and for a few years their infrastructure evolved independently. Then AWS was a huge success and took a life of its own. Only relatively recently did Amazon started to push to drop their internal infrastructure to put all their eggs on AWS in general but serverless solutions in particular.
Well, There's not going to be much because it would violate NDA, but, nothing is 'elastic'.
Somewhere, someone, has to buy a set amount of servers, based on a running capacity projection and build those into usable machines. The basis of a datacenter, is an inventory system, a dhcp server, a tftp server, and a DNS server that get used to manage the lifecycle of hardware servers. That's what everyone did at one point, and the best of them build themselves tooling.
What amazon has is built on what was available at the time both for tooling and existing systems that they'd have to integrate with. You almost certainly don't have to build anything that complex. Additionally, you can get an off the shelf DCIM that integrates with your DHCP and DNS servers and trigger ansible runners in your boot sequences that handle the lifecycle steps. It's considerably easier to do now than it was 15 years ago.
While they don't use AWS specifically for a lot of stuff, the internal tooling can still build thousands of boxes an hour though they don't really pay for UI work for that stuff.
You can put a host(s) in a fleet, tell it the various software sets you want installed and click go and you'll have a fleet when you come back, so don't think that what you're being asked to build is impossible or not being used under every single major cloud provider or VPS provider.
The slightly harder part is deciding what you're going to give to devs for a front end. Are you providing raw hosts, VMs, container fleets, all of it? how are you handling multi-zone or multi-region . . ., how are you billing or throttling resources between teams.
The beauty of this is you get a lot of stuff for free these days. You can build out a fleet, provide a few build scripts that can be pulled into some CI/CD pipeline in your code forge of choice and you don't really need to build a UI.
Provisioning tooling is hard, but it's a lot easier now that it was 15/20 years ago and all the parts are there. I've built it several times on very small teams. I would have loved to have 10 devs to build something like that, but the reality is that you can get 80% with a little glue code and a few open source servers.
Anyone who shows up and their only contribution is to push AWS services because that's what they know, the first question I asked them is if they are capable of doing it themselves on-prem. Their answer is no or they don't know how to or some babbling on about it's more expensive and ROI and things like that I dismiss them immediately. Because those may all be true things but without the ability to do it yourself it is impossible to make an accurate assessment if AWS or another cloud service is actually a good fit for what you're doing.
What I would give for my org to just buy an oxide rack and run everything license free on there. Shame the only people with access to our CIO are salesmen…
