Nojan Moshiri

developerWorks iOS app

Nojan Moshiri — Mon, 09 Jan 2012 22:25:35 GMT

Okay, I have to admit, I love IBM’s developerWorks. I was thrilled today to learn that there’s an iOS application (iPad, iPhone and touch devices) that gives us mobile access to all things developerWorks. I’m still learning to use the app, but by selecting the button in the upper right hand corner, you can chose any category within the site, such as groups, blogs, wikis, forums, downloads, and start exploring and reading.

It’s been a multi-decade affair with developerWorks for me, ever since Wietse Venema’s Postfix saved me from the horrors sendmail.cf in 1998 (sorry old time Unix grey beards!). IBM research has no end of awesome projects, including Watson, of recent Jeopardy! fame. IBM developerWorks is in any case the place for all types of cool, useful, upcoming, interesting, theoretical, awesome and community driven projects (throw in your own favorite adjective here). It’s definitely an app I’m looking forward to cozying up with during my commute (when by bus, of course).

IBM Rational AppScan

Nojan Moshiri — Wed, 28 Dec 2011 21:55:00 GMT

In my last post, I introduced my role as Solution Engineer for our IBM partnership and how many exciting solutions we have coming out in our partnership. Today I’m going to briefly cover one of our latest releases, the IBM Rational AppScan parser.

AppScan

IBM’s Rational AppScan implements the latest scanning technology to test your web applications for vulnerabilities. I’ve run this scanner many times and the complexity and depth of its scans is mind boggling. There are something like 30,000 tests that it can run in comprehensive mode, looking for all types of attacks against a website. When launching a new application or reviewing your security on an existing site, an investment like Rational AppScan may save your entire organization enormous amounts of pain and expense.

So how does AppScan work? You simply point it at your website and go. During a recent test, I tested a sample ecommerce site (designed to have flaws) and found over 129 problems, 37 of them critical exploits such as SQL injection and cross-site scripting. The beautiful thing with AppScan is that you simply see exactly where the exploit took place, how to repeat it and how to mitigate it. It’s an amazing tool and you should definitely check out the trial.

Once you have your scan, the next step is to fix the issues. In the example above, the 37 vulnerabilities might take days or weeks to solve. And that doesn’t even address the four dozen other medium and low priority issues. So how do you help speed this along? This is where BIG-IP ASM enters the picture. As of version 11.1, our IBM AppScan integration allows you to export your reports from AppScan, import them into ASM and immediately remediate the critical problems. In my test, I was able to remediate 21 out of the 37 critical vulnerabilities, leaving just a small handful to be worked on by the developers.

IBM Tivoli Maximo Asset Management Deployment Guide

Nojan Moshiri — Tue, 22 Nov 2011 22:23:42 GMT

I am pleased to announce that F5 Networks and IBM’s deployment guidance for Tivoli Maximo Asset Management is now live on the Resources section of f5.com and that the solution has been officially designated as “Ready for Tivoli.”. This comprehensive guidance covers acceleration, security and availability, showing how to configure LTM, WAM, APM and WOM with Maximo. Please check out the guidance and send us your feedback. But how did this come about, what is Maximo, and why am I blogging about it?

IBM

After more than three years working with SAP, VMware, Citrix and a host of other great partners I have moved to a new role working with IBM software solutions. As a solutions engineer with F5’s Business Development team, I am excited to be looking at a tower of joint solutions between F5 and IBM. Maximo represents the first of these solutions under my watch. I am so excited to be working with IBM solutions, for a number of reasons. First, they are a great partner with unparalleled responsiveness and every group I’ve worked with brings a real spirit of cooperation and “get the job done” attitude. Second, the technical solutions have few parallels, and I’m working with them all, form Tivoli to Websphere, Rational, Cognos and more. Finally, I’m very impressed by IBM’s Smarter Planet initiative and its ability to deliver, just as we have at F5. When Warren Buffett gives a thumbs up to a company (in the form of $10 billion dollars), you can’t help but feel you’re on the right track.

Maximo

