In the post-doctoral academic world there is a saying, “Publish or perish”.  In the IT world the corollary is, “Adapt or perish”.  Both worlds are ruthlessly Darwinian in nature. 

“What”, you may ask, “does this have to do with Office365 and other cloud services?”  Glad you asked!  Office365, Azure, Amazon and others have completely changed the IT marketplace.  The changes are impacting consumers of such services (you) and the traditional providers of the kit that provided the same services on-premise (me, my colleagues and all of our competitors) in a very big way.  For you it can mean significant cost savings as well as access to services that you might not have been able to budget for in that past.  For us it means waving “goodbye” to a general business model that has been in place for decades in what has been known as “the Channel”.

The Channel is the moniker attached to the group of businesses that sit between you, as the end user of IT kit and services, and the distributors which handle the distribution of products from the IT vendors.  We are a diverse group but, as a whole, we have have relied on the age-old model of providing you with kit (hardware, software) and services to build out your infrastructure and then services to keep it all running.  And, on average, we do it all again every three to four years.  There are variations on this theme and there are the “add-ons” such as Managed Services but, for the most part, this has been the Channel model for pretty much the last 30 years or so.

Office365 (and all the others) has blown a gaping hole in this model and it has left those of us in the Channel with the task of having to staunch the bleeding in our business model.  I don’t think it is an exaggeration to say that the next 3 – 5 years will see a massive “clean out” of the Channel with many firms going by the wayside.  Why?  Because they will refuse to adapt to this sea change in the way the IT business operates.

We (itgroove) know that the business is changing on an almost daily basis.  We know that we have probably performed our last on-premise Exchange install and we certainly see the complexion of the SharePoint business changing because of 365 and Azure.  We understand that we have a choice to make of sticking with the old model as long as we can and maximize short to medium term revenue or embrace some new model and “ride out” the short term revenue loss.  Not an easy choice to make from a pure “bottom line” point of view.

We have already made the choice and that is to embrace the changes and find a new path going forward.  We choose to adapt.  This means we keep our customer’s best interests at heart and if going to the Cloud (365 et al) for some or all of their IT needs is the best option for the customer then so be it.  On the surface it may seem like we are cutting our own throat by choosing this path but I don’t believe that is the case.  Today’s IT end user is a much more savvy animal than in the past.  I *might* be able to convince you to go for one more round of on premise upgrades and make that short term revenue BUT it’s also a good bet that will be the last time I get any significant business from you.  Why?  Because you will eventually twig to 365 and its brethren and you’ll be more than a little bit bent out of shape with me that I didn’t, at the very least, present the option to you.

What everyone has to understand is that while the whole landscape is changing and the old models and methods are dying off, the new landscape presents new opportunities.  You will still need “us” in the long run but your needs will be different as will be the services that those of us who adapt and remain will deliver.  SharePoint will always require expertise to maximize its value.  There will be all sorts of needs in the “hybrid cloud” space.  There will still be a small on premise component to support LOB apps that aren’t Cloud friendly.  And, no doubt, other services will appear to meet a whole new set of needs that we haven’t even thought about at this point. 

It’s going to be a very interesting time over the next few years for you and for us.   We will be here to help our customer’s maximize the return on their IT spend be it on premise, in the Cloud or some hybrid.

Adapt or perish!

We are Cloud Friendly.

Everyone nowadays talks about “the Cloud” as being the next big thing that ALL companies should be looking at as a part of their IT infrastructure planning. The problem is that the term, “Cloud”, has become so ambiguous and attached to so many things that it is hard for most companies to get a handle on what it actually is.

In the most simplistic terms, the Cloud is simply the idea that a computing service, whatever that service may be, is provided by an infrastructure that you, as a user, can’t generally put your hands on. OK, I know, that is very vague and that is precisely the point! The Cloud is fuzzy and blurry. The Cloud provides services as you need them and you, as the user, don’t really care where the service actually “lives”.

The interesting thing about the Cloud is that almost all of us have used Cloud services for years and don’t realize it. If you have used an Internet email system (gmail, Hotmail, etc) then you have used a Cloud service. Do you know where Hotmail or gmail files actually “live”? Not likely and it’s a good bet that you don’t care, either. You simply consume the service.

