SP2010: All SharePoint cloud scenarios

Okay. It’s 2012. You’re hearing all this talking about the cloud and you’ve studied it a bit. Seems quite cool: no need for expensive hardware any more, no need for people carrying around servers, routers and firewalls. Signing up should be enough, right? Sure, if you know what you want and need. And that sometimes is a problem. In this post, I’ll try to list all the options you’ve got at this moment (mind you: the options will probably change over time).

Let’s start with discussing the three major models:

  • On-premise (your hardware)
  • Cloud (their hardware)
  • Hybrid (a bit of both)

There’s no real need to lay these out for you I hope. If you don’t know what I’m talking about, take some time and bing or google them to find out more info. What I do want to make clear is that above choice is not enough. Within these three high level architecture options, you’ve got several subchoices to make. And that’s where it get’s interesting.

On-premise servers

I’ll start with on-premise, since that’s the oldest and easiest one. You buy some servers, install SQL Server and SharePoint on them and build out your farm. So there’s the normal costs you have for the hardware, licences and all. But what about development for instance? Suppose you want an DTAP environment (development, testing, acceptance and production), you’ll need more servers and licences. Disaster recovery? Sure, just call HP again and you’re good. You’ll become their friend, especially since they know you’ll be needing new hardware in a about three years if you want to keep up with specs. And you need guys who make sure all hardware keeps working, patches are installed and what else those guys do 🙂

Everyone who knows cloud, knows this scenario. You migrate to the cloud to be able to elastically cater the needs of your organisation. But just saying “we’re going cloud” isn’t enough any more.

Cloud based scenarios

First of all, there’s the choice on how much grip you need on your SharePoint environment. That basically comes down to how much customizing you want to do. If some team collab sites are enough for your needs, signing up for Office 365 is a quick and easy solution. But there are limitations. You cannot reach the servers, so you can’t install anything or check the logs for instance. You can use SharePoint Designer or (sandboxed) solutions to customize the environment, but again with strict limitations on functionality.

There are other hosting providers out there offering hosted sharepoint solutions. Those come in two flavours: shared or dedicated. A shared environment often resembles Office 365 and it’s limitations. Sometimes you do get some degree of freedom, but if your hosting provider will allow you to install full trust solutions on their shared platform; I would really doubt the security and stability of their offerings.

The dedicated offerings usually mean you get a series of hosted VM’s with SharePoint preconfigured. So what they usually do is spin up some machines based on prebaked images with SQL and SharePoint on them. You get RDP access and away you go. That’s nice if you need those full trust solutions. Check what options the provider is giving you in terms of virtual networks, VPN connections, loadbalancing and that kind of stuff. It matters when you’re running larger SharePoint environments and you don’t want to get stuck in a scenario in which you need to migrate your entire farm again after a few months, because the provider you chose lacks support of those techniques.

When we’re talking VM’s, we don’t really need a prebaked SharePoint install, right? You can just go to companies like Amazon, get some Windows 2008 R2 VM’s and install SharePoint yourself. Maybe takes a little bit more configuring, but you’ll know the environment is built with your requirements / preferences in mind.

Back to Microsoft. There’s Office 365, but now there’s also Azure Virtual Machines. An Azure hosted VM is basically the same as the option described above, but in this case it’s Microsoft hosting your VM on Azure. And Microsoft has got it’s act together when we’re talking cloud. Check out this presentation to see how you can run SharePoint on Azure VM’s. It’s really nothing more then spinning up some VM roles, connecting them in a virtual network and configuring SharePoint via RDP. Of course you need to setup things like loadbalancing if you’re using multiple front-ends, but that’s all made extremely easy in a nice management portal. If even a networking n00b like myself can figure that out, so can anyone else who can install a proper SharePoint farm.

You can also connect your Azure farm via VPN to your local network. A well known scenario would be to connect to your local active directory, in order to run a read-only domain controller in the cloud. That way all your cloud servers would be joined into the same domain, and thus your users would have a much better logon experience. Again, Azure is not unique in this, but does make it all extremely easy, safe and extendable (there are API’s for everything you can do in the management portal).

The last option I mentioned was the hybrid scenario. For SharePoint, that usually means having an on-premise farm and an Office 365 environment. Mixing those up to one environment is quite hard and you really shouldn’t expect too much of that. In my opinion, it should be viewed as two seperate SharePoint installations with (partially) the same users using them, nothing more, nothing less.

