We've all seen cloud computing discussed ad nauseam on blogs, on Twitter, Quora, Stack Exchange, your mom’s Facebook page... you get the idea. The tech bloggers and performance experts often pipe in with their graphs and statistics showing clearly that dollar-for-dollar, cloud hosted virtual servers can’t compete with physical servers in performance, so why is everyone pushing them? It's just foolhardy, they say.

On the other end, management and their bean counters would simply roll their eyes saying this is why the tech guys aren't running the business.

Seriously, why the disconnect?

Quite simply, they have very different agendas. The operations team is trying to deliver application speed, reliability, and scalability. Meanwhile the management team is trying to balance cash flow, capital investments and operating expenses, all this while retaining as much flexibility in decision making as possible.

Sound familiar? Yes, the bottom line for both are the same, but they approach the problem from two different sides.

After hearing this refrain from enough customers, I realized the question we were asking in operations was the wrong question. It is true that cloud servers do not perform as well as traditional servers -- at least not yet. The question that one should ask is, given this performance constraint with virtual servers, how can I alleviate the performance limitations of virtual servers and storage but still deploy into the cloud?

A little bit of history

Anyone who's been around computing since the mid 1990’s will see where I'm heading with this. Commoditization of computing, that's where. In the late nineties there was a big shift happening. In the 1990’s as Linux was maturing, commodity servers became all the rage. A big shift began to happen which drove cheaper PC hardware into the datacenter. Where once Sun stood supreme, suddenly all these upstarts were pushing crappy commodity hardware at 1/10th of the cost.

Old-guard systems administrators  at that time would balk, telling you how the stuff wasn't reliable, performance was worse, and they just failed too often. And you know what? They were right! Nevertheless look where we are today. Linux barreled through the datacenter because it lowered costs and introduced flexibility by giving you more choices and more redundancy.

All this rings very true today with the push to the cloud. Startups are the biggest adopters of cloud computing because the future is mostly unknown to them. Investing a quarter million dollars in hardware today when you don't know where you'll be in six months - that's a very hard prospect to entertain.

But cloud computing more than just lowers cost. Don't have the money for redundant servers to support Disaster Recovery? With Amazon EC2 you simply write scripts to rebuild your infrastructure and keep them handy when such an ill-fated day arrives. Flexibility, scalability and easier cost management. That's what the cloud delivers.

Walking around New York you find yourself stopping at plenty of different places to grab some takeout for lunch. There are Vietnamese sandwich places, pizza shops, noodle bars, taco stands, juice bars and of course your daily coffee shop. You'll find an endless variety.

As is customary in New York, even for takeout there is usually a tip jar at the checkout. Many of them have a large bowl, or glass jar in which you can throw your change as tips, or if you really love the place and service, a couple of dollars.

Of late I've noticed a few have placed those small plastic boxes with a tiny slot on the top. You try to put some change in the slot, and half of the money falls on the floor. It's as frustrating as threading a needle while suffering from astigmatic vision. Now when I come to a place that has this plastic box, I don't even bother tipping. I get a headache thinking about my change falling all over the floor. All I keep thinking is, why make it so difficult to tip?

Lessons from tipping

There're business lessons here to be sure. The most obvious being, when working with clients, make it easy for them to pay you. Don't ask them to jump through hoops to settle a bill. That goes just as well for complicated costs and itemization. Keep your invoices as simple as possible, so it's clear later on what it covers; the amount and the period. Do they like to pay by ACH or Wire, make that easy as well. Would they rather pay by Paypal? Perhaps have a carrier pigeon with a check? No problem!

This lesson might also be applied to add-on features and services. In many cases a client may require additional time or service from you. Does this involve a lot of approvals or details to be hashed over? Or is it already covered in your base contract so you both know what qualifies and how it will be billed? If you are in the design business, what's the cost of an additional design version or proof? Web operations, what's the cost of adding in another on-site day or weekend block of time?

We may not realize it but sometimes we fumble in the process of acquiring new business too. Recently I was looking to hire a web developer for a website facelift project. I liked the work of one of the applicants and tried to arrange for a quick chat over Skype. To my surprise they said they couldn’t get on Skype because they didn’t have an account. Granted they did offer to call me on my mobile but I’d also wanted to set up a three-way conference call. As a prospective client, I was amused at having to make the suggestion that they register for Skype in order to arrange the call. Someone more on the ball would’ve just said OK, and sign up for Skype right away.

Ultimately the lesson is to think in your customers’ shoes make it easy for your client to reward you when they're happy with your service, and want to buy more of what you are selling.

Strip by Randall Munroe; xkcd.com

First things first. This is not meant to be a beef against developers. But let’s not ignore the elephant in the living room that is the divide between brilliant code writers and the risk averse operations team.

It is almost by default that developers are disruptive with their creative coding while the guys in operations, those who deploy the code, constantly cross their fingers in the hope that application changes won’t tilt the machine. And when you’re woken up at 4am to deal with an outage or your sluggish site is costing millions in losses, the blame game and finger-pointing starts.

If you manage a startup you may be faced with this problem all the time. You know your business, you know what you're trying to build but how do you find people who can help you build and execute your ideas with minimal risk?

Ideally, you want people who can bridge the mentality divide between the programmers eager to see feature changes, the business units pushing for them, and the operations team resistant to changes for the sake of stability.

DevOps - Why can’t we all live together?

The DevOps movement is an attempt to bring all these folks together. For instance by providing insight to developers about the implications of their work on performance and availability, they can better balance the onslaught of feature demands from users with the business’ need for up-time.

Operations teams can work to expose operational data to the development teams.  Metrics collection and analytics aren’t just for the business units anymore. Employing tools like Cacti, OpenNMS or Ganglia allow you to communicate with developers and other business units alike about up-time, and the impact of deployments on site availability, and ultimately the bottom-line.

Above all, business goals and customer needs should underscore everything the engineering team is doing. Bringing all three to the table makes for a more cohesive approach that will carry everyone forward.

How to spot a DevOps person - Finding the sweet spot

The DevOps person is someone with the right combination of skill, knowledge and experience that places him or her in the sweet spot where quality assurance, programming skills and operations overlap.
There are also a few distinguishing characteristics that will help identify such an ideal candidate.

Look for good writers and communicators

Imagine the beads of sweat forming when a developer tells you: “We’ve made the changes. Nothing is broken yet.”
This is like stepping on glass because it implies something will actually break. The point is savvy developers should be aware that the majority of people do not think along the same lines as they do.
Assuming your candidate has all the required technical skills, a programmer with writing skills tends to be better at articulating ideas and methods coherently. He or she would also be less resistant to documentation and be able to step back somewhat from the itty-bitty details. Communication, afterall is at the core of the DevOps culture where different sides attempt to understand each other.

