WAN Governance

Application delivery? Come on, this is not complicated…

 

In a recent paper published last week in Computer World, Johna Till Johnson (president and senior founding partner at Nemertes Research) talked about "getting a handle on chaos and complexity" applied to networking. Johna points out that "complexity translates directly to increased operation costs and decreased reliability" and raised an interesting question "is being complicated the same as being complex?"

Wikipedia proposes a simple answer: Complex is the opposite of independent, while complicated is the opposite of simple.

Transposed to networking, we can see that:

• IP networking is "complicated" (myriad connecting stovepipes). The simple text page that you currently read has probably crossed 100+ active devices (switches, routers, repeaters, modems, etc.) from the Typepad blog server to your desktop, each of them transforming locally the information envelop to pass it to the next hop in a reasonably efficient (and effective) way. But there are finally very few interactions between all of these components (to make each hop as independent as possible was actually the great idea that made IP networking so successful).
• Application delivery is "complex" (effective integrated solutions). Above the pure transport of information between servers and clients, many interactions affect the user experience. There is a fundamental reason for this: in most cases the user is a human being (and when it is not the case, there are – still – humans behind the machine behind the machine). And we care about "time" (life is short) and "quality" (we feed ourselves with harmony and satisfaction). We want information quickly, in a format (frames, sounds, images) that matches our rising level of expectations. This creates constraints that networks built of independent routers and switches are not prepared to handle.

Transport is about controlling space (which route will this information use?) while application delivery is about controlling time (when will this information be delivered?). And time is one of the key components of the interactions that are the essence of complex systems.

This is why classical network management solution, thinking at box level, are so efficient to manage complicated transport infrastructure (inventory, configuration, supervision, etc.) and so ineffective in guaranteeing proper delivery of applications. You can breakdown a puzzle representing a cat into small parts and make it simpler. Please remember your tries with beetles when you were 5 years old and don't do that to the house cat!

This is why I believe that WAN Governance and its top-down path is the right global approach for effective application delivery: far from carving up the cat, let's take globally care of it.

Beam me up, Scotty. There is no intelligent life down here…

Classical networking approaches are no more consistent with cloud computing (see for example "the slowly evolving WAN" by Jim Metzler and Steve Taylor). The lack of innovation during the last 10 years laggards the network: static, blind, unable to control application flows and to guarantee the availability of good application performance to end users. Designed with other purposes in mind nearly 20 years ago, no wonder old-fashioned MPLS cannot match the new situation.

With cloud computing, situations are complex and change too fast for legacy and static policy based management. A cloud-ready network must learn, decide and adapt dynamically to match the increasingly dynamic users' traffic. It must take into account all the business applications (private and public cloud based, peer-to-peer voice and video) as well as the recreational ones.

A cloud-ready network must leverage Internet ubiquity and cost effectiveness and combine it with more guaranteed and value priced MPLS networks. It must also embrace mobility and new access devices (tablets, smart-phones).

One can set-up servers in an unknown datacenter from a web interface in a few minutes; why should he wait weeks and months for the network to adapt to the new situation? A cloud-ready network must couple cloud datacenter with network behavior in a flexible orchestration manner.

Enterprise's silos are vanishing. With cloud computing BUs go beyond the corporate IT organization: repressive policies don't make the job anymore. Yet IT managers need to keep a reasonable control of the situation: know what's happening, decide about strategic topics, apply the decisions and check results, manage costs. A cloud-ready network must provide CIOs with global control in a simple manner.

Far from complex, rigid and inefficient policy-based schemes, a cloud-ready network must be Objective-based. Intelligent and fast, it should learn and adapt by itself in real time, serving high level enterprise's goals. Autonomic networking has already proved its ability to solve this tricky problem in many situations.

Application visibility, QoS, control of each user's flow, hybrid networks, mobility, WAN Optimization, application acceleration…: cloud-ready networks must embrace and tightly couple all these features in an all-in-one approach.

A WAN governance model, allowing CIOs to take the right decisions at corporate level rather than to react under the pressure of daily events would be a key characteristic of cloud-ready networks.

The IT revolution has started with cloud computing: it's time for the network to wake up and meet the challenge!

Who wants to be a Millionaire?

No one is really interested to save money. Your kids aren't. Neither is your boss. They're kidding when they told they are. They all want more power, more security, more options, more speed, more free time, more education, more space, more dreams, more friends, more love.

Explorers, scientists, entrepreneurs, artists are not moved by money. They need dollars, euros, rupees, yens or yuans to make dreams happen and visions crystallize. Money before dreams? Ego before vision? These are road signs to decline, indications of no more territory to explore, discovery to make, innovation to offer and original work to undertake.

