Archive for the 'Uncategorized' Category

Scott Alan Miller

State of Thin Clients

The IT world loves to swing back and forth between moving processing out to the user via fat clients and moving processing back to the server leaving users with thin clients.  The battle is a long running one that started with the first appearance of multiuser computer systems several decades ago and has continued to this day and will likely continue for a very long time to come.

When I began working in IT, thin clients were simple text terminals attached to a single, central server via serial connections.  Limited to very basic text input these served their purpose at the time to provide relatively low cost computing to a large number of users.  The system wasn’t pretty or glamorous, but it was quite functional.

These ancient terminals gave way to the personal computer and computing power shifted from the datacenter to the desktop allowing users to run powerful apps like Lotus 1-2-3 and WordPerfect.  Responsive graphical applications were a powerful draw for decentralized processing.  Users were enthralled with the new usability.  The text terminal went into very rapid decline.

Eventually centralized power was available in such quantities and at such a low price point that graphical applications could be run with almost as much responsiveness from the server while clients could be “thin” needing just a shim of an operating system – enough to provide remote access back to the server.  Thin computing became the darling of the industry again and the term itself arose and moving towards centralized processing again came into vogue.

Administrators love the central computing model because data and configuration remains in one place.  Backups and management are a breeze.  The idea, at least in theory, is that in doing so desktop support becomes a non-issue with all desktop clients being nothing more than commodity components that can be replaced anytime with completely interchangeable parts.  Since nothing is stored or configured on the desktop there is nothing to support there.

In the initial swings of the “thin computing pendulum” the market movement was dramatic.  When text terminal computing first became available this was practically the only model used in the real world.  The value was so dramatic that no one could really justify doing anything else.  When the PC was introduced the movement to the fat client was so ubiquitous that many younger IT professionals today have never actually seen text terminals in use even though the move to fat “PC” clients was not as all encompassing as the move to text terminals had been one pendulum swing previous.

The PC model was generally better for end users because it mimicked how they used computers at home – those that had computers at home.  It also gave them more options for customization and, for better or for worse, opportunity for them to begin installing software of their own rather than only that software preconfigured for them on the central server.

Over time there have been a lot of developments from both camps giving each more and more advantages of the other.  Central domain services such as Microsoft’s Active Directory have come along allowing central management to extend out to fat clients bringing control and management more in line with traditional thin computing models.  Likewise, companies like Citrix have worked very hard developing new technologies that allow thin clients to perform much more like robust fat clients making their use as seamless as possible for end users and even making offline use possible for laptop users.

Most shops today have adopted hybrid models.  Fat clients where they make sense and thin clients for certain categories of users and for remote workers and continuity of business scenarios.

Over the past decade we have seen a shift in the way that business applications are created and deployed.  Today almost all business applications are web-based and have no client platform dependency.  This affords IT departments of today with a potential new opportunity – to shift from a traditional thin client platform – that requires remote graphical access – to the browser as the new thin client platform.

The move to web apps has happened slowly and most businesses have a rather large legacy codebase on which they are quite dependent that cannot be easily transferred to the new web app architecture and some apps simply are not good candidates for this architecture.  But by and large the majority of new business applications are web based, written most often in Java or .NET, and these apps are prime candidates for a new thin computing model.

If our custom business apps are available via the browser then our only commonly used apps that remain holding us back are the traditional productivity apps such as our office suites that are widely used by nearly all staff today (if they have a computer at all.)  Very few desktop apps are actually pervasive except for these.  Increasingly we are seeing browser-based alternatives to the traditional office suites.  Everyone is very aware of Google Apps as a pioneer in this area with Microsoft now offering online MS Office as well.  But the popular offerings making consumer news headlines require businesses to totally rethink long term strategies involving keeping critical business data within their walls and are not likely to be highly disruptive to the enterprise for quite some time.

What does pose a threat to the status quo is other alternative software products such as ThinkFree office which is installed within the organization and used and secured internally just like any other normal business application.  This category of “traditionally installed internal web applications” will allow enterprise IT departments to begin to reconsider their end users’ platforms without having to reevaluate their entire concept of IT in general.  The biggest barriers to this today are lingering business applications and power users using specific desktop apps that cannot be encapsulated within a browser.

One of the great advantages, however, of the browser as the new thin client is how simple it is to mix browser-based apps with traditional apps.  The move is transparent and most large businesses are moving in this direction today even if there is no overarching strategy to do so.  The market momentum to develop all new apps for the web is causing this to happen naturally.

Another key advantage of a completely “web based” architectural model is the great ease with which it can be exposed for users outside of the corporate network.  Instead of using cumbersome VPN clients and company laptops employees can find any web browser, sign in to the company network and have secure business applications delivered to any browser, anywhere.

Bringing this almost unnoticed shift into sharp relief today are a handful of, of all things, consumer devices such as: Apple’s iPhone and iPad and Google’s Android and ChromeOS platforms.  What all of these devices have in common is a focus upon being primarily thin web appliances – thin clients for consumers.  With the majority of consumer computing focused upon web connectivity the need for anything else from a platform is nearly non-existent in the consumer market.  This means that within a very short period of time users who once brought home PC experience to the office as their expectation of a computing environment will soon be beginning to bring web-based thin computing as their new expectation.

When this shift happens IT departments with need to rethink their internal application delivery strategy.  The change doesn’t have to be dramatic if current development trends are used commonly and legacy systems are routinely updated.  In fact, one of the great benefits of this new model is that traditional fat clients function very well as browser platforms and will do so for a very long time to come most likely.  Companies adopting this model will likely be able to slow desktop purchasing cycles and prepare for purchasing some form of traditional thin client with embedded browser or move to a business version of the new Nettop trend that we are beginning to see emerge in the consumer space.  Some businesses may even attempt the rather dangerous path of using consumer devices but the lack of management and security features will likely keep this from being popular in all but rare instances.

I believe, though, that this swing of the pendulum will not be as dramatic as the last one just as it was not as dramatic as the swing before that.  It will be an important trend but IT departments understand more and more that no new technological shift is a silver bullet and that with each new opportunity comes new challenges.  Most IT departments will need to implement some degree of browser-based thin computing over the next few years but most will retain a majority user base of fat clients.  Hybrid environments, like we’ve seen for many years with more traditional models, will continue as before with each technology being used in target areas where they make the most sense.

The one area where thin clients continue to be challenged the most is in mobile computing where disconnected users end up being digitally marooned away from their company networks unable to continue working until network connectivity is reestablished.  This is a significant issue for power users who must travel extensively and need to be able to continue working regardless of their current connectivity.  Today this is being solved in the traditional thin client arena thanks to companies like Citrix who continue to advance the state of the art in thin application delivery.

In the browser-based arena we have had to turn to technologies like Google Gears and Adobe AIR in the past to make this possible but these had poor market penetration.  Coming down the pike, however, is the new HTML 5 Offline API which is set to redefine how the web works for users who need to go “off the grid” from time to time.  With HTML 5 incorporating offline capabilities and a richer feature set into the specification for the web itself we expect to see broad and rapid adoption from all of the leading vendors – most likely even before the draft standard is finalized.  While still quite some ways away this new standard will certainly lay the groundwork for a significant shift towards the browser as a ubiquitous, standard and robust platform.

The future of thin computing looks to be incredibly promising both in the enterprise as well as, for the first time, in the consumer arena as well.  Adoption of thin computing models will be spurred on by the current movement towards Software as a Service models and SaaS adoption will continue to be encouraged by the widespread presence of thin computing devices.  In many ways browser-based thin computing represents the technology aspect that is now maturing in the SaaS arena where SaaS itself is maturing in social acceptance rather than technical feasibility.

  • Share/Bookmark
Scott Alan Miller

Choosing an Email Architecture: Internal or Hosted

If you talk to email specialists what you seem to find, in my small, anecdotal survey of the market, is that half of all of these professionals will tell you to simply install email locally, normally Microsoft Exchange, and the other half will simply tell you to go with a hosted (a.k.a. Software-as-a-Service / SaaS or “in the cloud”) service, most often Google Apps, but email is not such a simple architectural component that it should be distilled to trite answers.  Email is one of the most important components of your business’ communications infrastructure, often surpassing telephony, and choosing the right delivery methodology for your company is critical for your long term success.

We will start by considering some basic factors in email hosting.  Email systems require a good deal of bandwidth, quite a significant amount of storage, high reliability, careful management and significant security consideration.

Bandwidth is the first area to consider.  Every email sent and received must travel between the end user and the email server as well as between the email server itself and the outside world in the case of email destined externally.  In small businesses nearly all email is destined to leave the company network to go to clients, customers, vendors, etc.  In larger enterprises email use changes and as we approach the Fortune 100 email shifts from being almost exclusively a tool for communicating with people outside the organization to being a platform primarily used for internal communications.

This shift in how email itself is used is a very important factor in deciding how to deploy email services.  If email is used almost exclusively internally for intra-staff communications then this will lend itself very well to hosting email systems in-house to increase security and improve WAN bandwidth utilization.  The caveat here being, of course, that a highly distributed company of any size would not keep this traffic on a LAN network and so should be treated as if the email usage is external regardless of whether or not it is intra-staff.  Small companies with communications happening primarily with external users will find better utilization in a hosted service.

Storage is actually often a smaller factor in email architecture decision making than it may at first appear that it should be.  Traditionally email’s storage requirements made a compelling argument for hosting internally due to the cost benefit of keeping large storage, especially that used for archival needs, local.  Recently, large hosted email vendors such as Rackspace and Google Apps have brought the price of online, archival email storage so low that, in many cases, it may actually be more cost effective to utilize hosted storage rather than local storage or, at least, the cost is at parity.  Even long term archival storage can be had very cost effectively in a hosted solution today.

Reliability is a rather complex subject.  Email is critical to any organization.  If an email system goes down many companies simply grind to a halt.  In some cases, the company effectively shuts down when email stops flowing.  Not only do employees stop communicating with each other but customers, vendors, suppliers and others see the company as being offline at best and out of business at worst.  Interrupting communications with the outside world can represent immediate and serious financial impact to almost any business.

Hosted email has the obvious advantage of being hosted in a large, commercial datacenter with redundancy at every level (assuming a top tier vendor) from hardware to storage to networking to power to support.  Hosting email in house requires a business to determine the level of redundancy that is most cost effective given the business’ ability to withstand email downtime and is generally an exercise in compromises – how much reliability can a company do without given the cost necessary to provide it.

Some companies will opt to host email servers at a colocation facility which will provide them with many redundant components but to meet the features of a Rackspace or Google level offering, multiple datacenters would likely be needed.  Colocation is a halfway option providing the technical features of hosted options with the management and flexibility of in-house email systems.

A more common scenario, though, is for companies to host a single email server completely within their walls relying on their internal power, hardware and network connection.  In a scenario like this a company must either take extreme measures to ensure uptime – such as hosting a completely redundant site at immense cost – or front-ending their entire email infrastructure with a reliable online spooling service such as Postini, MessageLabs or MXLogic.  The cost of such services, while critical for the reliability most companies need, is often equal to or even greater than complete email hosting options.  This spooling service cost will likely add an ongoing, scaling cost that will make fully hosted email services always a less expensive option than in-house hosting.

Management cost is very difficult to determine but requires attention.  A fully hosted solution requires relatively little technical knowledge.  Time to manage is low and the skill level necessary to do so is relatively low.  With an in-house solution your company must supply infrastructure, networking, security, system and email skills.  Depending on your needs and your available staff this may be part time for a single professional or it may require multiple FTEs or even outside consultants.  The total time necessary to manage an in-house email system will vary dramatically and is often very hard to calculate do the complex nature of the situation but, at a minimum, it is orders of magnitude greater than a hosted solution.