So, IBM is awesome and F5 and IBM are great partners, but what is Maximo and how is it used? In short, Maximo is Asset Management Software designed for the most demanding industries in the world. This enterprise tool is used for many applications including maintenance, scheduling, inventory management, planning and SLAs, and it is a complete end-to-end solution. In my environment I tested a sub-set of Maximo features and found that F5 and Maximo are an ideal match. In the coming weeks we will publish the Maximo Application Ready Solution guide which will provide even further details about the specifics of a Maximo deployment, but in the meantime, you can get the specifics of how to deploy BIG-IP and Maximo in the deployment guide.

BIG-IP and Maximo

The exciting results for me, in the joint testing of the solutions, was how we were able to bring value to Maximo and BIG-IP customers from so many different perspectives. The chart below summarizes some of these findings:

BIG-IP Module

Maximo Feature

Benefit

BIG-IP LTM

Core functionality

High availability; TCP Optimization; SSL Offload; Compression; Caching and intelligent load distribution

BIG-IP WAM

Asset tracking; image, PDF and file download

Asymmetric acceleration of content using the browser

BIG-IP WOM

Access from remote branches

Symmetric acceleration, deduplication and encryption

BIG-IP APM

Sign-on, authentication, entitlement and remote access

Singe Sign-on; SSL VPN; Endpoint inspection

Next Steps

Coming up next for Maximo specifically, we will be publishing our Application Ready Solution guide, so you can read all about the benefits, we will be doing a couple of quick recorded demos so you can see the acceleration first hand, and we’ll be at the IBM Pulse conference in March to talk about it in person.

Distributing SAP Load using BIG-IP Advanced Monitoring

Nojan Moshiri — Thu, 10 Mar 2011 01:49:33 GMT

Several recent forum posts on DevCentral forums have commented on the fact that SAP Landscapes often have asynchronous batch jobs that cause higher CPU loads on certain servers. This causes problems for application delivery controllers because load balancing methods are typically based on connection counts. Picture the scenario where one connection causes a big CPU or memory spike and then goes away. Now you have the same number of new connections coming into the server while one is slammed.

The solution to this problem is relatively straightforward and I recently documented this for everyone in our “Deploying F5 Networks with SAP NetWeaver” deployment guide, located here: SAP NetWeaver and Enterprise SOA: Enterprise Portal (BIG-IP v10.1, WOM, Edge, WA). The solution is based around using SNMP in conjunction with application based monitors. The BIG-IP SNMP monitor provides the ability to perform dynamic load balancing based on CPU, memory or disk utilization while the advanced monitors test the J2EE stack, the authentication system and the database. With this combination, SAP administrators should be able to sleep better at night knowing that their customers and users are getting to a live system that best prepared to service the request.

So, how does layer monitoring work? If you are not aware, it’s possible to have two monitors for a particular pool or node. In the UI, it looks like this:

In this example there are two monitors, SAP-CPU and ICMP. In the real world, ICMP would be replaced with the advanced application monitor. So, what does the SNMP monitor configuration look like:

Here we have an SNMP setup that is set at a CPU Threshold of 80%, a memory Threshold of 0% and a Disk Threshold of 10%. Obviously this is from my testing to insure the monitor is working properly. What this defines is that if the disk is more than 10% full, or the memory is being utilized at 0% or the CPU is being utilized at over 80%, then de-weight the amount of new connections that get sent to this node(server). The coefficients allow further granular control over the traffic weighting determination. This is not a config you would probably run in production, but it’s great for testing!

By logging into the BIG-IP advanced shell and enabling logging, I can see exactly what weight is being assigned. This is accomplished through the command:

bigpipe db Snmp.SNMPDCA.Log true and then by tailing the snmpdca.log located in /var/tmp :

tail -f /var/tmp/snmpdca.log

There you have it. Now all we have to do is change the load balancing mechanism for the pool to be based on dynamic, apply the advanced application monitor, and we have a fully dynamic decision making system. You can play with the Thresholds and Coefficients until you have a desired mix. The SNMP monitor will not mark a host down, but it will set the weight (between 1 and 100) in a manner that very few connections will get to a node that has exceeded all tresholds.