Pick good listeners

Even rarer than good writers are good listeners. Being able to hear what someone else is saying, and reiterate it in their own terms is a key important quality. In our example, the good listener would probably have translated ‘nothing is broken yet’ into “the app is running smoothly. We didn’t encounter any interruptions but we’ll keep watch on things.”

Lean towards pragmatists and avoid the fanatics

We all want people who are passionate about something but when that passion morphs into fanaticism it can be unpleasant. Fanaticism suggests a lower propensity to compromise. Such characters are very difficult to negotiate with. Analogously in tech, we see people latch on to a certain standard with unquestioning loyalty that's bafflingly irrational. Someone who has had their hand in many different technologies is more likely to be technology agnostic, or rather, pragmatic. They'll also have a broader perspective, and are able to anticipate how those technologies will play together.  Furthermore a good sense of where things will run smoothly and where there will be friction is vital.

Pay attention to extra-curricular activities

Look at technology interests, areas of study, or even outside interests. Does the person have varying interests and can converse about different topics?  Do they tell stories, and make analogies from other disciplines to make a point?  Do they communicate in jargon-free language you can understand?

Sniff out those hungry for success

As with any role, finding someone who is passionate and driven is important.  Are they on-time for appointments? Did they email you the information you requested? Are they prepared and communicative?  Are they eager to get started?

Hiring usually focuses on skills and very well-crafted resumés but why do you still find some duds now and then? By emphasizing personality, work ethics, and the ability to work with others, you can sift through the deluge of candidates and separate the wheat from the chaff for qualities that will surely serve your business better in the long run.

Stumbling onto 800-CEO-Read, and their top books feature, I found Brogan and Smith's work.  Brogan's blog intrigued me enough so I walked down to the Strand here in NYC to pick up a copy.

What I found was an excellent introduction to the nebulous world of social media marketing, where you find all sorts of advice and suggestions on how to engage your target audience.  If you're feeling like an ignoramus on matters of social media, Trust Agents is a great place to start and will give you ideas of how to 'humanize' your digital connections.

The authors illustrate the Trust Agent idea with Comcast Cares for example and how they engaged customers, and what worked so well for them.  Or Gary Vaynerchuk and his game changing Wine Library TV about wine.  He also emphasizes that building relationships online is a lot like building relationships in the real world a la Keith Ferrazzi of Never Eat Alone fame.  Engage in meaningful ways with people, don't market to them. Share valuable tidbits, and the community will reward you tenfold.

A 'trust agent'  lives by six principles:

1. Make your own game - be willing to take risks and break from the crowd
2. Be 'One of Us' - be part of the community by doing your bit and contributing to it
3. The Archimedes Effect - leverage your own strengths wisely
4. Agent Zero - position yourself at the center by connecting people and groups
5. Human Artist - learn how to work with people; help others and be conscientious of etiquette
6. Build an Army - you need allies to help spread your ideas

The book is excellent.  Put it on your holiday list.

What do you do after founding not one, but two companies and watching them fail miserably all by the time you were barely out of college?

Move to the Valley, make shrewd investments in other startups and become insanely rich like Sean Parker? A Bit lofty perhaps. How about try, try again and succeed. Then reinvent yourself as a guru dishing out startup wisdom through your blog and publishing a book that ends up the top of the New York Times Bestseller's list. That's essentially what Eric Ries, author of The Lean Startup did.

True entrepreneurs fail many times before they succeed and continuously find opportunities to reinvent themselves. Ries is one of them. He's taken all that he's learned from his failures, and later successes, from his college years in the 1990s right through the dotcom crash, and packaged them into a guide for startups to consult in their quest for world domination. 

Like any business or management book that wants to capture readers' attention The Lean Startup has ground-breaking ideas or rather something that challenges traditional thinking.

How to be lean and light-footed

One of  the main themes is that startups can stay lean and light-footed - and in the process avoid millions of dollars in sunk costs on failed ideas - by  discovering what customers want as they are developing the product itself. Ries advocates a Minimum Viable Product, that is when rolling out new products companies can already run and even charge, before they decide whether the blue or the red version is going to sell more. From there on the process of improving and perfecting the product is a continuous one through listening to what customers want, although not through their written feedback but rather through their actions. This favors scientific methods of decision-making over what is viewed as failure prone hunches and guess work. And it makes sense for startups who simple don't have the financial resources to take big risks.

Written in simple down-to-earth prose, The Lean Startup is an easy and quick read with sufficient real world examples. The good thing about books these days is they don't have to end up as dated publications. Since Ries is building a brand around the whole methodology, one can find additional resources and discussions it in his blog (where it all began anyway), and through Lean Startup circles and wikis.

Recently at Surge 2011, the annual  conference on scalability  and performance, Google's CIO Ben Fried gave an illuminating keynote address. His main insight was that generalists are the people that will lead engineering teams in successfully scaling the web.

Help! How To Become Slightly Happier and Get a Bit More Done

I've long overcome that sheepish feeling when browsing the Self-help section at the bookstore. Sure, How to Make Friends and Influence People or the Seven Steps to World Domination in your bookcase aren't exactly the sort of titles to suggest a deep intellect but I like to keep an open mind when checking out the latest hardcover secret to happiness and prosperity. Basically I try not to diss a book just because it's got "soup" on the cover.

I will concede that publishers have gone a bit overboard with churning out the number of self-help titles in the last 20 years or so. As with anything that proliferates you're stuck with having to wade through the swamp of well, BS. HELP! How to Become Slightly Happier and Get a Bit More Done by Oliver Burkeman is ideal for those curious enough about self-improvement but too cool to buy into mind-body-soul mantras.

Since 2006 Burkeman has been writing a column in The Guardian, self-mockingly titled, This Column Will Change Your Life. It has garnered a large enough following and accumulated a substantial amount of content to warrant a book version or if you like, a best-of collection.

Approaching the subject with rational skepticism, Burkeman has made it his mission to sort through the best and the worse of self-help literature to tell us what works and what doesn't. He doesn't hesitate to call out the snake oil salesmen nor does he dismiss all self-help advice as hokum because he genuinely believes there is something we can all learn from research in human-happiness, however flawed.