Security is the final significant consideration.  Beyond traditional system-level security email requires spam filtering.  Handling spam can be done in many ways: in software on the email server, on an appliance located on the local network, farmed out to a spam filtering service or left to the hosted email solution provider.  Spam filtering, if handled internally, is seldom a set and forget service but one that requires regular attention and generally extra cost in licensing and management.

After looking at these main considerations every company should sit down, crunch the numbers, and determine which solution makes the most sense for them on an individual level.  Often it is necessary to use a spreadsheet and play with several scenarios to see what each solution will cost both up front and over time.  This, combined with a valuation of features and their applicability to the company, will be critical in determining the appropriateness of each option.

The secret weapons of the in-house solution are features, integration and flexibility.  In-house email options can be extended or modified to offer exactly the feature set that the organization requires – sometimes at additional cost.  A perfect example of this is Zimbra’s instant messaging integration which can be a significant value-add for an email platform.  This has to be considered in addition to raw cost.  Integration with existing internal authentication mechanisms can be an important factor as well.

In my own experience and cost calculations, hosted solutions represent the vast majority of appropriate solutions in the SMB space due to raw economics while large and enterprise class customers will find insurmountable benefits from the flexibility and internal communications advantages of in-house solutions.  Small businesses struggle mostly with cost while large business struggle primarily with the communications complexity of their scale.  Large businesses also get the best value from in-house solutions due to “professional density” – the inverse number of IT professionals whose time is wasted due to corporate scale inefficiencies.

Today, whether a business chooses to host their own email or to receive email as a service, there are many options from which to choose even once a basic architecture is chosen.  Traditionally only a few in-house options such as MS Exchange and Lotus Notes would be considered but new alternatives such as Zimbra (recently acquired by VMWare,) Scalix and Kerio are expanding the landscape with lower costs, new deployment options and aggressive feature sets.  Hosting’s relative newcomer, and overnight industry heavyweight, Rackspace is drawing a lot of attention with their new email offerings which more closely mimic traditional in-house offerings while Google continues to get attention with their unique GMail services.  I expect to see the hosted email space continue to become more competitive with new integration features being a key focus.

Every business is unique and the whole of the factors must be considered.  Using a combination of business and IT skills is necessary to evaluate the available options and opportunities and no one discipline should be making these decisions in isolation.  This is a perfect example of where IT managers must understand the economics of the business in addition to the technological aspects of the solution.

  • Share/Bookmark
Scott Alan Miller

Linux Virtualization Deployment Advantage

As more and more businesses begin to deploy virtualization broadly, we must begin to step back and reconsider the opportunities presented to us by this shift in datacenter architecture.  Virtualization comes with new challenges and potential not only for cost savings but for aggressive project implementation.  Small businesses, especially, when using virtualization tend to prepare themselves for projects that they could never have envisioned doing during the era of physical-only servers.

The big winners in this space of emerging virtualization opportunity are the open source operating systems such as Linux, OpenSolaris and FreeBSD.  The reason that these particular operating systems have unique opportunities that Windows and Mac OSX do not is because of the way that they are, or can be, licensed.  Each of these operating systems has an option by which they are available completely for free – something that cannot be done with Windows or Mac OSX.

Traditionally, when purchasing a new server a business would price out expensive hardware with relatively inexpensive software.  An enterprise operating system, such as Windows, would typically represent a relatively small percentage of the cost of a new server.  Even a small server would cost a few thousand dollars and Windows Server can easily be purchased for less than one thousand dollars.  In this scenario a business looking to purchase a new server would see only a very small cost savings in opting for a “free” operating system since introducing a new OS has its own risks and the bulk of the cost of the new server is in the hardware which would still need to be purchased.

Given that equation, only a rare small business would consider the purchase of a non-Windows-based server.  The opportunity for failure is too high given the risk of change and the cost savings are too small.  Today, though, virtualization is commonplace and becoming more ubiquitous every day.  Businesses virtualizing their infrastructure typically have excess capacity on their servers that is going unused.  As these businesses and their IT departments begin to look to utilize this spare capacity they will increasingly find that the cost of deploying virtualized Windows Server remains high while the cost of deploying a virtualized Linux or OpenSolaris server is nominal – generally nothing more than the effort to do so without any capital expenditure or its associated risk.

The ability to deploy new servers, at any time, without any cost is a significant advantage that companies have not begun to truly comprehend.  If a business wants a new web server, for instance, they can have one provisioned and built in thirty minutes without buying any licenses.  Having redundant virtualization hardware means that a redundant web server can be had as well – again without any capital cost.  Unlike Windows (or other commercial operating systems) there is no need to purchase a second license just to have a backup server.

This means that for the first time many businesses can begin to consider clusters as well.  Typically the cost of licensing software for clustering was prohibitive but if that licensing becomes free then suddenly clusters become very attractive options.

Of course, as open source proponents will point out, the low cost of Linux and other free and open source solutions have long been reasons to move to these platforms, but this discounts the incredible shift in pricing structure that occurs only when spare usable capacity meets the previously existing free licenses.  It is only because so many business have already implemented virtualization strategies, or are in the process of doing so, that this new opportunity truly presents itself.

The first challenge will be in getting businesses to begin to think of operating systems and application platforms as being free.  The ways in which businesses may take advantage of this has yet to be seen.  Businesses are so used to being hamstrung by the need to buy new hardware and expensive server software licenses for every new system deployment that the widespread availability of spare server images is quite novel indeed.

Of course, as with many new technology changes, it is the small and medium business space where the greatest change will likely take place.  Large enterprises are already doing datacenter consolidation and do not necessarily have spare capacity available to them as their capacity plan already takes into account virtualization.  But in the smaller business space where capacity planning is a practically non-existent practice we see a different type of opportunity.

What we typically see in small businesses moving to virtualization is an over-purchasing of hardware.  This generally comes from a misunderstanding of how capacity planning and virtual guest interaction will occur in the virtualized environment but also from a desire to err on the side of overpowered versus underpowered and the nature of virtualization capacity planning being a bit of a “black art”.  Because of this, however, many small businesses have server resources sitting idle.  It is not uncommon to see a powerful server virtualizing just two server instances when there is capacity to virtualize a dozen or more.

It is this overprovisioning of hardware that offers unique opportunity.  Many small businesses, and even medium sized businesses, may manage to effectively virtualize their entire existing server infrastructure leaving no further opportunity for cost savings through consolidation.  At this point the spare capacity of the existing servers offers no further cost savings and can now be viewed as capacity for growth instead.

This begs the question of “What new deployment opportunities exist given these opportunities?”  This question is difficult to answer as it will be different for nearly every business, but we can look at some commonalities to build a rough picture of where we may see new value presenting itself.

The most obvious new opportunity is in new web applications.  Small businesses often would like to take advantage of free web-based applications but do not want to risk deploying new, low-priority applications to their existing Windows-based web server of do not even have a server available to do so.  Creating one or more open source application servers is incredibly simple.  Deploying a wiki, corporate web portal, a blogging engine or news site, bug or incident tracking application, microblogging platform (a la laconi.ca,) CRM, ERP or any of thousands of similar applications can be done quickly and easily with minimal cost using only “spare” time from the existing IT resources.  Any number of internal applications such as these could bring value to the company and produce very little impact on a virtualization platform so many could be deployed utilizing only a small amount of excess capacity.

Beyond obvious web apps there are more feature-rich systems that could be deployed for no cost.  A great example is the OpenFire instant messaging and presence server.  Companies can suddenly roll out complete enterprise class, secure, internal instant messaging applications at no cost whatsoever.  Another example is in monitoring systems such as Nagios, Zenoss or Zabbix – all of which are available for free and represent a real benefit for companies that currently have no such system.  Enterprise monitoring completely for free.

Beyond new applications there is also an “environmental” benefit to be had.  In an enterprise environment changes going into production go through a series of testing.  Typically big businesses will maintain a development server environment, a user acceptance testing environment and then the production environment.  For a small business to do this with Windows is extremely cost prohibitive as the servers in each environment need to be licensed.  But with open source servers being virtualized using spare capacity deploying virtual servers for each of these environments is completely free and allows small businesses to test their own processes before making production changes giving them added stability previously unaffordable to them.

After all of these growth benefits there is one additional benefit to consider – flexibility.  Because these new systems can be deployed and tested with no cost it provides a new opportunity for small shops to deploy open source solutions that may replace expensive Windows solutions that they are currently using.  This could include replacing Exchange with Zimbra or replacing IIS with Apache or Active Directory with an LDAP server.  Doing a project like this would be risky and potentially costly if the hardware and software had to be purchased up front.  But if the project can be done, only using free time from the existing IT department, and can be done as a free “proof of concept” before looking to do a pilot and then full production replacement then risk can be minimized and the entire project can be effectively free.

While a full architectural replacement may be very aggressive for an average small business it is also a very significant potential cost savings.  Moving completely to open source systems is not for everyone and should be evaluated carefully.  The ability to evaluate a project of this magnitude, for free, is very important and small businesses should consider doing so to be sure that they are using the systems that make the most sense for their business model and needs rather than simply using the solutions with which they are already familiar or are already in place.

There are many additional ways in which free and open source products, deployed using existing, excess server capacity, can be used to expand the IT infrastructure of small businesses.  Learning to seek out opportunities rather than seeking cost savings from IT is a new process for most small businesses and requires some relearning, but those that take the time to pursue these opportunities have many benefits to be gained.

  • Share/Bookmark
Scott Alan Miller

In House Email for Small Businesses

In small businesses the primary concern with email is cost.  Email is a commodity and especially in smaller shops the biggest differentiating factor between email products and vendors is cost.  In larger companies factors beyond cost begin to come into play more significantly such as directory services, system integration, push email, extended client support, collaboration tools, presence and more.

Surprisingly, when small businesses decide to bring their email in-house they seem to immediately turn to Microsoft Exchange.  Now I don’t want to belittle Exchange’s place in the market.  Exchange is an extremely robust and feature rich product that has earned its reputation as the go-to enterprise collaboration and messaging server.  In the last decade Exchange came seemingly from nowhere to completely dominate the large business email market.  People simply assume that you run Exchange in the Fortune 500 and, for the most part, they are correct.

The features for which Exchange is best known, however, are not features often critical or even useful to small businesses.  In actuality, the weight of Exchange – necessary to support so many great big-business features – can make it unwieldy for small businesses – even for those businesses with the financial and technological resources to support it.  Exchange focuses on collaboration and internal team communications.

Exchange brings with it many burdens.  The first being cost, up front purchasing, licensing and ongoing support.  Up front costs of Exchange include the Exchange email server purchase plus the licenses necessary for the Windows Servers – yes, that is multiple servers – on which it runs.  (Yes, you can mitigate some of this cost by purchasing Microsoft’s Small Business Server which integrates these components together but extra costs remain and flexibility is lost.)  Licensing costs for Exchange include needed Windows Server CALs and Exchange Email CALs for every user, and in some case fictional user accounts, who will need to access the system.  Ongoing support cost comes from the extra complexity arising from Exchange’s complex feature set and deployment architecture.

The second set of burdens with Exchange comes from the user interface, namely Outlook.  Now technically Exchange requires no additional user interface as Outlook Web Access, or OWA, is included for free and is a very functional web interface for email.  This would be fine if all of Exchange’s functionality was exposed through OWA, but this is not the case, so this is often nothing more than a decent fall-back solution for remote users who are away from their corporate laptops.  To really achieve the benefits of Exchange a company needs to invest in Microsoft Outlook which is a very robust and powerful email and collaboration platform but also an expensive one.  The per-user cost of Outlook can be quite significant when added to the per user costs already existing from the Exchange licensing.

