Microservices Expo Authors: Dalibor Siroky, Elizabeth White, Pat Romanski, John Katrick, Liz McMillan

Related Topics: Microservices Expo, Containers Expo Blog, @CloudExpo

Microservices Expo: Blog Feed Post

Fire and Ice, Silk and Chrome, SPDY and HTTP

The impact of SPDY on infrastructure architecture

The impact of SPDY on infrastructure architecture

The Internets were abuzz with the revelation that the custom browser Silk, distributed on Amazon’s latest endeavor Fire, leverages competitor Google’s own technological innovation, SPDY, against it.

quote-badgeSPDY, short for "speedy" was developed by Google as a way of augmenting the regular HTTP protocol. It uses compression and several methods of optimizing and even predicting requests so resources are sent faster from the server to the browser.

Amazon Silk uses SPDY for its connection to the EC2 cloud. Google also uses it in Chrome for all connections to Google sites. SPDY is an open protocol, so anyone is free to use it and Google is encouraging websites to adopt it.

spdy browserThis isn’t the first time I’ve pondered SPDY; the last time was a dive into how SPDY combined with Map/Reduce might make for a very interesting and scalable web architecture. We could focus on the advantages of owning the “hardware” with SPDY, Fire, Chrome, and the interaction with Google and Amazon’s own cloud services, but I think it more valuable to examine SPDY from the potential impact on infrastructure, architecture, and the broader market. With both web behemoths taking advantage of SPDY, the increasing rate of consumerization of IT and eager adoption of mobile devices by consumers, it’s becoming more obvious that perhaps the fledgling protocol might indeed be something the market should take a much, much closer look at.


There are three main points to SPDY that are (most) relevant to modern and emerging web architectures:

1. Only one, asynchronous connection is allowed between client and server

2. SPDY sits above TCP and encapsulates HTTP

3. Requests can be prioritized

The main premise of SPDY is the use of a single, asynchronous connection (1) between client and server to reduce latency inherent in network transfer times. Clients then fire off a series of requests with or without priority (3) desired over that connection. Those requests are encapsulated into SPDY (2) and sent to a SPDY-capable web server infrastructure where they imageare translated and processed before being returned. This process is, as Google points out, much faster than traditional acceleration techniques involving parallelization of requests because a browser simply cannot open a number of connections to the web server commensurate with the number of objects (requests) it must retrieve. Connection limitations and the synchronous nature of the HTTP protocol impose a performance penalty that is nigh unto impossible to eliminate. Hence, SPDY, which eliminates the penalty by changing the rules of the game. Google has some fairly impressive performance results from using SPDY (no doubt improved further by the proximity of Google services to the Internet backbone, as is also the case with Amazon) that I will not even attempt to refute. As I’ve long verified similar improvements in the use of TCP and HTTP multiplexing on the server-side of this equation, Google’s numbers are no doubt an accurate depiction of the improvements gained using similar techniques on the client side.

Now, the question becomes, “how could a typical enterprise take advantage of this?” After all, we all want faster web sites and user-experiences. But the reliance of SPDY on support in both the client and the server infrastructure seems a potentially insurmountable challenge. While we may be able to take advantage of Silk or Chrome’s native SPDY support, we would still need to ensure the web/application server infrastructure on which web applications are deployed (in the cloud and in the data center) supports it as well. This is because the traditional HTTP transaction is encapsulated inside the SPDY frame: it must be extracted before it can be processed by traditional web/application infrastructure.


The most obvious impact to any infrastructure between a SPDY-enabled client and server is that it drives intermediate processing back to layer 4, to TCP. Because SPDY is its own protocol and encapsulates HTTP inside its frame, infrastructure focused on layer 7 (application, HTTP) would effectively be blinded by SPDY. While traditional layer 4 functionality – network firewall, QoS, load balancing – would remain unaffected by being in the data path, traditional layer 7 functionality – web application firewall, web access management, application switching (a.k.a. “page routing” in Facebook speak), etc… – would be rendered ineffectual. This, much in the same way IPv4 encapsulation in IPv6-enabled architectures, would render infrastructure architectures dependent on such processing inoperable. After all, if web application firewall or access management services rely on a URI to determine which policy should be applied and that URI is no longer available as part of the request, the service cannot function.

Additionally, the use of encryption as an integral component of the protocol would prove problematic for many infrastructure intermediaries unable to decrypt the data and perform inspect of the contents.  “TLS encrypts the contents of all transmission (except the handshake itself), making it difficult for attackers to control the data which could be used in a cross-protocol attack.” – SPDY Protocol

That said, any intermediary capable of decrypting and subsequently extracting the HTTP data – such as via network-side scripting capable infrastructure - would be capable of serving in the same capacity as it has in the past, albeit while incurring some amount of latency while doing so.


There are several operationally-related issues that SPDY introduces as well as those it does not address. For example, SPDY does not address capacity constraints nor does it intelligently apply compression. Furthermore it assumes security will be applied at the server. Architectural best practices concerning both performance and capacity dictate SSL/TLS be offloaded upstream and that TCP multiplexing between intermediate load balancing servers and servers be used to improve utilization of server resources.