When the CEO tells the CFO who tells the CIO who tells the IT Director (who tells his suppliers) that she wants to save on IT, she is just joking. What she (he, he or he) wants is faster decision process, shorter implementation, improved flexibility, better customer service, more accurate indicators, more time to think…

This is the key difference between IT or WAN governance approaches and blind cost-cutting programs. Like a good doctor who treats the disease and not (only) its symptoms, holistic approaches address root causes of problems and offer sustainable solutions. At the end of the day, providing pragmatic solutions to oversized resources, inefficient processes, slow applications or disorganized operations is the fastest path to efficiency: Concentrate on cost and quality decreases – focus on quality and costs decrease.

Actually, the truly limited resource is time. Its fundamental limitation shapes every aspect of our life, every decision we (consciously or unconsciously) take. The proverb is wrong: time is much more than money. Who wants to be a millionaire? May be the right question should have been "who need to be a millionaire?"

Illustrations: Louise Bourgeois (Paris 1911 - New-York 2010) – "Give or Take" and "Maman" in front of Guggenheim Museum Bilbao. She recently passed away – What a character!

Bandwidth usage by the numbers

In conjunction with WAN Governance initiative, an approach that synchronizes application performance management directly with business requirements, Ipanema sampled 50 among its largest enterprise customers to understand their current bandwidth usage (see here for more details).

The rationale behind WAN Governance is to better align network performance according to direct business objectives. And in order to do that, we must start with an understanding of current performance and usage. By understanding the nature of data traffic on the network, the infrastructure managers can optimize performance and availability based on actual business usage, thereby lowering infrastructure costs and improving end-user productivity.

This analysis showed that the most critical applications account for only a small share of network usage—a mere 3%, up to 9% if we sum the [top+high] criticality applications—whereas the lowest priority applications eat up more than half (54%) of network resources.

Network Applications by the Numbers
(based on survey by Ipanema of 50 customers -10,000 sites)
69	Differentiated applications per enterprise
15	Families of applications, with 7 to 33 app. Each
4	Business criticalities (TOP, HIGH, MEDIUM, LOW)
3%	Traffic volume of TOP criticality applications
9%	Traffic volume of [TOP + HIGH] criticality apps
54%	Traffic volume of LOW criticality applications

The numbers tell an interesting story: the enterprises differentiate an average of 69 applications on their networks (even if some run a larger number of specific applications – the CIO of a international engineering company recently explained me that she identified 878 different applications across her global organization – birds of a same feather can easily be grouped, leading to a more manageable number). Enterprise applications were classified (and prioritized) according to four categories: top, high, medium and low. Top criticality applications require always-on availability with an immediate and direct impact on everyday business operations, such as SAP, Oracle, Citrix, VoIP, video conferencing; low criticality applications were those with little impact on business performance, including non urgent file transfers and personal/recreational applications like YouTube, Facebook and Twitter. Usually emails are classified in the medium criticality level.

This makes clear that bandwidth is not the main criterion to manage application performance. WAN Governance should apply the same granularity for network performance monitoring and analysis for each application to enable organizations to fully understand their applications traffic, however complex, and guarantee the availability of applications with greatest impact on business performance.

By analyzing critical sites and applications – in addition to measuring other core requirements such as actual delivered performance against current SLAs, technical network variances such as jitter and server response time, and indicators such as Application Quality Score (AQS) for data applications and Mean Opinion Score (MOS) for voice and video applications, enterprises have clear business priorities and a measurable set of Key Performance Indicators (KPIs) for application performance over their WAN.

Automated management tools (such as the one based on Autonomic Networking) can then dynamically control the network and its traffic accordingly – driving to end-user performance guarantees and further savings at network and IT level.

QWERTY, DHIATENSOR and DSK

I recently (re)read some of Stephen Jay Gould's wonderful articles he published in the 80s and 90s (1980s, I mean). Gould (1941-2002) who was a paleontologist and educator at Harvard University made his largest contributions to science as the leading spokes-person for evolutionary theory. He wrote very imaginative and accessible monthly columns in Natural History magazine that have been gathered in an abundant bibliography of over 20 books with appealing titles, like the "Panda's Thumb" or the "Flamingo's Smile".

Gould used to write his texts on an old Smith-Corona typewriter (similar to the one above), and was then teased by one of his friends (Paul A. David, Clio and the economics of QWERTY – 1986) about the letters arrangement (named QWERTY for English typewriters). Gould's article is particularly rich, with provocative implications in many aspects of the IT business, from the uselessness of ROI studies to the power of marketing and necessity of being lucky.