The third set of burdens comes from the overhead of managing such a complex and powerful beast as Exchange.  Exchange is no simple system and, when secured according to best practices, spans multiple physical servers and operates in multiple roles.  Exchange system administration is considered its own discipline within IT or, at least, a Windows Server specialty.  Qualified Exchange admins are costly and in-demand from big business.  Small businesses looking to acquire good Exchange talent will either be paying top dollar, hiring consultants or attempting to make do with less experienced staff – a potential disaster on such a critical and publicly exposed system.  In addition to managing the Exchange system itself the staff will also need to contend with managing the deployment and maintenance of the Outlook clients which, while not complicated, does increase the burden on the IT department compared to other solutions.

More potential cost comes from the need to supply anti-virus technologies and anti-spam technologies to support the Exchange installation.  It would be unfair to mention AV and AS technologies in relation to Exchange without pointing out that any in-house email system will absolutely need these technologies as well – these costs are certainly not unique to Exchange.  However, the ecosystem surrounding Exchange has a very strong tendency to encourage the use of expensive, commercial third party tools to meet these needs.  Outside of Exchange, AV and AS technologies are often included with the email packages and no further purchases are needed.

Vying for attention in the Exchange-alternative space are open source entries Zimbra and Scalix as well as several commercial products such as IBM’s Lotus Notes, Novell’s Groupwise, Open-Xchange and Kerio’s MailServer.  Of these, Lotus Notes and Groupwise target, primarily, the large business space bringing their own set of complex collaboration functionality and cost.  The other four, Zimbra, Scalix, Open-Xchange and Kerio MailServer, focus primarily on the small business space and bring leaner, more targeted solutions that will more likely fit the profile desired for a majority of small businesses who are looking to bring their email solution in-house.

Over the last few years Zimbra especially has been in the news with their advanced web interface and early sale to Yahoo! and very recent acquisition by VMWare.  Zimbra has led, at least in the media, the charge of alternative vendors looking to open the in-house email market.  What makes these products stand out is that they deliver the bulk of Exchange’s enterprise level features, including calendaring and other important corporate applications, but do so either for free or at very competitive prices and through robust web interfaces removing the need for a local fat client like Outlook (but while maintaining the option.)

Zimbra and Scalix truly stand out as ideal candidates for the majority of small businesses looking to keep their email in-house.  Both Zimbra and Scalix offer a wide range of functionality, robust AJAX-based web interface, large commercial installation bases, broad industry support and offer the paid option of full vendor support.  But the biggest benefit for many small businesses is that these packages are available in completely free editions allowing an SMB on a budget to rely completely upon their internal IT department or their IT vendor for support rather than buying expensive, per-user email system licenses.

In addition to being free themselves, Zimbra and Scalix offer a range of deployment scenarios including Red Hat Linux, and its free alternative CentOS Linux, as well as Novell’s Suse Linux. By being available on these platforms these vendors again lower the cost of deploying their solutions as no Windows Server license is required to support them.  This is a large potential cost savings over Exchange again as Exchange requires not one but at least two Windows Server licenses on which to run.  Linux also brings some cost and performance advantages in the virtualization space with more and more varied virtualization options compared to most other platforms.

Caveats exist, of course.  Many shops are wary when looking at non-Microsoft solutions.  A lack of skilled Linux technicians in the SMB space is of real concern.  Windows Admins are abundant and it is a rare shop who would need to even seek one out let alone fail to find one capable of supporting their systems.  While Linux Admins are hardly found by swinging cats, they are widely available and tend to be on average, in my opinion,  more skilled – if only because there is a smaller, more senior pool of people from whom to draw talent.  This helps to balance the equation making Linux support not nearly as scary as it may seem like it will be for small businesses, but it does mean that most SMBs will have to look to more experienced IT consulting firms to assist them – which can bring long term cost benefits as well.

Many users are addicted to the functionality and interfaces of Exchange.  This can be a significant factor in deciding to try an alternative product.  Once workers have become accustomed to their existing workflows and processes, changing them by replacing their email server architecture can be rather disruptive.  Exchange offers quite an extensive array of functionality and users who are using those functions, not handled by competing products, will not likely be pleased losing those features, even if there are alternatives available.  So knowing your userbase and what features are being used is important.  Many companies never touch these features and can migrate easily.

Zimbra and Scalix bring their own features, of course.  One of the best being Zimbra’s built-in instant messaging system and presence system built using the standard XMPP protocol.  Putting secure instant messaging directly into the email interface is a huge win for Zimbra and a significant value-add over the status quo.

Obviously the ideal time to consider an alternative email product is at the very beginning when email is first being deployed or when a migration from another system is already underway.  But even companies with existing email systems can seek cost benefits by moving to a less costly system with savings being recouped over a longer period of time and more work necessary to train users.

Small businesses should look first to products like Zimbra and Scalix as the de facto choice for their environments and heavier, more expensive products like Microsoft Exchange should be considered a “special case” choice that requires careful cost analysis and justification.  Far too many SMB IT departments are picking the expensive route without being required to justify their actions.  If more small businesses were diligent about monitoring their IT spending they would likely find many places where their money is not only being spent somewhat liberally but sometimes even for features that they cannot use at all and sometimes on systems that carry many long term support costs as well.

  • Share/Bookmark
Scott Alan Miller

RAID Revisited

Back when I was a novice service tech and barely knew anything about system administration one of the few topics that we were always expected to know cold was RAID -  Redundant Array of Inexpensive Disks.  It was the answer to all of our storage woes.  With RAID we could scale our filesystems larger, get better throughput and even add redundancy allowing us to survive the loss of a disk which, especially in those days, happened pretty regularly.  With the rise of NAS and SAN storage appliances the skill set of getting down to the physical storage level and tweaking it to meet the needs of the system in question are rapidly disappearing.  This is not a good thing.  Just because we are offloading storage to external devices does not change the fact that we need to fundamentally understand our storage and configure it to meet the specific needs of our systems.

A misconception that seems to have entered the field over the last five to ten years is the belief that RAID somehow represents a system backup.  It does not.  RAID is a form of fault tolerance.  Backup and fault tolerance are very different conceptually.  Backup is designed to allow you to recover after a disaster has occurred.  Fault tolerance is designed to lessen the chance of disaster.  Think of fault tolerance as building a fence at the top of a cliff and backup as building a hospital at the bottom of it.  You never really want to be in a situation without a both a fence and a hospital, but they are definitely different things.

Once we are implementing RAID for our drives, whether locally attached or on a remote appliance like SAN, we have four key RAID solutions from which to choose today for business: RAID 1 (mirroring), RAID 5 (striping with parity), RAID 6 (striping with double parity) and RAID 10 (mirroring with striping.)  There are others, like RAID 0, that only should be used in rare circumstances when you really understand your drive subsystem needs.  RAID 50 and 51 are used as well but far less commonly and are not nearly as effective.  Ten years ago RAID 1 and RAID 5 were common, but today we have more options.

Let’s step through the options and discuss some basic numbers.  In our examples we will use n to represent the number of drives in our array and we will use s to represent the size of any individual drive.  Using these we can express the usable storage space of an array making comparisons easy in terms of storage capacity.

RAID 1: In this RAID type drives are mirrored.  You have two drives and they do everything together at the same time, hence “mirroring”.  Mirroring is extremely stable as the process is so simple, but it requires you to purchase twice as many drives as you would need if you were not using RAID at all as your second drive is dedicated to redundancy.  The benefit being that you have the assurance that every bit that you write to disk is being written twice for your protection.  So with RAID 1 our capacity is calculated to be (n*s/2).  RAID 1 suffers from providing minimal performance gains over non-RAID drives.  Write speeds are equivalent to a non-RAID system while read speeds are almost twice as fast in most situations since during read operations the drives can access in parallel to increase throughput.  RAID 1 is limited to two drive sets.

RAID 5: Striping with Single Parity, in this RAID type data is written in a complex stripe across all drives in the array with a distributed parity block that exists across all of the drives.  By doing this RAID 5 is able to use an arbitrarily sized array of three or more disks and only loses the storage capacity equivalent to a single disk to parity although the parity is distributed and does not exist solely on any one physical disk.   RAID 5 is often used because of its cost effectiveness due to its lack of storage capacity loss in large arrays.  Unlike mirroring, striping with parity requires that a calculation be performed for each write stripe across the disks and this creates some overhead.  Therefore the throughput is not always an obvious calculation and is dependent heavily upon the computational power of the system doing the parity calculation.  Calculating RAID 5 capacity is quite easy as it is simply ((n-1)*s).  A RAID 5 array can survive the loss of any single disk in the array.

RAID 6: Redundant Striping with Double Parity.  RAID 6 is practically identical to RAID 5 but uses two parity blocks per stripe rather than one to allow for additional protection against disk failure.  RAID 6 is a newer member of the RAID family having been added several years after the other levels had become standardized.  RAID 6 is special in that it allows for the failure of any two drives within an array without suffering data loss.  But to accommodate the additional level of redundancy a RAID 6 array loses the storage capacity of the equivalent to two drives in the array and requires a minimum of four drives.  We can calculate the capacity of a RAID 6 array with ((n-2)*s).

RAID 10: Mirroring plus Striping.  Technically RAID 10 is a hybrid RAID type encompassing a set of RAID 1 mirrors existing in a non-parity stripe (RAID 0).  Many vendors use the term RAID 10 (or RAID 1+0) when speaking of only two drives in an array but technically that is RAID 1 as striping cannot occur until there are a minimum of four drives in the array.  With RAID 10 drives must be added in pairs so only an even number of drives can exist in an array.  RAID 10 can survive the loss of up to half of the total set of drives but a maximum loss of one from each pair.  RAID 10 does not involve a parity calculation giving it a performance advantage over RAID 5 or RAID 6 and requiring less computational power to drive the array.  RAID 10 delivers the greatest read performance of any common RAID type as all drives in the array can be used simultaneously in read operations although its write performance is much lower.  RAID 10’s capacity calculation is identical to that of RAID 1, (n*s/2).

In today’s enterprise it is rare for an IT department to have a serious need to consider any drive configuration outside of the four mentioned here regardless of whether software or hardware RAID is being implemented.  Traditionally the largest concern in a RAID array decision was based around usable capacity.  This was because drives were expensive and small.  Today drives are so large that storage capacity is rarely an issue, at least not like it was just a few years ago, and the costs have fallen such that purchasing additional drives necessary for better drive redundancy is generally of minor concern.  When capacity is at a premium RAID 5 is a popular choice because it loses the least storage capacity compared to other array types and in large arrays the storage loss is nominal.

Today we generally have other concerns, primarily data safety and performance.  Spending a little extra to ensure data protection should be an obvious choice.  RAID 5 suffers from being able to lose only a single drive.  In an array of just three members this is only slightly more dangerous than the protection offered by RAID 1.  We could survive the loss of any one out of three drives.  Not too scary compared to losing either of two drives.  But what about a large array, say sixteen drives.  Being able to safely lose only one of sixteen drives should make us question our reliability a little more thoroughly.

This is where RAID 6 stepped in to fill the gap.  RAID 6, when used in a large array, introduces a very small loss of storage capacity and performance while providing the assurance of being able to lose any two drives.  Proponents of the striping with parity camp will often quote these numbers to assuage management that RAID 5/6 can provide adequate “bang for the buck” in storage subsystems, but there are other factors at play.

Almost entirely overlooked in discussions of RAID reliability, an all too seldom discussed topic as it is, is the question of parity computation reliability.  With RAID 1 or RAID 10 there is no “calculation” done to create a stripe with parity.  Data is simply written in a stable manner.  When a drive fails its partner picks up the load and drive performance is slightly degraded until the partner is replaced.  There is no rebuilding process that impacts existing drive members.  Not so with parity stripes.