The behavior of SPDY assumes a persistent connection between the client and the server. Again, best practices for architecting highly available applications include the use of load balancing services to provide a mechanism for failover as well as scalability, introducing potential issues with persistence. While rudimentary, albeit effective, layer 4 load balancing services would alleviate this potential pitfall (layer 4 load balancing maps clients and servers at the TCP layer upon initial connection and thereafter act as little more than a layer 3 forwarding  mechanism, a.k.a. a switch) but introduce others, such as effective server capacity management necessary to dynamically scale in and out, i.e. elasticity.

Other questions remain, as well, around basic security of SPDY-enabled infrastructure. The premise of the protocol is a rapid-firing of requests with client-specified priority at a web site or application. Differentiating between legitimate clients and potential attackers may be an interesting exercise and one that is not directly addressed by SPDY with the exception of a mention regarding the ability to throttle clients.


The conclusion at this point may be that traditional architecture and infrastructure is inherently incompatible with SPDY. This is far from an accurate conclusion. For application delivery components, at least, the introduction of SPDY should not be viewed as problematic nor a show-stopper. In fact, it could be viewed as the opposite. An advanced application delivery controller serves as a SPDY-enabling technology.

An advanced application delivery controller with network-side scripting ability could easily act as a translator for SPDY enabled clients interacting with non-SPDY enabled sites and applications. Through the use of network-side scripting, the HTTP data could be extracted, inserted into a traditional HTTP exchange with servers, and the responses re-injected into a SPDY-compliant data exchange with the client. Such an architecture could easily serve as a migratory step toward a fully SPDY-enabled web and application architecture, or as a means to support (the currently limited set of) SPDY-enabled browsers. Even in a SPDY-enabled architecture, an advanced application delivery controller remains a key component for security, access and capacity management. If able to extract and interpret SPDY, the intermediary retains its ability to perform processing on the data without sacrificing the inherent performance gains achieved by the nascent protocol. This allows existing web and application architectures to remain in place but supports the use of the protocol as a means of accelerating the end-user experience.

This approach is likely preferred by the infrastructure market itself as it remains to be seen whether SPDY will become more widely used in mobile devices (and other browsers) and the investment to natively support what is a new protocol in what is a rather large and varied market would need to be justified by widespread demand. If intermediaries are able to "speak" SPDY natively, they could act in much the same way IPv6 Gateways today serve as an transitional step between IPv4 and IPv6. In this respect, a component based on a full-proxy architecture is perfectly suited to inserting itself (and thus its other capabilities such as security and access control) into a SPDY conversation to ensure both sides of the equation are equally efficient and performant.

Because of the limited deployment and support for SPDY, this is likely to remain a non-issue for most organizations for quite some time. However, with growing use on mobile devices like Silk and other Android-based devices and the push to integrate Amazon and Google cloud services with enterprise architectures, it may be time to put SPDY on the list of technologies to keep a closer eye on.

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