I reckon Burkeman's greatest achievement is his ability to strip down what has been pedaled as new enlightenment by the self-help gurus, into realistic terms with wry humor and wit. I say realistic, because he reminds us that self improvement is a lifelong project for anyone who cares to make the effort, and it would be ridiculous to take a prescriptivist approach. From managing your inbox to procrastinating less, the topics he tackles are easy to relate to; for example, why your friends' Facebook statuses usually make their lives seem more awesome than they actually are or his explanation of the Color of the Bike Shed phenomenon, where the time spent on any item is inversely related to its cost and importance.

Although I sometimes wonder why buy a book when you can read all its contents online, Burkeman's writing has obviously been compelling enough for its publishers to re-release the title with a new so-called mass-market cover (notice the cute belly-up turtle). Even if it doesn't change your life, HELP! will definitely entertain.

Restaurant Scalability

Could pro-waitering serve up some lessons on web scalability? Observing peak hour dining at a New York restaurant gave us some insight.

I was dining at a restaurant the other day with friends. It was a warm and cozy place, nicely decorated with a long, narrow dining room.  The food was scrumptious, yet we were getting increasingly frustrated by the service as the night went along.

With some waiting experience behind me, I could immediately see the problem. The waiters, probably through lack of experience, were making the mistake of doing one thing at a time.  They would go to a table, respond to one customer's request, and go and fetch that item.  Back and forth, back and forth they would dart, but always dealing with one request at a time.

As the night got busier the demands began weighing in, like the insidious lactic acid build-up in a distance runner. Soon the incessant gesturing and requests from diners would turn the once beaming, confident servicemen into distressed drones evasive of eye-contact for fear of having to fulfill yet another request for a water top-up.

I knew how they felt because this happened to me many times when I first learned to wait tables.  Until a seasoned veteran waiter showed me how it was done I used to scamper about like a headless chicken. He explained to me that I should enter the dining room, look up, walk to each table and see if they needed anything.  Each time walking around to all the tables in my station, I would then return to fetch many requests all at once.  A fork or napkin for this customer, a glass of wine or condiments for another.  I would then put all of those items on my tray and return to satisfy all those requests in parallel.

Observing the waiters that night, it struck me that this is very much what web scalability is about.

Serialization

Serialization in web applications for example is like when the waiter fetches only one item at a time.  So-called decoupling of services is like delegating out the table cleanup to a busboy so you can concentrate more on customers.

Complex Infrastructures

Gordon Ramsay often makes his first move paring down the menu.  Complex menus can be confusing to customers, but they can also complicate things in the kitchen and thereby reduce quality.  So too can complicated infrastructures.  Years ago we had a client whose environment included two different webservers (nginx and Apache), three programming languages (Python, Ruby, and PHP), inconsistent versions across them and load balancing only across apache.  If that wasn't enough they had MySQL databases scattered randomly across machines, some of which were not backed up.   This kind of complexity breeds all sorts of problems.

Be Mindful of Scaling 

While developing your application, bake scalability into the mix.  Include multiple database handles for read and write databases.  Back to our restaurant analogy;  this is similar to opening shop in a building that has a adjacent vacant unit available.  As your business grows, you can occupy that additional space fairly easily because you put a little extra thought into your location at the beginning.

Shoe leather cost is similar to opportunity cost.  It refers to the cost of counteracting inflation by keeping less of your assets in cash.  Your strategy would require more trips to the bank and more walking, and incur a cost in the wearing out of the leather in your shoes.

All joking aside, it's an interesting idea.  It highlights how there are all sorts of hidden costs to different strategies.  There are hidden costs to using coupons, loyalty cards, frequent flyer miles, managing assets & investments, hiring resources and in general running a business.  Let's look at a few.

Cost of R&D

Years ago I wanted to open a mutual fund and did some research.  Luckily a friend pointed me towards Vanguard, and I got on the index investing bandwagon early.  I've had a lot of opportunities to buy stocks directly, but I've seen too many surprises in the market even in areas of tech stocks and business that I understand very well.

What's more stock investing requires attention, research into fundamentals, and certainly a bit of luck.  In my case my background is engineering, so finance is not my strong suit.  In effect there is more cost hidden there, getting up to speed in a new discipline and the many hidden surprises and fine print.

By choosing an index fund strategy you track the market, are guaranteed to beat 90% of stocks and mutual funds over time, pay a very very small fee as those funds are not actively managed by a fund manager with costs and overhead.  What's more the shoe leather cost is very low.   It's a no brainer.

Cost in People Search

Whatever technologies you choose, you embark down a path with costs on all sides.  Costs of hardware & software components, costs of licenses, and costs to find people with those skill sets.  Deciding to use the latest wiz-bang technology as an early adopter that looks like it will provide you a lot of extra bang for your buck.

Consider carefully what the market adoption of that technology is, as you will inevitably have to find resources skilled in servicing those components down the line.  Lean heavily toward widely adopted technologies and you'll have an easier time finding skilled technologists in the future.

Not Your Core Business

Early on publishing our newsletter, we chose to host the newsletter software ourselves.  The open-source solution was robust and full featured.  However many of the features proved cumbersome to configure.  Since we had the basic functionality working, we left the more complex switches alone.  This solution was a free one since we already hosted a server for the website.

Eventually we switched to mailchimp.com to host the newsletter.  Suddenly many hidden costs came to light.  By hosting ourselves we were ending up in spam folders for a lot of users.  So we were reducing our audience.  Plus we could not track who was reading the newsletter, which issues were popular, or what sections.  That analytical data provide invaluable.  What's more mailchimp integrates and automates a lot of other functions that were done manually before.  Freeing up time!

To Sum Up

Whenever you are spending inordinate time on something that is not your core business, chances are the shoe leather cost is high, and outsourcing that to a provider who specializes in that become a great cost saver.

Best Practices, the term we hear thrown around a lot.  But like going on that new years diet, too often ends up more talk than action.

Manage Processes

Operator error ie typing the wrong command is always a risk.  Logging into the wrong server to drop a database or typing the dump command such that you dump data into the database, these are risks that operations folks face everyday.

Accountability is important, be sure all of your systems folks login to their own accounts.  Apply the least privileges model, give permissions on an as needed basis.

Set prompts with big bold names that indicate production servers and their purpose.  Automate repetitive commands that are prone to typos.

Don't be afraid to give developers read-only accounts on production servers.

Communicate Clearly

Regular team meetings, a la the Agile stand ups are a great way to encourage folks to communicate.  Bring the developers and operations folks together.   Ask everyone in turn to voice their current todos, their concerns and risks they see.  Encourage everyone to listen with an open mind.  Consider different perspectives.

Communication is a cultural attribute.  So it comes from the top.  Encourage this as a CTO or CIO by asking questions, communicating your concerns, repeat your own requests in different words and paraphrase.  Listen to what your team is saying, repeat and rephrase those concerns, and how and when they will be addressed.