RAID arrays with parity have operations that involve calculating what is and what should be on the drives.  While this calculation is very simple it provides an opportunity for things to go wrong.  An array control that fails with RAID 1 or RAID 10 could, in theory, write bad data over the contents of the drives but there is no process by which the controller makes drive changes on its own so this is extremely unlikely to ever occur as there is never a “rebuild” process except in creating a mirror.

When arrays with parity perform a rebuild operation they perform a complex process by which they step through the entire contents of the array and write missing data back to the replaced drive.  In and of itself this is relatively simple and should be no cause for worry.  What I and others have seen first hand is a slightly different scenario involving disks that have lost connectivity due to loose connectors to the array.  Drives can commonly “shake” loose over time as they sit in a server especially after several years of service in an always-on system.

What can happen, in extreme scenarios, is that good data on drives can be overwritten by bad parity data when an array controller believes that one or more drives have failed in succession and been brought back online for rebuild.  In this case the drives themselves have not failed and there is no data loss.  All that is required is that the drives be reseated, in theory.  On hot swap systems the management of drive rebuilding is often automatic based on the removal and replacement of a failed drive.  So this process of losing and replacing a drive may occur without any human intervention – and a rebuilding process can begin.  During this process the drive system is at risk and should this same event occur again the drive array may, based upon the status of the drives, begin striping bad data across the drives overwriting the good filesystem.  It is one of the most depressing sights for a server administrator to see when a system with no failed drives loses an entire array due to an unnecessary rebuild operation.

In theory this type of situation should not occur and safeguards are in place to protect against it but the determination of a low level drive controller as to the status of a drive currently and previously and the quality of the data residing upon that drive is not as simple as it may seem and it is possible for mistakes to occur.  While this situation is unlikely it does happen and it adds a nearly impossible to calculate risk to RAID 5 and RAID 6 systems.  We must consider the risk of parity failure in addition to the traditional risk calculated from the number of drive losses that an array can survive out of a pool.  As drives become more reliable the significance of the parity failure risk event becomes greater.

Additionally, RAID 5 and RAID 6 parity introduces system overhead due to parity calculation which is often handled by way of dedicated RAID hardware.  This calculation introduces latency into the drive subsystem that varies dramatically by implementation both in hardware and in software making it impossible to state performance numbers of RAID levels against one another as each implementation will be unique.

Possibly the biggest problem with RAID choices today is that the ease with which metrics for storage efficiency and drive loss survivability can be obtained mask the big picture of reliability and performance as those statistics are almost entirely unavailable.  One of the dangers of metrics is that people will focus upon factors that can be easily measured and ignore those that cannot be easy measured regardless of their potential for impact.

While all modern RAID levels have their place it is critical that they be considered within context and with an understanding as to the entire scope of the risks.  We should work hard to shift our industry from a default of RAID 5 to a default of RAID 10.  Drives are cheap and data loss is expensive.

  • Share/Bookmark
Scott Alan Miller

Virtualization for Small Business

In the last year or two we have seen virtualization go from a poorly understood concept to a much-hyped industry buzz word being bantered about constantly in every conversation involving technology.  There is no doubt that virtualization is playing an important role in today’s IT landscape, but the question we are asking is whether virtualization applies to the small and medium business markets at this time.

The quick answer to this question is: absolutely.  Unlike many technologies that are of questionable value or that provide a great degree of technological complication, risk and expense that may not be appropriate for a small business, virtualization is a mature technology (IBM CP/CMS circa 1968) that is well understood and provides a layer of hardware abstraction that can benefit an IT organization of any size and may possibly apply even more to the small business IT department than it applies in the enterprise space.

Before looking at how virtualization can benefit the SMB market I would like to provide some definitions to be sure that we are discussing the same set of technologies.  In today’s IT landscape it has become popular to relabel common technologies as “virtualization” for marketing reasons and this has unnecessarily complicated the issue.

True virtualization refers to the virtualizing of entire operating systems.  Wikipedia uses the term platform virtualization and I will as well.  Technically we could refer to this as “System Virtualization” or “Operating System Virtualization” to distinguish it from loosely-related technologies that may arguably have the right to also use the same general term.

The basic concept of platform virtualization involves running an abstraction layer on a computer that emulates the hardware itself. Through the combination of abstraction and emulation we get what is known as a virtual machine.  This virtual machine is a completely working “computer” onto which we can install an operating system just as if we were installing onto the bare metal of a dedicated machine.  Instead of being limited to only installing one operating system image per computer we can now, with platform virtualization, install many copies of the same or disparate operating systems onto the same piece of hardware.  A powerful concept indeed.

The obviousness of the utility of this technology begs the obvious question: “If platform virtualization has been available since 1968, why is it only becoming popular and important recently?”  This is an excellent question.  The answer is actually quite simple.

Traditional platform virtualization technologies require a lot of support within the computer hardware itself.  IBM has been building this type of support into its mainframe systems for decades and large UNIX vendors like Sun have been providing this in their high-end UNIX servers for years as well.  These systems are highly specialized and typically run their own custom operating system(s).  Generally only large IT shops could afford servers of this magnitude and small shops did not have ready access to these technologies.  For those IT professionals who have worked with this type of equipment in the past the idea of virtualization was often so ingrained into the platform that it was often discussed very little as it was seen as simply an aspect of these high-end server systems and not necessarily a concept in its own right.

What has changed recently is the move to bring platform virtualization to the commodity hardware space occupied by the AMD and Intel (x86_64) processors used by the majority of small and medium businesses as well as larger enterprises.  The first move was to use software alone to make this possible on the x86 processor family.  The early players in this space were VMWare and Microsoft with products like VMWare Workstation, Virtual PC, VMWare GSX and MS Virtual Server.  These products showed that no special hardware was needed to effectively virtualize whole operating systems and began to allow companies of all sizes to experiment with the concept of virtualizing their existing commodity platforms.  This form of virtualization is known as “host-based virtualization” as it requires a host operating system on which the virtualization environment will run.

Following on the tail of these software-only solutions the big processor vendors in the commodity space, AMD and Intel, began building virtualization capabilities into the processor allowing for more flexibility, security and performance and bringing the commodity x64 hardware market much more in line with the traditional offerings from the other processor families common in big iron servers.  By doing so the virtualization market has really exploded both from the vendor side as more and more vendors begin offering virtualization related products and from the customer side as virtualization begins to be better understood and its use becomes more commonplace.  With the latest rounds of purchasing most small IT shops have purchased servers, and often desktops, that support hardware-level virtualization even without intending to prepare themselves for a move to virtualization making the equation often tip in that direction naturally.  This hardware-supported virtualization model is called “hypervisor-based virtualization” as all operating systems run on top of a tiny kernel called the hypervisor and no traditional operating system runs directly on the hardware.

Now that we have a good idea of what platform virtualization is and why it is now available to us as an option we will look at why platform virtualization may be beneficial to us in the small and medium business space.

There are two things that we can readily virtualize (without getting esoteric or starting to virtualize our routing and switching infrastructure) – servers and desktops.  By far the easier and more obvious choice is the virtualization of servers.

Virtualizing the server infrastructure, or part of it, is the first place that most IT shops look today as a potential for virtualization.  Most companies find that the majority of their servers are extremely underutilized with excess CPU, memory and drive capacity sitting idle while additional workloads fail to find a home due to budget constraints, space or implementation time.  Virtualization to the rescue.

Through virtualization we have the opportunity to run several virtual servers on a single piece of server hardware.  We could virtualize just a single server system but this would not gain us any utilization advantages or we could, in theory, virtualize hundreds of servers if our hardware could handle it.  Typically, small businesses can virtualize several typical servers roles onto a single physical server.  Virtual machine density is, of course, determined by load characteristics as well as by the available hardware.  Virtualization uses a lot of memory and storage, obviously, and so careful planning must be made.  Memory and storage are relatively inexpensive today and are certainly vastly less expensive than purchasing additional server hardware and paying to support it.  It is not uncommon for a small business to easily virtualize half a dozen servers on a single piece of hardware at a minimum and a score or more is not an unreasonable number to hope to achieve.

Many small shops instantly jump to the conclusion that virtualization requires expensive SAN storage.  This is not the case at all.  Virtualization provides a range of benefits even without using a SAN storage infrastructure of which shops can take advantage immediately.  There are, of course, some significant advantages available by using SAN in conjunction with virtualization and high availability or load balancing technologies.  Often, though, these high availability and load balancing capabilities are additional features that did not exist prior to virtualization and are not necessary in order for a shop to see significant benefits from virtualization but do present an opportunity for future improvement when and if budgets allow.

Small businesses will see many advantages from virtualization immediately even doing so on a small scale.  Some of these benefits are obvious and some are less so.

Our first advantage is that of hardware cost as I mentioned above.  By eliminating the need to purchase and support expensive server hardware on a per operating system basis we can now deploy more systems at lower cost per system.  In many cases this is not only a cost savings but will also provide greater funds necessary to move from more spartan servers into fewer but more enterprise class offerings with important performance, stability and support features such as integrated power management and KVM over IP from an out of band management console.

Our second advantage is the cost savings from reducing power consumption.  It is very trendy, and for good reason, for companies to be concerned with how “green” they are today and IT virtualization plays a key role in the greenification of the department.  The addition of virtual machines onto a single physical server typically represents a trivial, if even measurable, increase in power draw.  Adding additional physical servers, of course, adds a significant amount of power consumption even for systems that are lightly used or used only occasionally.

Our third advantage is in reducing backup complexity.  Virtualized servers can be backed up using completely traditional methods such as file system level backups from the operating system itself as made popular by traditional backup systems like NetBackup, BackupExec, Amanda, Bacula and others.  So if we desire to stick with current backup strategies we can without any additional complexity, but if we want to move to image-based backups we can do so quite easily.  Using system images as backups is not necessarily new or unique to virtualization but virtualization makes this far more obvious and accessible for many users.  In fact, with virtualization system images (a copy of the entire system, not just of its individual files) can be taken using nothing but the regular filesystem – no special software needed.  A complete system backup can be taken by simply shutting down the virtual server, making a copy of its virtual filesystem – often a single, large file, and starting the system up again.  Restoring a system can be a simple as copying an image file from a backup storage device to the virtual server and starting it back up.  Restore done.  System back online.  This is as simple as it gets.

Our fourth advantage is in the ease of provisioning.  Building a new server operating system directly on hardware is a time consuming venture for most shops.  This is especially true if there are any surprises with new hardware type that has not been used previously.  There may be missing drivers or special operating system settings and parameters needed to support the hardware.  With virtualization the target platform is always identical removing many surprises from this process making it both faster and more reliable.  In many cases deployment is also faster simply because the process of preparing the base machine is so much faster.  To kick off a manual install of Linux on a traditional physical server I must purchase said server, install into rack, connect power and networking, provision networking, turn on server, update firmware, configure out of band management system, burn in hardware, install installation media and begin installing.  Or from some virtualization environments I can simply kick off the entire process with a single command at the command line.  Deploying a new server could go from hours or days to minutes.  This does not even begin to address the simplicity of cloning existing systems within a virtual environment.

A fifth “soft” advantage of virtualization is that there is quite often a significant software cost savings when virtualizing.  Some vendors, like Novell with Suse Linux, allow you to virtualize as many servers as you want on a single physical machine while paying for only a single machine license.  Red Hat gives you multiple installs but not unlimited like Novell.  Microsoft has a range of virtualization pricing options depending on your needs including an unlimited per processor deployment license.  In a worst case scenario you will need to pay for additional operating system and other software licenses exactly as if you were running the same machines physically but in almost all cases there is more pricing flexibility and often dramatic cost reductions for multiple virtualized hosts.