A quick note on the advanced health monitor. I can’t stress how important it is to have layered monitoring in this and other dynamic load balancing scenarios. Especially in an SAP NetWeaver J2EE stack installation (or even a dual stack implementation) many things can go wrong. Just because the CPU, memory and disk are normal, doesn’t mean that your J2EE stack hasn’t crashed, or that your authentication system has gone down. By layering monitors, you cover all BASIS. :-)

I hope this post has been helpful, and as always, please email me if you have any questions. Remember that detailed installation instructions including step-by-step configuration is in the deployment guide linked at the top, or through f5.com ---> Resources -- > Deployment Guides ---> SAP NetWeaver and Enterprise SOA: Enterprise Portal (BIG-IP v10.1, WOM, Edge, WA)

To all my SysAdmin friends I say - Run your databases through BIG-IP and sleep better at night

Nojan Moshiri — Fri, 30 Jul 2010 20:36:17 GMT

When I was an “Internet Architect” (lofty title alert!) I used to hear this question fairly often in design meetings, whether to run the database (DB) through the load balancer or not. I would almost always come down on the side of “no there’s no point” because the DBs have their own high availability solutions, they don’t benefit from load balancing and there are usually no multi-master solutions. Also, load balancers are expensive and resources are finite on them.

Over the last few years a number of factors have changed, and today the answer is a solid maybe. There are a lot of compelling features and the crafty engineers that see the light may be able to solve some sticky architectural problems and even sleep better at night.

Change in viewpoint

Enter 2010, things have changed a lot and so has my viewpoint. More often now I’m finding that there are reasonable cases to be made for running the DB through the Application Delivery Controller (ADC). Resources are not as finite anymore, especially on BIG-IPs, and the added benefits include monitoring, flexibility, scaling and control. As an architect I always want more options and as a sydadmin I was stable solutions that let me sleep at night. The ADC has come of age and the benefits outweigh the main negative which is one more potential point of failure for a critical infrastructure component.

The changes that have made me change my mind is first, the resource issue on the ADC. Even from our BIG-IP 1600 series, our so-called “entry-level” point, our 10.2 release allows for passing of 1 Gigabit per second. On the SSL side, we’re talking about 5000 transactions per second of encrypted traffic. Many of the ADCs I’ve used in production spend a large amount of their time mostly idle, just serving front-end traffic and could easily handle the additional load of database connections. I’ve seen these boxes pushed to the limits and it doesn’t worry me nearly as much as it did even five years ago to run database connections through them for fear of overload.

But question still exists why bother?

Once we rule out the “hardware can’t handle it” argument, the second benefit is the ability to monitor the databases, built into our ADC. As Ryan Corder demonstrates in his entry Monitoring Open Source databases with BIG-IP, monitoring Postgres and MySQL is a snap with BIG-IP. This only makes me sleep better at night. I can setup replication to another local instance and create my own high-availability hot/standby cluster without all the overhead of a software clustered solution. Or, I can have the ability to instantly recognize outages and using iRules make intelligent traffic flow changes on the fly, without having to include my monitoring system. We all know how it works today, the monitoring system finds a problem, sends out a page to a system administrator (happy sys-admin day by the way guys and gals!) and meanwhile traffic is down until the problem can be resolved. How about this: the ADC finds the problem beginning with the very first request that has an issue and makes a decision to route traffic around the problem, and the sysadmin doesn’t have to run a fire-drill at that instant.

I’m already a long way towards sold on this now. But finally there’s the idea hinted at above, the flexibility of having the ADC in the way. This is the flexibility of making routing decisions based on layer-7 content. This is the flexibility of putting the databases where you need them and relying on the ADC to optimize TCP, or perhaps even to accelerate connections using BIG-IP WAN optimization. This is the flexibility of opening long-distance VMotion and having your database follow, all made possible by having an ADC in the architecture.

So, should I run my database through BIG-IP?

So, should you? It depends of course, if you’re a mom-and-pop shop with one site and no growth, probably not! But if you’re larger:

* Could you benefit from having more fine-grained control over the uptime and availability of your DB?