Many people argue that a virtualised infrastructure such as those provided by VMware vSphere or Microsoft Hyper-V are also “cloudy” because you can turn up or turn down services (or capacity) at any time, another hallmark of the Cloud. So, if you have a virtualised environment you should congratulate yourself for having an “internal Cloud”.

We at itgroove would argue the way forward for many of our customers is going to be something of a hybrid between on-premise servers (and these can include the virtualised servers/services) and services that actually do live somewhere “out there” on the Internet. In fact, many in the industry are already talking about a “hybrid cloud” and that is pretty much what we see happening over the next few years for many of our customers.

So, what does this hybrid look like? In simple terms it really means that the services you currently consume within your IT infrastructure will expand so that some services – most likely Line-of-Business app’s (LOB) like accounting programs – will live on in on-premise servers just like they do now and other services – email (Exchange) and SharePoint being the most obvious ones – move out to a Cloud-hosted service through something like Microsoft Office 365. The point is that services and programs are evolving and you as the consumer of these services will have choices available that you have not had in the past. Do you HAVE to go to the Cloud? No. Is it a good idea to move some services to the Cloud? Probably, it all depends on your particular needs and circumstances. Can itgroove help you with migrating to Cloud services? Absolutely! We are Cloud-friendly and here to help every step of the way. If you want to explore your Cloud migration options or if you just want to discuss the whole “Cloud thing” a bit more then please contact itgroove.

As I mentioned in an earlier post, we have been in the process of migrating a customer to Office365 in preparation for their migration from SBS2003 to SBS2011 Essentials.  We decided to move them to 365 well in advance of the server migration itself in order to lessen the “shock” of the migration to all concerned.

