Randomness

The Soft Risks of Social Networking

Lori MacVittie — Thu, 06 Nov 2008 11:10:08 GMT

Just about every large organization, a whole lot of startups, are trying to leverage the potential of social media in their marketing efforts. We all read great articles containing tips and tricks regarding how to use social media for business purposes, and how to gauge whether or not we are successful.

The discussions often ignore the risks, especially the soft risks, of engaging the market and so-called citizen journalists at the Internet's watercoolers.

Soft risks are always part of the equation of the return on investment for a product or piece of software. Soft risks are usually nebulous, incalculable costs that are not necessarily directly related to the function of the solution we are purchasing. These are often things like the potential for the vendor to survive a tougher economy, the investment in learning a new skill or programming language required in order to leverage the new technology solution, and the unknowable costs of integrating with the rest of the infrastructure.

Like investing in a solution, investing in social media has risks, but unlike solutions that are purchased to do a specific thing social media's risks are almost all soft. They are immeasurable and, often times, not obvious.

A recent article, You Better Think Before You Twit, highlighted one of the potential soft risks of social media: the always uncomfortable foot in mouth. Interestingly, this article, while pointing out the potential negative aspects of being always connected to others at the Internet watercooler, kept the focus personal.

But the risks involved in engaging social media in such an informal way can adversely affect the company you represent, and it's important to recognize that risk - and give guidance - before your employees are out tweeting or powncing or plurking or uploading pictures of the company's Christmas party to Flickr.

It's not just the potential slip of the tongue that reveals upcoming product plans or launches, or that gives away potentially sensitive corporate information. Most employees understand the potential harm to the organization such actions can cause and are careful to ensure they don't cross the lines they know exist.

But they aren't so careful about expressing themselves on other subjects because it is, as it were, like hanging around the watercooler. We're just doing it electronically instead of physically. This can be great for remote office and tele-workers for making them feel like a part of the organization, but when the conversation turns to topics of a more personal and sensitive nature, it can backfire on the organization.

When Google CEO Eric Schmidt decided to publicly endorse a political candidate, he may have meant to do so personally, but because he used his position at Google while doing so he made one of the first faux pas of social networking on the job: getting political. Discussions around the web indicated a mix of reactions, some good and some bad. Similarly, Apple's donation of $100,000 to the "No on Prop 8" campaign raised similar objections and support at Internet watercoolers around the country.

In both cases there were reactions that included "I am not buying/using their products anymore because of this." Right or wrong, the reactions were real. Both companies lost customers - or potential customers - over their decisions to dabble publicly in politics. Sure, that number might be minimal, but it might also be more far reaching than either considered. Conversely, their support might have gained them customers. That's why it's called a soft risk, because the effects can't be easily, if at all, quantified.

A long time ago we taught folks that politics and religion had no place in business; that discussing these taboo topics within the confines of the business world was a no-no and dangerous. It was a risk. The same is true for organizations who, unlike Google and Apple, certainly can't afford the negative hits on their reputation across the Internet based on any given employee's public discussions of things best left at home.

The line between professional and personal life is indeed blurring, especially for those who are considered corporate spokespersons, as their opinions on subjects that are outside the realm of technology can be taken as reflecting corporate culture and views on those subjects. It's easy to forget when you're hanging out on Twitter that you aren't just you, you're representing your organization. At the beginning of the hype cycle for the election, @prnewswire lamented a bit on this fact, but wisely decided that not commenting on such things was the only logical thing to do lest the person behind the avatar risk damage to the corporate entity it represents.

And no matter which side you take on divisive topics, someone is going to be angry with that opinion and may choose to take their business elsewhere because of it. And you kids out there, remember, Google is forever (or at least it looks like it will be) and what you say on the ever-archiving web and how you say it will certainly be discovered in 5 or 10 years when your (next) potential employer searches you out to aid in their decision whether or not to hire you.

Before you get all bent out of shape about the potential restriction, remember that when you choose to make yourself a public figure of any kind to any size audience that you are giving up a lot of your privacy and personal flexibility. Becoming an Internet personality sounds great until you realize it can be (and I would argue in many cases should be) a soft muzzle on your personal opinions on touchy subjects.

The rule of thumb when you are engaging folks 'out there' is simple. We call it "social media" for a reason, after all. If you're commenting on blogs, or tweeting, or powncing, or just generally engaging in conversation electronically, it behooves you to remember the "media" in social media, and treat everyone like a potential member of the press rather than as "that cool guy/gal I met on Twitter". If you wouldn't talk to the press about political or religion or other potentially divisive topics, then you probably shouldn't be tweeting about them, either.