* Are you running MySQL or PostgreSQL? If you’re running Oracle, Sybase or MS-SQL, what kind of applications connect to your DBs?

* Is there a better connection manager solution available?

* Would the ADC conflict with your other high availability solution?

* Do you have a fairly complex architecture that could require multiple sites?

* Do you have an architecture that can change rapidly based on business needs?

Hopefully this will be another arrow in the quiver of the lofty Internet Architects ( :-) ) out there enabling them to successfully nail down another great infrastructure design.

Until later, I give all of the System Administrators out there the rest of the day off! May your pager be quiet and your systems remain up!

Introducing: F5's Management Plug-in for VMware

Nojan Moshiri — Wed, 07 Jul 2010 23:37:57 GMT

Today I’m happy to announce that F5’s Management Plug-In for VMware has been released! Last week I was lamenting the problems of managing virtualized environments, something I face with virtual environments all the time. I explained that three of the biggest headaches I have are adding VLANs to my VMware servers in order to insure VMotion works properly, associating and managing my Virtual Machines (VMs) to my BIG-IP Local Traffic Managers (LTMs) and managing VMotion. The plug-in tackles the association of BIG-IP with VMs and solves one of my big three headaches.

While adding VLANs has been scripted and VMotion made easier through our Wide Area Network Optimization Module (WOM), this is another step forward in addressing the BIG-IP management piece of this management chaos. The plug-in allows users to add a VM to pools on BIG-IP, perform maintenance on a VM and gracefully shut down a VM, all form within the vSphere Client. There’s a lot of substance in this plug-in and I encourage everyone to read the deployment guide on F5.com

(Screenshot showing how a VM can be managed directly from the vSphere Client)

The idea behind the plug in is that it’s easy to install into your vSphere Client, it takes away work duplication and lets you manage VMs associated with your BIG-IP right from within the client without a bunch of jumping around from client to client. Working with ESX/ESXi and LTMs, the plug-in actually installs on top of VMware Management Assistant (vMA).

The main features are the ability to add a VM to a pool, perform maintenance on a VM and shut down a VM, all from within the vSpshere Client. Of the features that really come in handy I find that adding virtual machines the most amazing because you can add rules, including a regular expression, that lets the plug-in automatically associate a VM to a BIG-IP.

For example, if I want to bring on-line a new server for my SAP environment’s dialog instances, I can simply give a pre-determined name (e.g., sap-mobile-43) and my regular expression will catch that this is a mobile instance of SAP DI and automatically add it to the predetermined SAP pool on my BIG-IP. That’s the type of automation that reduces clicks and makes life easier all around.

You can read the in-depth instructions in the deployment guide that our team has put together. The documentation covers the installation and the usage of the guide in the Resources (Deployment guide) section of F5.com. If you have any questions about the deployment guide , you can always email solutionsfeedback@f5.com

In the tradition of DevCentral, I’m really happy that the source code is available for everyone! To download the plug go to the F5 Management Plug-In page on DevCentral and select the “Discussions and Downloads” tab from the menu bar in the middle of the screen. Let us know what you think by joining the discussion there.

VMware vSphere and BIG-IP a bigger management nightmare?

Nojan Moshiri — Thu, 01 Jul 2010 20:59:59 GMT

(Our series of tubes may be virtualized but they’re just as hard to manage)

Can we make management of VMs easier?

In my role at F5 Networks I build many server environments to research and document application deployment guides. Virtualization makes it possible for me to rapidly build and iterate through software versions. Virtual Machines (VMs) are not just handy, they are a requirement, but setting them up and managing their interaction with my other lab equipment is so much work that it often feels like a chore.

We’ve been doing a lot of work this year to make VMs extendable, manageable and automated and to document great solutions to resolve the issues. Here are some of the areas that really bug me:

* Add/Remove a VLAN to each of my 8 ESX servers to support DRS and other VMotion needs,

* Add/Delete a newly generated VM to an existing Local Traffic Manager Pool (BIG-IP LTM),

* Disable a VM in LTM for maintenance or testing.

