Actually BIG-IP has no problems decrypting... working with app data...load balancing...tcp multi-plexing...etc... then re-encrypting. You can get offloading for caching and compression and at the same time be SSLed on both the client and server side of the proxy.

Discloser: I work for F5... You're discounting the real time OS which provides all the integrated SSL offload, compression, caching, etc inline... TMOS. Even a comment on our own Dev Central was asking where they could download our proxy source, just because we use CentOS as a bootstrap and platform for our control plane (GUI). It would be a major technology misunderstanding to believe that we process our real time integrated proxy code in standard SMP interrupt driven I/O ways on the hardware. We don't. I really appreciated the fact that the author and comments at least see clearly the need to go to true proxies without fast pathing the server response. I'll have you talk to the customers of my competition and expect the P.O.s to show up. Here is a list of critical features I deploy regularly for my customer with TMOS which I would be interested in hearing the FOSS solutions for. These are all stock features, not software add-ons (we have those too!) of BIG-IP LTM on 6900. - Homing 100-1000s of virtual servers each with their own separate layer 4 WAN/LAN optimization characteristics. We give about 20% performance improvement at layer 4 for your TCP based applications (not just HTTP). What's the corresponding FOSS way of doing 100s of different TCP layer optimization configurations on the same box? - We base the level of HTTP gzip compression on the layer 4 rtt timing, effectively giving variable rate compression tuned to the individual end client's connection ability. We don't compress at all if you are sitting right next to the server on a Gbps link... why would you.. it slows things down? - We do HTTP level connection multiplexing on the backend, saving your server 1000s of connection requests...driving your scaling way up. - We user our business logic engine to AES encrypt/decrypt HTTP cookies on the fly. (Shall I start base64ing everyones cookies now and see how many sessions I can high-jack?) - We use our business logic engine to perform DR and business continuity decisions based on backend application performance metrics. This demands dynamic SNATs per backend connection. (Personally I need this for a charity I help with... Someone have interesting iptables on steroids solution for me?) - We use our business logic engine to consume HTTP redirects, avoiding costly WAN re-connections. That can be as much as a 4-5x improvement in user experience over the Internet. - We use our business logic engine to intelligently decide to cache or compress specific pieces of content. Anyone run into IE choking on specific Javascript because it was compressed...we do all the time. - We use our busines logic engine to help direct search bots to optimized content servers to improve a sites search ranking. - How about something as simple as rewriting the page content to replace hard coded links on the fly at Gbps speeds? We do it everyday. I can go on for hours.. We use our real time software stack (TMOS) as a swiss army knife to perform solutions which vary between helping reduce backend replication topologies, to SIP message based load balancing for IVRs, to SMTP mail reputation service integration, to.. you name it. And we do it at high-speeds for everything because of the tight integration... not point proxies chained together in a box. With the level of switching integration also provided in our platforms, we virtualize layer 2,3,4,5,6, and 7 in the stack with integrated business logic. You add that to our load balancing and monitoring heritage, and that's a 6900..not just basics SSL offload, caching, compression proxies. We're a layer of intelligence on the network you are not used to having. A lot of the guys inside F5 are linux heads and love their FOSS. Me included.

I can agree with many of the points made, but I need to point out a few others. I think the article focused too tightly on software and tech for tech sake. 1) Saying Microsoft is so overwhelming as to nullify the other technology players in Seattle is not correct. There is plenty of tech in Seattle that has nothing to with Microsoft PC based OSes or products (hello... aerospace anyone?) PC based software systems don't equal technology. 2) IT product companies can be notoriously cheap on spending. Business centers in turn can become places where actual use of the technology drives product requirements and innovation. That puts some very bright people making good money in New York, Tokoyo (not the whole of Japan), London, Chicago, Dallas, Houston, etc.. There are some tech folks in the business sector I would stack up against the best vendor engineers or university types out there. Notice most of the world's telecom isn't found in the cities on the list. It's more towards business. Wall Street and Main Street spends money.... Not just the list above. 3) While innovation is increasingly becoming much more a corporate thing (vs government and state education institutions), you have to give props to tech towns built around universities like Austin. You still go to specific universities if you want to research specific areas of science. I'm sure the diversity arguments still play here too. I thought Austin was a pretty big miss.