Document Processes

A culture of documenting services, and processes is healthy.  It provides a central location and knowledge base for the team.  It also prevents sliding into the situation where only one team member understands how to administer critical business components.  Were that person to be unavailable or to leave the company, you're stuck reverse engineering your infrastructure and guessing at architectural decisions.

Better Practices

Rather than think of best practices as something you need to achieve today, think of it as an ongoing day-to-day quest for improvement.

• repetitive manual processes - employ automation & script those processes where possible.
• where steps require investigation and research - document it
• where production changes are involved - communicate with business units, qa & operations
• always be improving - striving for better practices

Metrics are those pesky little numbers we like to keep an eye on to see how we're doing.  Website performance may be full of lots of jargon and fancy terminology but in the end the purpose is the same.  Watch the numbers to know how we're doing.

In Economics

If you follow the economy you're probably familiar with GDP or Gross Domestic Product tells you the total amount of goods and services that a country produced.  What about the CPI or Consumer Price Index, well that measures the price of a so-called basket of goods.  Those are intended to be goods everyone must have, such as food & beverages, housing, apparel, transportation, medical care and so forth.  By measuring the CPI we get a sense of consumers buying power or how far the dollar goes.

In Baseball

If you follow sports, you've probably heard of a players batting average which is hits divided by at bats.  A simple ratio, gives a picture of the players past performance.  Another statistic is the RBI or runs batted in, which tells you how many times the player caused runs to be scored.

Web Performance

Taken generally metrics give us a quick view of a more complicate picture.  Performance metrics for websites are no different.  For instance if we're looking at the business or application level, we might keep track of things like:

• user registrations
• subscriptions sold
• widgets sold
• new accounts sold
• user & social interactions
• ratings and other gamification stats

So too at a lower level we can capture metrics of the systems our web application runs on top of with tools like Cacti, Munin, Ganglia, Zabbix, or OpenNMS.  The basics include:

• cpu utilization
• network throughput
• disk throughput
• memory usage
• load average

And further down the stack we can keep metrics of are database activity such as:

• buffer pool usage
• files & table I/O
• sorting activity
• locking and lock waits
• queries per second
• transaction log activity

By tracking these metrics over time, we can view graphs at-a-glance and see trends.  What's more folks from different sides of the business, can get visibility into what others needs are.  Business teams can see server loads and operations people can see real revenue and income.  That brings teams together to a common goal.

I've recently been doing a lot of Search Engine Optimization for my corporate website.  This makes your site more visible and keyword rich for the search engines, helping your customers more easily find you. In that process it quickly becomes clear how important the website is to your business.  On the internet it is surely the cornerstone of your business, your virtual storefront.

Site Speed Is Key

Study after study from Google and others have shown that the speed and response of a website directly affects user experience and in turn use of your product or service.  It translates directly to the business bottom line.

Speed is accomplished by first measuring current speed and performance, then tuning and optimizing the various layers of technology which support it.  Then measuring again to determine the speedup.  You can then tie those changes to customer retention, higher click through rates, more time spent on the site, and higher conversions.  Apply a dollar value to your conversions and you can then estimate the direct value of that effort.

Interface to Customers

The image your company projects is formed first by your website.  The usability and simplicity affects how customers feel about interacting with your products and services.  What's more the information, solutions, tools and downloads available also reflect directly on your business.

Analytics tools like Google's or Yahoo's allow you to track conversions.  These are important metrics to show when customers are taking action.  They are traditionally used for when a purchase is made on an ecommerce site, but can just as easily be put to useful work tracking bookmarks, form submissions, phone call or request a callback, downloads, newsletter signups, likes and a lot more.  If you do use conversions for these diverse functions, be sure to assign a dollar value by estimating based on the percentage who convert and those who later become paying customers in one way or another.

It's All About Operations

Your website should be backed by a solid and flexible content management system so you can make SEO and ongoing process as well as tuning and optimization.  WordPress, Drupal, Joomla are just a few.  Use caching at every layer, and optimize images for faster download.  Of course you'll also need to apply best practices for disaster recovery, making sure your database and content are backed up regularly, as well as your server configuration components.

All of this boils down to web operations, that hidden support providing your internet technology foundation.

Book Review: The Art of SEO by Enge, Spencer, Fishkin & Stricchiola

Search Engine Optimization is for sure one part art, but it is certainly a lot of science too, and this book really covers all of the angles.  Even if you don't plan to do the SEO yourself, it's good to have a strong grounding in the material so you can make intelligent decisions.

Plan to do research and brainstorm on the main keywords your customers use, what your competitors do differently and tune your site and CMS to best fit those searches.  You'll learn to optimize title tags, content and anchor text to be keyword rich, and most importantly of all plan a link building campaign to grow inbound links to your site and thus your authority and reputation on the internet.

Art of SEO is comprehensive, easy to follow & thorough, but also easy enough to dip into here and there for pointers if that's all you need.  I also like O'Reilly's layouts and font, so it's very easy on the eyes.

I meet new people all the time.  It's a way of life in New York.  One of the first questions new people ask each other is "What do you do?".  It begins to sound like a cliche after a while, but it can also provide endless fascinating discussions as there are so many people with different professions in New York.  Some choose a titled answer "i'm an investment banker", "I'm an emcee", "I'm an executive recruiter".  I find for "Web Scalability Consultant" or "Web Operations Expert" this only leaves confused looks.

A Plumber By Another Name

The solution of course is to tell a good story.  Stories illustrate what titles and crusty vernacular cannot.  I've used analogies to surgeons or mechanics, of course they all operate on something people can related to in front of them.  People or vehicles we use everyday.  Of course with the internet, there is a huge hidden infrastructure that most people don't see everyday.  They may vaguely know it's there, but it's still hidden out of site.

That's why I think plumbing provides such an apt visual.  As it turns out the internet is built with countless data pipes both large and small, coming into your home or laying across the bottom of the transatlantic ocean.  These pipes plug into routers, high speed traffic lights and traffic cops.  Ultimately they feed into datacenters, huge rooms filled with racks of computers, holding your websites crown jewels.  Therein contains the images and status updates from your facebook profile, your banking transactions from your personal bank account or credit card, your netflix movie stream, or the email you sent via gmail.  Even your instant messaging stream, or the data from your favorite iphone app are all stored and retrieved from here.

Amazon Outage

The recent Amazon outage has been high profile enough that a lot of folks who don't follow the latest trends in web operations, devops, and datacenter automation still heard about this event.  Turns out it's had a silver lining for Amazon cause now everyone is scrutinizing how many sites actually rely on this goliath of a hosting provider.