When it comes to interoperating VMs with our application delivery controllers (ADCs) the system administration can be just as lengthy as if we were dealing with real machines. And the question is why? With ESX VCenter Server and client there is endless room for automation of repeatable tasks. Let’s review some of the challenges and the advancements we’ve made so far and highlight some of the advancements coming.

Challenge #1 - Automating VLAN Creation

When I create a new environment, the first thing I do is pick the next available set of BIG-IPs and VLANs from my ZenOSS management utility (they definitely deserve a plug for being a great management platform). Now, I have to go and provision these new VLANs on each of my 8 ESX servers. Through the user interface (UI) this is a time consuming and irritating task requiring tens of clicks and lots of waiting:

(Click on the server, then Configuration, then Networking, then find the appropriate client VSwitch, click Properties, then Add, then choose VMKernel, enter the VLAN id, press okay, wait, press close and repeat this process 7 more times for each of your 8 servers!)

Automating this is a slam dunk with the esxcfg-vswitch program from the ESX servers console. In my case, I have Secure Shell (SSH) trust relationships between my host and all of my ESX hosts and a small script to which I provide my new VLAN name, VSwitch name and ID. SSH then calls each host sequentially and executes the command, adding the VLAN I need to all 8 servers. Tens of clicks skipped and many minutes saved.

Challenge #2 - What about IT Agility? How do we perform rapid movement of hosts

We started 2010 with as many questions as answers on our VM automation and acceleration projects. With the introduction of F5’s long distance VMotion solution and other solutions for VMware we’ve created a flexible toolbox that can make jobs easier and faster. Use cases are springing up all over from customers for how they would like to implement long distance VMotion but invariably, it comes back to management, how do my BIG-IPs interact with VMware and other hypervisors, this brings me to the third challenge.

Challenge #3 - Managing VMs in a load balanced environment Now that I’ve created my environment and enabled it for VMotion, what are the steps I need to make them work with my BIG-LTM ADC. In other words, how do I relate my VCenter tasks to the tasks in BIG-IP. If I’m adding a new server to an existing pool, I’d love for that pool member to be auto-detected to add the host to the appropriate pool, or to be able to remove a host, or disable and bleed off connections. What if we could address these tasks in just as automated a way as we do VLAN addition or Long Distance VMotion:

* Automatically adding a VM to pools on the BIG-IP based on configurable criteria,

* Disable a VM on all BIG-IPs for maintenance

* Bring a VM back online after maintenance

* Bleed off connections form a VM for maintenance

In the end - It’s all about reduction of time spent managing and reducing duplication of effort With virtualization, we have conquered the problem of tedious and physical datacenter work (I do kind of miss the extra physical labor though). Finding a new machine, lifting it into place, formatting its hard drive, plumbing it into the patch panel and so forth. Now we’re going to reduce the virtual heavy lifting that still exists with the management and setup of these environments.

Introducing: Long Distance VMotion with VMWare

Nojan Moshiri — Tue, 02 Feb 2010 22:46:27 GMT

It seems like I blinked and 2009 went by, but in that time I've been working on so many interesting projects at F5, I have a backlog of information to share with the community. The first post this year is about the long distance VMotion with VMWare's ESX system. This is a solution that enables the movement of live running virtual machine hosts from one data center to another.

The main problems in routing VMotion between data centers are latency, bandwidth, client traffic and security. In BIG-IP 10.1 we have a solution that compresses, encrypts and shields the ESX servers from prevailing WAN conditions, to enable long distance motion of running hosts. Take a look at the following screencast to see how this works:

In the chart below are some of the typical improvement times we see with long distance VMotion with BIG-IP. When latency goes up, VMotion is often not possible without BIG-IP in place. For example, with 100 ms of round-trip latency, on an OC3, a virtual machine that has one gigabyte of active RAM memory, takes roughly three and a half minutes to migrate across the WAN. If you were to try the same VMotion without BIG-IP in place, it would take more than 13 minutes and only succeed about half the time.

I'm excited about the types of architectures that can be enabled with this kind of solution in place. F5 is laying the ground work to make some exciting infrastructures possible

Have a look at the F5 deployment guide which describes how to set this solution up and how to architect new solutions across your data centers: http://www.f5.com/pdf/deployment-guides/vmware-vmotion-dg.pdff