But the VM-hosted scenarios, be it Azure or not, provide a new kind of hybrid option. As said, you can setup a VPN tunnel to your cloud farm. Now I’ll step back to some of the examples I mentioned in the beginning of this post. Take disaster recovery. Imagine your local datacenter get’s hit by power outage, a fire or flooding. A ready to go cloudfarm could mean you’re up and running again in a matter of minutes. You might say “isn’t it expensive to have a second farm up in the cloud?” Not nescessarily. The only machine you really need running is a database server mirroring you primary database server. You could shut down the front-end and only activate them when they’re actually needed. Switch around a DNS and you’re up and running again. And as a plus, you allways have a back-up available too. That’s when the real power of cloud computing comes in.

Same goes for your DTAP environment. Is your development team stable, or do you sometimes have 10, sometimes 20 developers working on a project? In your local farm, you would need resources for the maximum number of simultaneous users. And when you’re team holds only 10 developers, the other resources are only costing you money. Provide Azure based VM’s for your developers and you just shut down the 10 you don’t need and thus don’t pay.

Isn’t that real expensive?

No, it’s not. A large VM instance (it’s still SharePoint right… 4 cores, 7GB RAM) is $0,23 per hour. Say your typical developer is working 8 hours a day, 5 days a week; that’s 160 hours a month. Comes down to $36,80 a month. And yes; you’ll need to add storage and bandwith costs as well, I know. And of course your dev will need a local machine. And you need to make sure the machines are actually powered up and down each day (did I mention those API’s?).

So I’m not saying you should move all of your devs to Azure. What I’m saying is that Azure might be a good option when you want to temporarily increase your development team with 10 developers. And if you hire them at Atos, they come with laptops included 😉

 

Conclusion

If you’re one of those people who takes the retail price of a server a compares it to the price of an equal Azure instance, you’re of the kind that doesn’t quite get it yet. I’m sorry, it’s true.

These scenarios are much more then just uploading your VHD’s to the cloud and running them there. They’re about being able to scale when you need it, without investing first. They’re about not having to pay guys who understand virtualisation. Guys who are sitting in your serverrroom, patching cables and doing all kinds of things you don’t understand. They’re about maybe not even having a serverroom, airconditioning units for it and things like APC power back-ups or perhaps even generators. We’re talking uptimes of 99,95%. Are you getting those now? Start including all those things into your picture and then compare again.

In one of my next blogs I’ll describe a 2014 scenario for companies looking for a “desktop of the future” kind of solution. No local servers involved whatsoever. I’m convinced that our way of working is really going to change the next few years. There’s already great technology available, but things will get even better as soon as they really come together. Stay tuned!

,

Related posts

Long Term Support… or not?

Okay. It's 2012. You're hearing all this talking about the cloud and you've studied it a bit. Seems quite cool: no need for expensive hardware any more, no need for people carrying around servers, routers and firewalls. Signing up should be enough, right? Sure, if you know what you want and need. And that sometimes is a problem. In this post, I'll try to list all the options you've got at this moment (mind you: the options will probably change over time).

[DevOps] Should you migrate onto YAML release pipelines?

Okay. It's 2012. You're hearing all this talking about the cloud and you've studied it a bit. Seems quite cool: no need for expensive hardware any more, no need for people carrying around servers, routers and firewalls. Signing up should be enough, right? Sure, if you know what you want and need. And that sometimes is a problem. In this post, I'll try to list all the options you've got at this moment (mind you: the options will probably change over time).

Latest posts

Long Term Support… or not?

Okay. It's 2012. You're hearing all this talking about the cloud and you've studied it a bit. Seems quite cool: no need for expensive hardware any more, no need for people carrying around servers, routers and firewalls. Signing up should be enough, right? Sure, if you know what you want and need. And that sometimes is a problem. In this post, I'll try to list all the options you've got at this moment (mind you: the options will probably change over time).

[DevOps] Should you migrate onto YAML release pipelines?

Okay. It's 2012. You're hearing all this talking about the cloud and you've studied it a bit. Seems quite cool: no need for expensive hardware any more, no need for people carrying around servers, routers and firewalls. Signing up should be enough, right? Sure, if you know what you want and need. And that sometimes is a problem. In this post, I'll try to list all the options you've got at this moment (mind you: the options will probably change over time).

Leave a Comment

Leave a Reply

Your email address will not be published. Required fields are marked *