eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
I used to cover the CPU business, writing analysis of industry developments. Since the early ’90s, when most of the major RISC architectures began to gel, the main creative task of processor designers has been to inject more parallelization into design.
First there was superscalar execution, in which multiple execution units allow more than one instructions to execute at a time. Eventually multiple processors and now multiple cores allowed logically separate threads of execution to run in parallel.
The idea that running more than one code stream at a time speeds up the overall program is a great theory, but it always seems to run into limitations in real-world applications. The designers-the people who think about time in terms of nanoseconds-always seemed to think that the software people weren’t living up to their end of the bargain, since the big market apps were so bloody single-threaded.
Some think that virtualization is the answer to this problem, but there’s nothing like an application that itself is massively parallel to help you get your money’s worth out of expensive hardware.
Messaging might be it. These days, the number of tasks performed in the messaging pipeline is so large and the complexity of those tasks so great that a busy message stream in an enterprise can saturate the processors handling it. The old notion that the Internet pipe is going to be the gating factor anyway doesn’t necessarily hold true.
I was talking to Sendmail, the people who invented the mail server, about its new Sentrion appliances. Boxes dedicated to message processing are not a new thing, but these boxes do so much it makes you think.
Think, for example, of all the things that must happen to a message either inbound or outbound. There is the basic transport protocol, the SMTP commands. The message itself may be encrypted, so there is encryption and decryption. The message may be signed. The message needs to be scanned for malware, for phishing, for malicious HTML. The sender of the message may be authenticated through DKIM or Sender ID, and their reputation evaluated. Regulatory compliance rules must be enforced. Company policies about the message must be enforced. Think also that multiple messages might be processed at once-sort of like superscalar processing for messages.
Do all these things in one process and you diminish the chance that something will slip through. Do it all in one process and you also need a parallel performance monster that can justify a large budget and a state-of-the-art architecture.
There are some other Internet security apps that can be massively parallel, but I don’t think any of them compare to messaging. Messaging is so core and critical to businesses these days that it has to be done right and it has to be done with reasonable performance.
So bring on the CPU cores, throw memory and disk arrays at them and don’t skimp. While you’re at it, add some extra redundancy for reliability purposes. Your mail volume and the number of problems in that mail are only going to increase.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer’s blog Cheap Hack.