Typewriters have been invented in the 70s and 80s (1870s, I mean) and it took a few decades to stabilize their technical organization as well as their user interface: the keyboard.

Many different keyboard organizations competed before it stabilized under the well-known aspect of the QWERTY suite. The reason for QWERTY supremacy is not that obvious: it is not linked to the rapidity of typing, as you might think at first. Would typewriter manufacturers maximize speed, they would have put the letters DHIATENSOR in the most accessible line (the middle one), as 70% of English words can be written from this small list of letters. On the contrary, QWERTY is the result of fine-tuning (by C.L. Sholes) to slow down typing speed! At this time the main problem was that, when writing too fast, typebars tend to hurt and block among themselves, provoking d ff jmleesd kkjjjjjg disasters… And this is why QWERTY was designed to make people's life more difficult!

Finally, QWERTY victoriously resisted to all further attacks, from the optimized DSK (Dvorak Simplified Keyboard) in the 30s (1930s…), the IBM Selectric and its famous "gulf ball" in the 60s and finally the computer industry in the 80s that produces the laptop computer I'm writing on at the moment.

Isn't the vision of millions (if not billions) of humans fighting with the apparently random organization of their keyboard at home, at school or at work, because of technical constraints that disappeared 80 years ago, a really stimulating and refreshing one ?

Reference: Stephen Jay Gould, the panda's thumb of technology, in Bully for Brontosaurus – 1991

?evitatummoc sonitarepo krowten erA

In real life, most situations are not commutative: the order in which we make them matters (try a cooking recipe in reverse order: you'll see your guests' reaction…). So we can wonder if this is the case for enterprise network operations.

Of course, as defenders of Autonomic Networking and Objective-based management's Top-Down approach for application performance management, we are convinced that the answer is NO: performance objectives have to be at the root of the entire process, traffic policies and fine-tuning being only consequences. But, may be should we challenge this point of view?

Asking WolframAlpha was not that helpful. So we decided to experience Google translation tools, which provided the following results:

(English) Does the order in which network operations are performed impact the user experience? à (French) Est-ce que l'ordre dans lequel l'exploitation du réseau sont effectuées l'impact de l'expérience utilisateur? à (Japanese)これで、ネットワーク運用への影響、ユーザー体験を実施しているためですか？à (Turkish) Ağ operasyonlar Bu etki, ya da kullanıcı deneyimi için uygulanıyor? à פעולות רשת, האפקט הזה, או מיושמים על חווית המשתמש? (Hebrew) à (English) Network operations, this effect, or applied to the user experience?

Actually, this was not that bad for such a complex translation trip. So we decided to perform the same journey in the reverse direction to see if we can reach our starting point:

(English) Network operations, this effect, or applied to the user experience? à פעולות הרשת, את האפקט הזה, או להחיל את חוויית הגלישה (Hebrew) à (Turkish) Ağ işlemleri, bu etkiyi veya tarama deneyimi geçerlidir? à (Japanese) ネットワーク操作は、この効果が有効かブラウジング体験？à (French) Réseau d'exploitation, cet effet est expérience de navigation en cours de validité? à (English) Network operation, this effect is browsing experience valid?

Although not a complete disaster, we definitely lose the meaning of the initial question. At least we can conclude that Google translations (and likely any translations) are not commutative at all. So we have to resign ourselves to the reality: order matters, and even with network and application performance management, goals have to come before consequences…