For the most part the migration from on-premise Exchange to Office365 hosted Exchange has gone quite well. Our customer opted for the “Small Business Package” for Office365 and we got them set up inside of a day.  One thing we did do was elect to NOT host their DNS via Office365.  This is something that might be confusing to many people when they first look at 365 as it seems like you MUST move DNS to 365 when you first read the set up documentation.  If you read carefully you will find that this is not actually true and you can definitely use your own DNS management.  You do need to create all of the records that Microsoft suggests or many functions of 365 will fail so “read and heed” the setup docs.  In our case we could create all of the required records save one through the DNS management interface at HostPapa (where customer’s DNS is managed"). We had to request a manual record change be made by HostPapa support to complete all the necessary DNS record changes. One thing to note is that we set up the MX record to point at 365 as a much lower priority than the on-premise Exchange as on-premise MUST remain the primary receiver until after the migration is completed.

Once DNS was set up and the requisite 365 test was made against the customer’s domain we were able to start the actual migration process.  365 offers two distinct process for Exchange migration – Cutover and Staged.  A Cutover migration assumes you are migrating everything within the on-premise Exchange to 365 while a Staged migration assumes you are migrating “chunks” of the current on-premise or you expect to be migrating over a long period of time or you expect to run in a hybrid mode (both on-premise and 365) for an extended period.  There is more work involved with a staged migration and it requires the use of a “connector” tool between your AD and 365. A Cutover migration, on the other hand, relies solely on an RPC over HTTPS connection (think OWA) to “slurp” the data into 365.  Our customer had a very small number of mailboxes to migrate so we elected to use the Cutover method.

All users were instructed to clean up their mailboxes so there was only one really large mailbox (just over 6GB) to migrate, all the rest were well under a gig.  We set up a “migration batch” which defined all of the parameters required for the migration and kicked it off.  Within a couple of minutes we could see that 365 was already importing mailbox data.  The migration itself was started in the late afternoon and we allowed it to run until completed.  The following morning it was obvious the migration had completed and it was also obvious that 365 had performed a synchronizing update with the on-premise Exchange sometime after the batch had completed.  365 will perform a synchronizing update once every 24 hours until the migration process is completed and you have shutdown the on-premise Exchange.  This is because until you complete the migration and point the MX at 365 as the primary receiver, inbound email will still flow directly to the on-premise Exchange.  If there is no sync between the two then new email would not make it into 365 while the MX still points at the on-premise Exchange.

In our case as all required mailboxes had imported properly into 365 we were able to make an immediate MX switch and we made 365 the primary receiver for email.  As soon as the DNS record propagated we sent email to a couple of the users from our own Exchange and the emails arrived in the users 365 Inbox within seconds of being sent (we watched for this using 365 OWA).  At that point we connected all users to 365 by creating a new Outlook profile in their Outlook 2010.  All users with the exception of the user with the 6GB mailbox were fully updated within about 30 minutes from the point where there new profile for 365 was created within Outlook.  The user with the large mailbox took considerably longer to fully populate Outlook as would be expected.

Overall, it took about 2 days from start to finish to go form on-premise Exchange to Office365 Exchange.  It took the users a little bit to get used to being prompted for credentials when they logged into Outlook and they also had to get used to the fact that there might be a bit of a delay experienced when opening new items with large(ish) attachments.  Otherwise, it all went much more smoothly than any of us – itgroove or the users – expected.  We have seen an issue with the user with the large mailbox having some weird “connection” issues on start up of Outlook that, hopefully, will be solved shortly (looks like a corrupt profile problem).  That issue aside, it has gone quite well and is certainly FAR easier than any on-premise migration I’ve ever performed between old and new versions of Exchange.  We have a larger migration looming at another customer in a month or so and it will be interesting to see how it compares to this one as they have about 5 times as many mailboxes to migrate.  I’ll keep you posted on our progress.

Everywhere you look nowadays there is a reference to “The Cloud” yet there is no real clear definition as to WHAT “The Cloud” actually is.  You see references to public Clouds, private Clouds, hybrid Clouds … you name it and there is probably the “Cloud” moniker attached to it.  So just what IS “The Cloud”, anyway?

When you come right down to it, most people would equate the Cloud with being a set of accessible services that is not hosted on in-house hardware.  And it just explodes in all directions from that vague description.  And if the services are hosted elsewhere then what on earth is a “private Cloud”???  I can understand why people are confused and headaches start when the discussions starts!

Going back to the just-mentioned vague description, “Cloud” really refers to compute resources that you make use of that are not hosted on your own equipment or maintained in-house.  And let’s add that you should be able to expand or contract the services consumed “at will” (add capability, reduce capability) without giving any thought to the mechanics of doing so.  Yes, there are all sorts of exceptions to that particular general statement but lets agree to use it as the basis for this discussion going forward.

So where does that leave the average small business?  Is it possible to have ALL of your resources out in the Cloud and not have your own servers?  The answer is a qualified “maybe” because in the end it really depends on your line of business applications.  It is a given that “generic” applications like email and websites can easily be Cloud based; there has been a roaring business in that kind of thing since long before the Cloud moniker was bandied about.  And there are more specific applications that are or can be cloud based such as CRM (Salesforce, Sugar) and collaboration (SharePoint through Office365 and other vendors) just to name a few.  But the real roadblock for most organizations are the specific line of business applications that drive their business.  Accounting applications are the big hold back in most cases and/or line of business apps that are bound to an organization’s specific industry or market niche.

We (itgroove) deal with a few accounting firms in our SMB practice and these firms are perfect examples of users of specialized line of business applications that simply don’t exist in the cloud.  Yes, these firms can “cloudify” some of their applications such as email but they hit a real solid wall at what can be done with their public-accounting specific applications.  Applications that still rely on “fat clients” and “client/server” data models don’t lend themselves to a cloud model in any way.  That is not to say that a firm that uses these types of applications cannot move everything they use into a “hosted” environment (note the term “hosted” and not “cloud”) because they can and do all the time but a hosted environment is a much different animal from a Cloud environment.

A hosted solution usually refers to a situation where a firm’s applications and data live inside rented equipment (or a rented virtual environment) in someone else’s datacenter.  In the case of “fat client” applications there may be a Citrix XenApp or Windows Remote Desktop Server (RDS) set up that allows for full fat client operation (as far as the user is concerned) without having massive amounts of data moving across the WAN connection.  In essence, you just move the applications that you would have in-house on your own iron to someone else’s iron in a remote datacenter.  The XenApp or RDS servers then allow your users to run those apps in a remote session on the XenApp or RDS server.  This would be no different than the same process taking place on XenApp or RDS servers in-house, it’s just a matter of WHERE the servers reside.  Obviously, there are other hosted app scenarios that may not involve XenApp or RDS but I’m sure you get the picture.

A Cloud solution, on the other hand, is usually a bit more abstract in the sense that you just connect to the “service”, usually with your web browser, and just start working.  There is no sense of connecting to a server as in the XenApp or RDS scenario,  its just a service.  And with a Cloud service you are never really aware of where your data resides, its just “out there” somewhere. With a hosted solution its a pretty good bet that you know where your data lives (or your tech people do, at the very least).  There are many variations on this scenario, of course, as you look at things such as “platform as a service” (PaaS) and “software as a service” (SaaS) but, again, I’m sure you get the gist of it.  Cloud solutions are just that, “cloudy” and somewhat amorphous whereas hosted solutions are pretty cut and dried.

And that brings us to another point about the Cloud.  In many cases you simply have no idea where your data lives.  In the case of some Cloud providers your data can be constantly shifting around between various global data centers depending on load conditions.  If your operate under some form of privacy law you may actually be legally prohibited from using certain Cloud resources because your data is stored outside of the country of origin.  A concrete example of this would be a Canadian law firm using a Cloud service that stored sensitive client data outside of the country which is an absolute no-no under Canadian federal law (and many Province’s, too).

One other aspect of the Cloud that no one seems to discuss is the fact that there really is no such thing a s a free lunch.  Yes, in many cases, a Cloud-based service or application will look to be much cheaper than the same service or application running on your own in-house iron but you have to look at ALL the costs. When services and applications are moved out to the Cloud the network load generally moves from the local LAN to WAN which usually means you need to beef up your WAN connections which in turn means you have to spend more (sometimes much more) on said connections.  As an example, we have a client that has offices locally in Victoria along with a number of regional offices across Canada and the US.  When they moved from their own internal Exchange servers (there were local Exchange servers in a number of their offices) to a Cloud-based Exchange service they were shocked to see how much their WAN bandwidth jumped (skyrocketed would be a better term).  Their E10 connection locally was almost totally consumed with traffic to/from the Cloud service.  Now, to be fair to all, they made some configuration changes to both Exchange and their Outlook clients which reduced the traffic on the WAN but overall WAN traffic was still considerably higher than before the move to the Cloud service (and this could have also happened with a “hosted” service, just to be clear). 

There may be other costs as well such as subscription fees, use fees, storage fees, the list goes on.  In general, you really just move the dollar costs around going from a mixture of CapEx/OpEx to OpEX only but the dollars, ultimately, still go out the door.  It is even possible over a set period of time that a Cloud solution (or hosted) may actually cost you more than the same solution in-house!  Again, you have to analyze all the costs of the solutions at hand before you can make the decision as to whether or not the Cloud makes sense for your organization.

So, with all of this in mind, what is a “private” Cloud?  There are many possible definitions but I’d suggest that if you are running internal applications on virtualized gear then you can say you have a private Cloud.  Why, you ask?  Because you can generally dial up or dial back the resources you assign to virtual machines/apps just like you can with Cloud apps.  I realize this is a very “thin” definition but it does work for purposes of this discussion.

Small Business can definitely take advantage of the Cloud (and private Cloud) with a little judicious planning.  Office365 is a great Cloud offering that can work really well for small biz (in fact it is the cornerstone of Microsoft’s “hybrid” Cloud offering for small biz, Small Business Server 2011 Essentials).  Other things like SugarCRM, salseforce.com and Google Apps (the paid-for version) also offer big bang for the buck. But you probably won’t be able to migrate your line-of-business app to the Cloud at this point unless your application vendor provides a Cloud offering OR you make the move to a vendor that does have such an offering.  You CAN put your line-of-business apps (and other services) in to your own private Cloud, the tools are available to virtualize almost everything you do and, by extension, give you the ability to dial-up and dial-back resources (and services/applications) at will.

In the end it really doesn’t matter if a resource is local, lives in a private or public Cloud or is hosted.  What does matter is that the resource does the job you need it to do at a cost that makes sense for your business.  There is no one model that works for all resources for all businesses all of the time.  There is no point in pursuing a Cloud resource for an application that just isn’t suited to the Cloud model but, equally, there is also no point in staying rooted where you are simply because that’s “always the way we have done it”.  We are in the midst of a computing revolution thanks to Cloud resources (all types of Clouds) and the emergence of new types of devices that can consume those resources (phones, tablets, you name it).  Smart businesses will look at what ALL of these various resources can do and work with what works best for them without dwelling too much on the semantics of Cloud vs everything else.  And this works just as well for small business as it does for the global multinationals.