Technorati Tags: MacVittie,F5,social media,twitter,pownce,social networking,risks,politics,apple,google,eric schmidt,soft risks,ROI,web,microblogging

The Politics of Load Balancing

Lori MacVittie — Tue, 04 Nov 2008 10:56:34 GMT

If you're in the US, and even if you aren't, it's nearly impossible to ignore the fact that we're in the midst of a presidential election that will be resolved today. And we're quite passionate about the process. That's because the concepts of democracy are ingrained in us from the time we are small children and permeate almost every aspect of our lives, even though we may not realize it.

Even our technology is colored by our belief in the democratic process. Remember token ring networks? If the "leader" (the active monitor) of the token ring failed for some reason, a new "leader" was "elected" from those who were still connected. The process was far from democratic and was, in fact, more feudal in nature but it still used the same political jargon to describe the process.

Similarly, in data centers across the world application delivery controllers (a.k.a. load balancers) balance the responsibility for responding to user requests across farms or pools of servers. In a strange way, the application delivery controller elects one server to be in charge for that request based on a wide variety of parameters: performance history, current performance, and current load (utilization) among the possibilities.

Application delivery controllers use their application awareness to make that decision by querying each server directly and by listening to servers when they share information about their status. Based on all the variables and policies set by the administrator, the application delivery controller elects for each request the server it believes will best serve that user at the time the request is made. It is context-aware, and makes its decisions based on the environment as it exists when the request is made.

As a country we don't elect a new president for each situation we encounter, or each bill that's introduced into Congress, but we do elect a new person to respond to our requests every four years based on a wide variety of variables and policies that we, as individuals, set the parameters for. We are also context-aware, taking into consideration the state of our Union right now as we make the momentous decision of who should be our President for the next four years.

It is our Constitution that determines how often we elect new leaders, and it is the configuration of an application delivery controller that determines how it choose its "leaders of the moment". In order for applications to be delivered as fast and securely as possible it might be necessary to change "leaders" (servers) on every request. Or it might not. The process of choosing a server can be as simple as selecting the next server in a list, or as complicated as a calculus formula. It all depends on the needs of each application.

Your application delivery controller is in your data center, voting every day - every second, every request - to determine which server will best suit the needs of the application it's delivering.

We only vote once a year, and only vote for a new president once every four years. Like your application delivery controller, the process of intelligently determining who should be the new leader requires participation. The default configuration of an application delivery controller is fairly mundane in its decision making process; only by actively configuring it can you get the most benefit out of it for your applications.

Please, take some time out today to vote.

Technorati Tags: MacVittie,politics,F5,application delivery,load balancing,elections,token ring,networks,president

Making Infrastructure 2.0 reality may require new standards

Lori MacVittie — Wed, 22 Oct 2008 10:58:54 GMT

Managing a heterogeneous infrastructure is difficult enough, but managing a dynamic, ever changing heterogeneous infrastructure that must be stable enough to deliver dynamic applications makes the former look like a walk in the park. Part of the problem is certainly the inability to manage heterogeneous network infrastructure devices from a single management system.

SNMP (Simple Network Management Protocol), the only truly interoperable network management standard used by infrastructure vendors for over a decade, is not robust enough to deal with the management nightmare rapidly emerging for cloud computing vendors. It's called "Simple" for a reason, after all. And even if it weren't, SNMP, while interoperable with network management systems like HP OpenView and IBM's Tivoli, is not standardized at the configuration level. Each vendor generally provides their own customized MIB (Management Information Base). Customized, which roughly translates to "proprietary"; if not in theory then in practice.

MIBs are not interchangeable, they aren't interoperable, and they aren't very robust. Generally they're used to share information and are not capable of being used to modify device configuration. In other words, SNMP and customized MIBs are just not enough to support efficient management of a very large heterogeneous data center. As Greg Ness pointed out in his latest blog post on Infrastructure 2.0, the diseconomies of scale in the IP address management space are applicable more generally to the network management space. There's just no good way today to efficiently manage the kind of large, heterogeneous environment required of cloud computing vendors. SNMP wasn't designed for this kind of management any more than TCP/IP was designed to handle the scaling needs of today's applications.

While some infrastructure vendors, F5 among them, have seen fit to provide a standards-based management and configuration framework, none of us are really compatible with the other in terms of methodology. The way in which we, for example, represent a pool or a VIP (Virtual IP address), or a VLAN (Virtual LAN) is not the same way Cisco or Citrix or Juniper represent the same network objects. Indeed, our terminology may even be different; we use pool, other ADC vendors use "farm" or "cluster" to represent the same concept. Add virtualization to the mix and yet another set of terms is added to the mix, often conflicting with those used by network infrastructure vendors. "Virtual server" means something completely different when used by an application delivery vendor than it does when used by a virtualization vendor like VMWare or Microsoft.