(I make it short as we have to prepare our Global Wan governance webcast, which will take place on Thursday September 14^th, 2009. Would you like to attend, you'll find all details here).

(Illustration: Maciejowski Tower of Babel construction)

 

Frank Albert Benford Jr. hits again!

Do you know the Benford's law? It is one of these really irritating theories that you can't explain but do work very well (you'll find a lot of information and tools about it on the net). In a nutshell, it says that in current life, a number has a much higher probability to start with a "1" than with a "2", with a "2" than with a "3", etc. It is actually a logarithmic progression that has been empirically verified in many situations (some people even became crazy about it) and proved to be systematically true with 'natural' numbers like length of rivers, amount of money, size of objects… that's to say 99% of the figures we daily use. Although it has been proved that if the Benford's law exists then it should follow such logarithmic progression, it has never been really understood. Some people (like Stanislas Dehaene) believe that it is somehow linked to our brain capacity to access directly to small numbers (generally up to 3), without having to count or even 'think' (another amazing capacity called subitation).

In economy, Bentford's law is used for very serious matters like fraud detection and accounting certification (would you be tempted to evade tax, better you become an expert).

So we decided to question the relevance of Benford's law for Wan governance, Wan optimization and enterprise application delivery.

We took 3 sources of data:

• Some Ipanema configuration files. This is a machine generated file that contains IP addresses, access bandwidth values, natural names and a lot of different technical parameters;
• The Ipanema User Manual, which is a text document of nearly 500 pages that provides all details about this Autonomic networking system;
• … and of course this Wan governance blog since its beginning (not including this post to prevent self-reference situations).

Measured statistics are provided in the graph beside and compared to the values predicted by Benford. We can see that it works quite well, with two notable exceptions:

• Numbers in configuration files have much higher probability to start with a "1" than expected; this may be due to its 'machine generated' nature with many Booleans (0 or 1) and a relatively low rate of natural data and names;
• The User manual has a strange propensity to embed figures starting with a "2" (we even double checked it to get sure). Is it due to a mysterious characteristic of the Ipanema system, a psychological anomaly of the manual writer or do we finally find a notable exception to the Benford's law?

This should be an interesting topic for more investigations...

SYLDAVIA is a great country - but where is the delay?

Sometimes, marketing buzz is really good at creating confusion in people's mind - One may even wonder if it is not its main goal...

I was recently invited to meet the IT infrastructure team of a semi-public organization in a central European country. Let's call it Syldavia (http://en.wikipedia.org/wiki/Syldavia). It is a two or three hundred miles wide country with a few million inhabitants. It is a well organized country, with handsome, friendly and highly educated people. The organization that invited us is in contact with the public. In a nutshell, it runs a network of two datacenters and a few hundreds of branch offices located in Klow (Syldavia's capital) as well as in cities and villages all across the country. The purpose of the meeting was to discuss the various solutions to provide good and sustainable performance to their business applications running at branch offices and hosted in the datacenter.

The first question that raised was: "how could we solve our delay problem?". I must recognize I remained puzzled for a while: Syldavia is a really great country, but certainly not a large one. The maximum distance between datacenters and offices is about 300 kilometers: 1 millisecond at speed of light. Okay, networks are much slower than light (approximately half speed), and we need to add access modems (SDSL in this case); but I doubted the total delay could be much larger than 10ms.

Fortunately, I remembered that Bordurian spies (http://en.wikipedia.org/wiki/Borduria) made a recent attempt to brainwash our Sylvanian friends, using the old good FUD (fear, uncertainty, doubt) tactic: delay here, delay there, everything is about delay, solve this delay problem or you are a stupid manager, etc...

A more objective discussion demonstrated easily that delays, if any, would be caused not by distance but by congestion: saturated device buffers would easily store a few seconds of traffic, leading to poor user experience at branches. Congestion avoidance technologies (like traffic priorization, redundancy elimination or bandwidth upgrades) are then better suited than brute-force acceleration boxes.

To solve this situation, it is clear that a few well-located devices (in data centers and possibly some main offices) would guarantee good and stable performance for all business applications at a much lower cost than deploying Bordurian devices at every branches, with all its associated complexity and cost: it is then possible to satisfy both users and CFO at the same time.

Could I urge you to resist to Bordurian's intelligence services?

Delays are not the root cause of performance, they are symptoms. Real root causes of poor user experience over networks are:

• Geography: distance of long haul networks --> Delays (in the core network) --> Impact chatty applications only --> Protocol acceleration
• Lack of bandwidth (or excess of traffic) --> Congestions --> Delays (in network devices) --> Impact all applications --> QoS, compression, bandwidth upgrades

Viva Syldavia!

10 x 10 = 11

More is more... up to a certain extend. For example, let's have a look to Application Acceleration over the WAN. When you listen to vendors' marketing, it is up to the one that promise the largest possible acceleration (or data reduction) factor: x10, x100, x1000... Who wants more?

Now, back to the reality and consider Mark, an ACME enterprise's employee that works in a branch office, and uses an application which server is hosted in a remote datacenter. Before application acceleration, Mark used to wait 100 sec for the transaction to be completed(I know, this is quite long but it simplifies the discussion).

Deploying vendor Y's technology, Mark gets x10 acceleration factor: now, the waiting time is of 10 seconds, which is far better: the saving is of 90 seconds for each transaction.

Vendor Z comes to Mark's enterprise IT organization and commits to get x100 acceleration factor: 10 times better that Y! What a deal, indeed. After installation, the promise is fulfilled: transaction time goes from 10 seconds down to 1 second: the saving is of 99 seconds per Mark's transaction compared to the initial situation - 10 times better leads to 10% improvement!

I'm not arguing that 100 is not better than 10, but up to which extend, and at which price?

(I let you make the case for vendor W, that is sure to obtain x1000 acceleration factor).