Why Is Email So Complicated? Part 101: There's Just Too Much Of It
"Space is big. Really big. You just won't believe how vastly hugely mind-bogglingly big it is. I mean, you may think it's a long way down the road to the chemist, but that's just peanuts to space. Listen..."
So, as volume scales, you need to get more machines and bandwidth. That's pretty obvious. Almost as obvious is the need for more skilled operations personnel -- by the time you have tens of thousands of machines, like Google, one person couldn't even turn them all on or off in one day.
But even if you're on top of these things, there are some that might creep up on you. Can the line from the power company handle all your needs or do you need them to lay another? Do you have enough HR people to hire your new admins? Enough room for all your servers? Enough rows in all your databases? Enough failover plans? Enough compliance monitoring? Is your basic software architecture hurtling towards its capacity, with a major rewrite in the works?
It's nearly always the things you don't expect that burn you. For a while a major limiting factor in Mimecast's growth was the speed with which we could absorb new customers' often vast existing email archives. A simple one-time auxilliary process can become a major problem as you scale up.
Email isn't unique in this regard, but it suffers greatly from its own success. Beyond the challenges for operators hinted at above, there's the bozo factor. If a billion people are sending email, you can guarantee that quite a few of them are doing so using broken or amateur software, out of compliance with the standards, causing untold mischief. There are relatively few such problems, but even a few out of billions can create headaches for mail admins around the world.
The scale problem is shared with any other service that sees these kinds of volumes, but those are relatively few. Email's extraordinary scale only exacerbates its fundamental complexity, as I'll be explaining in future installments in this series.
Of course, that's still oversimplified .... Nathaniel Borenstein <[email protected]>