Technorati Tags: vmware,VMotion,Long Distance,iSessions,GTM,BIGIP-LTM 10.1,BIGIP-WOM

F5 and SAP Integration - Auto configuration and monitoring under BIG-IP V10

Nojan Moshiri — Sat, 18 Apr 2009 03:44:40 GMT

Are there ways that F5 Networks and SAP can make your SAP operations simpler, more elegant and more automated, with appropriate controls in place to detect abnormalities?

With V10, F5 Networks is delivering three things: first, template based configuration support for SAP Enterprise Portal and Web Based SAP ECC Instances (so that a few questions and one submit button perfectly configures your instances). Second, integration with SAP's ASLR (described below) to automatically detect and help configure all available SAP instances (so that your hunt for SAP instance numbers and port numbers during configuration is over). And third, a complete monitor that individually logs into each configured SAP Instance and checks that instance's unique health status (and then reacts appropriately).

SAP and F5 Networks's partnership manifests itself in exceptional ways and participating in the SAP Enterprise Services Community, part of SAP's Communities of Innovation was one of these opportunities. SAP's idea was elegant and came with a very practical goal: SAP reached out to all of the networking partners and asked us how we can simplify SAP NetWeaver operations.

The initial presentation from SAP asked this high level question and presented a series of APIs that could be used to build these solutions. SAP challenged us with the analog of the fly wheel governor (pictured above); could we invent a system that controls SAP based on the current working conditions. Through a series of working sessions with SAP we went to work at F5 Networks to solve this problem and the results of our work will be presented at the Americas SAP User Group Meeting (ASUG) in May.

Our solution has three components, detection of SAP instances, configuration of SAP web instances (Portal or other web based ECC instances) for high availability, web acceleration and security and monitoring of SAP web instances from login to database for a complete picture of what is up and what is down. These steps are performed with the aid of the SAP Application Server List Retrieval (ASLR) API which is part of the SAP Message Server (standard on all SAP NetWeaver installations out-of-the-box).

Configuration - Support for SAP Enterprise Portal and all your Web Based SAP ECC instances.

With F5 Networks BIG-IP V10 templates for SAP ERP Portal and SAP ECC instances, configuring BIG-IP with advanced application delivery controls is accomplished with just a few questions to be answered on one single page. Below, you can see a screen shot of my BIG-IP and the templates we have available today, especially for SAP, Enterprise Portal and a more generic SAP ECC template for the installation of any additional SAP Web Based instances.

Detection - Integration with SAP ASLR to automatically configure all SAP instances. The hunt for SAP instance numbers and port numbers is over.

With the coming addition of SAP ASLR integration (planned for after the upcoming ASUG meeting), we will have the message server integration pictured below. While this may look like a very small number of questions, the template takes care of all of the aspects of configuring SAP Portal. Of note to me is how easy it was previously for customers to miss important optimizations even though we detail and clearly document these in our deployment guides (for example the SAP Deployment Guide for V9). With BIG-IP V10 SAP application delivery will be the fastest possible through the network, every time.

Now, by providing the SAP Message Server IP Address and port number, BIG-IP automatically retrieves and populates the SAP instances in the load balancing portion of the questionnaire. The hunt for instance numbers and port numbers is over, with the cooperation of ASLR and BIG IP Application Templates.

Monitoring - A complete monitor that individually logs into each SAP Instance and checks that instance's unique health status (and then reacts appropriately)

One of the shortcomings that F5 Networks has found with the APIs as they stand today is that although graceful shutdown is well detected by the ASLR API, more is needed to address unforeseen outages. We hope that with the community involvement this will be addressed in coming versions of the API.

To solve this issue now, our SAP templates install a series of health monitors to cover the state of SAP Web Instances up the entire stack. We begin with automatic configuration of ping and port monitors (which indicates the individual server or VM instance is up). We then configure a monitor which checks for HTTP/1.1 presence (which indicates that SAP Dispatcher is up) and finally we now will recommend the addition of a health monitor to log into the SAP Web Application portal and check for a specified piece of validation text (we then log out, of course). None of this configuration requires any command line interaction and can be delegated to SAP NetWeaver or Basis administrators.