As it turns out the root of the amazon outage was indeed a plumbing problem.  Amazon has shown rather high transparency publishing intimate details of the problem and it's resolution.  Read more.

A misconfigured network cascaded through the system creating countless failures.  If you imagine water repairs being done in a large New York City building, they often ask tenants to turn off their water, so they won't all come on at the same time when service is restored.  SImilarly intricate problems complicated the Amazon effort, slowing down attempts to restore everything after the incident.  I wrote at length about the outage if you're interested, read more.

BOOK REVIEW:  Game-Based Marketing by Zicherman & Linder

There are so many new books coming out all the time, it's tough to sift and find the good ones.  Anyone with a website as their storefront, whether they are a product company or a services company, can gain from reading this book.

From leaderboards to frequent flyer programs, badges and more this book is full of real-world examples where game-based principles are put into action.  On the internet where attention is a rarer and rarer commodity, these concepts will surely make a big difference to your business.

Amazon book link - Game Based Marketing

Your recent social media campaign has gone viral.  It's what you've been dreaming about, pinning your hopes on, and all of your hard work is now coming to fruition.  Tens of thousands of internet users, hoards of them in fact, are now descending on your website.  Only one problem, it went down!!

That's a situation you want to avoid.  Luckily there are some best practices for avoiding scenarios like the one I described.  In engineering it's termed "degrade gracefully".  That is continue functioning but with the heaviest features disabled.

Browsing Only, But Still Functioning

One way to do this is for your site to have a browsing only mode.  On the database side you can still be functioning with a read-only database.  With a switch like that, your site will continue to function while pointed to any of your read-only replication slaves.  What's more you can load balance across those easily, and keep your site up and running.

Decoupling

In software development, decoupling involves breaking apart components or pieces of an application that should not depend on one another.  One way to do this is to use a queuing system such as Amazon's SQS to allow pieces of the application to queue up work to be done.  This makes those pieces asynchronous, ie they'll return right away.  Another way is to expose services internal to your site through web services.  These individual components can then be scaled out as needed.  This makes them more highly available, and reduces the need to scale your memcache, webservers or database servers - the hardest ones to scale.

Identify Features You Can Disable

Typically your application will have features that are more superfluous, or that are not part of the core functionality.  Perhaps you have star ratings, or some other components that are heavy.  Work with the development and operations teams to identify those areas of the application that are heaviest, and that would warrant disabling if the site hits heavy storms.

Once you've done all that, document how to disable and reenable those features, so other team members will be able to flip the switches if necessary.

BOOK REVIEW:  Outsmart! - by Jim Champy

This is a great business book out on FT Press.  It's chapters are organized around eight case studies of companies that grew quickly, earning huge returns for their shareholders and customers as well.

What I like most about this book is the "Get Smart" section at the end of each chapter.  There he lists the lessons learned from that case study in a succinct summary.  Following that is a "Questions to Ask Yourself" section which really points the spotlight back on you, to help you apply those lessons.

He didn't choose companies that all took the same path or solved the same problems either.  Some were new companies filling a niche noone saw like SonicBids while others were long established brands that had languished such as Smith & Wesson.

An excellent read and highly recommended book.

What Do Consultants Do?

Consultants bring a whole host of tools to experiences to bear on solving your business problems.  They can fill a need quickly, look in the right places, reframe the problem, communicate and get teams working together, and bring to light problems on the horizon. And they tell stories of challenges they faced at other businesses, and how they solved them.

Frame or Reframe The Problem

Oftentimes businesses see the symptoms of a larger problem, but not the cause.  Perhaps their website is sluggish at key times, causing them to lose customers.  Or perhaps it is locking up inexplicably.  Framing the problem may involve identifying the bottleneck and pointing to a particular misconfigured option in the database or webserver.  Or it may mean looking at the technical problem you've chosen to solve and asking if it meets or exceeds what the business needs.

Tell Business Stories

Clients often have a collection of technologies and components in place to meet their business needs.  But day-to-day running of a business is ultimately about bringing a product or service to your customer.  Telling stories of challenges and solutions of past customers, helps illustrate, educate, and communicate problems you're facing today.

Fill A Need Quickly

If you have an urgent problem, and your current staff is over extended, bringing in a consultant to solve a specific problem can be a net gain for everyone.  They get up to speed quickly, bring fresh perspectives, and review your current processes and operations.  What's more they can be used in a surgical way, to augment your team for a short stint.

Get Teams Communicating

I've worked at quite a number of firms over the years and tasked with solving a specific technical problem only to find the problem was a people problem to begin with.  In some cases the firm already has the knowledge and expertise to solve a problem, but some members are blocking.  This can be because some folks feel threatened by a new solution which will take away responsibilities they formerly held.  Or it can be because they feel some solution will create new problems which they will then be responsible to cleanup.  In either case bridging the gap between business needs and operations teams to solve those needs can mean communicating to each team in ways that make sense to them.  A technical detail oriented focus makes most sense when working with the engineering teams, business and bottom-line focused when communicating with the management team.

Highlight Or Bring To Light Problems On Horizon

Is our infrastructure a ticking timebomb?  Perhaps our backups haven't been tested and are missing some crucial component?  Or we've missed some security consideration, left some password unset, left the proverbial gate open to the castle.  When you deal with your operations on a day-to-day basis, little details can be easy to miss.  A fresh perspective can bring needed insight.

BOOK REVIEW - Jaron Lanier - You Are Not a Gadget

Lanier is a programmer, musician, the father of VR way back in the 90's, and wide-ranging thinker on topics in computing and the internet.

His new book is a great, if at times meandering read on technology, programming, schizophrenia, inflexible design decisions, marxism, finance transformed by cloud, obscurity & security, logical positivism, strange loops and more.

He opposes the thinking-du-jour among computer scientists, leaning in a more humanist direction summed up here:  "I believe humans are the result of billions of years of implicit, evolutionary study in the school of hard knocks."    The book is worth a look.

In a recent trip to Southeast Asia, I visited the Malaysian city of Kuala Lumpur.  It is a sprawling urban area, more like Los Angeles than New York.  With all the congestion and constant traffic jams the question of city planning struck me.  On a more abstract level this is the same challenge that faces web application and internet website designers.  Architect and bake the quality into the framework, or hack it from start to finish?

Urban Un-Planning

Looking at cities like Los Angeles you can't help but think that no one imagined there would ever be this many cars.  You think the same thought when you are in Kuala Lumpur.  The traffic reaches absurd levels at times.  A local friend told me that when the delegates travel through the city, they have a cavalcade of cars, and a complement of traffic cops to literally move the traffic out of the way.  It's that bad!