A sixth benefit is in the ability to “roll back” an entire operating system.  Most virtualization platforms allow for a concept of taking a system snapshot, making changes to the active system and then restoring the system back to its original state when done.  This is great for software testing and especially for the testing of operating system patches or any critical update process where something going wrong could cause your system to become unresponsive and potentially not repairable.  The ability to go “back in time” to the latest snapshot, taken seconds before the patch application or risky configuration change can be a lifesaver.  Of course taking an image backup could be used in the same way but snapshots allow for even more rapid recovery due to their “proximity” to the original filesystem.

All of these aforementioned benefits come with a move to virtualization and do not require additional cost for software or hardware.  If our budget allows and the need exists there is also the option of adding one of more virtualization servers and having these servers share a SAN for storage of virtual machine images.  At a minimum this will roughly triple the hardware cost but provides double the processing power and some really amazing features.  The main feature that really makes this solution impressive is the concept of live migration.  Live migration is when a virtual operating system can be moved, while running, from one physical virtualization server to another.  This can be done for purposes of load balancing, disaster testing or to survive a disaster itself.  With some live migration solutions, generally sold as high availability, this migration can happen so quickly that it provides effectively “zero downtime” and even heavily used web servers could survive the loss of a physical server without customers ever knowing that a physical server had gone down.  The transition between virtual machine host nodes is completely transparent to the end users.

There is one major caveat.  Relying upon a SAN in a disaster recovery scenario, of course, creates another point of failure – the SAN system.  So when planning to use SAN to increase the reliability of your virtual machines be sure not to use SAN that is not as redundant or moreso than your servers themselves or you may increase cost while accidentally lowering reliability and performance.

For the average small business it is not unlikely that it will make sense to not only virtualize some of the server infrastructure but virtualize all or nearly all of it.  Virtualization’s advantages are so many and its downsides so few and minor that it is a rare workload in the small business space that would justify dedicated hardware servers.

Now that we have examined why server virtualization makes sense we can begin looking towards desktop virtualization.  Unlike real desktops and servers, virtualized desktops often add a bit of complexity due to licensing requirements especially with Microsoft Windows desktops.

Virtualizing desktops is also somewhat complicated because there are many modes for physically providing desktops.  Obviously once we begin talking about virtualizing the desktop infrastructure we are actually talking about a range of solutions because some device must always exist “on the desktop” providing a keyboard, mouse and monitor which cannot be virtualized and the desktop operating system itself must be running elsewhere.  Even without virtualization this is done (and sometimes marketed as virtualization when, in fact it is simply remote access) very commonly through desktop blades, rackmount desktops or terminal servers.  All of these solutions move the desktop into the datacenter and provide access to it either from thin client front ends or simply via software to remote users existing machines such as users at home logging in to the office.

We will start with the concept of the terminal server as this is the most easily virtualized and the most straightforward.  Whether we are talking about virtualizing the server on which we run Microsoft Terminal Server (now known as Remote Desktop Services), Citrix XenApp or simply a standard Linux remote desktop terminal server we need do nothing more than install that server into a virtual environment rather than into a physical one.  It is really a question of server virtualization not of desktop virtualization – it is only perceived by the end user as being related to their desktops.

The other method of desktop virtualization, “true desktop virtualization” as I will refer to it, is to actually run desktop operating system images on a virtual server just as if they were normal desktops dedicated to a user.  This means virtualizing operating systems like Windows XP, Windows Vista or Windows 7 with each image being dedicated to a single user just as if it was a physical desktop.  We could, theoretically, do the same thing with Linux or some other flavor of Unix but as those systems do not have per user licensing or desktop specific versions and since they always run their desktops in a server mode we would only be able to differentiate between a true virtualized desktop and a Unix-based terminal server in its usage and not by any strict technological means as they are one and the same.  Only Windows truly offers a dedicated desktop model that allows this to happen in this particular manner without the concept of shared access to a single image simultaneously.

Due to licensing restrictions from Microsoft, Windows desktops must be installed one image per user even if technologies exist to make this technologically unnecessary, but still there are benefits to this model.  The big benefits to virtualized desktops definitely go to companies who have employees who roam either internally or even externally.

Using virtualized desktops provides far more control to the company than does providing laptops.  Laptops can be stolen, lost or damaged.  Laptops wear out and need to be replaced regularly.  A virtual desktop that is made accessible from the outside of the company can be secured and protected in ways that a laptop cannot be.  Upgrades are much simpler and there is no concern of the virtual desktop becoming cut off from the corporate network and being unable to be supported by the IT staff.

Almost any worker who uses a computer in the office already has one at home for personal use and often has a  laptop as well in addition to high speed Internet access.  Providing remote access to a virtual desktop at the office therefore potentially incurs no additional hardware expense for the company or staff while easing administrative burdens, lowering power consumption and increasing security.  Some workers will always require laptops but many will not.

For workers still sitting at a traditional desk inside of the company’s offices there is still a need for something physically sitting on the desk that will connect the keyboard, mouse and monitor to the newly virtualized desktop.  This could be an old PC that was planned for retirement, a dedicated hardware thin client or even a laptop.  Internal staff can then move around the office or between offices and sit at any available desk with a thin client and log in to their own dedicated virtual desktop and work exactly as if they were at their own desk.  They can then go home and work from there as well if this is allowed.

Like virtualized servers, desktops, if the need is warranted, can be easily backed up using either traditional means or by simply taking complete system images.  The flexibility is there to do whatever makes the most sense in your environment.

With the complexity and surprise cost of licensing as well as lack of ability to completely do away with hardware on the desktop except for solely remote users, desktop virtualization is hardly the no-brainer that server virtualization is.  Desktop virtualization will require careful analysis on a case by case basis to determine if it will meet the cost and usability needs of the individual organization.  Most organizations who choose to go this route will likely opt to only partially virtualize – using it only in cases where it makes the most sense such as roaming users and remote workers while keeping traditional desktops for those users who would seldom be in a position to take advantage of this technology.  Using terminal server options will often be far more common than “true desktop virtualization” which often makes sense only for power users, developers or to support certain applications that work poorly in a terminal server mode.

There is a final usage of virtualization that warrants discussion if only because it is important to understand its use in the business environment.  This final type of virtualization is not used to put operating systems into the datacenter on server hardware but instead is used to run additional operating system images on traditional desktops and laptops.  This is a common scenario for people who need to test multiple operating systems for support or development.  It is not useful for production systems and is generally outside the scope of this discussion.  It is a highly useful use of the technology but it is rather a niche scenario primarily useful for compatibility testing.

In all of this discussion there has been, somewhat conspicuously, no mention of Apple’s Mac OSX products.  There is a reason for this.  Apple does not license Mac OSX so that it may be virtualized on non-Apple hardware and Apple does not have an enterprise-ready virtualization product ready for its own platform.  The only way to virtualize Mac OSX is to purchase full, additional licenses for each operating system instance thereby eliminating most of the cost benefits of this approach and to run it on a host-based virtualization product such as VMWare Fusion or Parallels which are designed for use on top of a desktop and not as a server-class product.  This is a major gap in the Mac OSX portfolio and one of the ways in which Apple continues to lag behind the rest of the market in capability and in its understanding of its business customers’ needs.  If Apple were to change its licensing strategy around virtualization Mac OSX would prove to be an extremely popular and useful operating system to virtualize both from the server and desktop perspective.

Virtualization is a great opportunity to lower cost and raise productivity while reducing risk for businesses of any size and with budgets as low as zero.  Many technologies promise important improvements for businesses but most create questionable value while incurring real cost.  Virtualization brings real, measurable value while often costing nothing and often reducing spending immediately.  For many businesses virtualization is the technology that they have always dreamed of and is, in fact, available today.

  • Share/Bookmark
Scott Alan Miller

The SMB IT and Vendor Relationship Dilema

When most people compare enterprise IT and the small business IT markets they generally think about size and scale.  Enterprise environments are huge and small business IT often consists of just one or a few IT professionals holding a company together.  The differences between these two classes of environments are much deeper than just size.  Thinking of the small and medium business market as being small-scaled enterprises is a great way to misunderstand what this market is all about.   There are fundamental behavioral differences between these organizational types and I would put forth that this behavior is likely a far better determinant between what constitutes a small or medium business and what constitutes an enterprise business from an IT perspective.

One of the places in which this difference in behavior is most visible is in vendor relationships.  In the enterprise space, as well as in large businesses, vendors act very much as a partner with the corporate IT department.  Often vendors will have dedicated representatives who spend some or possibly all of their time at the customer site and are available to answer questions, make contact with support, provide input and guidance – whatever is needed by the IT department as it relates to that vendor’s products and in some rare cases even outside of the scope of the vendor’s own products.  In exchange the vendor has nearly constant access to the “ears” of IT and management in order to inform them and to sway their opinion in favor of said vendor’s products.  This also gives the vendor direct access, in many cases, to the “on the ground” IT people who are using their products and providing them with critical, non-management feedback.

In many ways this relationship causes “the conversation” between the vendor and the “market”, as proposed by Levine, Locke, Searls and Weinberger in their groundbreaking 1999 tome “The Cluetrain Manifesto”, to take place in-person, in real-time in a way that is very traditional and effective.  When the company wants product information it simply contacts its vendor representative and that rep will provide samples, get documentation, give a presentation, organize training sessions, obtain roadmaps and more.  If the products do not meet the company’s needs the feedback is immediate and meaningful.  The relationship is symbiotic and everyone gains from the tight communication channel that is created between the enterprise IT department and their vendors.

The small business market sees none of this.  There are many reasons for this.  The scale on which the SMB IT department operates does not allow a vendor to dedicate a sales resource, let alone a technical resource, to a single client.  This one, simple difference breaks the communication channel leaving SMB IT departments in a far different position than their enterprise counterparts.  Any conversation held between an SMB IT manager and a vendor is an ad-hoc, temporary conversation.  Vendors do not get to know their clients.  They don’t have a deep understanding of their business.  They don’t see their clients as individuals but as a pool of consumers more akin to the standard, personal consumer market than to the enterprise where each customer is well known and appreciated individually.

The differences in interaction are not solely from the vendor’s perspective.  In the enterprise the IT department typically has resources with time to dedicate to interacting with vendor representatives.  Technical support roles such as server administrators may work directly with sales and engineering resources for support issues and purchasing recommendations while architectural professionals may use vendor representatives to assist in capacity planning, system design or to establish performance metrics.  In the SMB there do not exist these dedicated internal roles and the available IT resources are often overworked and spread too thinly between many different tasks leaving little or no available time to focus on single issues such as these even if the vendors were to provide such resources.  Enterprise departments often manage to even allow regular, “in the trenches” technical staff to attend sales luncheons and other vendor-sponsored events only loosely tied to their job functions.  In the SMB space this is all but unheard of.

Another key difference between the SMB and enterprise markets is in the way that they purchase for IT.  Enterprises generally view their purchasing process in terms of services.  These may include warranty services, datacenter management, software customization, hardware leases, software customization, etc.  The small business market generally sees purchasing in terms of products – either hardware or software.  Small businesses think in terms of buying desktops, monitors, servers, software licenses, etc.  Small businesses purchase the same whether buying directly from their vendor, from the channel or from the local store.  The transactions are very simple.  Enterprises think of a server in terms of its monthly support cost and total lifespan while SMBs simply see a price tag.  This does not mean that SMBs never purchases services – only that they do so typically in a very up-front, set price sort of way although they typically purchase far fewer services than do enterprise IT departments.