Edit-June16,2010: As a point of clarification, some users have wondered if the SAP template for BIG-IP installs the in-dept scripted monitor I discuss here. The answer is no . The scripted monitor is a recommendation for users interested in in-depth monitoring and needs to be installed manually. Please email me for additional questions or for a copy of the script. Below you can see that we allow the configuration of the login username, password and validation text all via the UI.

For more on this project from our wonderful partners at SAP I highly recommend checking out Joerg Nalik's post at the SAP Community Network: Catching Up with Deploying and Operations Automation.

Technorati Tags: SAP,NetWeaver,Server Operations,SAP Enterprise Services Community,SAP Portal

Mobile data - Where does it go?

Nojan Moshiri — Tue, 10 Feb 2009 19:00:29 GMT

I was excited to see our press release coverage today about F5 Networks and Bytemobile's ability to scale T-Mobile's 3G Network Capacity with our VIPRION product. The article mentions the "explosive" growth of data on mobile networks and how data network capacity has to be scaled to handle the tremendous growth. As a sentence, this all makes sense, and most networking professionals wouldn't give it a second thought; it's a data network and it needs to be scaled.

On the other side of this datacenter-centric story is the world we see around us from day-to-day. Most professional have some sort of mobile data device these days, from Apple iPhones, to Google Android to Blackberry devices, and no one is shy about using the mobile data services they come with. The missing connection for many people I talk to casually about mobile data is where exactly their data goes, in other words, what is the path of the data and where does it run into limits?

At home and work, our email, web pages and videos all take generally the same path. This is not so true with mobile networks. On mobile networks, Text messages (SMS) ride an out-of-band portion of the voice network (thus the 160 byte limitation), Blackberry email messages involve additional hops through RIM servers and involve their protocols as well, data such as web pages and other TCP content have yet another path. The over-the-air part is just one small part of this path.

I see the light-bulb usually go off when I ask people "Where do you think the data goes from your phone?" and they say "oh, I've never thought about that". To take a very high level view, when we make a request for a web page or a YouTube video from our 3G device, let's consider the path our data has to take.

The request goes from the mobile device via over-the-air radio frequency to a local cell site. This is the 3G network, and this is only the first "hop". Your mobile request has traversed the over-the-air network in the fastest available way today, but now what? It doesn't go straight to YouTube.

From the cell site it's either relayed to another cell site or relayed back via high-speed lines to the carrier's network. At this point, depending on the network, there might be another conversion process to get to the TCP network and the request finally enters the "data network". In most networks, there has to be an authentication process to authorize the connection. Once the request has entered the carrier's network, it gets processed by all the standard mechanisms (DNS requests, proxy servers, caches, etc). This datacenter is the single point that all data communication go through and carriers work day-and-night to optimize the speed and reliability of these datacenters.

Once you realize that every single subscriber to your carrier's network is going through that same network, you realize just how important it is, certainly equally important to the 3G network, if not more. Finally, once the request is processed it returns to the mobile phone via that great and speedy 3G network.

And this is why today's news is so exciting to me. Seeing investments being made at the Mobile Carrier's datacenter is good news for everybody. It's these investments that will ultimately enable the "feature XYZ" or background applications or many of the other wish list items we crave on our mobile devices. When people see the performance numbers of our VIPRION, they sometimes ask who could possibly push that much traffic, in the mobile providers we have one of the many examples of an answer to that question.

Technorati Tags: F5,Mobile,Data,VIPRION,T-Mobile,ByteMobile

BIG-IP Module	Maximo Feature	Benefit
BIG-IP LTM	Core functionality	High availability; TCP Optimization; SSL Offload; Compression; Caching and intelligent load distribution
BIG-IP WAM	Asset tracking; image, PDF and file download	Asymmetric acceleration of content using the browser
BIG-IP WOM	Access from remote branches	Symmetric acceleration, deduplication and encryption
BIG-IP APM	Sign-on, authentication, entitlement and remote access	Singe Sign-on; SSL VPN; Endpoint inspection