Of course predicting how traffic will grow is no science.  But still cities can be planned.  Take a mega-city like New York for example.  The grid helps with traffic.  A system of one way streets, a few main arteries, and travelers and taxis a like can make better informed decisions about which way to travel.  What's more the city core is confined to an island, so new space is built upward rather than outward.  Suddenly the economics of closeness wins out.  Many buildings in midtown you can walk between, or at most take a quick taxi ride.  Suddenly a car becomes a burden.  What's more the train system, a spider web of subways and regional transit branches North to upstate New York, Northeast to Connecticut, East to Long Island, and West to New Jersey.

If you've lived in the New York metropolitan region and bought a home, or work in real estate you know that proximity to a major train station affects the prices of homes.  This is the density of urban development working for us.  It is tough to add this sauce to a city that has already sprawled.   And so it is with architecting websites and applications.

Architecting for the Web

Traffic to a website can be as unpredictable as traffic within the confines of an urban landscape.   And the spending that goes into such infrastructure as delicate.  Spend too much and you risk building for people who will never arrive.  What's more while the site traffic remains moderate, it is difficult to predict patterns of larger volumes of users.  What areas of the site will the be most interested in?  Have we done sufficient capacity planning around those functions?  Do those particular functions cause bottlenecks around the basic functioning of the site, such as user logins, and tracking?

Baking in the sauce for scalability will never be an exact science of course.  In urban planning you try to learn from the mistakes of cities that did things wrong, and try to replicate some of the things that you see in cities doing it right.  Much the same can be said for websites and scalability.

For instance it may be difficult to do bullet proof stress testing and functional testing to cover every single possible combination.  But there are best practices for architecting an application that will scale.  Basics such as using version control - of course but I have seen clients who don't.  There are a few options to choose from, but they all provide versioning, and self-document your development process.  Next build redundancy into the mix.  Load balance your application servers of course, and build various levels of caching - reverse proxy caching such as varnish, and a key-value caching system like memcache.  Build redundancy into the database layer, even if you aren't adding all those servers just yet.  Your application should be multi-database aware.  Either use an abstraction layer, or organize your code around write queries, and read-only queries.  If possible build in checks for stale data.

Also consider various cloud providers to host your application, such as Amazon's Elastic Compute Cloud.  These environments allow you to script your infrastructure, and build further redundancy into the mix.  Not only can you take advantage of features like auto-scaling to support dynamic growth in traffic, but you can scale servers in place, moving your server images from medium to large, to x-large servers with minimal outage.  In fact with MySQL multi-master active/passive replication on the database tier, you could quite easily switch to larger instances or from larger to smaller instances dynamically, without *any* downtime to your application.

Conclusion

Just as no urban planner would claim they can predict the growth of a city, a devops engineer won't claim they can predict how traffic to your website will grow.  What we can do is mitigate that growth, build quality by building scaffolding so it can grow organically, and then monitor, collect metrics and do basic capacity planning.  A small amount of design up front will payoff over and over again.

Book Review: How To Disappear by Frank M Ahearn

With such an intimidating title you might think at first glance that this is a book only for the paranoid or criminally minded.  Now granted Mr Ahearn is a Skip Tracer, and if you were one already you certainly wouldn't need this book.  Still Skip Tracers have a talent for finding people, just as an investigator or a detective has of catching the bad guys.  And what a person like this can teach us about how they find people is definitely worth knowing.

If you've had your concerns about privacy, what companies have your personal information and how they use it, this is a very interesting real-world introduction to the topic.  Of particular interest might be the chapter on identity thieves and another on social media.  All-in-all a quick read and certainly one-of-a-kind advice!

View on Amazon - How To Disappear

Finding good vendors who provide professional services may have a lot in common with finding good restaurants.  There may be an abundance of them, while the best ones remain difficult to find.

A long line does not mean quality food

Some restaurants have a long line because they have slow service.  If that's because you're getting quality personalized service, great.  But if it's because of incompetence and general disorganization or because they can't keep quality help, that's another story.

Hype and marketing can bring a lot of customers to a new restaurant.  Sometimes it's a celebrity chef or architect.  If that's what you're after then you may be at the right place.  If you're looking for the best home cooked meal, you may have to keep looking.

Convenience and location can also bring long lines.  Finding a restaurant on the main street or square is usually not the one with the best food.

A better way to find quality

Take a look at how long the restaurant has been around.  A service provider who has been in business for a long time has obviously been successful at acquiring customers, solving their problems, and charging a fee that matches both their needs and those of their customers.

Check the testimonials of your provider.  If their website doesn't list some, ask for one or two customers that they've worked with recently.

Pay attention to service.  If you are a small fish for your vendor, it's likely that service will be affected.  If you on the other hand are one of your vendors bigger clients, they'll likely give much more attention to you.  Notice how regular customers at a restaurant or lounge tend to get the best service.

Book Review:  The Power of Pull by Hagel, Brown & Davison

A lot of really influential people like this book.  Joichi Ito, Richard Florida and Eric Schmidt to name a few.  Enterprises are faced with a bewildering array of challenges from finding good people, to retaining them, and putting them to work in the most creative ways.  This book brings another new and welcome perspective on the future of building and growing successful organizations.

In the business of technology consulting, there are times when I've heard this statement.  It's Easy!  Perhaps the single biggest thing I've learned through a decade and a half of consulting is, people use this phrase when they are feeling overly confident.

What do I mean by that?  Well it turns out in psychology there are all sorts things we communicate with our spoken language & body language.  Some of those things we aren't even conscious of.  In the case of the statement "It's easy" your first thought may be about all the intricate details that have yet to be ironed out, all the hiccups that may happen along the way.  Or you may just simply be thinking of Murphy's Law that always seems to rear it's ugly head at the worst time.

Truth is when you hear this statement, you may also be inclined to think of it as a statement of fact.  The person saying that they have reviewed all the facts and ascertained that task x is in fact a trivial one.

Of course one doesn't want to be the naysayer either, but you can raise concerns while still acknowledging both sides.  My tack is first to repeat what the person said in more detailed language.  By reiterating all of the details, it can sometimes illustrate right there some hidden complexity and weaken the sense of triviality to the task at hand.

A Software Developer

A few years back I had subcontractor developer working on a project.  We went over some details about what changes needed to happen.  A web-based analytical tool needed some additional search functionality.  We went over how that search would index documents in the site.  The developer explained to me "That's easy.  No problem".  I was suspicious.

