Category: Development

Skytap vs. CloudShare

Since I got to Trek a year ago, we’ve been using cloud providers for our dev and test stuff. It’s very slick stuff and I don’t have to sit around and wait for a new box. I just log in, spin up my VMs, and off I go. Consider these providers your own personal Easy button when it comes to dev/test infrastructure.

Based on my experiences, I felt compelled to provide a comparison of the two. Please bear in mind that this is my opinion and your experiences may differ from mine. Let the cage match begin!

 

Their bread and butter is SharePoint offering pre-configured, fully licensed VM’s complete with all necessary service apps , accounts, and site collections. However, CloudShare also offers many other VM’s to choose from including: Windows Server, Exchange, Oracle, CentOS, Ubuntu and Windows 7. CloudShare deploys 2 account types: CloudShare Pro ($49/month) and CloudShare Enterprise (negotiable based on number of users). Each image is fully built and ready to use.

Pros

  • Pre-configured VM’s with absolutely no administration needed to get started. Doing so gives it much more of a PaaS feel; however, you are free to manipulate the servers in any way you like making it a full IaaS option
  • Fully licensed. No need to have an MSDN or TechNet subscription as the licensing price is already factored in to the monthly fee
  • Easy to add VMs to the localized domain, but not much control beyond that
  • Friendliest UI available
  • Flat cost for Pro plan at $49 per month / $490 per year

Cons

  • Little freedom to manipulate the network/domain. Cannot setup multiple subnets or add a firewall. Because of this CloudShare is much more geared towards application development rather than architecture testing
  • Zero support (yet) for Red Hat or Suse, which makes Hadoop deployment more difficult to accomplish
  • Limited run time. For Pro plan, images can only be on for 180 minutes at a time. There is an option to upgrade to "Always on" but the pricing appears to be exponentially more per month.
  • Easily snapshot environment
  • Difficult to import your own images. Must contact sales to do so and it is more trouble than it’s worth

 

Skytap offers complete flexibility in their offering by giving you everything from raw images to pre-built, multi-VM configurations. Monthly pricing varies based on the base package of resources as well as utilization rate. Your own OS and app licenses are required

Pros

  • Full, granular control of the environment including (but not limited to): networking, firewalls, group policy, domain administration, server administration, application administration, & user administration
  • Easy to import your own images, although can take considerable amount of time due to file sizes
  • Straightforward operation to snap a copy of all or part of a environment and rebuild within a matter of minutes
  • Big advantages in availability of build scripting and timing usage based on Google Calendar
  • Nice selection of public Skytap templates to choose from (examples include Red Hat, Suse, Windows 7, Windows Server, etc.)
  • Convenient point-to-point VPN connections are available as well Skytap offers users to federate VM’s to their own domain

Cons

  • Minor nuisance – must possess your own licenses
  • Limited shelf-life for images – environments are not meant to be permanent or "Always on"
  • Difficult to manage large environments due to the web-based management console
  • Zero system-level alerting available

Both providers work off a resource pool model, meaning you pay for a specific amount of RAM (20GB to start) which is shared amongst your VMs. CloudShare Pro offers 10 GB RAM, 300 GB disk, and 10 virtual CPUs to start. CloudShare Enterprise and Skytap are both negotiable.

 

Winner

Winner: Skytap. The flexibility offered makes this provider king. CloudShare is too one dimensional as it is 90% focused on SharePoint and SharePoint developers. While building Skytap images is far more time consuming than CloudShare, the ability to create templates means you only need to setup your environment once. Improvements for Skytap include offering fully licensed VM’s, more granular storage control, and more pre-built application and/or service configurations (Visual Studio, Exchange, Oracle, System Center, etc.).

Anyone using these services or others? Would love to hear about your experiences in the comments below.

My first 2 weeks @ Trek: Setting up a Development Environment with Production Data

So I started as the new SharePoint administrator at Trek Bicycles (in Waterloo, WI for those of you keeping score at home) last Monday. It’s been quite the whirlwind thus far. The biggest learning curve I ran into was setting up our development environment with a snapshot of production data. In all my prior gigs other people were responsible for that. Here at Trek I’m the lone ranger. So I foraged ahead with my admin handbook, navigated to my dev environment’s Central Admin, and clicked on “manage web applications.”

Note: This post assumes you’ve got an available (and functioning) SharePoint 2010 environment, a breathing database administrator, and working knowledge of Central Admin.

Click New in the Ribbon and you’ll get this mean nice form.

Add a New Web App

 You see 10 sections and you think “Gee, how hard could this be.” Well, it’s not hard per se, but it ain’t easy either.

Authentication

Depending on your scenario, you’ll generally pick Classic Mode Authentication.

IIS Web Site

On to the IIS Web Site section.  Here it is important to note that you need to have your domain (i.e. your web address) already setup and have it pointed in the right direction (i.e. pointed to the right IP address). In my case, I only have 1 Dev server so it’s not that complicated. I e-mailed the person in charge of IP addresses, told her I needed a new A Record (the web address), gave her the IP address of the server, and we were off and running.  You’ll want to create a new IIS web site. Name it something you’ll easily recognize in IIS. Use port 80 (http) or 443 (https). If you use any other port you’ll have to add it to the end of the URL. For example, if you use port 4455 and your address is https://www.getaclue.com, you’ll need to have users add :4455 to the end of their URL in order to hit the site correctly (https://www.getaclue.com:4455).  Shout out to Brian Winkers for the help on that.

Next you’ll need to add a host header. Using the example above you would add [www.getaclue.com] (note: no brackets). You can leave the Path alone. In fact, I recommend you don’t touch it. Once that’s done you’ve completed the IIS section. Moving on . . .

Next half of the form:

The rest of the form

Security Configuration

 These are 3, subtle, yet oh-so-imporant radio buttons. For now, let’s just leave the first 2 alone. Kerberos is a beast and if this is for an internal network you wouldn’t want anonymous access. If you’re using port 443 it’s probably a good idea to use SSL, especially if it’s internal. You’ll need to buy an SSL certificate from an external vendor (I recommend RapidSSL).  The certificate is installed on the server(s) in your environment via IIS, but that’s a topic for another blog article.

Public URL

Here you put in your URL. Pretty straightforward here.  I don’t know what Zone does, and I’m sure it’s important, but this blog is called SharePoint Rookie; not SharePoint Expert. 

The rest of the form

For the rest, I would just leave it alone unless you do not have an Application Pool account in the App Pool section. Again, topic for another blog.

Now hit OK at the bottom of the form and wait for SharePoint to work it’s magic. It’ll take 30 seconds or so, but once it’s done the Web Applications page will refresh with your brand-spankin new web app provisioned.

The database

Last step is to connect the copy of production’s database to your newly minted Dev web app. Contact your Database Administrator (DBA) and ask him/her to put a copy of the production content database on the Development SQL server. It’s important to have a good idea of what’s in Production because you’re going to reproduce it on a different server. Depending on where you work or where you’re doing this, this may be a bad idea. Check with whoever (boss, director, higher-power) you may need to and make sure this is okay. Once you get the go ahead, do the following:

  1. Click on Application Management in the left-hand navigation
  2. Click Manage content databases
  3. Make sure the correct web application in the dropdown is selected (This would be the one you created above)
  4. Click “Add a content database”
  5. Add the correct database server name and the correct database name

Now if you and your DBA did everything right (and I didn’t forget to mention anything here) you should have a production copy of your team site(s) now running in dev. Cheers!