Enterprise IT environments have the distinct advantage of large scale peer interaction both internally and externally.  IT professionals working in large environments are constantly learning about new products, technologies and techniques from their counterparts within their own organization as well as from peers in competing organizations in their market verticals.   This gives enterprise staff an advantage in working with their vendors because they see how these vendors interact with their peers locally and elsewhere and get feedback on how other vendors in competing areas work with their clients.  This creates a competitive market for vendors based on their level of service to their clients.  In small and medium business there is very little insight into these relationships at other, similar companies.  SMBs naturally do not get interaction with a direct peer group.  At best they can hope for peer support groups for organizations of similar size, but even that is extremely rare.  Vendor relationships with the SMB market are very much isolated from peer review and market pressures.

SMB IT professionals seldom get a chance to attend industry events like their enterprise counterparts either.  They often do attend some but few by comparison.  This provides fewer opportunities for SMBs to learn about vendors with whom they do not already have a relationship.  This is very beneficial to big vendors like HP, Dell, IBM and Microsoft who need no introduction to any IT professional, but smaller vendors, new vendors and niche vendors will often find it hard to make SMBs aware of their existence let alone find an opportunity to discuss their products and services directly with them.  Making connections between SMBs and vendors capable of meeting their needs is a significant challenge in most cases.

SMBs also suffer from not having industry publications and other vertical resources available to them in most cases.  SMB IT managers may use general resources from the IT field such as technology publications and online magazines to investigate what others in their peer group are doing, but targeted materials designed specifically for their technology needs are rare if not non-existent.

Another difference in how SMB and enterprise IT departments behave is in their driving force behind purchasing.  Enterprise customers typically purchase products strategically.  This purchasing may be driven by a desire for datacenter consolidation, power reduction, features, easing administrative burdens, market pricing advantages and more.  Careful cost analysis will often cause them to buy opportunistically and a tightly coupled vendor relationship helps to enable this.  SMBs, on the contrary, are typically tactical (demand-driven.)  They purchase new products when the old are no longer serviceable, no longer meeting demand, no longer supported or additional capacity is needed.  They will seldom buy when market pressures make purchasing most advantageous but will do so quite suddenly with relatively little research leading up to the point of spending.

The SMB market is very likely to be keenly aware of the bottom line of any purchase.  This seems obvious but in the enterprise space there is normally much more room for a technical specialist to ask for features that carry extra cost because they simply feel confident that they will be beneficial.  Enterprises are often more likely to trust the hunches of their technical staff and to pay for “soft benefits” that are not easily quantifiable.  SMBs will almost always look at the bottom line and if a feature does not meet a clear requirement or provide a rather certain return on investment then they will typically opt for the lower priced option.

The final difference that I would like to address is in how prices are determined.  Enterprise customers typically negotiate a blanket discount rate that applies to everything that they purchase from their vendor.  Getting pricing on new products or price comparing many products is easy.  Very easy.  Pricing for the enterprise is quite transparent making it very simple to do cost analysis on one solution over another.

In the SMB market prices are generally negotiated on a purchase by purchase basis.  Because of this SMB IT departments generally have only a very general idea of the price differences between two different solutions – especially if those products come from two different vendors.  Gathering enough data to do a large cost analysis study is both time prohibitive and ineffectual as prices continuously change and vendors will change discounts regularly based on other factors and behaviors.  SMB IT managers cannot simply go to a single web site and look up many different discounted prices and do a quick comparison of many different products giving them a strategic disadvantage over their enterprise counterparts.

This leaves us with a significant challenge.  Now that we see why small and medium businesses are fundamentally and behaviorally different than large enterprise businesses we have the obvious question of “how are vendors and SMB customers going to overcome their natural barriers?”

To some degree there is no simple answer.  Both vendors and small business IT managers need to be aware of how vendors and their customers behave and think so that they can begin moving toward each other in a meaningful way, but this is only the first step.

Vendors need to have dedicated small and medium business representatives who specialize in the needs of this market.  These need to be professionals who have truly studied the market and understand how very small and moderately small businesses behave, what products are generally in use, what their architectures normally look like and more.  Vendors often think that SMB IT managers spend their day thinking about ERP, CRM, rapid disaster recovery planning and datacenter consolidation problems as do enterprise CIOs but, in fact, most are concerned with desktop management, virtualization, basic security and maybe even purchasing their very first server!  Vendors need empathy with the small business market in order to service it well.  Even vendors with amazing products that are perfect for this market often fail to inform their potential customers on when these products may make sense for them or may lack the ability to support them in the configurations that make the most sense.

Most importantly vendors need to find a way to join the conversation (as put forth in “The Cluetrain Manifesto”). In the enterprise space the conversation takes place inside the organization as well as in peer groups and conferences.  It is everywhere and finding it is simple.  Small businesses struggle with joining the conversation themselves – mostly because they cannot always find it, but it is there.

A perfect example of where this conversation is beginning to emerge is in online technology social media platforms like the SpiceWorks Community.  This online community has hundreds of thousands of small and medium business IT professionals and managers online and engaged in ongoing discussions on everything from low level technical problems and architecture concerns to product selection and vendor relationship management.  A few progressive vendors have joined the community and are interfacing with their customers and potential customers in a mode that, in many ways, mimics the behavior found in the enterprise.  Suddenly vendors and customers have an opportunity for personal interaction and open dialogue.

Through this conversation between vendors and customers there is a real opportunity for vendors to learn about the needs and desires of their customers, interact with customer peers, share resources and, most importantly, simply have an open discussion where concerns and needs can be exposed and addressed.  Customers have questions, often a lot of them.  There is not time during a sales call requesting pricing for the customer and the vendor to get to know one another and become acquainted with each other’s needs and offerings.  Through ongoing conversations, not only when a customer is considering an immediate purchase but on a regular basis, the relationship between vendor and customer can be formed allowing them to understand one another, feel comfortable reaching out with questions and suggestions and more.

Vendors have more than simply the chance to answer product questions when they are part of a larger conversation.  They can also provide input into conversations that are not necessarily directly related to their own products.  They can provide insight into larger architectural and design decisions.  In many cases they can take the time to explain how their products work or why they are valuable to their customers.  It is not uncommon, especially in the SMB space, for potential customers to have no previous knowledge of products that are available to them or if products would apply to them, work in their environment or integrate with their architecture.

Because the conversation is an opt-in experience vendors can talk with customers or potential customers without the need for a sales or marketing interface.  The customers are ready to hear about products.  They want know and they want to learn.  This is a marketplace where sales lead generation is already done simply by the fact that the customers are present.  They have already given the vendor their ear.

Learning how to behave in this open conversation marketplace is difficult for many vendors – especially those that are very well established large businesses. Adapting is critical as those companies that are perceived as caring about their customers will have a significant advantage over those companies who appear to find it a burden to stoop to interacting with small clients.

Large businesses are accustomed to keeping the SMB market at arm’s length often arguing that the “channel” – the reseller and system integration market – was their interface to small business.  The channel, however, acts as a chasm keeping small businesses from ever speaking directly to their vendors causing both to rely on a third party, who may not share any common interest with either, to broker any semblance of a conversation.  The channel is not incentivized to act in the interest of either party and will likely only present products and services that they themselves support and those with the greatest profit margins rather than exploring niche product options and exotic solutions that may be a better fit.  The interest of the customers are then not passed back to the vendors leaving the vendors guessing blindly what products and services would be useful to the SMB marketplace.  The lack of experience with SMBs often means that vendors are completely unknowledgeable about their customers or in many cases simply do not even have those customers.

A perfect example of this breakdown in communications is with IBM.  I watched an active online conversation involving IBM where a large group of heavily experience SMB IT professionals were discussing IBM and its place in the SMB space – what products it offered, how they would compete with other vendors and IBM’s specific relationship with small businesses.  In this conversation I heard repeatedly people speak about IBM’s only SMB focused offerings being its desktops and laptops.  I was shocked, as I suppose was IBM itself, since IBM stopped manufacturing these products many years ago having sold that division to Lenovo.  Even experienced IT professionals taking an interest in IBM, enough to participate in what evolved into a virtual panel discussion on their role in the market, were kept so far removed from IBM itself that they were unaware of even who IBM was and what they offered in the market.  A significant eye opener for everyone.  Likely this breakdown in market communications has been caused by IBM’s reliance on the channel to provide them an interface to their customers and that channel finding it better to sell Lenovo products as IBM products to customers who know the name IBM but do not know Lenovo than to take the time to educate their customers.

IBM is certainly not alone here but with their relatively recent divestment of their desktop and laptop business to Lenovo has created a unique and dramatic challenge in their interface to the SMB market.  IBM’s key competitors, Hewlett-Packard and Dell, use their desktop, laptop, display, networking and printer products as their key “in” with SMB customers and then, once chosen as a vendor, are able to make the relatively rare server sales to this market as well.  IBM has the challenge of selling servers and services to a market that is guaranteed to be buying its desktops and other products from a competing vendor.

Sun (now a part of Oracle) has long faced this same challenge in this market.  SMB IT managers understand desktops and laptops well – this is their bread and butter, what they deal with primarily every day.  Most SMB concerns are desktop related and the bulk of their purchasing is done there.  SMBs do not buy servers in large quantities with rare exception and using a different vendor for infrequent server purchases, which would involve separate vendor relationships and managing different support contracts, is not something that SMB IT managers are going to seek out.  Companies like IBM and Sun need to be involved directly with these customers and make them aware of their unique product offerings, such as Power and Sparc platforms in this example, to even have customers understand who they are and what they may offer.

This issue, hardly unique to IBM and Sun, is exacerbated by the use of the channel.  SMB IT shops will generally only turn to one system integrator, managed service provider or vendor to supply them with hardware.  Since PCs drive SMB IT this means that SMB shops will, by necessity, be turning to managed service providers who are partnered with someone who supplies desktops.  That then makes it rather unlikely that those service providers would additionally be partnered with someone like IBM or Sun.  This then, in turn, causes that service provider to automatically recommend products only from the vendor(s) with whom they are partnered further isolating customers from potential solutions from alternative vendors.  This isolation can be mitigated through direct vendor to customer relationships even if purchasing itself is still handled through a channel provider.  It is in both the vendor and the customer’s interests to interface directly and to engage in a conversation.

It is not uncommon to see IT managers choose a vendor based primarily upon that vendor’s willingness to engage in an open conversation.  Customers like vendors with whom they have a relationship.  They really like knowing that when something goes wrong or when a great new, but not entirely understood, opportunity arises that they can turn to a vendor representative, especially in an open community like SpiceWorks, and ask them for assistance or guidance.  No one expects the representative themselves to have all, or even any, of the answers.  They expect that person to have the resources necessary to reach out internally at the vendor and engage the right people.  Not only is this method friendly and cost effective but it is also very low stress.  Customers often don’t know where the problem may reside and do not have contacts internal to the vendor, unlike enterprise customers who often deal with specific issues so often that they know the necessary resources at the vendor, and without a representative to whom they could turn they may be left without the necessary contact information or channels to get the assistance that they need.  In some cases this may result in customers feeling that the product is poorly supported or just does not work and in others could result in new opportunities being lost or the customer turning to another vendor whom they know offers a workable solution.

While the online SpiceWorks community is hardly the only venue for vendor to customer interactions it is rapidly becoming a unique place, do to its scale, reach and unique SMB focus, where vendors and customers can make connections, join in open discussions, create relationships and get support.  The community is extremely large, over 700,000 IT professionals all from the SMB ranks and is rapidly expanding both with its online presence but also with local users groups and regional SMB IT conferences – all of which present opportunities for vendors to interact with the SMB marketplace in new and exciting ways.  SpiceWorks represents, I feel, a key component in the future of vendor relationships in the SMB IT market.  SpiceWorks acts as a broker to the conversation providing the venue and framework necessary to make customer/vendor interactions as simple and valuable as possible.  As the community continues to grow and as more vendors decide to become a part of the conversation I expect to see the value of this forum expand exponentially.  It is in communities like this that those vendors serious about the SMB IT market will succeed in differentiating themselves and engaging current and potential customers.

  • Share/Bookmark
