Microservices and HTTP/2
It's all about that architecture. There's a lot of things we do to improve the performance of web and mobile applications. We use caching. We use compression. We offload security (SSL and TLS) to a proxy with greater compute capacity. We apply image optimization and minification to content. We do all that because performance is king. Failure to perform can be, for many businesses, equivalent to an outage with increased abandonment rates and angry customers taking to the Internet to express their extreme displeasure. The recently official HTTP/2 specification takes performance very seriously, and introduced a variety of key components designed specifically to address the need for speed. One of these was to base the newest version of the Internet's lingua franca on SPDY. One of the impacts of this decision is that connections between the client (whether tethered or mobile) and the app (whether in the cloud or on big-iron) are limited to just one. One TCP connection per app. That's a huge divergence from HTTP/1 where it was typical to open 2, 4 or 6 TCP connections per site in order to take advantage of broadband. And it worked for the most part because, well, broadband. So it wouldn't be a surprise if someone interprets that ONE connection per app limitation to be a negative in terms of app performance. There are, of course, a number of changes in the way HTTP/2 communicates over that single connection that ultimately should counteract any potential negative impact on performance from the reduction in TCP connections. The elimination of the overhead of multiple DNS lookups (not insignificant, by the way) as well as TCP-related impacts from slow start and session setup as well as a more forgiving exchange of frames under the covers is certainly a boon in terms of application performance. The ability to just push multiple responses to the client without having to play the HTTP acknowledgement game is significant in that it eliminates one of the biggest performance inhibitors of the web: latency arising from too many round trips. We've (as in the corporate We) seen gains of 2-3 times the performance of HTTP/1 with HTTP/2 during testing. And we aren't alone; there's plenty of performance testing going on out there, on the Internets, that are showing similar improvements. Which is why it's important (very important) that we not undo all the gains of HTTP/2 with an architecture that mimics the behavior (and performance) of HTTP/1. Domain Sharding and Microservices Before we jump into microservices, we should review domain sharding because the concept is important when we look at how microservices are actually consumed and delivered from an HTTP point of view. Scalability patterns (i.e. architectures) include the notion of Y-axis scale which is a sharding-based pattern. That is, it creates individual scalability domains (or clusters, if you prefer) based on some identifiable characteristic in the request. User identification (often extricated from an HTTP cookie) and URL are commonly used information upon which to shard requests and distribute them to achieve greater scalability. An incarnation of the Y-axis scaling pattern is domain sharding. Domain sharding, for the uninitiated, is the practice of distributing content to a variety of different host names within a domain. This technique was (and probably still is) very common to overcome connection limitations imposed by HTTP/1 and its supporting browsers. You can see evidence of domain sharding when a web site uses images.example.com and scripts.example.com and static.example.com to optimize page or application load time. Connection limitations were by host (origin server), not domain, so this technique was invaluable in achieving greater parallelization of data transfers that made it appear, at least, that pages were loading more quickly. Which made everyone happy. Until mobile came along. Then we suddenly began to realize the detrimental impact of introducing all that extra latency (every connection requires a DNS lookup, a TCP handshake, and suffers the performance impacts of TCP slow start) on a device with much more limited processing (and network) capability. I'm not going to detail the impact; if you want to read about it in more detail I recommend reading some material from Steve Souder and Tom Daly or Mobify on the subject. Suffice to say, domain sharding has an impact on mobile performance, and it is rarely a positive one. You might think, well, HTTP/2 is coming and all that's behind us now. Except it isn't. Microservice architectures in theory, if not in practice, are ultimately a sharding-based application architecture that, if we're not careful, can translate into a domain sharding-based network architecture that ultimately negates any of the performance gains realized by adopting HTTP/2. That means the architectural approach you (that's you, ops) adopt to delivering microservices can have a profound impact on the performance of applications composed from those services. The danger is not that each service will be its on (isolated and localized) "domain", because that's the whole point of microservices in the first place. The danger is that those isolated domains will be presented to the outside world as individual, isolated domains, each requiring their own personal, private connection by clients. Even if we assume there are load balancing services in front of each service (a good assumption at this point) that still means direct connections between the client and each of the services used by the client application because the load balancing service acts as a virtual service, but does not eliminate the isolation. Each one is still its own "domain" in the sense that it requires a separate, dedicated TCP connection. This is essentially the same thing as domain sharding as each host requires its own IP address to which the client can connect, and its behavior is counterproductive to HTTP/2*. What we need to do to continue the benefits of a single, optimized TCP connection while being able to shard the back end is to architect a different solution in the "big black box" that is the network. To be precise, we need to take advantage of the advanced capabilities of a proxy-based load balancing service rather than a simple load balancer. An HTTP/2 Enabling Network Architecture for Microservices That means we need to enable a single connection between the client and the server and then utilize capabilities like Y-axis sharding (content switching, L7 load balancing, etc...) in "the network" to maintain the performance benefits of HTTP/2 to the client while enabling all the operational and development benefits of a microservices architecture. What we can do is insert a layer 7 load balancer between the client and the local microservice load balancers. The connection on the client side maintains a single connection in the manner specified (and preferred) by HTTP/2 and requires only a single DNS lookup, one TCP session start up, and incurs the penalties from TCP slow start only once. On the service side, the layer 7 load balancer also maintains persistent connections to the local, domain load balancing services which also reduces the impact of session management on performance. Each of the local, domain load balancing services can be optimized to best distribute requests for each service. Each maintains its own algorithm and monitoring configurations which are unique to the service to ensure optimal performance. This architecture is only minimally different from the default, but the insertion of a layer 7 load balancer capable of routing application requests based on a variety of HTTP variables (such as the cookies used for persistence or to extract user IDs or the unique verb or noun associated with a service from the URL of a RESTful API call) results in a network architecture that closely maintains the intention of HTTP/2 without requiring significant changes to a microservice based application architecture. Essentially, we're combining X- and Y-axis scalability patterns to architect a collaborative operational architecture capable of scaling and supporting microservices without compromising on the technical aspects of HTTP/2 that were introduced to improve performance, particularly for mobile applications. Technically speaking we're still doing sharding, but we're doing it inside the network and without breaking the one TCP connection per app specified by HTTP/2. Which means you get the best of both worlds - performance and efficiency. Why DevOps Matters The impact of new architectures - like microservices - on the network and the resources (infrastructure) that deliver those services is not always evident to developers or even ops. That's one of the reasons DevOps as a cultural force within IT is critical; because it engenders a breaking down of the isolated silos between ops groups that exist (all four of them) and enables greater collaboration that leads to more efficient deployment, yes, but also more efficient implementations. Implementations that don't necessarily cause performance problems that require disruptive modification to applications or services. Collaboration in the design and architectural phases will go along way towards improving not only the efficacy of the deployment pipeline but the performance and efficiency of applications across the entire operational spectrum. * It's not good for HTTP/1, either, as in this scenario there is essentially no difference** between HTTP/1 and HTTP/2. ** In terms of network impact. HTTP/2 still receives benefits from its native header compression and other performance benefits.F5 Friday: Should you stay with HTTP/1 or move to HTTP/2 ?
Application experience aficionados take note: you have choices now. No longer are you constrained to just HTTP/1 with a side option of WebSockets or SPDY. HTTP/2 is also an option, one that like its SPDY predecessor brings with it several enticing benefits but is not without obstacles. In fact, it is those obstacles that may hold back adoption according to IDG research, "Making the Journey to HTTP/2". In the research, respondents indicated several potential barriers to adoption including backward compatibility with HTTP/1 and the "low availability" of HTTP/2 services. In what's sure to noticed as a circular dependency, the "low availability" is likely due to the "lack of backward compatibility" barrier. Conversely, the lack of backward compatibility with HTTP/1 is likely to prevent the deployment of HTTP/2 services and cause low availability of HTTP/2 services. Which in turn, well, you get the picture. This is not a phantom barrier. The web was built on HTTP/1 and incompatibility is harder to justify today than it was when we routinely browsed the web and were shut out of cool apps because we were using the "wrong" browser. The level of integration between apps and reliance on many other APIs for functionality pose a difficult problem for would-be adopters of HTTP/2 looking for the improved performance and efficacy of resource utilization it brings. But it doesn't have to. You can have your cake and eat it too, as the saying goes. HTTP Gateways What you want is some thing that sits in between all those users and your apps and speaks their language (protocol) whether it's version 1 or version 2. You want an intermediary that's smart enough to translate SPDY or HTTP/2 to HTTP/1 so you don't have to change your applications to gain the performance and security benefits without investing hundreds of hours in upgrading web infrastructure. What you want is an HTTP Gateway. At this point in the post, you will be unsurprised to learn that F5 provides just such a thing. Try to act surprised, though, it'll make my day. One of the benefits of growing up from a load balancing to an application delivery platform is that you have to be fluent in the languages (protocols) of applications. One of those languages is HTTP, and so it's no surprise that at the heart of F5 services is the ability to support all the various flavors of HTTP available today: HTTP/1, SPDY, HTTP/2 and HTTP/S (whether over TLS or SSL). But more than just speaking the right language is the ability to proxy for the application with the user. Which means that F5 services (like SDAS) sit in between users and apps and can translate across flavors of HTTP. Is your mobile app speaking HTTP/2 or SPDY but your app infrastructure only knows HTTP/1? No problem. F5 can make that connection happen. That's because we're a full proxy, with absolute control over a dual-communication stack that lets us do one thing on the client side while doing another on the server side. We can secure the outside and speak plain-text on the inside. We can transition security protocols, web protocols, and network protocols (think IPv4 - IPv6). That means you can get those performance and resource-utilization benefits without ripping and replacing your entire web application infrastructure. You don't have to reject users because they're not using the right browser protocol and you don't have to worry about losing visibility because of an SSL/TLS requirement. You can learn more about F5's HTTP/2 and SDPY Gateway capabilities by checking out these blogs: What are you waiting for? F5 Synthesis: Your gateway to the future (of HTTP) Velocity 2014 HTTP 2.0 Gateway (feat Parzych) F5 Synthesis Reference Architecture: AccelerationWhat Ops Needs to Know about HTTP/2
So HTTP/2 is official. That means all the talking is (finally) done and after 16 years of waiting, we've got ourselves a new lingua franca of the web. Okay, maybe that's pushing it, but we do have a new standard to move to that offers some improvements in the areas of resource management and performance that make it definitely worth taking a look at. For example, HTTP/2 is largely based on SPDY (that's Google's SPDY, for those who might have been heads down in the data center since 2009 and missed its introduction) which has proven, in the field, to offer some nice performance benefits. Since its introduction in 2009, SPDY has moved through several versions, resulting in the current (and according to Google, last) version of 3.1, has shown real improvements in page load times mostly due to a combination of reduction in round trip times (RTT) and use of header compression. An IDG research paper, "Making the Journey to HTTP/2", notes that "According to Google, SPDY has cut load times for several of its most highly used services by up to 43 percent. Given how heavily based it is on SPDY, HTTP/2 should deliver similarly significant performance gains, resulting in faster transactions and easier access to mobile users, not to mention reduced need for bandwidth, servers, and network infrastructure. " But HTTP/2 is more than SPDY with a new name. There are a number of significant differences that, while not necessarily affecting applications themselves, definitely impact the folks who have to configure and manage the web and application servers on which those apps are deployed. That means you, ops guy. One of the biggest changes in HTTP/2 is that it is now binary on the wire instead of text. That's good news for transport times, but bad news because it's primarily the reason that HTTP/2 is incompatible with HTTP/1.1. While browsers will no doubt navigate protocols (separately, of course), thus alleviating any concern that end-users will be able to access your apps if you move to the new standard, it's problematic for inter-app integration; i.e. all those external services you might use to build your app or site. The assumed HTTP/1.1 will not communicate with an HTTP/2 endpoint, and vice versa. Additionally, HTTP/2 introduces a dedicated header compression protocol, HPACK. While SPDY also supported header compression as a way to eliminate the overhead associated with redundant headers across lots (an average of 80) requests per page, it fell back on standard DEFLATE (RFC 1951) compression, which is vulnerable to CRIME (yes, I'm aware of the hilarious irony in that acronym but it is what it is, right?). Operational ramification: New header compression techniques will mean caches and upstream infrastructure which may act upon those headers will need to be able to speak HPACK. If you haven't been using SPDY, you may also not be aware of the changes to request management. HTTP 1.1 allowed for multiple requests over the same (single) connection but even that was found to be inadequate as page complexity (in terms of objects needing to be retrieved) increased. Browsers therefore would open 2, 3 or 6 connections per domain in order to speed up page loads. This heavily impacted the capacity of a web/app server. If a web server could manage 5000 concurrent (TCP) connections, you had to divide that by the average number of connections opened per user to figure out the concurrent user capacity. SPDY - and HTTP/2 - are based on the use of a single connection, introducing parallel request and response flows in order to address performance in the face of extreme complexity. So that means a 1:1 ratio between users and (TCP) connections. But that doesn't necessarily mean capacity planning is simpler, as those connections are likely to be longer lived than many HTTP/1.1 connections. Idle time out values in web servers may need to be adjusted and capacity planning will need to take that into consideration. Operational ramification: Idle time out values and maximum connections may need to be adjusted based on new TCP behavior. Some of the other changes that may have an impact are related to security. In particular, there has been a lot of confusion over the requirement (or non requirement) for security in HTTP/2. It turns out that the working group did not have consensus to require TLS or SSL in HTTP/2 and thus it remains optional. The market, however, seems to have other ideas as browsers currently supporting HTTP/2 do require TLS or SSL and indications are this is not likely to change. SSL Everywhere is the goal, after all, and browsers play a significant (and very authoritative) role in that effort. With that said, TLS optional in the HTTP/2 specification. But of course since most folks are supportive of SSL Everywhere, it is important to note that when securing connections HTTP/2 requires stronger cryptography. Ephemeral keys only Preferring AEAD modes like CGM Minimal key sizes 128 bit EC, 2048 bit RSA This falls squarely in the lap of ops, as this level of support is generally configured and managed at the platform (web server) layer, not within the application. Because browsers are enforcing the use of secure connections, the implications for ops start reaching beyond the web server and into the upstream infrastructure. Operational ramification: Upstream infrastructure (caches, load balancers, NGFW, access management) will be blinded by encryption and unable to perform their functions. Interestingly, HTTP/2 is already out there. The BitsUp blog noted the day the HTTP/2 official announcement was made that "9% of all Firefox release channel HTTP transactions are already happening over HTTP/2. There are actually more HTTP/2 connections made than SPDY ones." So this isn't just a might be, could be in the future. It's real. Finally. For a deeper dive into the history of HTTP and how the protocol has evolved over time, feel free to peruse this HTTP/2 presentation.HTTP 2.0 changes everything
#HTTP #ietf #webperf #infosec Despite the hype and drama surrounding the HTTP 2.0 effort, the latest version of the ubiquitous HTTP protocol is not just a marketing term. It's a real, live IETF standard that is scheduled to "go live" in November (2014). And it changes everything. There are a lot of performance enhancing related changes in the HTTP 2.0 specification including multiplexing and header compression. These are not to be overlooked as minimal updates as they significantly improve performance, particularly for clients connecting over a mobile network. Header compression, for example, minimizes the requirement to transport HTTP headers with each and every request - and response. HTTP headers can become quite the overhead, particularly for those requests comprised simply of a URL or a few bytes of data. Multiplexing has traditionally been a server-side technology, designated as an offload capability that optimizes both server resources and, in turn, performance. Enabling multiplexing on the client side, a la SPDY (which is the actually the basis for HTTP 2.0 and is supported by 65% of browsers today) and MPTCP protocols, enables the same benefits in terms of reducing resource consumption. It has the added benefit of improving performance by eliminating overhead associated with not just opening a new connection, but maintaining the state of each of them. These are not what changes everything, however. While these are needed improvements and will certainly benefit clients and applications that can take advantage of them (either natively or by employing an HTTP gateway) the real game changer with HTTP 2.0 is the mandatory use of SSL. Yes, that's right. SSL is mandatory. What does that mean? For everyone on the data center side of this equation - whether that data center is a cloud or a traditional one - mandating SSL or TLS for HTTP will effectively blind most of the application data path. This has always been true; enabling end-to-end SSL for web applications (which Our (that's F5) data shows is 64% of all applications being delivered) has always meant restricting visibility into web traffic. After all, the purpose of transport layer security protocols like SSL and TLS is to protect data in flight from prying eyes. Those eyes include benevolent services like performance monitoring, IDS, IPS, DLP, web acceleration and any other service which relies on the ability to inspect data in flight. This requirement for SSL or TLS means there's going to have to be some changes in the network architecture if you're going to move to HTTP 2.0 to take advantage of its performance benefits. Somehow you're going to have to figure out how to support a MUST use TLS/SSL requirement while still enabling monitoring, acceleration and security services - hopefully without requiring that every service in the application service conga line decrypt and re-encrypt the data. While marketing made much of the "SSL Everywhere" movement and many organizations did, in fact, move to complying with the notion that every web interaction should be secured with SSL or TLS, not everyone was as dedicated to enforcing it on consumers and employees. Non-secured HTTP was still often allowed, despite the risks associated with it. HTTP 2.0 will mean giving more than just lip service to security by requiring that organizations adopting the new protocol utterly and completely embrace it.Optimizing IoT and Mobile Communications with TCP Fast Open
There's a lot of focus on the performance of mobile communications given the incredible rate at which mobile is outpacing legacy PC (did you ever think we'd see the day when we called it that?) usage. There's been tons of research on the topic ranging from the business impact (you really can lose millions of dollars per second of delay) to the technical mechanics of how mobile communications is impacted by traditional factors like bandwidth and RTT. Spoiler: RTT is more of a factor than is bandwidth in improving mobile app performance. The reason behind this isn't just because mobile devices are inherently more resource constrained or that mobile networks are oversubscribed or that mobile communications protocols simply aren't as fast as your mega super desktop connection, it's also because mobile apps (native ones) tend toward the use of APIs and short bursts of communication. Grab this, check for an update on that, do this quick interaction and return. These are all relatively small in terms of data transmitted, which means that the overhead from establishing a connection can actually take more time than the actual exchange. The RTT incurred by the three-step handshake slows things down. That same conundrum will be experienced by smart "things" that connect for a quick check-in to grab or submit small chunks of data. The connection will take longer than the data transmission, which seems, well, inefficient, doesn't it? Apparently other folks thought so too, and hence we have in Internet Draft form a proposed TCP mechanism to alleviate the impact of this overhead known as "TCP Fast Open". TCP Fast Open Draft @ IETF This document describes an experimental TCP mechanism TCP Fast Open (TFO). TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake, and saves up to one full round trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged. However TFO deviates from the standard TCP semantics since the data in the SYN could be replayed to an application in some rare circumstances. Applications should not use TFO unless they can tolerate this issue detailed in the Applicability section. The standard relies on the existence of a cookie deposited with the client that indicates a readiness and willingness (and perhaps even a demand) to transmit some of the data in the initial SYN and SYN-ACK packets of the TCP handshake. The cookie is generated by the app (or gateway, the endpoint) upon request from the client. There's no special TCP behavior on this request, so it seems likely this would be handled during the "initial setup" of a thing. On subsequent communications in which the TFO cookie is present, the magic happens. The app (or gateway, the endpoint) recognizes the cookie and is able to grab the data and start processing - before the initial handshake is even complete. While the use of 'cookies' is more often associated with HTTP, it is also found within the realm of TCP (SYN cookies are a popular means of attempting to detect and prevent SYN flood attacks). Needless to say, such a mechanism is particularly of interest to service providers as their networks often act as gateways to the Internet for mobile devices. Reducing the time required for short-burst communications ultimately reduces the connections that must be maintained in the mobile network, thus relieving some pressure on the number of proxies - virtual or not - required to support the growing number of devices and things needing access. A word of caution, however. TFO is not designed for nor meant to be used for every application. The draft clearly spells out applicability as being to those applications where initial requests from the client are of a size that they are less than the TCP MSS. This is because otherwise the server still has to wait until after the handshake completes to gather the rest of the data and formulate a response. Thus any performance benefit would be lost. Proceed with careful consideration, therefore, in applying the use of TCP Fast Open but do consider it, particularly if data sets are small, as may be the case with things reporting in or checking for updates.The Evolution of TCP
#sdas #webperf Like everything about the Internet, TCP keeps on changing. In 1974 a specification was developed that would, eventually, launch what we know of as "The Internet." That specification was TCP and though it is often overshadowed by HTTP as the spark that lit the fire under the Internet, without TCP HTTP wouldn't have a (transport) leg to stand on. Still, it would take 10 years before the Internet (all 1000 hosts of it) converted en masse to using TCP/IP for its messaging. Once that adoption had occurred, it was a much shorter leap for the development of HTTP to occur and then, well, your refrigerator or toaster can probably tell you the rest at this point. That makes TCP 40 years old this year. And despite the old adage you can't teach an old dog new tricks, TCP has continued to evolve right along with the needs of the applications that rely so heavily on its reliable transport mechanism. Consider the additions, modifications, enhancements and changes that have been made just in the past 20 years or so. In total, there are well over 100 different RFCs associated with TCP that offer ways to improve performance, or reliability or support new technology like mobile networks and devices. Like SSL and even HTTP, TCP must continue to evolve. Unlike the Internet in 1984 which boasted a mere 1000 hosts, the ISC domain survey puts the number of hosts in Jan 2013 at well over 1 billion. That means to move to some other transport protocol we'd have to coordinate, well, more than seems humanly possible. Especially given that doesn't count the switch required on the client side - which numbers in the 2.4 billion range according to Internet World Stats, which tracks growth of Internet users world wide. What this means, practically, is that TCP must evolve because we can't just move to something else. Not without a long term transition plan and we see how well that's working for the move to IPv6, despite the depletion of IPv4 addresses. So it shouldn't be a surprise when new, TCP-related technologies like MPTCP (Multipath TCP) are introduced to address challenges that continue to crop up as new devices, networks and applications pop up like dandelions in your front yard. Nor should we be surprised when support for such protocols, like SPDY before it, are offered to the market with a transitional approach, i.e. gateways and dual-stack supporting proxies. The only real way to support the use of what would otherwise be a disruptive technology without disrupting the billions of hosts and users that communicate each and every day is to provide strategic transitional protocol points of control that enable transparent and (one hopes) seamless support as hosts and devices begin to support it. TCP isn't going anywhere, it's too critical to the entire Internet at this point. But that doesn't mean it's static or inflexible. It is constantly evolving to meet the needs of the next generation of devices, networks and applications that rely upon it.Caching for Faster APIs
Pop quiz: Do you know what the number one driver cited in 2016 for networking investments was? No peeking! If you guessed speed and performance, you guessed right. If you guessed security don’t feel bad, it came in at number two, just ahead of availability. Still, it’s telling that the same things that have always driven network upgrades, improvements, and architectures continue to do so. We want fast, secure, and reliable networks that deliver fast, secure, and reliable applications. Go figure. The problem is that a blazing fast, secure, and reliable network does not automatically translate into a fast, secure, and reliable application. But it can provide a much needed boost. And I’m here to tell you how (and it won’t even cost you shipping and handling fees). The thing is that there have long been web app server (from which apps and APIs are generally delivered) options for both caching and compression. The other thing is that they’re often not enabled. Caching headers are part of the HTTP specification. They’re built in, but that means they’re packaged up with each request and response. So if a developer doesn’t add them, they aren’t there. Except when you’ve got an upstream, programmable proxy with which you can insert them. Cause when we say software-defined, we really mean software-defined. As in “Automation is cool and stuff, but interacting with requests/responses in real-time is even cooler.” So, to get on with it, there are several mechanisms for managing caching within HTTP, two of which are: ETag and Last-Modified. ETag The HTTP header “ETag” contains a hash or checksum that can be used to compare whether or not content has changed. It’s like the MD5 signature on compressed files or RPMs.While MD5 signatures are usually associated with security, they can also be used to determine whether or not content has changed. In the case of browser caching, the browser can make a request that says “hey, only give me new content if it’s changed”. The server-side uses the ETag to determine if it has and if not, sends back an empty HTTP 304 response. The browser says “Cool” and pulls the content from its own local cache. This saves on transfer times (by reducing bandwidth and round trips if the content is large) and thus improves performance. Last-Modified. This is really the same thing as an ETag but with timestamps, instead. Browsers ask to be served new content if it has been modified since a specific date. This, too, saves on bandwidth and transfer times, and can improve performance. Now, these mechanisms were put into place primarily to help with web-based content. Caching images and other infrequently changing presentation components (think style-sheets, a la CSS) can have a significant impact on performance and scalability of an application. But we’re talking about APIs, and as we recall, APIs are not web pages. So how does HTTP’s caching options help with APIs? Well, very much the same way, especially given that most APIs today are RESTful, which means they use HTTP. If I’ve got an app (and I’ve got lots of them) that depends on an API there are still going to be a lot of content types that are similar, like images. Those images can (and should) certainly be cached when possible, especially if the app is a mobile one. Data, too, for frequently retrieved content can be cached, even if it is just a big blob of JSON. Consider the situation in which I have an app and every day the “new arrivals” are highlighted. But they’re only updated once a day, or on a well-known schedule. The first time I open the menu item to see the “new arrivals”, the app should certainly go get the new content, because it’s new. But after that, there’s virtually no reason for the app to go requesting that data. I already paid the performance price to get it, and it hasn’t changed – neither the JSON objects representing the individual items nor the thumbnails depicting them. Using HTTP caching headers and semantics, I can ask “have you changed this yet?” and the server can quickly respond “Not yet.” That saves subsequent trips back and forth to download data while I click on fourteen different pairs of shoes* off the “new arrivals” list and then come back to browse for more. If the API developer hasn’t added the appropriate HTTP cues in the headers, however, you’re stuck grabbing and regrabbing the same content and wasting bandwidth as well as valuable client and server-side resources. An upstream programmable proxy can be used to insert them, however, and provide both a performance boost (for the client) and greater scalability (for the server). Basically, you can insert anything you want into the request/response using a programmable proxy, but we’ll focus on just HTTP headers right now. The basic pattern is: 1: when HTTP_REQUEST { 2: HTTP::header insert "ETag" "my-computed-value" 3: } Really, that’s all there is to it. Now, you probably want some logic in there to not override an existing header because if the developer put it in, there’s a good reason. This is where I mini-lecture you on the cultural side of DevOps and remind you that communication is as critical as code when it comes to improving the deployment and delivery of applications. And there’s certainly going to be some other stuffs that go along with it, but the general premise is that the insertion of caching-related HTTP headers is pretty simple to achieve. For example, we could insert a Last-Modified header for any JPG image: 1: when HTTP_RESPONSE { 2: if { [HTTP::header "Content-Type" ] equals "Image/jpeg" } { 3: HTTP::header insert "Last-Modified" "timestamp value" 4: } 5: } 6: } We could do the same for CSS, or JS, as well. And we could get more complex and make decisions based on a hundred other variables and conditions. Cause, software-defined delivery kinda means you can do whatever you need to do. Another reason a programmable proxy is an excellent option in this case is because it further allows you to extend HTTP unofficial functionality when servers do not. For example, there’s an unofficial “PURGE” method that’s used by Varnish for invalidating cache entries. Because it’s unofficial, it’s not universally supported by the web servers on which APIs are implemented. But a programmable proxy could be used to implement that functionality on behalf of the web server (cause that’s what proxies do) and relieve pressure on web servers to do so themselves. That’s important when external caches like memcached and varnish enter the picture. Because sometimes it’s not just about caching on the client, but in the infrastructure. In any case, HTTP caching mechanisms can improve performance of APIs, particularly when they are returning infrequently changing content like images or static text. Not taking advantage of them is a lost opportunity. * you shop for what you want, I’ll shop for shoes.F5 Friday: I am in UR HTTP Headers Sharing Geolocation Data
#DNS #bigdata #F5 #webperf How'd you like some geolocation data with that HTTP request? Application developers are aware (you are aware, aren't you?) that when applications are scaled using most modern load balancing services that the IP address of the application requests actually belong to the load balancing service. Application developers are further aware that this means they must somehow extract the actual client IP address from somewhere else, like the X-Forwarded-For HTTP header. Now, that's pretty much old news. Like I said, application developers are aware of this already. What's new (and why I'm writing today) is the rising use of geolocation to support localized (and personalized) content. To do this, application developers need access to the geographical location indicated by either GPS coordinates or IP address. In most cases, application developers have to get this information themselves. This generally requires integration with some service that can provide this information despite the fact that infrastructure like BIG-IP and its DNS services, already have it and have paid the price (in terms of response time) to get it. Which means, ultimately, that applications pay the performance tax for geolocation data twice - once on the BIG-IP and once in the application. Why, you are certainly wondering, can't the BIG-IP just forward that information in an HTTP header just like it does the client IP address? Good question. The answer is that technically, there's no reason it can't. Licensing, however, is another story. BIG-IP includes, today, a database of IP addresses that locates clients, geographically, based on client IP address. The F5 EULA, today, allows customers to use this information for a number of purposes, including GSLB load balancing decisions, access control decisions with location-based policies, identification of threats by country, location blocking of application requests, and redirection of traffic based on the client’s geographic location. However, all decisions had to be made on BIG-IP itself and geographic information could not be shared or transmitted to any other device. However, a new agreement allows customers an option to use the geo-location data outside of BIG-IP, subject to fees and certain restrictions. That means BIG-IP can pass on State, Province, or Region geographic data to applications using an easily accessible HTTP header. How does that work? Customers can now obtain a EULA waiver which permits certain off-box use cases. This allows customers to use the geolocation data included with BIG-IP in applications residing on a server or servers in an “off box” fashion. For example, location information may be embedded into an HTTP header or similar and then sent on to the server for it to perform some geo-location specific action. Customers (existing or new) can contact their F5 sales representative to start the process of obtaining the waiver necessary to enable the legal use of this data in an off-box fashion. All that's necessary from a technical perspective is to determine how you want to share the data with the application. For example, you'll (meaning you, BIG-IP owner and you, application developer) will have to agree upon what HTTP header you'll want to use to share the data. Then voila! Developers have access to the data and can leverage it for existing or new applications to provide greater location-awareness and personalization. If your organization has a BIG-IP (and that's a lot of organizations out there), check into this opportunity to reduce the performance tax on your applications that comes from double-dipping into geolocation data. Your users (especially your mobile users) will appreciate it.SSL gets an SEO promotion in rank from Google. Business loses its mind.
#SSL Forget #infosec benefits and #webperf implications, SSL just did an end-run around IT and went straight to the business. With fewer than 1/3 of organizations securing apps with SSL, that could be a problem. If the business isn't panicking, it should be. Google is taking a stand on security, and using the power of placement to get the word out: SSL is important. Given that fewer than one-third of all web apps are secured with SSL despite its benefits, strong-arm business tactics may be just what the security doctor ordered. Google is taking a stance on security and has made SSL a piece of their ranking algorithm. As we are aware search engine ranking remains one of the single most important components of any organization’s branding efforts and online presence. -- HTTPS as a ranking signal, August 6, 2014 in its announcement regarding the inclusion of SSL (or TLS) in its ranking algorithms, Google also noted some best practices to get folks started in their journey to a more secure web presence. Most focus on the strength of the certificate keys you should use (2048 at least) and app development tips that can make the transition between HTTP and HTTPS less disruptive, such as using relative URLs. But even so, what isn't mentioned is the administrative nightmare imposed by turning on SSL (or TLS) on every app server in the data center. It's not just the short term go out and get them (which aren't cheap, by the way) and get them deployed, it's also the impact long term on managing expirations as well as figuring out how all the services in the network between the end-user and the app - like that IDS and IPS, your anti-virus and anti-fraud, your WAF, etc... - are going to perform their tasks blindly. Without a solid strategy moving forward, simply turning on SSL on an application disrupts not only operations but a whole lot of security and business-related services. One of the ways in which this journey can be made much less disruptive is by taking advantage of strategic transition points along an application's data path where SSL can be applied (and thus also managed) centrally. This point logically occurs at the point at which the application is virtualized for purposes of scale and reliability. In other words, at the load balancer or application delivery controller (ADC). By using an ADC or an application proxy as a natural protocol gateway (something that can transition easily between two protocols like HTTP and HTTPS, or vice versa) the disruption of enabling SSL everywhere (which is a Very Good Thing TM by the way) on every app server can be effectively eliminated. The reality is that your load balancer (LB) or ADC or application proxy (AP) is, for all intents and purposes, The Application as far as the end-user is concerned. It is at the LB or ADC or AP that an application is "virtualized" and presented to the outside world. When an end-user connects to www.myapp.com they are almost certainly connecting not to the app, but to a load balancing service or an ADC or an application proxy. This provides a strategic opportunity for organizations to centralize capabilities like enabling SSL or supporting next-generation protocols like SPDY or HTTP 2.0 without incurring the costs and headaches associated with upgrading and updating each and every one of the hundreds (or thousands) of servers that provide the resources for that application. But the argument is no longer going to be focused on the technical merits or even the security benefits. The SSL argument has just gone business, because search engine ranking is a significant component of today's business. With SSL part of that ranking equation, the business is going to see competitive advantage in getting "out there" first with SSL to help boost their search rankings before their competitors. IT can be the hero this time by using a strategic point of control to get it done, and get it done fast. That means you're going to need a game plan, and you're going to need it sooner rather than later.What Does 'HTTP is the new TCP' Mean for You
#SDN #webperf It means you can't use "network" protocols to make intelligent decisions about applications any more. Back in 2000 (or 2001, I forget exactly), I got to test a variety of bandwidth management appliances. Oh, they were the bomb back then - able to identify (and classify) applications by nothing more than an IP address and a TCP port. Once identified you could set quotas on bandwidth consumption and burst capabilities. It was quite the technology, back then. But that was before applications all starting using HTTP as if it were TCP. Between the rapid ascent of the Internet as place to do business and the webification (remember when that was a thing?) of applications there are very few applications that don't rely on HTTP as their primary "transport" protocol. What that means is that there are a whole lot of very different applications that use port 80 (or 443). You can't, by port, determine anything about that application except that, well, it's probably HTTP and definitely TCP. Is it video? It is text? Is it interactive? Dynamic? Static? An API? Having just the IP and Port is like having a street and house number but not knowing who lives there or what's inside. You end up sending mail to "our friends at" or "current resident" because you have no clue as to who actually lives there. Your marketing and offers are general, they aren't tailored or specific, and you've no clue if you're even reaching the right demographic. Oh, your coupons are delivered, but if I don't shop at your store anyway, you just wasted several cents on me that you could have saved had you known better. And several cents times thousands (or tens of thousands) of coupon flyers is a lot of waste. Sometimes you hit the right house and your message is well received and appreciated, it has a positive result. But it's hit and miss. More often than not, you wasted time, effort and money because you were blind. That's how it is in the network, where reliance on TCP and port number wind up rarely hitting a home run in terms of positive impacts, and the rest of them time end up as wasted effort. The implications go beyond classification. It means that services like acceleration, optimization and security must be application-aware. They must be fluent in a given application's behavior and requirements in order to apply the right policy at the right time. Which means anything operating at TCP or below isn't able to effectively do that. It means that without application layer (L4-7) services, you're pretty much out of luck in terms of how much you can leverage the network to impact the performance, availability and security of applications. It means L4-7 is now critical, because it's only at those layers of the network stack that visibility into an application can be achieved and only at those layers can you execute the kinds of policies and functions needed today to make data centers more efficient and secure. It means that without application-aware (and application-fluent) services your policies and processes in the network are executing either blindly or too broadly to have a real impact on the performance, reliability or security of a a specific application. It might be application-aware, but it's not application-fluent - or driven.