@MicroservicesExpo Stories
How is DevOps going within your organization? If you need some help measuring just how well it is going, we have prepared a list of some key DevOps metrics to track. These metrics can help you understand how your team is doing over time. The word DevOps means different things to different people. Some say it a culture and every vendor in the industry claims that their tools help with DevOps. Depending on how you define DevOps, some of these metrics may matter more or less to you and your team.
For many of us laboring in the fields of digital transformation, 2017 was a year of high-intensity work and high-reward achievement. So we’re looking forward to a little breather over the end-of-year holiday season. But we’re going to have to get right back on the Continuous Delivery bullet train in 2018. Markets move too fast and customer expectations elevate too precipitously for businesses to rest on their laurels. Here’s a DevOps “to-do list” for 2018 that should be priorities for anyone w...
If testing environments are constantly unavailable and affected by outages, release timelines will be affected. You can use three metrics to measure stability events for specific environments and plan around events that will affect your critical path to release.
In a recent post, titled “10 Surprising Facts About Cloud Computing and What It Really Is”, Zac Johnson highlighted some interesting facts about cloud computing in the SMB marketplace: Cloud Computing is up to 40 times more cost-effective for an SMB, compared to running its own IT system. 94% of SMBs have experienced security benefits in the cloud that they didn’t have with their on-premises service
DevOps failure is a touchy subject with some, because DevOps is typically perceived as a way to avoid failure. As a result, when you fail in a DevOps practice, the situation can seem almost hopeless. However, just as a fail-fast business approach, or the “fail and adjust sooner” methodology of Agile often proves, DevOps failures are actually a step in the right direction. They’re the first step toward learning from failures and turning your DevOps practice into one that will lead you toward even...
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily own their code into production, but want to use platforms instead of raw automation. That’s changing the landscape that we understand as DevOps with both architecture concepts (CloudNative) and process redefinition (SRE). Rob Hirschfeld’s recent work in Kubernetes operations has led to the conclusion that containers and related platforms have changed the way we should be thinking about DevOps and...
The goal of Microservices is to improve software delivery speed and increase system safety as scale increases. Microservices being modular these are faster to change and enables an evolutionary architecture where systems can change, as the business needs change. Microservices can scale elastically and by being service oriented can enable APIs natively. Microservices also reduce implementation and release cycle time and enables continuous delivery. This paper provides a logical overview of the Mi...
While walking around the office I happened upon a relatively new employee dragging emails from his inbox into folders. I asked why and was told, “I’m just answering emails and getting stuff off my desk.” An empty inbox may be emotionally satisfying to look at, but in practice, you should never do it. Here’s why. I recently wrote a piece arguing that from a mathematical perspective, Messy Desks Are Perfectly Optimized. While it validated the genius of my friends with messy desks, it also gener...
The next XaaS is CICDaaS. Why? Because CICD saves developers a huge amount of time. CD is an especially great option for projects that require multiple and frequent contributions to be integrated. But… securing CICD best practices is an emerging, essential, yet little understood practice for DevOps teams and their Cloud Service Providers. The only way to get CICD to work in a highly secure environment takes collaboration, patience and persistence. Building CICD in the cloud requires rigorous ar...
The enterprise data storage marketplace is poised to become a battlefield. No longer the quiet backwater of cloud computing services, the focus of this global transition is now going from compute to storage. An overview of recent storage market history is needed to understand why this transition is important. Before 2007 and the birth of the cloud computing market we are witnessing today, the on-premise model hosted in large local data centers dominated enterprise storage. Key marketplace play...
The cloud revolution in enterprises has very clearly crossed the phase of proof-of-concepts into a truly mainstream adoption. One of most popular enterprise-wide initiatives currently going on are “cloud migration” programs of some kind or another. Finding business value for these programs is not hard to fathom – they include hyperelasticity in infrastructure consumption, subscription based models, and agility derived from rapid speed of deployment of applications. These factors will continue to...
Some people are directors, managers, and administrators. Others are disrupters. Eddie Webb (@edwardawebb) is an IT Disrupter for Software Development Platforms at Liberty Mutual and was a presenter at the 2016 All Day DevOps conference. His talk, Organically DevOps: Building Quality and Security into the Software Supply Chain at Liberty Mutual, looked at Liberty Mutual's transformation to Continuous Integration, Continuous Delivery, and DevOps. For a large, heavily regulated industry, this task ...
Following a tradition dating back to 2002 at ZapThink and continuing at Intellyx since 2014, it’s time for Intellyx’s annual predictions for the coming year. If you’re a long-time fan, you know we have a twist to the typical annual prediction post: we actually critique our predictions from the previous year. To make things even more interesting, Charlie and I switch off, judging the other’s predictions. And now that he’s been with Intellyx for more than a year, this Cortex represents my first ...
"Grape Up leverages Cloud Native technologies and helps companies build software using microservices, and work the DevOps agile way. We've been doing digital innovation for the last 12 years," explained Daniel Heckman, of Grape Up in this SYS-CON.tv interview at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.
The Toyota Production System, a world-renowned production system is based on the "complete elimination of all waste". The "Toyota Way", grounded on continuous improvement dates to the 1860s. The methodology is widely proven to be successful yet there are still industries within and tangential to manufacturing struggling to adopt its core principles: Jidoka: a process should stop when an issue is identified prevents releasing defective products
Defining the term ‘monitoring’ is a difficult task considering the performance space has evolved significantly over the years. Lately, there has been a shift in the monitoring world, sparking a healthy debate regarding the definition and purpose of monitoring, through which a new term has emerged: observability. Some of that debate can be found in blogs by Charity Majors and Cindy Sridharan.
We seem to run this cycle with every new technology that comes along. A good idea with practical applications is born, then both marketers and over-excited users start to declare it is the solution for all or our problems. Compliments of Gartner, we know it generally as “The Hype Cycle”, but each iteration is a little different. 2018’s flavor will be serverless computing, and by 2018, I mean starting now, but going most of next year, you’ll be sick of it. We are already seeing people write such...
It’s “time to move on from DevOps and continuous delivery.” This was the provocative title of a recent article in ZDNet, in which Kelsey Hightower, staff developer advocate at Google Cloud Platform, suggested that “software shops should have put these concepts into action years ago.” Reading articles like this or listening to talks at most DevOps conferences might make you think that we’re entering a post-DevOps world. But vast numbers of organizations still struggle to start and drive transfo...
Let's do a visualization exercise. Imagine it's December 31, 2018, and you're ringing in the New Year with your friends and family. You think back on everything that you accomplished in the last year: your company's revenue is through the roof thanks to the success of your product, and you were promoted to Lead Developer. 2019 is poised to be an even bigger year for your company because you have the tools and insight to scale as quickly as demand requires. You're a happy human, and it's not just...
"Opsani helps the enterprise adopt containers, help them move their infrastructure into this modern world of DevOps, accelerate the delivery of new features into production, and really get them going on the container path," explained Ross Schibler, CEO of Opsani, and Peter Nickolov, CTO of Opsani, in this SYS-CON.tv interview at DevOps Summit at 21st Cloud Expo, held Oct 31 – Nov 2, 2017, at the Santa Clara Convention Center in Santa Clara, CA.