As development unfolded we hit a bump in the road.  Besides the database indexing, additional xml documents needed to be indexed in order for the search function to work properly.  That added quite a bit of additional complexity because the search solution developer had envisioned couldn't deal with that xml data.

A Business Prospect

I was recently reviewing a contract with a prospect, and going over items and deliverables.   They explained that for the database portion we'll just use Amazon RDS, instead of installing MySQL and configuring the server manually.  "This piece will be easy".  Unfortunately using Amazon's solution is still not  push-button  in any event.   These types of oversimplifications are fine if you're working on a time and materials basis because the complexity of the project will unfold organically, and the process will educate everyone involved.  But if you are trying to do a fixed fee project, these can be a harbinger of trouble later on.

Conclusion

When you hear people say "That's Easy" understand that they are only expressing their confidence, despite their assurances.  If you are not equally confident,  you'll both need to discuss details until you reach a middle point.  If it scares you to hear someone say something is EASY, think of it as a warning flag that you are not both on the same page.  Then remedy the situation with ample communication.

BOOK REVIEW:  Satyajit Das - Traders, Guns & Money

Financial Times has very high standards, and with an endorsement by Gillian Tett on the back, you know you are on the right track to some excellent material.  Das' expose explores the inside world of derivatives, the so-called WMD of the financial world.   Along the way you'll enjoy wacky stories of rogue traders, $70,000 meals, LIBOR numbers, delusional thinking, and even more about financial risk.  It illustrates exactly why Warren Buffet said "You only find out who is swimming naked when the tide goes out."

It's not a caution you here very often, but a worthy one now as ever.  Don't Over Engineer solutions to your problems, features in your product, moving parts in your infrastructure, or solutions for your customers.

Five Levels of Settings

Years ago during the dot-com boom we were involved with a project for a financial services firm.  We were building out a subscription-based web service for them.  As part of the requirements gathering, we discussed various components and features that the site should have.  Their vision included various levels of settings and customizations that the user could control to filter and tune presentation.  It all appeared very rube goldbergian to us.

Our suggestion was to drastically reduce the initial settings, simplify the process, shorten development and then find out what real customers wanted.  In this case the client is always right, so we went ahead and built out the complex settings scheme.  Once the product rolled out, however customers indeed had much different usage patterns than either our development team or the client had even expected.  Their demands in turn drove a different direction, but one matching real-world requirements that only the customers ultimately understood.

Features But No Customers

A colleague of mine is in the process of building out software for a web service.  Currently they've built version one of the product as they envisioned.  They have no customers.  They're in the process of reviewing the product and deciding on a second round of new features to add.  Let me repeat the earlier part - they have no customers.

I asked my colleague, why not launch with it as it is, and then see what your customers want.  Their response - we don't want to launch until we're ready.

Well chances are you'll never be ready because you don't know where you're going.  You can't really know where you're going until your customers tell you.

Zero Percent Downtime

I've spoken with many managers and CEOs about infrastructure and architecture over the years.  I remember one instance where I was asking about expectations, and downtime.  The managers response - we want zero downtime.  Well that's not necessarily practical in the real-world.  Well let's put everything in place we can to get as close as we can to that.

The real world is messier.  Data centers have power outages.  In fact the east coast had over a day of power loss.  Averaged out that is one hour per year over the past thirty years.  Adding more components, more software to detect anomalies, more redundancy behind redundancy has it's own commensurate costs.  At a certain point you have to err on the side of simplicity, as ultimately the complexity of the system itself contributes to outages and downtime.

Evolution of a Company

iPhone applications are everywhere these days.  A couple of years ago we were gathering feedback and opinion from experts and investors about a concept we had to build a venue and event management platform.  A colleague put us in touch with the CEO of a company building a iphone platform.  After discussing our concept he explained that they had started out with a very similar concept.  But over the past two years their company had evolved quite a bit from that starting point.  They simply responded to their customers requests for features, and grew organically from their.

Conclusion

It's not easy to engineer a perfect widget from the start.  You usually don't know what customers want, or how they will use your product or service.  Or further you don't always know what the real world will deliver up.  So it is very easy to over engineer it, and miss the mark.  Better to build less, build small and release early.  Then let your customers or real-world dictates decide your next move.

Book Review - The Four Agreements - A Practical Guide To Personal Wisdom by Don Miguel Ruiz

This small little book is full of some very big ideas.

1. Be Impeccable With Your Word.
2. Don't Take Anything Personally.
3. Don't Make Assumptions.
4. Always Do Your Best.

Whether you find personal insights, or help in your business relationships, this book will surely give you some fresh perspectives.

BCP or business continuity planning sometimes also called Business Continuity and Resiliency Planning is the process of protecting your business against disaster.

There are a lot of risks associated with running a business from competitors, and hackers to legal entanglements to natural disasters or power outages.  For my subject matter expertise, I'll focus on the datacenter.

Your computing resources are hosted at a colocation facility or perhaps in the cloud.  So one part of BCP would be looking at redundancy and high availability.  Do you have two webservers, two database servers, two networks, routers, power systems.  Can you failover easily?  Have you tested the failover and documented the process?

Once you have considered the issues within your datacenter, you can look at bigger outages such as power outages, or general datacenter downtime.  Even with solid SLAs, mistakes do happen.  If your business can't handle this risk, you can look at using multiple datacenters - say on the east and west coast, or perhaps on different continents.  In that case global server load balancing (GSLB) may work for you, allowing load balancing to bring you to the physically closest servers or datacenter to service your request.  In the event one of those datacenters is unavailable, all traffic will be routed to the available one.

As more and more deployments happen in the cloud, the process of failover and testing becomes more crucial.  And that's a good thing.  With many clients I suggest doing a firedrill to run through all the disaster recovery steps.  This makes sure all your backups are complete, but more importantly that the process is well documented.  When an outage happens it's not the time you want to put all the pieces of the puzzle back together, and figure out that one piece is missing.

Cloud deployments though push you to automate processes, create images of server configurations and generally script the process of spinning up new servers.  That's because virtualization requires it.   That pressure will only serve to improve recoverability and thus support business process continuity further.

Book Review: Richard Florida - The Rise of the Creative Class

Florida's idea of creative is wide ranging.  The folks he includes are everyone whose job involves creating new ideas, new technologies, or new content.  Well written and exhaustive, he provides an insightful look at the horizon of our changing job market and economy.

View The Rise of the Creative Class on Amazon

Considering proximate causes versus ultimate causes can help give us a sense of perspective.  When it comes time to assign blame, it often isn't as cut and dry as we'd like.  Getting this sense of perspective might help us consider and formulate more constructive solutions rather than pointing fingers.