Scott Alan Miller

The Dangers of Blade Servers in SMB

Blade Servers are the hottest trend in datacenters today.  I am sure that you have heard the hype: lower cost and better efficiency.  To be sure, blades have come a long way in the last few years and are looking better than ever, but considering putting blades into your own business is something that should be considered very carefully.  There are many hidden dangers inherent to the blade concept that are often overlooked and these hidden dangers can come back to haunt you long after you have committed to the idea of blades.

Before we look into blades themselves I want to discuss what blades are.  According to Wikipedia: “Blade servers are stripped down computer servers with a modular design optimized to minimize the use of physical space. Whereas a standard rackmount server can function with (at least) a power cord and network cable, blade servers have many components removed to save space, minimize power consumption and other considerations, while still having all the functional components to be considered a computer.”  It is important to define blade servers because it has become common, especially in the used server market, for resellers to use the term blade to refer to standard, 1U and 2U rackmount servers in the hopes of confusing customers new to the blade market.  Blades are a specific hardware category that requires the use of an enclosure and are not simply “small” servers.  Blade servers use shared components in the enclosure, such as power supplies and remote management consoles, reducing the components necessary in each individual blade server.

The first danger of blades is cost.  Blade enclosures are generally very expensive even though blades themselves are often less expensive than their rackmount counterparts.  In a quick price comparison of a large blade vendor’s offerings the enclosure was approximately $5,000 and could hold a maximum of eight blade servers.  Each blade was roughly $500 less expensive than the matching vendor’s rackmount server of the same or similar specs.  This means that a fully populated blade enclosure, at list price, from this vendor would cost $1,000 more than the equivalent computational power in traditional form factors.  And every blade slot not populated would be an additional $500 deficit.

The cost of blades is not just a total cost factor.  Blade enclosures, often holding eight to sixteen blade servers, need to be purchased up front.  If you need enough servers to match the capacity of an enclosure this is not a factor, but if you are looking to buy only a single server now you may be making a significant investment in proposed future server farm growth.  This means increased risk as well as an investment against the time-value of your dollar.

Hardware cost is always a difficult number to nail down.  Stated prices from the vendors rarely reflect reality and, as most companies know, dramatically lower prices are available if you demand them.  I have known companies to get their blade enclosures for free, for example, which completely changes the cost equation of blades.  But in the same breath one must remember that if a blade enclosure is available for free that serious discounts on traditional rackmount servers are likely also available.  So the list prices are often a good judge of relative prices even if not absolute ones.  Your mileage will vary – so due diligence is necessary to create a cost analysis appropriate for your given situation and the deal that you receive from your vendor.

The second danger of blades is technological obsolescence.  Unlike traditional racks which have gone practically unchanged for many decades, blade enclosures are new and relatively dynamic.  Several generations of blade enclosures have come and gone since their inception in 2001 and each subsequent generation, thus far, has required shops to replace their enclosures to support new blade servers.  This is a high risk if you are not buying servers often enough and in large enough quantity to justify the technology churn in the enclosures.  This rate of change is slowing as the technologies mature, but risks remains.  When doing a proper cost analysis of blade servers this rate of change needs to be factored.

The third danger is vendor lock-in.  Traditional rack technologies are vendor agnostic.  Most shops will mix and match not only servers but batteries, routers, switches, monitoring equipment and other gear into their racks.  Blades are vendor specific.  For a large enterprise this is of little or no concern.  In a small shop with a limited number of servers it can be crucial not to give up the ability to use different vendors and technologies.  This can be a limitation on technology but also is a limitation on leverage to obtain premium vendor pricing discounts in the future.

Take, as an example, a shop that wishes to run HP Integrity blades with their Intel Itanium processors today.  They invest in blade enclosures and begin using them.  In three years they purchase software that runs on Sun UltraSparc or IBM Power processors.  In order to use blades each of these technologies will require their own brand of blade enclosure and will significantly increase the risk in a small shop that enclosures will not be able to be fully populated.  There is much more flexibility in technologies using traditional rackmount servers because each vendor generally supplies one set of RISC or EPIC-based systems and one set of AMD / Intel-based commodity systems.  If you want more than that blades will become quite difficult for a small shop to manage.  I have worked first hand with shops that use multiple technologies like this on a regular basis making blades a most difficult choice today before considering potential future platform desicions.  The use of Apple Mac OSX must also be mentioned as Apple does not provide blade servers so any deployment of OSX-based servers cannot be integrated into a blade enclosure.

The fourth danger is the shared backplane and other key components.  A blade enclosure, while generally built with massive redundancy and with truly amazing design, still represents a single point of failure that must be considered.  If your enclosure fails you do not lose just a single server but as many as sixteen physical server platforms.  With rackmounts servers you can add redundancy simply by adding an additional server – typically one matching server for each server you need.  With blades you have to have redundant enclosures for the same level of reliability.  Again, for a large enterprise this is trivial and obvious.  For a small business the need to suddenly own dual enclosures for full redundancy will often result in simply foregoing that level of protection and increasing risk.

The fifth danger is in the cost of flexibility.  Small IT shops may not often move their equipment around.  The option is generally there, though.  If a small business owns three servers and replaces one with a shiny, new unit the option is almost always there to redeploy the old server to another role elsewhere in the company – perhaps in a branch office.  With blades the old blades can only be redeployed in a location that has a blade enclosure matching the one from which the blade was pulled.  This is a cost of lost opportunity late in the server lifecycle and often completely ignored in cost analysis of blades.  If there is not a spot ready for an older server it is far more likely to be discarded in the blade model rather than redeployed unless the company is large enough to have many enclosures available all of the same generation and with available space ready to accept an older server.

The sixth danger of blades is the high cost of storage.  Storage is a subject all its own these days with SAN, NAS and DAS as possible options.  Shops of all sizes are moving to SAN and NAS quickly and with enough network storage in place this can alleviate much of the storage risk associated with blade servers.  Many shops, however, use circular reasoning and justify SAN because of the blades and blades because of the SAN.  Taking a holistic view of the server and storage picture is crucial.

A typical blade server can house only one or two 2.5″ SAS or SATA drives.  This is far less than a typical rackmount server would provide as potential storage space.  It is common to find eight to sixteen drive bays available in popular 2U rackmount configurations – sometimes using 3.5″ drives rather than 2.5″ drives.  One popular and very cost effective 2U server can hold 28TB of low-cost storage on fourteen spindles.  You cannot put this type of storage into a blade enclosure.  Because local drive space is simply not available, blade server owners are forced to use minimal direct attached storage and use SAN or NAS instead even when DAS would provide better performance and cost (otherwise) for that particular application.

To bridge this need most blade vendors provide storage blades – blade servers that act as tiny, low volume SAN devices and fit directly into the blade enclosure.  These units are generally of rather low capacity, often just six drives, and rather expensive compared to other means of providing storage.  Additionally they use a critical enclosure bay removing one of the potential slots necessary for a blade enclosure to provide server density.  So an eight bay blade enclosure with two small storage blades would only be able to house six blade servers.

Obviously buying a blade enclosure does not mean that you have given up the ability to also use rackmount servers when appropriate.  You can continue to mix and match.  But to obtain the numbers necessary for a small business to cost justify the blade infrastructure often requires that purchases lean heavily towards blade servers to fill the enclosure(s) as densely as possible.

Much of the danger of blades is in the potential for lost opportunities.  Small businesses especially function best and compete most strongly against larger businesses by being flexible and agile.  Blades are the opposite of agile.  They require large, upfront infrastructure planning that includes technological, physical and geographic lock-in.  Even if a business plans ahead and sees no obstacles to adoption this does not mean that opportunities will not be missed in the future, caused by a lack of flexibility to adapt to changing business conditions effectively.  Once a blade enclosure is in place purchasing decisions almost certainly are made based on the investment already made and no longer on simply what is best for the company.  This doesn’t have to happen but almost certainly will.  The existing investment needs to be protected.  This is the natural reaction to have.

All of this being said, blade servers can still make a lot of sense for certain businesses.  Blade servers generally consume less power than their non-blade counterparts due to their shared system components.  Be sure to consider the power consumption differences in the storage area, however, as blades push power consumption from the server to the SAN and can often be misleading as to where the power is going.  A savings in one place is only valuable if the cost does not appear again in another.

Blades are easy to transport and relocate when enclosures are available.  This can be a bigger factor than is obvious especially when it means that there are several additional staff members capable of relocating a server.  Almost anyone can lift and move a blade server.

When combined with a very aggressive SAN infrastructure, blades can be very beneficial to a virtualization environment.  This combination gives the maximum cost and flexibility advantage to businesses large enough to leverage it.  The SMB market mostly consists of businesses for whom this would be very prohibitive, though, and this solution will continue to be relegated to businesses at the larger end of the SMB spectrum.  Virtualization will, in fact, reduce the number of servers needed by most businesses making it even harder to justify blades to smaller businesses where previously a dozen or more servers would have been needed but today only two to four are needed to not only meet but to surpass earlier service levels.

If you can support adequate densities or get really aggressive vendor incentives then blades can be quite cost effective if you calculate against your risks.  Blades are always a little more risky, but if your cost is reduced significantly in buying them then they may be very much worth the risk in flexibility.  The cost of the enclosure is a key factor here.  If your enclosure is free then suddenly the cost savings of a blade system can be enormous – especially if a large number of blades are purchased providing really good enclosure density.

Blade servers are a great technology and show a lot of promise for the future.  As enclosure lifecycles slow, new technologies emerge, costs are reduced, volumes increase and, hopefully, as vendor-neutral standards emerge I am confident that blades will become the de facto standard in even the smallest datacenters.  I see this as taking at least another market cycle before this will really occur.  Most likely, in my opinion, it will be another five to seven years before the form factor truly displaces the rackmount server in general utility.

  • Share/Bookmark
Scott Alan Miller

Using a Wiki for Quick Documentation

If your business is anything like the businesses with which I normally deal one of the hardest items to tackle is documentation.  This can include all kinds of documentation from human resources processes to accounting practices to core business procedures to the information technology department’s system records.  Businesses need good documentation for many reasons.

Traditionally small businesses simply end up doing without key documentation and have to reinvent the wheel every time something comes up for which the people currently working have not had a chance to memorize the process.  Larger businesses often place their limited documentation into Microsoft Word or Adobe PDF files and store them away in an unsearchable file server or possibly even on paper – putting them into large, ringed binders that no one even knows exist let alone how to find necessary information within.  These are not effective processes, but there is a simple solution.

The solution is a web-based application known as a Wiki.  Most people get their first introduction to a Wiki through the ubiquitous online encyclopedia Wikipedia which is built on a Wiki platform (MediaWiki, to be specific), but this is hardly the only use for a Wiki.  Wikis are simple document repositories designed to allow many editors to easily create and modify online documentation.  The whole concept of the Wiki is about being simple and easy.  The full name, Wiki Wiki, means “quick” or “fast” in Hawaiian.

Wikis have now been around for several years and have begun to become popular in many businesses.  Wikis are generally very lightweight and there are many vendors making both open source and proprietary Wiki products in addition to several hosted services available online.  You can really pick out a Wiki based on your particular needs.  Most Wiki products are free and for the budget conscious business there is no reason to need to consider a Wiki to be a cost center.  This is a simple product that your IT department should be able to roll out for you quickly and easily giving you a documentation repository right away.

