Earlier quoted context omitted.
Hey, this response makes you look like an adolescent asshole. Parent poster was clearly asking about prioritization.
[flagged]
Being an asshole is being a moron.
Why we use our own hardware
361–370 of 547 posts
Re: Why we use our own hardware
#362Earlier quoted context omitted.
Your comment is confusing because you start this one saying your inbox is full of spam, but respond to a suggestion to mark it as spam by saying it's not actually spam. If something is not spam but you want it out of your inbox there's a few options: - click Unsubscribe next to the sender. This should be possible for essentially all promotional email. - click Actions -> click Block . Messages from this address will n…
I guess what's confusing is that I'm calling the promotional emails also "spam". But thanks for your suggestions. I see a few problems. When I receive a promotional email, I want to add a rule, and I have to click 7 times (including once for "Archive"), and use the scroll-wheel to select the "Promotions" label. Secondly, the rule is not applied directly. This is confusing, and cumbersome. Note: I don't want to Unsubs…
One rule that may be good, depending on how much of the mailing list email you receive is promotional, is to match "A header called List-Unsubscribe exists" and move that to Promotional. Then you could put any exceptions that it categorizes wrong above it.
Re: Why we use our own hardware
#363The whole push to the cloud has always fascinated me. I get it - most people aren't interested in babysitting their own hardware. On the other hand, a business of just about any size that has any reasonable amount of hosting is better off with their own systems when it comes purely to cost. All the pro-cloud talking points are just that - talking points that don't persuade anyone with any real technical understanding…
Even as an Anti-Cloud ( Or more accurately Anti-everything Cloud ) person I still think there are many benefits to cloud. Just most of the them are over sold and people dont need it.
Number one is company bureaucracy and politics. No one wants to beg another person or department, go on endless meetings just to have extra hardware provisioned. For engineers that alone is worth perhaps 99% of all current cloud margins.
Number two is also company bureaucracy and politics. CFOs dont like CapX. Turning it into OpeX makes things easier for them. Along with end of year company budget turning into Cloud credits for different departments. Especially for companies with government fundings.
Number three is really company bureaucracy and politics. Dealing with either Google, AWS and Microsoft meant you no longer have to deal with dozens of different vendors from on server, networking hardware, software licenses etc. Instead it is all pre-approved into AWS, GCP or Azure. This is especially useful for things that involves Government contracts or fundings.
There are also things like instant worldwide deployment. You can have things up and running in any regions within seconds. And useful when you have site that gets 10 to 1000x the normal traffic from time to time.
But then a lot of small business dont have these sort of issues. Especially non-consumer facing services. Business or SaaS are highly unlikely to get 10x more customers within short period of time.
I continue to wish there is a middle ground somewhere. You rent dedicated server for cheap as base load and use cloud for everything else.
Re: Why we use our own hardware
#364Earlier quoted context omitted.
The other part is that when us-east-1 goes down, you can blame AWS, and a third of your customer's vendors will be doing the same. When you unplug the power to your colo rack while installing a new server, that's on you.
OTOH, when your company's web site is down you can do something about it. When the CEO asks about it, you can explain why its offline and more importantly what is being done to bring it back. The equivalent situation for those who took a cloud based approach is often... ¯\_(ツ)_/¯
With the cloud, in a lot of cases you can have additional regions that incur very little cost as they scale dynamically with traffic. It’s hard to do that with on-prem. Also many AWS services come cross-AZ (AZ is a data center), so their arch is more robust than a single Colo server even if you’re in a single region.
Re: Why we use our own hardware
#365The original answer to "why does FastMail use their own hardware" is that when I started the company in 1999 there weren't many options. I actually originally used a single bare metal server at Rackspace, which at that time was a small scrappy startup. IIRC it cost $70/month. There weren't really practical VPS or SaaS alternatives back then for what I needed. Rob (the author of the linked article) joined a few months…
As a customer of Fastmail and a fan of your work at FastAI and FastHTML I feel a bit stupid now for not knowing you started Fastmail.
Now I'm wondering how much you'd look like tiangolo if you wore a moustache.
Re: Why we use our own hardware
#366To me, Cloud is all about the shift left of DevOps. It’s not a cost play. I’m a Dev Lead / Manager and have worked in both types of environments over the last 10 years. It’s immeasurable the velocity difference as far as system provisioning between the two approaches. In the hardware space, it took months to years to provision new machines or upgrade OSes. In the cloud, it’s a new terraform script and a CI deploy awa…
Exactly this. It is culture and organisation (structure) dependent. I'm in the throes of the same discussion with my leader ship team, some of whom have built themselves an ops/qa/etc. empire and want to keep their moat.
Are you running a well understood and predictable (as in, little change, growth, nor feature additions) system? Are your developers handing over to central platform/infra/ops teams? You'll probably save some cash by buying and owning the hardware you need for your use case(s). Elasticity is (probably) not part of your vocabulary, perhaps outside of "I wish we had it" anyway.
Have you got teams and/or products that are scaling rapidly or unpredictably? Have you still got a lot of learning and experimenting to do with how your stack will work? Do you need flexibility but can't wait for that flexibility? Then cloud is for you.
n.b. I don't think I've ever felt more validated by a post/comment than yours.
Re: Why we use our own hardware
#367You also terminate accounts at your sole discretion
Re: Why we use our own hardware
#368The biggest win with running your own infra is disk/IO speeds, as noted here and in DHH's series on leaving cloud ( https://world.hey.com/dhh/we-have-left-the-cloud-251760fb ) The cloud providers really kill you on IO for your VMs. Even if 'remote' SSDs are available with configurable ($$) IOPs/bandwidth limits, the size of your VM usually dictates a pitiful max IO/BW limit. In Azure, something like a 4-core 16GB RAM…
Biggest issue isn't even sequential speed but latency. In the cloud all persistent storage is networked and has significantly more latency than direct-attached disks. This is a physical (speed of light) limit, you can't pay your way out of it, or throw more CPU at it. This has a huge impact for certain workloads like relational databases.
I ran into this directly trying to use Azure's SMB as a service offering (Azure Files) for a file-based DB. It currently runs on a network share on-prem, but moving it to an Azure VM using that service killed performance. SMB is chatty as it is, and the latency of tons of small file IO was horrendous.
Interestingly, creating a file share VM deployed in the same proximity group has acceptable latency.
Re: Why we use our own hardware
#369Re: Why we use our own hardware
#370Earlier quoted context omitted.
To avoid sysadmin tasks, and keep costs down, you've got to go so deep in the cloud, that it becomes just another arcane skill set. I run most of my stuff on virtual Linux servers, but some on AWS, and that's hard to learn, and doesn't transfer to GCP or Azure. Unless your needs are extreme, I think sysadmin'ing is the easier route in most cases.
For so many things the cloud isn't really easier or cheaper, and most cloud providers stopped advertising it as such. My assumption is that cloud adoption is mainly driven by 3 forces: - for small companies: free credits - for large companies: moving prices as far away as possible from the deploy button, allowing dev and it to just deploy stuff without purchase orders - self-perpetuating due to hype, cv-driven develo…
A cloud is really easy to get started with.
Free tiers, startup credits, easily available managed databases, queues, object storage, lambdas, load-balancing, DNS, TLS, specialist stuff like OCR. It's easy to prototype something, run for free or for peanuts, start getting some revenue.
Then, as you grow, the costs become steeper, but migrating off of the cloud looks even more expensive, especially if you have accumulated a lot of data (egress costs you, especially from AWS). Congrats, you have become the desirable, typical cloud customer.