And the same tasks must be accomplished regardless of which piece of the infrastructure is being configured. VLANs, IP addresses, gateway, routes, pools, nodes, and other common infrastructure objects must be managed and configured across a variety of implementations. Scaling the management of these disparate devices and solutions is quickly becoming a nightmare for vendors involved in trying to build out large-scale data centers, whether those are large enterprises or cloud computing vendors or service providers.

In a response to Cloud Computing and Infrastructure 2.0, "johnar" points out:

Companies are forced to either roll the dice on single-vendor solutions for simplicity, or fill the voids with their own home-brew solutions and therefore assume responsibility for a lot of very complex code that is tightly coupled with ever-changing vendor APIs and technology. The same technology that vendors tout as their differentiator is what is causing the integrators grey hair.

Because we all "do it different" with our modern day equivalents of customized MIBs it makes it difficult to integrate all the disparate nodes that make up a full application delivery network and infrastructure into a single, cohesive, efficient management mechanism. We're standards-based, but we aren't based on a single management standard.

And as "johnar" points out, it seems unlikely that we'll "unite for data center peace" any time soon: "Unlike ratifying a new Ethernet standard, there's little motivation for ADC vendors to play nice with each other."

I think there is motivation and reason for us to play nice with each other in this regard. Disparate competitive vendors came together in the past to ratify Ethernet standards, which led to interoperability and simpler management as we built out the infrastructure that makes the web work today. If we can all agree that application delivery controllers (ADCs) are an integral part of Infrastructure 2.0 (and I'm betting we all can) then in order to forward adoption of ADCs in general and make it possible for customers to choose based on features and functionality then we must make an effort to come together and consider standardizing a management model across the industry. And if we're really going to do it right, we need to encourage other infrastructure vendors to agree on a common base network management model to further simplify management of large heterogeneous network infrastructures. A VLAN is a VLAN regardless of whether it's implemented in a switch, an ADC, or on a server.

If a lack of standards might hold back adoption or prevent the ability of vendors to compete for business, then that's a damn good motivating factor right there for us to unite for data center peace.

If Microsoft, IBM, BEA, and Oracle were able to unite and agree upon a single web services interoperability standard (which they were, the result of which is WS-I) then it is not crazy to think that F5 and its competitors can come together and agree upon a single, standards-based management interface that will drive Infrastructure 2.0 to be reality.

Major shifts in architectural paradigms often require new standards. That's where we got all the WS-* specifications and that's where we got all the 802.x standards: major architectural paradigm shifts.

Cloud computing and the pervasive webification of, well, everything is driving yet another major architectural paradigm shift. And that may very well mean we need new standards to move forward and make the shift as painless as possible for everyone.

Technorati Tags: MacVittie,F5,standards,Microsoft,VMWare,IBM,Oracle,BEA,HP,OpenView,Tivoli,MIB,SNMP,802.x,IEEE,WS-I,OASIS,INfrastructure 2.0,cloud computing infrastructure,cloud computing,management

Can the future of application delivery networks be found in neural network theory?

Lori MacVittie — Thu, 09 Oct 2008 10:57:04 GMT

I spent a big chunk of time a few nights ago discussing neural networks with my oldest son over IM. It's been a long time since I've had reason to dig into anything really related to AI (artificial intelligence) and at first I was thinking how cool it would be to be back in college just exploring topics like that. Then, because I was trying to balance a conversation with my oldest while juggling my (fussy) youngest on my lap, I thought no, no it wouldn't.

Artificial neural networks (ANN) are good for teaching a system how to recognize patterns, discern complex mathematical relationships, and make predictions based on a variety of inputs. It learns by trying and trying again until the output matches what is expected given a sample (training) data set. That learning process requires feedback; feedback that is often given via backpropagation. Backpropagation can be tricky, but essentially it's the process of determining how far off the output is from the expected output, and then propagating that back into the network so it can essentially learn from its mistakes. Just like us.

If you guessed that this was going to tie back into application delivery, you guessed correctly. An application delivery network is not a neural network, but it often has many of the same properties, such as using something similar to a hidden layer (the application delivery controller) to make decisions about application messages, such as to which server to distribute them and how to best optimize those messages.

More interestingly, perhaps, is the ability to backpropagate errors and information through the application delivery network such that the application delivery network automatically adjusts itself and makes different decisions for subsequent requests. If the application delivery network is enabled with a services-based API, for example, it can be integrated into applications to provide valuable feedback regarding the state of that application and the messages it receives to the application delivery controller, which can then be adjusted to reflect changes in the state of that application. This is how we change the weights of individual servers in the load balancing algorithms in what is somewhat akin to modifying the weights of the connections between neurons in a neural net.

But it's merely a similarity now; it's not a real ANN as it's missing some key attributes and behaviors that would make it one.

When you look at the way in which an application delivery network is deployed and how it acts, you can (or at least I can) see the possibilities of employing a neural network model in building an even smarter, more adaptable delivery network. Right now we have engineers that deploy, configure, and test application delivery networks for specific applications like Oracle, Microsoft, and BEA. It's an iterative process in which they continually tweak the configuration of the solutions that make up an application delivery network based on feedback such as response time, size of messages, and load on individual servers. When they're finished, they've documented an Application Ready Network with a configuration that is configured for optimal performance and scalability for that application that can easily be deployed by customers.

But the feedback loop for this piece is mostly manual right now, and we only have so many engineers available for the hundreds of thousands of applications out there. And that's not counting all the in-house developed applications that could benefit from a similar process. And our environment is not your environment. In the future, it would awesome if application delivery networks acted more like neural networks, incorporating the feedback themselves based on designated thresholds (response time must be less than X, load on the server must not exceed Y) and tweak itself until it met its goals; all based on the applications and environment unique to the organization.

It's close; an intelligent application delivery controller is able to use thresholds for response time and size of application messages to determine to which server an individual request should be sent. And it can incorporate feedback through the use of service-based APIs integrated with the application. But it's not necessarily modifying its own configuration permanently based on that information; it doesn't have a "learning mode" like so many application firewall and security solutions.

That's an important piece we're missing - the ability to learn the behavior of an application in a specific environment and adjust automatically to that unique configuration. Like learning that in your environment a specific application task runs faster on server X than it does on servers Y and Z, so it always sends that task to server X. We can do the routing via layer 7 switching, but we can't (yet) deduce what that routing should be from application behavior and automatically configure it.

We've come a long way since the early days of load balancing, where the goal was simply to distribute requests across machines equally. We've learned how to intelligently deliver applications, not just distribute them, in the years since the web was born. So it's not completely crazy to think that in the future the concepts used to build neural networks will be used to build application delivery neural networks.

At least I don't think it is. But then crazy people don't think they're crazy, do they?

Technorati Tags: MacVittie,F5,iControl,APIs,neural networks,artificial intelligence,application delivery network,application ready network,oracle,microsoft,bea,internet,web,networks,load-balancing

Why Flowgram Beats SlideShare Hands Down

Lori MacVittie — Thu, 25 Sep 2008 18:31:19 GMT

There are a lot of things you can share on the Web today - you can bookmark pages, share pictures on Flickr or twitpic, blast a 12 second audio message out, e-mail links, or post nifty tidbits to your Facebook profile. But rarely do you find an online tool that lets you bring all that disparate content together in one elegant presentation-like format.

Flowgram aims to change the way you share content, by allowing you to mashup multiple media formats into a single, audio-backed "flowgram", sharable across a large number of social networking sites as well as via more traditional channels (IM and e-mail). Flowgram take the presentation paradigm and dresses it up; giving it a hip, trendy look and feel that makes it appealing to just about anyone.

A flowgram is essentially a mashup of content: video, audio, text, presentations, photos, and web pages. Much like a traditional presentation, information is presented in linear fashion and timing of each page is user configurable. Audio can be imported or recorded within the web-based editor. Unfortunately (or fortunately, depending on how you look at it), I'm suffering from a pretty nasty cold and wasn't willing to narrate my flowgram.

A couple of popular Flowgrams that demonstrate the use of more visual media more effectively:

Google Zeitgeist Europe 2008 by Joi
Digg Picks of the Week by brick

After talking to the good folks at Flowgram, viewing a few public Flowgrams, and then creating a couple Flowgrams myself, Flowgram beats SlideShare hands down in ability to mashup different kinds of content and easily sharing presentations along with narration. Bringing in audio, video, and even text to augment or spice up a presentation is a huge advantage that SlideShare can't offer at this time.

Another huge advantage of Flowgram over SlideShare is audio. Unlike SlideShare, Flowgram gives you the ability to keep the audio with the content rather than requiring you to synchronize with a remotely stored audio stream. Flowgram allows you to record audio during the creation process or import and synchronize, which means you won't have to worry that jitter or congestion will throw off that synchronization during playback.

THE GOOD

THE BAD

Imports a wide variety of content, including PowerPoint, PDF, a Word documents, web pages, photos, RSS/Atom feeds, and video
Can create custom text-based pages as well, complete with working hyperlinks
Bookmarklets make the process of inserting live web pages a breeze
Notes can be added to pages for additional info, good for images needing a bit of context

Flowgrams can be easily shared to a wide variety of social networking sites

Rearranging pages is simple - drag and drop

Highlighting of text simple and editable

Can share finished Flowgram as a YouTube video

Can share Flowgrams publicly or privately

Like other web-based solutions, animations in PowerPoint presentations are stripped
Each page in a flowgram is restricted to one type of content. Mixing and matching of content in a single page is not possible, though images can be included in a custom page.

SSL encrypted pages can't be inserted and saved

Notes inserted on pages don't appear in the embedded version of a flowgram

OpenID is not currently supported, though it is on the roadmap

Custom text pages aren't easily readable in embedded versions

Embedded version less impactful and functional in general than full version

For the curious, I whipped out HttpFox (my newest favorite analyzer and FireFox add-on, by the way) and checked out what was going on under the covers. It is, as expected of most Web 2.0/AJAX-based applications, a very chatty application. There's lots of AJAX calls going on to retrieve content and to record API usage statistics.

Custom text and images are transferred as text/html and the appropriate image types, as expected. PowerPoint is apparently converted into SWF, and is served, interestingly enough, by a host named "ppt.flowgram.com".

If you haven't checked it out, head on over and view a few flowgrams or try making one yourself. Whether you are looking for a good way to share images and stories with family and friends, demonstrating how to use an application, or a way to get the message out about your latest widget or gadget, you'll probably find a good way to do it with a flowgram.

Technorati Tags: MacVittie,F5,Flowgram,Slideshare,presentation,audio,video,mashup,application,SaaS,web 2.0,social networking,internet

The worst misuse of the term 'load balancing' ever

Lori MacVittie — Wed, 24 Sep 2008 12:18:26 GMT

I've seen some controversial use of terminology to describe technology before but this one beats them all.

I'm cruising through my Google alerts, looking for something interesting, when I come across this post:

Linux Web Server Hack - How to Write Automated Load Balancing Script!

Sounds cool, right? I like Linux. I like hacks. I like load balancing. So, much to my chagrin now, I read it.

The script isn't the problem, it's really quite nice - I love a well-written script, especially one that makes use of awk - and it definitely solves the issue described by the author. The problem is the use of the term "load balancing" to describe a script that kills a web server when load is too high.

Let me repeat that just to make you sure you heard me. The "load balancing" script kills the web server when load is too high.

Maybe it's just me, but I was under the impression that the term load balancing was used to describe a technology that keeps web servers available and running under load. Taking them down would be, like, the opposite of what a load balancing "thing" is supposed to do.

I'm pretty sure my head is going to explode over this one. Seriously, I'd back away from the screen if I were you.

If I don't post again, you know why.

Technorati Tags: MacVittie,F5,load balancing,Linux,scripts,misuse,web,internet,terminology

Corporate Blogging: The Fallacy of Quantity vs Quality

Lori MacVittie — Mon, 22 Sep 2008 18:46:35 GMT

As a corporate blogger I rarely post "off topic". There's a reason for that, and a reason why I'm doing so now. The core reason for doing so now is that it's a subject that's near and dear to me, having spent the majority of the past eight years writing and blogging in publishing and on the corporate side of the table, and I see far too many posts out there offering advice about blogging that's focused solely on "getting more hits". While that might be sound advice for personal blogs, it's off-key when it comes to corporate efforts.

There is a belief, and it's wrong, that more is better - whether it's more posts or more hits - when it comes to corporate blogging. In fact, the opposite is true: quality is more important - whether it's readers or posts - than quantity.

To understand the fallacy of quantity vs quality you first have to understand the history of trade publishing, and why it's suffered so much financial pain. Don touched on this briefly, having also spent a lot of time in the publishing industry (we like to work together, thank you, I know it's weird, but that's the way we are) but I'm going to expand further on the topic.

Back in the old days (print) trade publications and, if we're honest, newspapers, were all based on one of three revenue models: advertising, subscriptions, or a hybrid of both. Magazines that subsisted on advertising only managed to do so by qualifying their circulation base, thus ensuring advertisers that they were paying those high rates because the reader-based was primarily their target market.

When the Web exploded everyone demanded "free" content, including from trade publications and newspapers. The publishing industry was a bit confused and wasn't certain how to respond to the move to the web because the revenue model wasn't the same. An anonymous page view of an article is hardly equivalent to a well-qualified reader, and thus advertising revenue on the web was seriously impacted. Advertisers were no longer willing to pay the same rate for "views" because they couldn't be certain of the value of that page view; they couldn't qualify it as being part of their target market.

Advertising rates plummeted, and trade publications - and newspapers - began to drop faster than the waistlines of girls' jeans over the past few years.

The publishing industry as a whole floundered for a time, until it started to implement more gated content. Gated content requires you to provide certain pieces of information during the registration process before you're allowed to see the content. Some of that information is, not coincidentally, similar to that traditionally found on a qual card - the card you filled out to see if you're qualified for a "free" subscription to a trade publication. This model breathed new life into publishing, as advertisers are much more willing to sponsor micro-sites or pay higher rates for advertisements on specific types of gated content because they are more confident about the quality of the page view.

Corporate blogging is becoming nearly a mandate for many organizations. Its value in promoting brand awareness, thought leadership, and market education cannot - and should not - be underestimated. But it is easy to fall into the trap of correlating quantity of hits to success; e.g. a thousand hits on a blog post is better than a hundred hits on a blog post, posting every day is better than two or three times a week. Quantity is often considered more important than quality.

As the publishing industry has come to understand, and as corporations should already know because they drove the industry to understand it, the quantity of page views is less relevant than the quality of the reader, and a few good posts are better than many mediocre or irrelevant posts.

It's actually fairly easy to write a post that will make the front page of Digg, or make it onto Slashdot and generate a ton of hits. Unfortunately for most corporate bloggers the kinds of posts that generate that kind of traffic and interest are rarely related to their industry and thus do not forward corporate blogging goals of brand awareness, education, or thought leadership which, in most cases, should be relevant to the industry in which a corporation operates. Unfortunately, a post exhorting the benefits of a CRM or an application delivery controller or a BI suite are just unlikely to engender that kind of attention.

Relevant, engaging content that educates and forwards corporate goals should be the goal for corporate blogging efforts. Hit counts, while certainly nice, have been proven by the trials and tribulations of the publishing industry to be an unreliable measure of success and do little for the corporation unless it's well understood where the hits are coming from.

Yes, writing relevant content often results in a lower hit count, one of the challenges discussed by Jeremiah Owyang in "The Many Challenges of Corporate Blogging". I write primarily on the subject of application delivery - from security to optimization to acceleration. It isn't, for the most part, controversial, nor is it as exciting as politics so its reach and audience is much smaller than, say, something of interest to the masses. But I've learned from long experience in publishing hits from the masses aren't likely to help "forward the cause". A page view from Sally in finance is unlikely to ever really be of value because she isn't involved in IT, would likely not understand the relevance of application delivery to the applications she uses at work, and isn't likely to discuss high availability or load balancing with the guys in IT or even be able to suggest or influence the option - she probably doesn't even know IT is looking into it.

The page view from Sally is virtually worthless in terms of achieving corporate goals. The problem is that it's impossible to know if a page view came from Sally or from the CIO or IT manager responsible for architecting an application delivery network.

Targeted, relevant content does a much better job of qualifying readership than general, unrelated topics. Readers of a post on cloud computing or virtualization are likely to be interested in the technology and thus their hits are both valuable and desired.

But what about brand awareness? Don't we want to get our brand "out there"?

Yes, and no. You want your brand out there, certainly, but you want it out there amidst people who will actually do something with that knowledge. You want to attract and educate non-customers who could be customers, not non-customers who will never, ever in a million years be customers. Mass advertising and blogging might work for a brand like GM or Apple, whose products are targeted at, well, everyone. But while John Q. Farmer might enjoy listening to an iPod while he's out riding his combine, he isn't likely to give a hoot about application delivery or information security or how awesome the latest SSL VPN might be.

Blogs cannot - and should not - go the way of traditional publishing. We can't gate the content, that does us and readers a disservice. But in order to quantify success of corporate blogging initiatives it is important to qualify, somehow, whether we're reaching the audiences we want to reach. The best way to do that is to artificially gate readership through relevant, quality posts.

Choose quality over quantity. Qualify through relevancy. Let's not repeat the painful process publishing had to experience to arrive where we're at today. Don't get sidetracked from your goals by lower hit counts than you'd hoped. If you're writing quality posts and seeing little growth, you may need to reach out to your audiences rather than let them come to you. Syndication, participation in appropriate social networking sites, link and bookmark sharing, etc... are all ways to reach out to and get your content in front of the appropriate audiences.

What you want to see is consistent growth - even if it's small - over time in not only hit counts but referrals and returning and new visitors as well as lower exit and bounce rates. Hit count is only one factor that contributes to a complex calculation quantifying "success". As long as you're staying on focus and growing, you're doing it right and adding value and you can be more sure that the hits you are getting are worth the effort you're putting forward.

Technorati Tags: MacVittie,F5,blogging,corporate blogging,jeremiah Owyang,gated content,publishing,media,metrics,measurement,qualification,social media,web 2.0,blogs

Cloudware and information privacy: TANSTAAFL

Lori MacVittie — Mon, 15 Sep 2008 14:07:00 GMT

Ars Technica is reporting on a recent Pew study on cloud computing and privacy, specifically concerning remote data storage and the kind of data-mining performed on it by providers like Google, indicates that while consumers are concerned about the privacy of their data in the cloud, they still subject themselves to what many consider to be an invasion of privacy and misuse of data.

68 percent of respondents who said they'd used cloud services declared that they would be "very" concerned, and another 19 percent at least "somewhat" concerned, if their personal data were analyzed to provide targeted advertising. This, of course, is precisely what many Web mail services, such as Google's own Gmail, do—which implies that at least some of those who profess to be "very" concerned about the practice are probably nevertheless subjecting themselves to it.

One wonders why those who profess to be very concerned about privacy and data-mining tactics used by cloudware providers would continue to use those services?

One answer might lie in the confusing legalese of the EULA (end user license agreement) presented by corporations.

Where's F5?

VMWorld
Sept 15-18 in Las Vegas
Storage Decisions
Sept 23-24 in New York
Networld IT Roadmap
Sept 23 in Dallas
Oracle Open World
Sept 21-25 in San Francisco
Storage Networking World
Oct 13-16 in Dallas
Storage Expo 2008 UK
Oct 15-16 in London
Storage Networking World
Oct 27-29 in Frankfurt

It's necessary, of course, that the EULA be written using the language of the courts under which it will be enforced. But there are two problems with EULAs: first, they aren't really required to be read and second, even if they were really required to be read, they can't be easily understood by the vast majority of consumers.

I'll be the first to admit I rarely read EULAs. They're long, filled with legalese speak, and they always come down to the same basic set of rules: it's our software, we don't make any guarantees, and oh, yeah, any rights not specifically listed (like the use of the data you use with our "stuff") are reserved for us. It's that last line that's the killer, by the way because just about everything falls under that particular clause in the EULA.

Caveat emptor truly applies in the world of cloudware and online services. Buyer beware! You may be agreeing to all sorts of things you didn't intend.

The argument against such privacy and security assurances for consumers is that they aren't paying for the service, therefore the provider needs some way to generate revenue to continue providing the service. That revenue is often generated by advertising and partnerships, but it's also largely provided by selling off personal information either directly gleaned from users or mined from their data. Which is what Google does with GMail.

Enterprises, at least, are not only aware of but thoroughly understand the ramifications of storing their data "in the cloud". SaaS (Software as a Service) has had to provide proof positive that the data stored in their systems are the property of the consumer, that the data is not being used for data-mining or sharing purposes, and that security is in place to protect it from theft/viewing/etc...

But in between the consumer and the enterprise markets lies the SMB, the small-medium business. Not quite financially able to afford a full data center and IT staff of their own, they often take advantage of cloudware services as a stop-gap measure. But in doing so, they put their business and data at risk, because they aren't necessarily using cloudware designed with businesses in mind, at least not from a data security perspective, and that means they are often falling under the more liberal end-user license agreement. All bets are off on the sanctity of their data.

TANSTAAFL. There ain't no such thing as a free lunch, people, and that has never rang as true as it does in the world of cloudware and online services. If it's heralded as "free" that only means you aren't paying money for it, but you are bartering for the service; exchanging your personal information and data for the privilege of using that online service.

In many cases folks weigh the value they receive from the "free" service against divulging personal information and data and make an informed choice to exchange that information for the service. When that's the case - the consumer or business is making an informed choice - it's all good. Everybody wins.

Bartering is, after all, the oldest form of exchanging goods or services. And it's still used today. My grandmother paid her doctor three chickens for delivering my father, and that was in the mid 1900s, not that long ago at all. So exchanging personal information and access to your data for services is completely acceptable; just make sure you understand that's what you're doing - especially if you're a business.

Technorati Tags: MacVittie,F5,TANSTAAFL,cloudware,cloud compuitng,saas,google,data,privacy,security,compliance

Is the URL headed for the endangered technology list?

Lori MacVittie — Thu, 04 Sep 2008 11:52:35 GMT

Jeremiah Owyang, Senior Analyst, Social Computing, Forrester Research, tweeted recently on the subject of Chrome, Google's new open source browser.

Jeremiah postulates:

Chrome is a nod to the future, the address bar is really a search bar. URLs will be an anachronism.

That's an interesting prediction, predicated on the ability of a browser translate search terms into destinations on the Internet. Farfetched? Not at all. After all, there already exists a layer of obfuscation between a URL and an Internet destination; one that translates host names into IP addresses, hiding the complexity and difficult in remembering IP addresses from the end-user. And apparently Chrome is already well on its way to sending URLs the way of the dodo bird, otherwise we wouldn't be having this conversation.

But IP addresses, though obfuscated and hidden from view for most folks, aren't an anachronism any more than the engine of car. Its complexity, too, is hidden from view and concern for most folks. We don't need to know how the engine gets started, just that turning the key will get it started. In similar fashion, most folks don't need to know how clicking on a particular URL gets them to the right place, they just need to know to click on it.

Operating technology doesn't necessarily require understanding of how it works, and the layer of abstraction we place atop technology to make it usable by the majority doesn't necessarily make the underlying technology an anachronism, although in this case Jeremiah may be right - at least from the view point that using URLs as a navigation mechanism may become an anachronism. URLs will still be necessary, they are a part of the foundation of how the web works. But IP addresses are also necessary, and so is the technology that bridges the gap between IP addresses and host names, namely DNS.

More interesting, I think, is that Jeremiah is looking into his crystal ball and seeing the first stages of Web 3.0, where context and content is the primary vehicle that drives your journey through the web rather than a list of hyperlinks. Where SEO is king, and owning a keyword will be as important, if not more so, than brand. The move to a semantic web necessarily eliminates the importance of URLs as a visible manifestation, but not as the foundational building blocks of how that web is tied together.

To be fair to other browsers, the address bar in FireFox 3 also acts like a search bar. If I type in my name, it automatically suggests several sites tied to my identity, and takes me by default to this blog. Similarly a simple search for "big-ip" automatically takes me to F5's product page on BIG-IP. That's because my default search engine is Google, and it's taking me to the first ranked page for the search results. This isn't Web 3.0, not yet, but it's one of the first visible manifestations we have of what the web will eventually become.

That's what I mean about keywords becoming the new brand. Just as "bandaid", which is really a brand name, became a term used to describe all bandages, the opposite will happen - and quickly - in a semantic web where keywords and phrases are automatically translated into URLs. SEO today understands the importance of search terms and keywords, but it's largely a supporting cog in a much larger wheel of marketing efforts. That won't be true when search really is king, rather than just the crown prince.

But URLs will still be necessary. After all, the technology that ties keywords and search terms to URLs requires that URLs exist in the first place, and once you get to a site you still have to navigate it. So while I'm not convinced that URLs will become a complete anachronism, they may very well become virtualized.

Just like everything else today.

Technorati Tags: MacVittie,F5,Jeremiah Owyang,Forrester,URLs,DNS,IP,web,internet,http,Google,Chrome,Firefox,browser,virtualization,obfuscation

Congratulations! You are a moron

Lori MacVittie — Fri, 15 Aug 2008 16:34:23 GMT

Dear Internet Tough Guy,

You know who you are. You're the individual who has an insecurity complex, probably due to a sad childhood, the story of which no one is really interested in hearing. You're the troll that prowls technology blogs and forums looking for someone to voice an opinion with which you disagree just so you can tell them they're an (idiot|moron|fool) without any context or reference.

You're the person who posts comments without leaving a name, e-mail address, or website because deep down you're afraid of voicing your opinion (insults) without hiding behind the digital equivalent of mommy's apron: anonymity.

You add nothing of value to the conversation. Your observations are little more than school-yard bullying, comprised of name calling and vitriol for which you'd likely receive a good mouth washing if your mother heard you.

You're the individual that makes other people question the usefulness of the Internet.

You've left some comments on posts here calling other posters and bloggers such creative names as "moron". Comments here are moderated, by the way, so if they actually appear online it's because they've been "approved". In the past, I've generally allowed such comments to be posted, but as of today - no more.

I've spent eight long years in the public eye. Writing for trade publications, authoring books, and blogging. I'm tired of hearing from you, Mr. Internet Tough Guy, with your potty mouth and your bad attitude and your insults. I've heard it all in those eight years, some of it more than once. I'm tired of it. So I have two choices: stop interfacing with the public or stop you from interacting with the public, at least in any setting over which I have control.

I've decided I'm not ready to quit, so guess which option that leaves?

If you want to disagree with me, please do. If you want to point out an error in logic, or a poor assumption, or a better technology - please do so. If you want to disagree passionately, go for it. But if the entire substance of your e-mail, forum post, or comment on a blog is "you are a moron", don't waste your time because it's not going to see the light of day.

I know this is hard, Mr. Internet Tough Guy, but think before you post. If you wouldn't say it with your mother looking over your shoulder, then it's likely you shouldn't post it.

And if you don't want people knowing you said it, then you definitely shouldn't post it at all.

Technorati Tags: MacVittie,social networking,internet,blogs,forums,internet tough guy,moron