At first the idea of a Wiki is a bit foreign to most people.  On the Internet we often encounter Wikis in use for system documentation.  This is becoming increasingly popular. Wikis are often used to allow anyone to log in and make documentation changes.  This can be a good way to get started with your Wiki.  You can also start from the beginning with detailed user access controls allowing only certain individuals to post documentation in the system instead of allowing a documentation free-for-all.  Your needs will depend upon your type of organization.

What makes the Wiki concept powerful is the ease with which anyone can hop on, search for documents that they need and create or modify those documents if they cannot find the information for which they are looking.  The entire concept of the Wiki really encourages staff to make use of the format.  Lowering the barrier to creating useful documentation is the best possible way to get documentation created, and because the documentation is so easy to modify it makes it far more likely that that document will be kept up to date.

A common feature amongst Wiki systems is the idea of tracking changes to Wiki pages.  This means that if someone goes in and makes a change to a page that people using the Wiki system can view past versions of that document to see what changes have been made over time and by whom those changes were made.  This feature also makes it very simple for a system administrator to roll back bad changes if someone is not posting appropriately.

One of my personal favourite Wiki features is the idea of subscribing to a particular Wiki page either through email or an RSS feed.  The subscription model allows any staff members to be alerted to changes to documentation in which they take an interest.  These can be staff members for whom a particular Wiki page is critical to their job functions such as HR managers following changes to the corporate employment policies pages or just interested staff members who want to know when a page changes such as managers subscribing to the cafeteria’s lunch menu page or developers subscribing to a page about a particular software project’s status.

This method is a wonderful way to allow anyone to keep up with any publicly available knowledge without needing to interupt the actual process to view status.  Useful at every level of the organization and extremely simple.  So often organizations do a poor job of keeping everyone “in the loop” who needs to be and with the Wiki subscription model everyone has the opportunity to take responsibility for keeping themselves informed through whatever method is most useful to them.

As I mentioned before, there are many Wiki products available on the market today.  There are enough that choosing one is actually a rather formiddable task.  Some key differentiators between products include their use license, the data store architecture – typically filesystem based or database based, their platform dependence and their integration with other products and authentication systems.  Of course there is also the option of choosing a hosted Wiki service that hosts your Wiki online – mostly this is popular with companies using Wikis as a means of serving their customers rather than for private, internal documentation.  There are so many Wikis from which to choose that the site WikiMatrix is dedicated to helping you choose the Wiki that is best for you.

Before you dive into the world of exploring Wikis on your own I will mention a few that are rather popular and worth looking into early on in your Wiki decision making process.  Popular Wiki platforms include MediaWiki, DokuWiki, TWiki and pmWiki.  These are just the tip of the Wiki iceberg but provide a good look into the features that you should expect to see throughout your search for the best Wiki for your implementation.  The Wiki choosing wizard on the WikiMatrix web site is a great place to begin as well.  Each of these Wikis that I have mentioned thus far are available for free and rather than spending a lot of time studying their benefits you may wish to simply download one or more of them, install them on a spare server and give them a try.

In addition to stand-alone Wiki products like we have mentioned here there are also Wiki engines built into several enterprise content managment and portal systems such as Microsoft’s Sharepoint, Alfresco and Joomla.  For any businesses looking to make a larger investment in an enterprise content management system having a Wiki functionality built into that product can provide a single, unified Intranet web portal interface to serve many different internal documentation and document storage needs.

Wikis are powerful and affordable tools that small and medium businesses can leverage today, even in a climate of budget cuts and uncertainty, to document processes, ease documentation burdens and increase internal communications and efficiency.  It is unlikely that we will see the popularity of the Wiki concept wane but rather they are already beginning to take their place as a staple of the business documentation and communication process.

  • Share/Bookmark
Scott Alan Miller

MicroBlogging for Business

If you mention microblogging to anyone today the first thing that you are going to get is an ear-full about the importance of social media and platforms for enabling the conversation and about customer interaction.  Okay, fine.  Over-hyped and poorly understood buzz that we can probably safely ignore for now.  Social media matters, yes, but spend some time on Twitter and, while a lot of people are talking, you will quickly learn that very few people are listening.  The platform is going somewhere, but right now most of the people talking in the microblogging space are talking about microblogging.  This will pass.  For now we have other concerns that are more immediate.

While I tend to quickly dismiss microblogging as the “next big thing in social media” as mostly hype from the marketing folks trying to convince people to look at them for another ten minutes I do think that the concept of a highly limited, easy to use, microblogging architecture to be one of great potential import to business.

When I talk about microblogging for business I am not talking about the popular notion of sending your intern out to post about your product on Twitter in order to garner market attention.  What I am talking about is using an internal microblogging infrastructure to deliver status about the people in your organization to your organization.  In the same way that companies have internal blogs delivering information to their own staff the microblogging platform can be an internal tool for our organization and not just something that we use to tell our friends across town what we are having for lunch.

Other social communications tools like traditional blogging, instant messaging, email, etc. started as over-hyped social media, even if the term did not exist yet, and ended up becoming standard, well understood business communication tools that are important pieces of the corporate communications toolkit today.  Microblogging will be the same.  And, like all of those communications tools that came before it, this tool is one that your company can start using today to get the benefits years before your competitors catch on.

Microblogging offers a potential boon to inter-team communications in companies of just about any size.  By providing an easily accessible microblogging platform for the use of your team you provide a simple way for individuals and teams to provide small, manageable amounts of status information to the rest of the company in a highly consumable format that is easily understood.  In the smallest organizations, those with less than five people who all sit in a single office, this may not matter, but start adding any additional number of people or start putting those people in disparate locations and suddenly microblogging matters.

Instead of hypothesizing about microblogging out of context let’s dive right into some sample scenarios and see how microblogging for internal use can help your company.  Remember that like many social media technologies, the leading microblogging platform, Laconi.ca, is completely free and something that your IT staff can roll out for you today.

Scenario 1: The Saleman

John is a salesman.  He works for your company but is almost never in the office.  He spends his days on the road, often in other cities.  You are lucky if you have face time with John twice per month.  Several people would benefit from knowing John’s status, but John is incredibly busy and does not have time to manage any extra email traffic.  He carries a BlackBerry but only answers emails from his current and prospective clients during the day and is exhausted at night when he gets back to his hotel room.  He communicates the bare essentials to you, his boss, but allows you to provide the necessary information out to anyone in the company who might need to know what customers need or new accounts might be coming online.  This makes you both a bottleneck and a point of failure.  What if you don’t communicate the necessary information to the right people quickly enough?

The solution?  Microblogging.  If your firm had an internal microblogging platform you could have extended it to John’s BlackBerry (iPhone, Windows Mobile device, regular cell phone, whatever) so that instead of sending you a quick email John could have posted all relevant information to his own microblogging feed.  Then any interested party in your organization could look at that feed to get up to the minute data straight from the horse’s mouth rather than having it unintentionally filtered and delayed.  People who need immediate updates could be subscribed to John’s feed while people who just want casual sales updates from time to time would just visit his web page when they felt it necessary.  Everyone gets the right data at the right time and you have more time to worry about the business itself.

Scenario 2: Software Development Teams

Software development is famous for its extensive need for communication.  Developers are famous for being unable to communicate easily between individuals and between teams.  Software development often requires a great deal of granual status updates at both a team and at an individual developer or manager level.  Microblogging is hardly a panacea for this situation, but it may be a very powerful tool in the communications toolbelt for this situation.

By giving each individual developer their own internal microblogging account they can make quick and easy status updates whenever their current task changes.  Other developers, who need to know on which components work is currently being done, can just subscribe to the feeds of the appropriate developers to know what everyone is doing at the moment.  Managers can know on what each of their team members is working without needing to stop by their desks and interrupting them unnecessarily to do so.

In this model, communications happens more quickly, more thoroughly and with less disruption to staff who are extremely sensitive to disruption and task switching.  Training the developers to make regular status updates – probably just a few per day taking less than five total minutes – will take some time but once it is part of the usual workflow it will make everyone’s life much easier.  It is also a great opportunity for people to solicite and offer help on certain problems.  A developer might post “working on the foo widget and trying to figure out the bar interace” and someone subscribing to their feed might see that and, being the bar interface expert, can shoot an email or run over to their office to help them out before they waste an afternoon reinventing the wheel or looking helplessly for missing documentation.

Scenario 3: General Office Updates

Most offices are bigger than a single space in which everyone can sit down and have lunch together.  Even a relatively small business with two offices or even two home offices could likely benefit from the advantages of simple updates.  It is important for businesses to communicate.  Internal business communications is one of the ways in which companies are able to outperform individuals – by sharing knowledge and tasks between many people.  If each of those tasks is so discrete that you need no communications then you just might be better off working as individuals doing the same tasks.

By the use of microblogging even general office staff can post simple updates a few times per day so that all of the offices have a good idea of what is happening in the other locations.  Whether it is seeing when lunch or meetings are underway, when the office has left for the day, seeing what new projects or challenges have arisen or finding out what customer interactions have taken place that day that information can be used to keep the separate offices working in a unified manner rather than as two completely separate locations with a very poor understanding of what the other one is doing.

Scenario 4: Department Information

If your company is large enough to have separate departments then microblogging may be just the tool that you need to enable departmental status updates to the organization.  This is not an appropriate solution for human resources to publish their latest employee handbook updates but it could be the perfect spot for them to announce the company picnic or open enrollment for benefits.

Many departments’ core function is to supply a needed to service to the rest of the organization.  Human resources, information technology, finance, billing, purchasing, etc. all exist to service the internal business needs of the organization.  If each department had its own microblog feed then it would be easy for each of them to provide simple updates to the entire company.  People might subscribe to individual department feeds, look at the department website when they have an interest or possibly all department feeds would be aggregated onto an employee portal web page or other unified information location to make these updates obvious to everyone.

The information technology department might post a reminder about phishing attacks or social engineering dangers or could post a status update to the email system that is currently down allowing everyone to keep working without spending their time phoning the already overworked IT department and delaying them from fixing a problem on which they are already working full speed.  Purchasing might post a link to a page on new purchasing procedures that may otherwise have gone unnoticed.  Finance may send information regarding a change in the way that employees must file expenses.  Potential examples are numerous.  How often does your organization wish to make a policy or procedure change but find that informing the company of the change can be very difficult once employees have learned the old procedure.  Updating the employee handbook or financial web site do little good if people have memorized the process and no longer reference those materials.

Scenario 5: Mentoring and Employee Growth

One of the less obvious ways in which microblogging can benefit your organization is in the area of employee development.  Senior employees, while posting regular updates to their microblog feeds, provide an opportunity for more junior members of staff, especially new employees and interns, to follow their feeds in order to gain a deeper understanding into the tasks that they complete on a day to day basis.

By giving junior employees the chance to observe their “mentors” in an unobtrusive manner they may benefit from learning how they work, how their time is spent and how they prioritize their days in addition, perhaps, to learning about their interests, what relevant books or articles they have been reading, what websites are important to them and more.  This is hardly a replacement for traditional mentoring but allowing employees to seek out information about other employees that they admire or from whom they wish to learn can be very valuable.

I don’t know the specific communication needs of your business, but I would be surprised to find that it would not benefit from an increase in internal visibility.  Microblogging can facilitate communications between teams, between peers,  between managers and their staff and even between disconnected pieces of the organization.  Microblogging offers a simple, low-overhead, loosely-coupled process that allows every level of an organization to provide status and information to all interested parties within that organization.

Microblogging does, of course, offer additional benefits outside of internal status communications that we have discussed here.  Servers and other IT equipment can post alerts automatically via the microblogging architecture giving anyone interested a chance to see real time failures and alerts on the network that may affect them.  And then there is external microblogging offering status and information out to customers, vendors and interested parties outside of your organization.  But those topics are too broad for this article.

Special thanks to Andrew T. West for his help with this article.

  • Share/Bookmark

Next »