Oil Spills

With the oil spill all over the news in the last weeks, its easy to see this finger point.  What's the proximate cause?  Perhaps a faulty valve is to blame.  If we look at larger causes of that, we see that regulation, oversight and checks and balances were missing.  But why drill in such a hazardous extreme environment 1 mile down?

Ultimately the cause is of demand for oil.  As a supply of easy oil dwindles, we search ever more remote locations for it.  So in essence each of us plays a part in this demand for oil.  Since complex technology and systems are inherently unstable, accidents are inevitable.  They can be mitigated, but there always remains a degree of error.  One might even argue that ultimate cause was an ever growing human population which needs energy to make food, which in turn is an inherent quality of living creatures.  So says Jared Diamond in his book collapse, discussing the rise, and fall of some past societies.

Diamond's book is also a great example of constructive thinking on this topic, as he provides examples of some societies which pulled back from that edge, and how they did it.

Financial Instability

With the recent financial meltdown, a lot of fingers have been pointed too.  Everyone is looking to find the bad guy, and upon whom to assign blame.  But individuals or large financial firms have always taken risks.  Their whole raison d'etre is to find more and creative ways of making money, off of fees, leverage, or so-called arbitrage.  So that impulse is obviously nothing new.  Lack of regulation, perhaps the government is to blame?  True regulatory changes did usher in a new wave of gambling.  Many would argue not enforcing capital requirements allowed firms like Lehman to get so overleveraged in the first place.

But economists argue that ultimately capitalism is prone to cycles of boom and bust.  It also seems that those cycles are shortening.  And ultimately the internet and computerization of trading has played a huge huge role in speeding up the global economic machine in ways that we have yet to understand or unravel.

Tech Outages

Just as with these other complex systems we've described, computing systems have inherent complexity built into them.  Many web-facing applications have a fleet of database servers, webservers, load balancers, and many many interlocking software components interacting in a myriad of ways.

When a site outage happens they typically coincide with a huge spike in traffic, which means some spike in popularity or attention or focus to your services and business.  So it often happens to be the worst time for an outage.  So the pressure mounts when such an outage occurs to find a root cause.  Now obviously root cause analysis is important to help mitigate future problems, but we must be careful not to also assign blame too quickly along with that.  It is a very human knee-jerk reaction, but may miss the bigger picture.

An infinite amount and variety of QA and testing can be performed, and still not model what will happen in the real world.  Perhaps your users all started coming to your site because they wanted some specific piece of content that was suddenly indexed by google making your site the best result?  Or maybe a new feature was rolled out, but enough testing was not done to find one particular bug.  Or a developer added a new table without the proper index, making a heavily used part of the site an even heavier burden for the database.

Again as with the other scenarios we've described there are indeed root causes, but we also must consider the ultimate causes of complexity, and inherent failure built into such systems.

Conclusions

Proximate causes are in the details, they point to the specific event that triggered an outage, avalanche or other disaster.  But they do not provide the entire picture.  Only by considering the ultimate causes of and the complexity of the system as a whole along with proximate causes, can we can get perspective.  It is from that vantage point that we may build more constructive solutions to not eliminate all risk, but at least to mitigate it.

BOOK REVIEW - Seth Godin - The Big Moo

Seth Godin edits this little book of insights, including essays and new ideas from such luminaries as Malcolm Gladwell, Mark Cuban, Tom Peters, and Amit Gupta.

View The Big Moo

In a lot of different kinds of systems there are moving parts.  Electronics, automobiles, bridges and even living systems.  As it turns out in many if not most of these systems, the simpler designs tend to have various advantages over the more complex designs.  These benefits ring true in the business world as well.

Rock Climbing

Take the extreme sport rock climbing as an example.  I've been rock climbing off and on for about five years, though mostly indoors at rock climbing gyms.  One thing that you learn a lot about in rock climbing is safety.  There is a discussion of the harness, and how to double-back the waist cinch, and using multiple carabiners to lock into the rope, and then how to tie the rope in such a way that it tightens as it bears weight.  Both the person climbing and the person balaying - gathering the rope below - each have to take care of these things.  So generally they both check their own rope, harness, carabiners, and then check the other persons.

With indoor climbing this is all rather simple, and with just six checks for each climber to make, generally quite safe.  Plus there are monitors in the room watching people climb, and further checking for mistakes or oversights.  So over the years I've heard of practically *no* injuries in the gym.  It is so-called top-roping, and their are few moving parts.

With outdoor climbing you can do top-roping, however more advanced climbers prefer lead climbing.  It is much more challenging, and as I've described above there are many more moving parts.  The lead climber has to place "protection" into the rock every few meters.  These are special camming devices that grip into the rock.  Obviously all these components are not fool-proof, hence you want to add as many as possible.  But there are limits to endurance, and statistical averages at play, and more importantly many more moving parts.  So unfortunately lead climbing outdoors although possible to be on the safe side, tends to be much more prone to accidents.  More moving parts increases the statistical chance of a system breakdown.

iPhone

Something similar is at play when it comes to interface design.  With user interface or UI design, there is often a discussion of how many steps it takes to perform a function.  The more steps, the deeper the function is hidden.  Fewer steps means simplicity of design.

The iphone is a great example of this.  By simplifying the user interface, the machine works better.  At the Mobile World Congress last year Google announced that they get 50 times more searches from the iphone than *any* other mobile device.  Fifty times!  Think about that statistic.  This is more that flashy glitz and a pretty package.  This is a device that has fewer moving parts, not only in terms of buttons, but in the virtual interface components that a user navigates on the touch screen.

Internet & Engineering

Many of the same truisms that apply in the examples of rock climbing or smartphones also apply to internet systems, and the operations side of the business.  Can we use a web-services solution such a mailchimp.com to handle our email newsletter?  That means less to manage in-house, so our IT staff can focus on more important tasks.  Or how about outsource all email handling through a service like google's Gmail for Business, or salesforce.com for CRM.

Simplifying your operations can also mean going with managing hosting solution, or better yet embracing the cloud with Amazon Web Services or Rackspace Cloud.   For that matter what database platform are you running on, or what computing platform?  Does it embrace the complexity and more  features philosophy?  Or does it strive for simplicity, and fewer moving parts?  And for that matter how many of those endless features are you actually using for your application?

Conclusion

As it turns out, engineers as much as business folks are wowed by endless features and the appeal of glitz and shine of a fancy new car.  But often in business what you need is reliability, simplicity, and fewer moving parts to get the job done, and get it done well.