What Does Mobile Mean, Anyway?
We tend to assume characteristics upon hearing the term #mobile. We probably shouldn’t… There are – according to about a bazillion studies - 4 billion mobile devices in use around the globe. It is interesting to note that nearly everyone who notes this statistic and then attempts to break it down into useful data (usually for marketing) that they almost always do so based on OS or device type – but never, ever, ever based on connectivity. Consider the breakdown offered by W3C for October 2011. Device type is the chosen taxonomy, with operating system being the alternative view. Unfortunately, aside from providing useful trending on device type for application developers and organizations, this data does not provide the full range of information necessary to actually make these devices, well, useful. Consider that my Blackberry can either connect to the Internet via 3G or WiFi. When using WiFi my user experience is infinitely better than via 3G and, if one believes the hype, will be even better once 4G is fully deployed. Also not accounted for is the ability to pair my Blackberry Playbook to my Blackberry phone and connect to the Internet via that (admittedly convoluted) chain of connectivity. Bluetooth to 3G or WiFi (which in my house has an additional chain on the LAN and then back out through a fairly unimpressive so-called broadband connection). But I could also be using the Playbook’s built-in WiFi (after trying both this is the preferred method, but in a pinch…) You also have to wonder how long it will be before “mobile” is the GPS in your car, integrated with services via Google Map or Bing to “find nearby” while you’re driving? Or, for some of us an even better option, find the nearest restroom off this highway because the four-year old has to use it – NOW. Trying to squash “mobile” into a little box is about as useful as trying to squash “cloud” into a bigger box. It doesn’t work. The variations in actual implementation in communication channels across everything that is “mobile” require different approaches to mitigating operational risk, just as you approach SaaS differently than IaaS differently than PaaS. Defining “mobile” by its device characteristics is only helpful when you’re designing applications or access management policies. In order to address real user-experience issues you have to know more about the type of connection over which the user is connecting – and more. CONTEXT is the NEW BLACK in MOBILE This is not to say that device type is not important. It is, and luckily device type (as well as browser and often operating system), are an integral part of the formula we all “context.” Context is the combined set of variables that make it possible to interpret any given connection with respect to its unique client, server, network, and application needs. It’s what allows organizations to localize, to hyperlocalize, and to provide content based on location. It’s what enables the ability to ensure performance whether over 3G, 4G, LAN, or congested WAN connections. It’s the agility to route application requests to the best server-side location based on a combination of client location, connection type, and current capacity across multiple sites – whether cloud, managed hosting, or secondary data centers. Context is the ‘secret sauce’ to successful application delivery. It’s the ingredient that makes it possible to make the right decisions at the right time based on current conditions that address operational risk – performance, security, and availability. Context is what makes the application delivery tier of the modern data center able to adapt dynamically. It’s the shared data that forms the foundation for the collaboration between application delivery network infrastructure and provisioning systems both local and in the cloud, enabling on-demand scalability and at some point, instant mobility in an inter-cloud architecture. Context is a key component to an agile data center, because it is only be inspecting all the variables that you can interpret them in a way that leads to optimal decisions with respect to the delivery of an application, which includes choosing the right application instance whether it’s deployed remotely in a cloud computing environment or locally on an old-fashioned piece of hardware. Knowing what device a given request is coming from is not enough, especially when the connection type and conditions cannot be assumed. The same user on the same device may connect via two completely different networking methods within the same day – or even same hour. It is the network connection which becomes a critical decision point around which to apply proper security and performance-related policies, as different networks vary in their conditions. So while we all like to believe that our love of our chosen mobile platform is vindicated by statistics, we need to dig deeper when we talk about mobile strategies within the walls of IT. The device type is only one small piece of a much larger puzzle called context. “Mobile” is as much about the means of connectivity as it is the actual physical characteristic of a small untethered device. We need to recognize that, and incorporate it into our mobile delivery strategies sooner rather than later. [Updated: This post was updated 2/17/2012 - the graphic was updated to reflect the proper source of the statistics, w3schools ] Long-distance live migration moves within reach HTML5 Web Sockets Changes the Scalability Game At the Intersection of Cloud and Control… F5 Friday: The Mobile Road is Uphill. Both Ways More Users, More Access, More Clients, Less Control Cloud Needs Context-Aware Provisioning Call Me Crazy but Application-Awareness Should Be About the Application The IP Address – Identity Disconnect The Context-Aware Cloud
LTE: Context is King
The ubiquity and influence of LTE is intensifying by the day. According to the 2014 Ericsson Mobility report,65%of the world's populationwill be covered by LTE in 2019, with data trafficin theCentral Europe, Middle East and Africa (CEMEA) region alonesetto increase 11-fold between2013 and 2019. But while service providersaren’t exactly shy to trumpetLTE’stransformational credentials,few are equipped to bestmonetise the technology and cope with both soaring data and complexity of consumer demand. One of the major issueshereis thatevery subscriber, application, and device is currently treated in the same way and, when the network getsclogged,servicequality takesan inelegant nosedive. Operators need to rethink their strategie to cope withthe data conundrum, continual demands for improved quality of service, as well as increasingly diverse device mixes, usage patterns and advanced policy-based services. In particular, an efficiencystep-changeis required whenit comes to managing unpredictable changes in traffic.This means collectingand analysingreal-time data on networkload and performance, as well as subscriber activity,andrelating it all backto policy. In other words, context is king. One of thebestways service providers can up their game is byadaptingto exponential increasesinsignalingtraffic using Diameter,which isthe protocol that enables network elements to communicate with each other to coordinate and optimize end-to-end transmissionfrom the internet to mobile devices.Thisis the foundation to establish context, implement charging, and leverage traffic and services management. Domain name system (DNS)protection is also going to bevital indeliveringabest-of-breed and reliableservice.For example,to protect the network againstdistributed denial-of-service (DDoS)attacks and other sudden surges in DNS traffic, operatorsmust be able torapidlydetermine and mitigatethreatsto minimise network disruption.In order to tackle theemerging challengesassociatedwith traffic growth and malicious activity configuredto hobblemobile infrastructures, operatorsare likely to turn totools like IP-client rate limiting. These cancontrol traffic surges, and DNS caching can reduce the load on the DNS server.Furthermore,DNS processing complements Diameter functionality to optimize message routing to provide scalability. Network Functions Virtualization (NFV)smarts are another up and comingmust-have,making it easierfor operators toaggregateinformation from multiple sources andachieve aplatform withthe right level of scalabilitytobest leveragecontext-aware data. Operatorssimplycannotafford toremain aloof, complacent and disconnected from the user-experience any more. While they might be catering to consumers in the same area, their needswill alwaysvary wildly.Clunky and presumptuousone-size-fits all approaches aredefinitivelyon the way out,and things like intricately tailored, geolocation-driven serviceswill become the norm. Encouragingly for all concerned,we arenow entering an era of service provision that has the potential to becomefarricher personalisedand differentiatedthanever before, allwhile utilising network resources withutmost efficiencyand delivering sound ROI. (Originally published in CommsMEA)I am wondering why not all websites enabling this great feature GZIP?
Understanding the impact of compression on server resources and application performance While doing some research on a related topic, I ran across this question and thought “that deserves an answer” because it certainly seems like a no-brainer. If you want to decrease bandwidth – which subsequently decreases response time and improves application performance – turn on compression. After all, a large portion of web site traffic is text-based: CSS, JavaScript, HTML, RSS feeds, which means it will greatly benefit from compression. Typical GZIP compression affords at least a 3:1 reduction in size, with hardware-assisted compression yielding an average of 4:1 compression ratios. That can dramatically affect the response time of applications. As I said, seems like a no-brainer. Here’s the rub: turning on compression often has a negative impact on capacity because it is CPU-bound and under certain conditions can actually cause a degradation in performance due to the latency inherent in compressing data compared to the speed of the network over which the data will be delivered. Here comes the science. IMPACT ON CPU UTILIZATION Compression via GZIP is CPU bound. It requires a lot more CPU than you might think. The larger the file being compressed, the more CPU resources are required. Consider for a moment what compression is really doing: it’s finding all similar patterns and replacing them with representations (symbols, indexes into a table, etc…) to a single instance of the text instead. So it makes sense that the larger a file is, the more resources are required – RAM and CPU – to execute such a process. Of course the larger the file is the more benefit you see from compression in terms of bandwidth and improvement in response time. It’s kind of a Catch-22: you want the benefits but you end up paying in terms of capacity. If CPU and RAM is being chewed up by the compression process then the server can handle fewer requests and fewer concurrent users. You don’t have to take my word for it – there are quite a few examples of testing done on web servers and compression that illustrate the impact on CPU utilization. Measuring the Performance Effects of Dynamic Compression in IIS 7.0 Measuring the Performance Effects of mod_deflate in Apache 2.2 HTTP Compression for Web Applications They all essentially say the same thing; if you’re serving dynamic content (or static content and don’t have local caching on the web server enabled) then there is a significant negative impact on CPU utilization that occurs when enabling GZIP/compression for web applications. Given the exceedingly dynamic nature of Web 2.0 applications, the use of AJAX and similar technologies, and the data-driven world in which we live today, that means there are very few types of applications running on web servers for which compression will not negatively impact the capacity of the web server. In case you don’t (want || have time) to slog through the above articles, here’s a quick recap: File Size Bandwidth decrease CPU utilization increase IIS 7.0 10KB 55% 4x 50KB 67% 20x 100KB 64% 30x Apache 2.2 10KB 55% 4x 50KB 65% 10x 100KB 63% 30x It’s interesting to note that IIS 7.0 and Apache 2.2 mod_deflate have essentially the same performance characteristics. This data falls in line with the aforementioned Intel report on HTTP compression which noted that CPU utilization was increased 25-35% when compression was enabled. So essentially when you enable compression you are trading its benefits – bandwidth reduction, response time improvement – for a reduction in capacity. You’re robbing Peter to pay Paul, because instead of paying for bandwidth you’re paying for more servers to handle the same load. THE MYTH OF IMPROVED RESPONSE TIME One of the reasons you’d want to compress content is to improve response time by decreasing the total number of packets that have to traverse a wire. This is a necessity when transferring content via a WAN, but can actually cause a decrease in performance for application delivery over the LAN. This is because the time it takes to compress the content and then deliver it is actually greater than the time to just transfer the original file via the LAN. The speed of the network over which the content is being delivered is highly relevant to whether compression yields benefits for response time. The increasing consumption of CPU resources as volume increases, too, has a negative impact on the ability of the server to process and subsequently respond, which also means an increase in application response time, which is not the desired result. Maybe you’re thinking “I’ll just get more CPU then. After all, there’s like billion core servers out there, that ought to solve the problem!” Compression algorithms, like FTP, are greedy. FTP will, if allowed, consume as much bandwidth as possible in an effort to transfer data as quickly as possible. Compression will do the same thing to CPU resources: consume as much as it can to perform its task as quickly as possible. Eventually, yes, you’ll find a machine with enough cores to support both compression and capacity needs, but at what cost? It may well have been more financially efficient to invest in a better solution (that also brings additional benefits to the table) than just increasing the size of the server. But hey, it’s your data, you need to do what you need to do. The size of the content, too, has an impact on whether compression will benefit application performance. Consider that the goal of compression is to decrease the number of packets being transferred to the client. Generally speaking, the standard MTU for most network is 1500 bytes because that’s what works best with ethernet and IP. That means you can assume around 1400 bytes per packet available to transfer data. That means if content is 1400 bytes or less, you get absolutely no benefit out of compression because it’s already going to take only one packet to transfer; you can’t really send half-packets, after all, and in some networks packets that are too small can actually freak out some network devices because they’re optimized to handle the large content being served today – which means many full packets. TO COMPRESS OR NOT COMPRESS There is real benefit to compression; it’s part of the core techniques used by both application acceleration and WAN application delivery services to improve performance and reduce costs. It can drastically reduce the size of data and especially when you might be paying by the MB or GB transferred (such as applications deployed in cloud environments) this a very important feature to consider. But if you end up paying for additional servers (or instances in a cloud) to make up for the lost capacity due to higher CPU utilization because of that compression, you’ve pretty much ended up right where you started: no financial benefit at all. The question is not if you should compress content, it’s when and where and what you should compress. The answer to “should I compress this content” almost always needs to be based on a set of criteria that require context-awareness – the ability to factor into the decision making process the content, the network, the application, and the user. If the user is on a mobile device and the size of the content is greater than 2000 bytes and the type of content is text-based and … It is this type of intelligence that is required to effectively apply compression such that the greatest benefits of reduction in costs, application performance, and maximization of server resources is achieved. Any implementation that can’t factor all these variables into the decision to compress or not is not an optimal solution, as it’s just guessing or blindly applying the same policy to all kinds of content. Such implementations effectively defeat the purpose of employing compression in the first place. That’s why the answer to where is almost always “on the load-balancer or application delivery controller”. Not only are such devices capable of factoring in all the necessary variables but they also generally employ specialized hardware designed to speed up the compression process. By offloading compression to an application delivery device, you can reap the benefits without sacrificing performance or CPU resources. Measuring the Performance Effects of Dynamic Compression in IIS 7.0 Measuring the Performance Effects of mod_deflate in Apache 2.2 HTTP Compression for Web Applications The Context-Aware Cloud The Revolution Continues: Let Them Eat Cloud Nerd RageDrama in the Cloud: Coming to a Security Theatre Near You
#mobile #infosec #gdi Conflicting messages from various trends are confusing … should you care about the client end-point or not? On the one hand, cloud: "Another key enabling factor for enterprise mobility is the cloud based delivery model for applications. With applications stored and delivered from the cloud, the endpoint device is largely irrelevant, with access allowed through smartphones, tablet devices or laptops. ” -- Enterprise Mobility ranks highly for IT investment, 25% of businesses rate mobility as a priority in 2012, finds Frost & Sullivan On the other hand, security: "If you want to secure the cloud, you need to secure your mobile devices," he explained. "They are the access points to the cloud -- and from an end-user perspective, the difference between the cloud and the mobile phone is lost." -- BYOD: if you can't beat 'em, secure 'em What’s a data center to do? Lock them all out, let them all in. There doesn’t seem to be a happy medium. This is comedy meets tragedy without the Greek mythology to make it a satisfying action film. The conflicting messages are the result of security colliding with productivity, which is probably a lot like security colliding with performance. In other words, we know who all too often wins that confrontation, whether we like it or not. The problem is that many are approaching the conflict with an either/or perspective. They’re trying to answer the question with an allow or deny policy based on the end-point, but ignoring the other end of the equation: the application or resource. SOLVE for X to DETERMINE ACCESS RIGHTS Like the two halves of drama, comedy and tragedy, the client and the resource (whether application or file or otherwise), go together. Settling on a BYOD strategy should necessarily not be based solely on the answer to “do we allow X on the network” but on the answer to “do we allow X to access this resource”. For example, in the case of many SaaS-styled applications, i.e. data is always stored in the database or on the server and never on the client, is there some other reason to deny an iPad or other mobile device access over any network? Probably not. However, attempting to download that confidential presentation with the latest roadmap of your product line … that may be something you don’t want leaving the building on a mobile device, especially those over which you have no control and cannot wipe in the event of loss or theft. Perhaps even if you do have control, you don’t want certain sensitive documents or data leaving the perimeter of the data center. The thing is that a BYOD policy can be as complex or simple as you need it to be. You can solve only for X. You can add Y (the network) to the equation. You can add Z (the user) to the equation. You can even add A, B and C to the equation, if desired, where each represents different user, network, or device characteristics, i.e. is the end-point secured and accessing the resource via a VPN? But it doesn’t have to be the source of more drama than a Greek tragedy starring Oedipus and his ill-fated daughter, Antigone, that’s so tragic it’s nearly comedic (to those watching, of course). With the proper tools and the right integration, you can implement a BYOD policy that works in the data center and in the cloud, without compromising security or productivity. Context-aware mobile mediation, in addition to providing developers with consistent identification of mobile devices, can also provide the means by which access rights to applications or resources can be determined. Context-awareness encompasses more than just device-type, it can provide network, user, and environmental variables that can be plugged in to your BYOD/Cloud policies and alleviate the frustrating one-off add-on rules that would otherwise overload operations. If the context-aware mobile mediation is enabled via an intelligent intermediary, like an application delivery controller, operations is further empowered not just to deny access, but to explain why, in simple HTML, to the end-user so they aren’t just frustrated by a failure to connect or a generic “403 Forbidden” status message. Give them an answer; explain to the end-user why they can’t download that confidential, highly sensitive document to their personal iPad. Offer some rationale into the policy behind the allow or deny and it might engender understanding from the end-users (or at least eliminate some dramatic tech support calls asking Why oh WHY can’t they get that file!?). Right now the conflict between unfettered access to cloud-based and corporate resources and reality is causing a lot of unnecessary drama. The right tools can enable operations and security to implement more flexible, reasonable access policies that may reduce that drama and return some sanity to the data center. The Half-Proxy Cloud Access Broker Mobile versus Mobile: An Identity Crisis The Three Axioms of Application Delivery Cloud Security: It’s All About (Extreme Elastic) Control Total Eclipse of the Internet The Cost of Ignoring ‘Non-Human’ Visitors Identity Gone Wild! Cloud EditionCloud Delivery Model is about Ops, not Apps
#cloud #byod #mobile #devops If there’s a difference between cloud and traditional app delivery from the end-user perspective, you’re doing it wrong. There seems to be a growing disconnect between reality and hype, fueled by the rainbow and unicorn dressing that’s been applied to cloud computing . The latest craze is to make reference to a “cloud delivery model” and almost always attached to BYOD and cloud computing. Generally such references take the form of: “Thanks to the cloud delivery model, any device can access applications delivered from the cloud.” Here’s a good example of this phenomenon: "Another key enabling factor for enterprise mobility is the cloud based delivery model for applications. With applications stored and delivered from the cloud, the endpoint device is largely irrelevant, with access allowed through smartphones, tablet devices or laptops. ” -- Enterprise Mobility ranks highly for IT investment, 25% of businesses rate mobility as a priority in 2012, finds Frost & Sullivan Seriously? There is no discernable difference from the point of the end-user between “cloud” and “traditional” data center application delivery. If there is, you’re doing it wrong. The transformation associated with cloud computing is internal; it’s inside IT and the business, it’s inside organizations, it’s inside operations. It is not on the outside, where the end-user might notice. Again, if it is, you’re doing it wrong. There is nothing inherently magical about cloud or its delivery model (which is, after all, the same as the delivery model in traditional data centers) that would better enable it to provide access to mobile devices. Nothing. Nothing at all but organizational policy that prevents certain devices from being on the network. That’s not innate to the model, it’s a decision made by the business or IT to disallow them. It’s a policy. What’s being delivered with cloud computing – off-premise, on-premise, across-premise – is an operational model. It delivers ops, not apps. Apps are delivered by application delivery networks or servers, not operational models. Cloud delivers operational resources – servers, storage, network, security – in a service-oriented fashion. Cloud delivers efficiency through scalable, repeatable application deployment processes. Cloud delivers a lower price per resource unit through the sharing of commoditized systems. It is not the purpose or intent of cloud computing to deliver unfettered access to applications to end-users. But this concomitant access is exactly what seems to be hailed as the greatest thing since TCP/IP took IPX/SPX out back in the school yard and kicked its legacy derriere back into the 20th century. Because the only difference between a data center serving applications to mobile devices and a cloud computing environment serving applications to mobile devices is access control. In the enterprise data center there is bound to be policies governing access to resources that may or may not restrict users from getting at specific data or files inside the data center when they are outside the data center and/or on a mobile device. In the enterprise there is likely to be tighter control over access to sensitive corporate information. Moving to a cloud computing model inside or outside the data center, a la private cloud, does not change the business and operational requirements to constrain access based on location, user, or end-user device. Yet that seems to be the implied “benefit” here of a so-called “cloud delivery model” in which the end-point is largely irrelevant (that’s another trap that operations needs to be aware of and put down with extreme operational prejudice. The end-point matters – not just from a security perspective but from a performance and delivery governance perspective. But more on that some other day). Sometimes the argument about cloud delivery models enabling agnostic mobile device access seems to center around applications stored in and delivered from “the cloud”. And web applications in the past weren’t? They aren’t now? They won’t be next month? From the perspective of the end-user – nothing has changed, except, perhaps, the ease with which they can find, install, and run applications on their mobile devices. And that’s not because of “cloud”, that’s because of APIs and some darn smart developers and architects. Cloud was completely inessential to the rapid adoption and success rates of mobile devices; that’s applications and ease of use. Cloud changes how applications are deployed, how they are provisioned, how their lifecycle in production is managed. It doesn’t change how they are delivered from an end-user perspective. The Conspecific Hybrid Cloud At the Intersection of Cloud and Control… The Battle of Economy of Scale versus Control and Flexibility The Magic of Mobile Cloud Cloud-Tiered Architectural Models are Bad Except When They Aren’t HTTP Now Serving … Everything When Big Data Meets Cloud Meets Infrastructure The Three Axioms of Application DeliveryF5 Friday: F5 Application Delivery Optimization (ADO)
#ado #fasterapp #webperf The “all of the above” approach to improving application performance A few weeks ago (at Interop 2012 to be exact) F5 announced its latest solution designed to improve application performance. One facet of this “all of the above” approach is a SPDY gateway. Because of the nature of SPDY and the need for a gateway-based architectural approach to adoption, this piece of the announcement became a focal point. But lest you think the entire announcement (and F5’s entire strategy) revolves around SPDY, let’s take a moment to consider the overall solution. F5 ADO is a comprehensive approach to optimizing application delivery, i.e. it makes apps go faster. It accomplishes this seemingly impossible feat by intelligently applying accelerating technologies and policies at a strategic point of control in the network, the application delivery tier. Because of its location in the architecture, a BIG-IP has holistic visibility; it sees and understands factors on the client, in the network, and in the server infrastructure that are detrimental to application performance. By evaluating each request in the context it was made, BIG-IP can intelligently apply a wide variety of optimization and acceleration techniques that improve performance. These range from pure client-side (FEO) techniques to more esoteric server-side techniques. Being able to evaluate requests within context means BIG-IP can apply the technology or policy appropriate for that request to address specific pain points or challenges that may impede performance. Some aspects of ADO may seem irrelevant. After all, decreasing the size of a JavaScript by a couple of KB isn’t really going to have all that much impact on transfer times. But it does have a significant impact on the parsing time on the client, which whether we like it or not is one piece of the equation that counts from an end-user perspective, because it directly impacts the time it takes to render a page and be considered “loaded”. So if we can cut that down through minification or front-loading the scripts, we should – especially when we know clients are on a device with constrained CPU cycles, like most mobile platforms. But it’s important to recognize when applying technologies might do more harm than good. Clients connecting over the LAN or even via WiFi do not have the same characteristics as those connecting over the Internet or via a mobile network. “Optimization” of any kind that takes longer than it would to just transfer the entire message to the end-user is bad; it makes performance worse for clients, which is counter to the intended effect. Context allows BIG-IP to know when to apply certain techniques – and when not to apply them – for optimal performance. By using an “all of the above” approach to optimizing and accelerating delivery of applications, F5 ADO can increase the number of milliseconds shaved off the delivery of applications. It makes the app go faster. I could go into details about each and every piece of F5 ADO, but that would take thousands of words. Since a picture is worth a thousand words (sometimes more), I’ll just leave you with a diagram and a list of resources you can use to dig deeper into F5 ADO and its benefits to application performance. Resources: The “All of the Above” Approach to Improving Application Performance Y U No Support SPDY Yet? Stripping EXIF From Images as a Security Measure F5’s Application Delivery Optimization – SlideShare Presentation Application Delivery Optimization – White Paper Interop 2012 - Application Delivery Optimization with F5's Lori MacVittie – Video When Big Data Meets Cloud Meets Infrastructure F5 Friday: Ops First Rule New Communications = Multiplexification F5 Friday: Are You Certifiable? The HTTP 2.0 War has Just Begun Getting Good Grades on your SSL WILS: The Many Faces of TCP WILS: WPO versus FEO The Three Axioms of Application DeliveryWhen Big Data Meets Cloud Meets Infrastructure
#stirling #interop #infosec #bigdata Bridging the Gap between Big Data and Business Agility I’m a huge fan of context-aware networking. You know, the ability to interpret requests in the context they were made – examining user identity, location, client device along with network condition and server/application status. It’s what imbues the application delivery tier with the agility necessary to make decisions that mitigate operational risk (security, availability, performance) in real-time. In the past, almost all context was able to be deduced from the transport (connection) and application layer. The application delivery tier couldn’t necessarily “reach out” and take advantage of the vast amount of data “out there” that provides more insight into the conversation being initiated by a user. Much of this data falls into the realm of “big data” – untold amounts of information collected by this site and that site that offer valuable nuggets of information about any given interaction. Because of its expanded computing power and capacity, cloud can store information about user preferences, which can enable product or service customization. The context-driven variability provided via cloud allows businesses to offer users personal experiences that adapt to subtle changes in user-defined context, allowing for a more user-centric experience. -- “The power of cloud”, IBM Global Business Services All this big data is a gold mine – but only if you can take advantage of it. For infrastructure and specifically application delivery systems that means somehow being able to access data relevant to an individual user from a variety of sources and applying some operational logic to determine, say, level of access or permission to interact with a service. It’s collaboration. It’s integration. It’s an ecosystem. It’s enabling context-aware networking in a new way. It’s really about being able to consume big data via an API that’s relevant to the task at hand. If you’re trying to determine if a request is coming from a legitimate user or a node in a known botnet, you can do that. If you want to understand what the current security posture of your public-facing web applications might be, you can do that. If you want to verify that your application delivery controller is configured optimally and is up to date with the latest software, you can do that. What’s more important, however, is perhaps that such a system is a foundation for integrating services that reside in the cloud where petabytes of pertinent data has already been collected, analyzed, and categorized for consumption. Reputation, health, location. These are characteristics that barely scratch the surface of the kind of information that is available through services today that can dramatically improve the operational posture of the entire data center. Imagine, too, if you could centralize the acquisition of that data and feed it to every application without substantially modifying the application? What if you could build an architecture that enables collaboration between the application delivery tier and application infrastructure in a service-focused way? One that enables every application to enquire as to the location or reputation or personal preferences of a user – stored “out there, in the cloud” – and use that information to make decisions about what components or data the application includes? Knowing a user prefers Apple or Microsoft products, for example, would allow an application to tailor data or integrate ads or other functionality specifically targeted for that user, that fits the user’s preferences. This user-centric data is out there, waiting to be used to enable a more personal experience. An application delivery tier-based architecture in which such data is aggregated and shared to all applications shortens the development life-cycle for such personally-tailored application features and ensures consistency across the entire application portfolio. It is these kinds of capabilities that drive the integration of big data with infrastructure. First as a means to provide better control and flexibility in real-time over access to corporate resources by employees and consumers alike, and with an eye toward future capabilities that focus on collaboration inside the data center better enabling a more personal, tailored experience for all users. It’s a common refrain across the industry that network infrastructure needs to be smarter, make more intelligent decisions, and leverage available information to do it. But actually integrating that data in a way that makes it possible for organizations to actually codify operational logic is something that’s rarely seen. Until now. Mobile versus Mobile: 867-5309 Why Layer 7 Load Balancing Doesn’t Suck BYOD–The Hottest Trend or Just the Hottest Term What Does Mobile Mean, Anyway? Mobile versus Mobile: An Identity Crisis The Three Axioms of Application Delivery Don’t Let Automation Water Down Your Data Center The Four V’s of Big Data The Challenges of SQL Load BalancingMobile versus Mobile: 867-5309
#mobile #context The identity crisis created by common platforms negatively impacts the ability to serve consumers and corporate IT consistently The focus on the explosion of mobile devices is heavily weighted toward IT in terms of management and security. While there’s nothing wrong with it, there’s another aspect of mobility that is often ignored. Much like their tethered counterparts, many mobile devices are constrained by a tight-coupling to numbers. In the case of the desktop it’s often IP address. In the mobile word, it’s another number: your phone number. I love my tablet, I really do. And I love mobile applications. But what I don’t love is mobile applications that, while perfectly able to run on my tablet and written for the same OS that powers many smart phone mobile devices, require tethering to a phone number. Because, Hello? McFly!?! It doesn’t have a phone number! NUMBER-BASED IDENTITY We’re going to skip the Prisoner analogy and just assume it was made, okay? While it’s always applicable to discussions this, it gets a bit tedious and cliché after a while and so let’s just assume that tethering identity to a number of any kind is a Very Bad Idea TM , m’kay? In the tethered world this is because such numbers are – especially today – highly volatile. You can’t count on even an application instance having the same IP address from one minute to the next let alone a user who may be roaming around the world. And in the mobile world, it’s even less of a sure bet as mobile devices of all kinds are moving between WiFi and mobile network faster than a four-year old tears open a Christmas present. We (as in IT) simply cannot enforce corporate security and serve the access needs of a highly nomadic user community if we’re constrained to doing so based on a single number – whether it be IP address or phone number. We’ve got to leverage as much information as possible about the user – their network, the device, their location, the security posture of the end-point. We’ve got to take into consider the context of each and every request and use that data as the basis for allowing or denying (or at least limiting) access to corporate resources. Mobile applications requiring phone-number do so as a means to secure access to resources. It is a failure of Epic Proportions because it tends to engender a false sense of security on the IT side, based on the premise that phone number is unique to an individual and highly static, which is not always the case. It is a failure of Epic Proportions because it stratifies a much larger technological market into “haves” and “have nots” based on whether a single identifying characteristic is present: a number. Such strategies are further a Very Bad Idea TM because of the impact on policy management and security and development. Applications relying on numbers for identity work only on devices that have such numbers; for the rest of the market (which is growing by leaps and bounds as more and more consumer devices are Internet-enabled) there must exist a separate but equal application. Developers time is already strapped, and maintaining two (in some cases three when the web is considered separately from mobile devices) discrete applications is madness, I say, madness. The pressure on IT to secure, manage, and support multiple versions of the same application were supposed to go the way of the Dodo with the advent of REST and the ascendancy of the API. And yet here were are, managing and securing and developing applications tied to numbers. MOBILE-MEDIATION You may recognize this one from a previous post, “Mobile versus Mobile: An Identity Crisis”, and it’s no less applicable to this problem than it was to the problem of mobile clients and OS or platform-based identification. Whether it’s OS, platform, or IP address/phone number, no single characteristic of a user’s request is enough information upon which to base any kind of decision. Period. No single piece of information gives IT the context in which security and delivery decisions can be accurately made. Without the big picture, without the context, it is nigh-unto impossible to ascertain which decision should be made with respect to the request. It is only by taking advantage of context that we can make decisions that are not only best for the organization and preserve a positive security posture, but that are also best for the user in terms of experience and performance. It is only at strategic points of control in the network, such as the application delivery tier, that all the variables on both sides of the equation – user and data center – are visible. It is at this tier where the rubber meets the road, as they say, and the two worlds of consumer and corporate meet. It is here where security and performance and access policies are most efficiently applied, where all the requisite variables that make up the context of the request can be extracted, evaluated, and acted upon. It is paramount to both end-user adoption and a positive corporate operational posture that such strategic points of control are leveraged. It is only context that provides insight into the “bigger picture” and ensures a smooth and secure experience for end-users that simultaneously preserves the security and availability of the applications and resources being delivered. Mobile users are not a number, nor are their tethered counterparts. They are users, with unique characteristics that are increasingly not only varied but volatile. Such variables must be evaluated contextually for every request to ensure the best possible experience without compromising operational or business expectations and requirements.Complexity Drives Consolidation
The growing complexity of managing more users from more places using more devices will drive consolidation efforts – but maybe not in the way you think. Pop quiz time. Given three sets of three items each, how many possible combinations are there when choosing only one from each set? Ready? Go. If you said “27” give yourself a cookie. If you said “too [bleep] many”, give yourself two cookies because you recognize that at some point, the number of combinations is simply unmanageable and it really doesn’t matter, it’s too many no matter how you count it. This is not some random exercise, unfortunately, designed to simply flex your mathematical mental powers. It’s a serious question based on the need to manage an increasing number of variables to ensure secure access to corporate resources. There are currently (at least) three sets of three items that must be considered: User (employee, guest, contractor) Device (laptop, tablet, phone) Network (wired, wireless, mobile) Now, if you’re defining corporate policy based on these variables, and most organizations have – or would like to have - such a level of granularity in their access policies, this is going to grow unwieldy very quickly. These three sets of three quickly turn into 27 different policies. Initially this may not look so bad, until you realize that these 27 policies need to, at least in some part, be replicated across multiple solutions in the data center. There’s the remote access solution (VPN), access management (to control access to specific resources and application services), and network control. Complicating even further (if that was possible) the deployment of such policies is the possibility that multiple identity stores may be required, as well as the inclusion of mobile device management (MDM). On top of that, there may be a web application firewall (WAF) solution that might need user or network-specific policies that tighten (or loosen) security based on any one of those variables. We’ve got not only the original 27 policies, but a variable number of configurations that must codify those policies across a variable number of solutions. That’s not scalable; not from a management perspective and certainly not from an operational perspective. SCALING ACCESS MANAGEMENT One solution lies in consolidation. Not necessarily through scaling up individual components as a means to reduce the solution footprint and thus scale back the operational impact, but by consolidating services into an operationally unified tier by taking advantage of a holistic platform approach to (remote) access management. The application delivery tier is an increasingly key tier within the data center for enabling strategic control and flexibility over application delivery. This includes (secure) remote access and resource access management. Consolidating access management and secure remote access onto a unified application delivery platform not only mitigates the problem of replicating partial policies across multiple solutions, but it brings to bear the inherent scalability of the underlying platform, which is designed specifically to scale services – whether application or authentication or access management. This means dependent services can scale on-demand along with the applications and resources they support. A consolidated approach also adds value in its ability to preserve context across services, a key factor in effectively managing access for the volatile environment created by the introduction of multiple devices and connection media leveraged by users today. It is almost always the case in a highly available deployment that the first component to respond to a user request will be the application delivery controller, as these are tasked with high-availability and load balancing duties. When that request is passed on to the application or an access management service, pieces of the contextual puzzle are necessarily lost due because most protocols are not designed to carry such information forward. In cases where component-component integration is possible, this context can be maintained. But it is more often the case that such integration does not exist, or if it does, is not put to use. Thus context is lost and decisions made downstream of the application delivery controller are made based on increasingly fewer variables, many of which are necessary to enforce corporate access policies today. By consolidating these services at the application delivery tier, context is preserved and leveraged, providing not only more complete policy enforcement but simpler policy deployment. This is why it is imperative for application delivery systems to support not just specific applications or protocols, but all applications and protocols. It is also the driving reason why support for heterogeneous virtualization and VDI platforms is so important; consolidation cannot occur if X-specific delivery solutions are required. As the number of devices, users, and network medium continues to expand, it will put more pressure on all aspects of IT operations. That pressure can be alleviated by consolidating disparate but intimately related services into a unified application delivery tier and applying a more holistic, contextually aware solution that is not only ultimately more manageable and flexible, but more scalable as well.Mobile versus Mobile: An Identity Crisis
#mobileThe expansive options consumers revel in creates an identity crisis for IT that is best resolved via context-aware mobile mediation. Back in the days of the browser wars, when standards were still largely ignored and the battle for the desktop was highly competitive, developers had to make choices and compromises. They could either write extensive client-side scripts to detect the user’s browser and address the peculiarities of that environment or they could simply ignore them with a disclaimer that “this site (works best when viewed in | was written for) browser X.” As time went by, developers were able to discontinue this annoying practice as browser features converged and a common, standardized platform emerged upon which all applications were able to be delivered to any popular browser without concern. Then mobile phones appeared, and the user experience degraded again, this time driven by the relatively feeble processing power of the platform. Small screens aside, the memory and processing power available on a mobile phone was such that – when combined with a constrained networking environment – the delivery of increasingly chunky, graphic heavy, interactive applications to mobile phones was simply a bad idea for both organizations and its visitors. Developers and web ops returned to the inspection of HTTP headers to determine whether or not a visitor was using a mobile platform, and began writing leaner, more compact interfaces specifically for those platforms. Enter tablets. Neither desktop nor phone, these admittedly mobile platforms are compact but nearly as powerful as their overweight tethered cousins without sacrificing the mobility of their anorexic form-factor brethren. COMMON GROUND: MOBILE OPERATING SYSTEM Tablets are certainly able to take advantage of emerging web application standards such as HTML5 to deliver a full, rich interactive desktop-style experience on a mobile platform, but are rarely offered it. They are by default offered up a mobile experience because of a common element: the operating system. Even if the operating system was masked, still they’ll find out by checking a second, lesser known HTTP header: HTTP_X_WAP_PROFILE. And if not there, then potentially in HTTP_PROFILE. Unfortunately, this is not necessarily the fault of the developer. There are no standards prescribing what should or should not identity a mobile device, and thus manufacturers are left to their own devices (pun only somewhat intended). There is no reliable way, today, to identify a mobile device accurately. Developers are left writing complex scripts that strip apart user agents, profile strings and whatever other contextual data they can extract from HTTP headers to determine how best to serve up content. That often means visitors are served content that is not wholly appropriate for their device. Even if they could, the market is so volatile at this point that it’s a sure bet that a new device will enter soon that requires modification to the application yet again. More code, more string manipulation, more latency in processing. CONTEXT-AWARE MOBILE MEDIATION It would be nice if developers could simply receive accurate inbound HTTP headers. Headers that clearly identify the device not only from an operating system perspective, but from a form-factor and network perspective in a standard way. But there are no standards, yet, and may never be. Thus a solution may be found in imposing standards upon inbound requests specifically for developers to better address the disparities in resolution, functionality, and performance between the various mobile device types. This requires some amount of pre-planning. Design, if you will, or architecture up front. It requires that developers and devops sit down together and determine a standard means of communicating information between infrastructure and the applications it supports. Consider the possibility of two custom HTTP headers, one identifying the network type and one specifying form-factor and device: HTTP_X_NETWORK = “WIFI | MOBILE | LAN” HTTP_X_DEVICE = “TABLET | PHONE | DESKTOP” If developers could rely on these two custom HTTP headers to exist for every inbound request, they could then develop applications based upon these characteristics that were more appropriate for the given device and network over which the device connected. Implementation requires only minimal inspection and insertion on a context-aware mediating device such as a network-side scripting capable application delivery controller. Because the application delivery controller is topologically positioned in a strategic point of control, it has visibility into the network, client, and server-side environments. This gives it the ability to better interpret and execute policies that govern the delivery of applications to optimize performance and assure availability, but it also provides the ability to extract and share pertinent data with applications and other infrastructure. This data can be shared in a number of ways, including modification of the payload, of the headers, insertion of new headers, removal of old headers, etc… The flexibility inherent in network-side scripting solutions, particularly those capable of side-band connectivity, allows devops and developers to design and develop a solution that works for them – in their environment. The advantage to such a solution lies not only in more accurate, actionable data to share with applications, but in its ability to easily be modified without negatively impacting the application. A second advantage is the ability of developers to also take into consideration the network characteristics of the mobile device, data generally not available or, if available, generally inaccurate. A mobile device today may be accessing an application via WiFi or a mobile network, and that piece of information is quite pertinent as the performance and capabilities of each network are quite different and have a significant impact on the end-user experience from a delivery perspective. Yet this data is not available by default to developers and it cannot reliably be inferred from device type. By leveraging a context-aware mediating solution, however, it becomes possible to share this data with developers such that they are able to take that information into consideration when putting together a response to a given request. While not a panacea, such a solution certainly provides a more consistent and overall accurate environment in which to deliver applications to the increasingly broad and diverse spectrum of mobile devices. Stack Overflow: How do detect Android Tablets in general. Useragent? Mobile Browsing Reaches All Time High The Magic of Mobile Cloud Understanding network-side scripting At the Intersection of Cloud and Control… Cloud-Tiered Architectural Models are Bad Except When They Aren’t WILS: WPO versus FEO Fire and Ice, Silk and Chrome, SPDY and HTTP Grokking the Goodness of MapReduce and SPDY
