131–140 of 202 posts
It's a skill set that disappeared with AWS "engineering" became a thing unfortunately.
Earlier quoted context omitted.
Umm...no. Just no. > - Security specialist You need them in both environments if you're serious about security. Unless you somehow believe that being in the "cloud" grants you some kind of security by default? > - Hardware specialist (someone who knows how to physically install servers, NAS, SAN, etc.) You can contract this out to the datacenter itself. This is typically a one-time expense when installing infrastruct…
> You need them in both environments if you're serious about security. Unless you somehow believe that being in the "cloud" grants you some kind of security by default? I don't disagree that you need a security focused person in cloud. However, the scope of security is drastically different in cloud vs data center (and varies depending on what your data center setup is). > What does this even mean? What happens if yo…
It's 2023. Hardware operates within spec 99.99% of the time, unless the data center is literally on fire. AWS/GCP has outages too, btw.
> Yes, AND Nagios, Solarwinds, Cisco, IBM, VMWare, etc. etc. and every one of their subsidiaries that have esoteric needs.
If you have all these esoteric needs ON TOP of needing a multi-DC redundant setup with 1000s of servers, then being able to afford 1-2 additional engineers is a complete non-factor. In the cloud, this would mean you're hiring additional cloud engineers anyway.
> Ummm...no. Just no. Have you ever had to create multiple subnets, DMZs, SD-WAN setups, plus VPN access, etc. etc. with multiple locations, all with security in mind, and full redundancy across three data centers? "just a linux admin" isn't the job description for that.
Again, if that's your use case, then we're not talking about 1 cloud engineer vs 3 non-cloud engineers. We're talking an IT department of several hundred people just for infra. It's absolutely not evident that cloud would result in cost-savings here, because at this scale, everything is on an individual scenario basis.
My goodness is it Monday already and time for yet another of these articles? At a given scale and software maturity, it is cheaper to buy your own hardware and pay for your own team to operate it. Generally, this is when you start thinking of your hardware needs in terms of fractions of an entire data center, but in simple cases may be smaller. This almost is not ever true for software startups, who get more value fr…
>And then when you do reach that point, you get to write the article about how everyone using the cloud are fools because it's cheaper to self host.
at least read the article, this is about a software company that started in a colo and literally wouldn't be a viable company if they tried to use the cloud. It's more about the fact that if you have the skills you can avoid having to burn a huge amount of VC money by running your own hardware
Earlier quoted context omitted.
The cost differential in my experience is generally higher on the low end. Once you get into the hundreds of k per month in cloud fees you can get steep discounts, and some of the gap starts to close. You also need devops resources to manage a cloud setup - most of my jobs in recent years have involved exactly that, and it's not appreciably cheaper than managing "raw" hardware resources these days (ever since IPMI et…
I've heard many times that while retails AWS prices are high all big AWS customers are getting discounts. Just curious at which scale this starts in terms of $$.
This usually requires a term spending commitment and gets you an effective discount of around 5-10%. Higher spends can yield significantly deeper discounts, of course. I think you'll find it difficult to get specifics at higher spends due to non-disclosures.
Google 'AWS EDP negotiated' and you'll find some more info on the process.
From the caveat at the end of the original article: > This article doesn’t take into account other aspects that would make the comparison even more complicated. These include people skills, financial controls, cash flow, capacity planning depending on the load type, etc. You can't handwave all this away in real life though. If you're rolling your own data center, the engineering time you need to put into managing ser…
One of my longest contracts was being on call for a a company to assist with their cloud setup. Most of this is not abstracted away all that well. Having managed both on premises, colocated, managed servers and cloud services, my customers when I was consulting tended to need more of my time for similar sized setups to manage cloud setups. Yes, with a colocated setup we needed to rack and wire up servers, but the amo…
My goodness is it Monday already and time for yet another of these articles? At a given scale and software maturity, it is cheaper to buy your own hardware and pay for your own team to operate it. Generally, this is when you start thinking of your hardware needs in terms of fractions of an entire data center, but in simple cases may be smaller. This almost is not ever true for software startups, who get more value fr…
If you are software startup, then you don't need all those cloud services. You need a server, install webserver, database, redis or whatever you need and you're good to go. Going cloud as startup is almost always over-engineering. Just go simple. Your total costs will be couple of hundreds $$ and you'll serve a million people with this simple infra. Probably much more.
Earlier quoted context omitted.
Try to run LLaMA in cloud...
VPNs and hybrid architectures exist for a reason. If 99% of your IT infra is boring crap but you have this one special unicorn machine, maybe throw it on an employee's fiber connection and set up a point-to-site VPN for that machine. Does it make sense to abandon the entire cloud because of 1 use case?
Of course, those prices to rapidly up if you use serious data. Want to train your fancy ML model to draw cats based on your giant data set of customer cat photos stored on S3? Want to do it on your nice nVidia box at home? That, by itself, might cost as much as an expensive Silicon Valley FTE who could manage an entire installation in a colo facility nearby.
When you consider that 2U size servers with 128 cores and 2TB of RAM are now a commodity thing you can buy for not a totally absurd price, you can serve a real metric shitload of end-user-facing https content and applications from literally one item of hardware now. I'm not saying put all your stuff on literally one box, but colocation space for even a really high traffic thing might not exceed something like 1 44U c…
Earlier quoted context omitted.
So much kubernetes is just overkill. A fast modern 16 core machine with 128 gig of ram can meet a lot of needs.
> A fast modern 16 core machine with 128 gig of ram can meet a lot of needs. True, as long as you don't care about redundancy or scalability or wasting money because you actually only use 4GB of RAM and barely any CPU. > So much kubernetes is just overkill. Absolutely true. Kubernetes is great in some scenarios, but pretty complex so overkill when starting. Serverless (ideally containers as a service), docker-compose…
> True, as long as you don't care about redundancy or scalability or wasting money because you actually only use 4GB of RAM and barely any CPU.
Redundancy: you want two fast machines. More if you want them in multiple locations, but we still see a lot of people with presence only in us-east.
Scalability: You can go to 96-core per socket on commodity x86 servers now; 16 -> 96 is a lot of room to scale. You can also go up to I think 3TB per socket on Epyc Genoa.