Archive for August, 2007
Friday, August 31st, 2007
Configuration of the SaaS virtual lab continues.
I’ll be running Windows SharePoint Services in active directory account creation mode. In this mode, the SharePoint users will have Active Directory accounts instead of Domain accounts. To do this, AD has to be running on a machine other than the one hosting SharePoint Services. So I set up a second VM called MLP-AD.
I created a domain in Active Directory called mlp.mallardsoft.com. This domain is not a true entry in the mallardsoft.com DNS server. Instead, MLP-AD is running a DNS server of its own. It has an A record mapping mlp.mallardsoft.com to its own IP address. Because of these changes, MLP-AD needs a static IP address. Rather than try to convince the network admins to allocate an address for my virtual machines, I took the VMs off of the corporate network.
In VirtualBox, I created a second host interface for the second VM. But instead of bridging the host interfaces to the Local Area Connection, as I had previously, I bridged them to eachother. This creates a new Network Bridge connection, which you will find has its own IP address. The default happens to be 192.168.0.1, which works just fine for my purposes.
I’ve given each of the VMs a static IP addresses within this subnet (192.168.0.2 and 192.168.0.3) and configured them to use 192.168.0.1 as a default gateway. Then I enabled internet connection sharing on the Local Area Network to give the VMs access the outside. However, since the host's connection is acting as a NAT router, the VMs aren't visible from the outside.
Now MLP-FULLSTACK uses 192.168.0.2 as its DNS server, and can resolve the name mlp.mallardsoft.com. This allows MLP-FULLSTACK to join the domain.
Thursday, August 30th, 2007
I’ve installed VirtualBox as an alternative to Microsoft Virtual Server. I’ve set up a VM using the same parameters as the MVS VM (512 MB memory, 10 GB hard drive). And I've installed the same guest OS (Microsoft Windows Server 2003).
This is a much more accessible solution. Everything appears within one simple UI. You can create, manage, and run multiple VMs from one list. No running within the browser, and no ActiveX control.
As compared to Microsoft Virtual Server, VirtualBox offers all the same features (mounting ISO images, mapping network adapters, etc.), but also adds audio and USB support. And it puts snapshot capabilities right up front on its own convenient tab. To make a snapshot in MVS, you have to copy the virtual hard drive file to a different folder and manage it separately.
There is one extra step you need to take to give your virtual box access to – and make it accessible from – the outside world. Whereas this is a combo-box in MVS, you need to manually bridge network connections for VirtualBox.
First you will need to change the virtual network adapter. When you power down the VM, the configuration links become accessible in the VirtualBox Details tab. Click “Network” and in the “Attached To” combo box choose “Host Interface”. Hit the “Add” button in the “Host Interfaces” list and create an interface called “VirtualBox Host Interface 1”.
Next you will need to bridge this virtual adapter to your physical adapter. In XP, right click on “My Network Places” and select “Properties”. In Vista it’s conveniently hidden from you. Open the control panel and search on “Network”. Click on “View Network Connections”. You should now see all of your network adapters, including “VirtualBox Host Interface 1”. Select both your “Local Area Connection” and this virtual interface, right-click, and select “Bridge Connections”.
Start your VM again and it will now appear to be on your network.
Besides this additional networking hassle, the tradeoff between VirtualBox and Microsoft Virtual Server is that MVS looses the simpler UI and comprehensive device support in exchange for remote administration via its web interface and ActiveX control. It is designed primarily for headless servers, where remote administration is more important than audio or USB.
For my purposes, VirtualBox makes for a better lab experience.
Wednesday, August 29th, 2007
I've installed a virtual machine on my laptop so that I can work with the Microsoft server stack. Here are the steps I went through, just in case you want to follow along.
You will need:
- Windows Server 2003 install disk
- Install disk for SQL Server, BizTalk, SharePoint, and any other server components you want to test.
- Internet connection
- 10 GB free hard drive space
- At least 1 GB memory
I recommend that you get an MSDN subscription for all of the install disks that you need. Be sure to request a license key for Windows Server 2003. Click on Certified Partners Downloads and Product Keys. Drill down to Windows Server 2003 under Operating Systems in the left-hand panel.
Download Microsoft Virtual Server 2005 R2 SP1. The download requires a Live ID and registration, which is mildly annoying. An MSN or Passport login will work, too. Fill out all required fields if you want your download.
After you complete the install, you can access the administration interface at http://<your machine name>/VirtualServer/VSWebApp.exe?view=1. It only works in IE, not Firefox. And you need to specify your machine name, not “localhost”.
In the admin page, create a new virtual machine. I chose the name “FullStack” because I intend to install the full stack of services on this box. Choose a reasonable amount of memory and maximum hard drive space. I chose 512 MB of memory and 10 GB max hard drive, which is a bare minimum for my purposes. The virtual drive file will dynamically grow to this max, but I don't want it getting out of hand. In the future I may need to up these numbers. Also I’ll try moving the virtual hard disk to an external drive so I can keep the notebook drive clean.
You'll want to attach your virtual network adapter to your real network card so that other others can gain access to it. Simply choose your NIC in the drop down. I chose my wired vs. wireless NIC just to be safe. The Internal Network selection should allow you to access the VM from the host machine only, but I couldn't get that to work for me.
Once your VM is created, click on the screen thumbnail to remotely control it. The first time you do this, you’ll be prompted to enable the Virtual Machine Remote Control (VMRC) server. Just check Enable and hit OK. You will then be prompted to install an ActiveX control. Once you do, you should be able to see your brand new box prompting you to “Reboot and Select proper Boot device or Insert Boot Media in selected Boot device”. This was so cool, I just had to take a picture.
Now you can install the guest OS. I have ISO images for the install disks rather than physical media. So I changed the CD/DVD settings for the VM. First, copy the ISO images to the VM folder in “C:\Users\Public\Documents\Shared Virtual Machines”. Then, remove the existing “Primary Channel” attachment by selecting it and checking “Remove”. Add a new one by selecting the *.iso file from among the known ISO images. Now the ISO image will appear to be a physical CD within the VM. You can switch to a different ISO image at any time – even while the VM is running – by going back to the CD/DVD settings.
I'm going to see how far I get with this configuration. I'm also considering VirtualBox as an alternative to Microsoft Virutal Server. It would be nice to get out of the browser.
Tuesday, August 28th, 2007
After six years as a corporate product developer and architect, I have gone back to my roots as a consultant. During my year at Handmark and my five years at Radiant Systems, I've met some great people and grown quite a bit. However, I missed the opportunity to serve different clients and use a variety of tools.
I have joined SSG, the company for which I have been working part time for the past three months. While that side project is nearly complete, they need some architectural help on a much larger software-as-a-service project. So I am researching SaaS and the Microsoft server stack designed for this kind of project.
On the SaaS front, I found this excelent overview: Architecture Strategies for Catching the Long Tail. This article actually has little to do with the long tail, other than that long-tail services depend upon outsourcing to be viable. The article describes a maturity model for SaaS, and guides the reader to the best architectures for each of the four target levels. I can immediately see that Radiant's SaaS (Aloha Enterprise) was at level 2, and that it probably needs to migrate to a level 4. The article outlines at a high level how to get there, and what barriers you will have to overcome.
I still have to do some anaysis to determine what maturity level this new project should target. At first glance, it appears that level 3 will be appropriate. I'll have to learn more about their operations and expected growth to make a proper assessment.
Wednesday, August 15th, 2007
At Handmark, we use Subversion for source code control. (Check out this Subversion Quickstart at the Polymorphic Podcast.) Like most systems, it supports concepts like branching and tagging. The mechanics for each system varries, so check your documentation for those details. But a more interesting question is, how do you manage branches and tags? Where do you make your changes? What steps do you take when it's time to release?
There are essentially two schools of thought for branching: for features or for releases. We've chosen to branch for features and merge into the trunk to build a release. But another option would be to make all code changes in the trunk and branch at the point of release. You choose your policy based on where you will accept instability. If you can tolerate an unstable trunk, then branch for releases. If you need to isolate instability in the branches, then branch for features.
We've chosen to branch for features because our priorities change quickly. This strategy allows us to isolate changes away from each other, put them on hold for a time if necessary, and keep the trunk stable. All builds are performed from the trunk, so changes must be merged from their branches to the trunk prior to release.
Once we've build a release, it moves through various staging areas. A build starts in integration, moves to testing, and finally into production. At each point along the way, there are checks in place to ensure that it is ready to move forward. The pipeline is rigid in that no build may pass another on the way to production, and no build can move backward. If a build fails one of the checkpoints, it drops out of the pipeline. If we need to expidite a change to production, the build that's currently in the pipeline is dumped.
We find that this policy works best for our environment. It may or may not apply to yours. Choose the policy that fits your team, discuss it, document it, and stick to it.
Tuesday, August 7th, 2007
Russell Elledge and I have been conducting interviews at Handmark, looking for help on our Pocket Express and On Demand applications. In this office, we work on the server side, focusing on making these applications robust enough to handle the large numbers of cell phones that are out in the world. So one question that Russell likes to ask our candidates is as follows:
Name five things that you always do in a scalable enterprise application.
This is an open-ended question designed to create discussion and debate, as well as to test the boundaries of their experience. I thought we could all benefit from Russell's experience, so I asked him to answer the question. This is his list:
- All information must be a transient in memory.
- All information must be in a universally accessible data store or file system.
- Use an RPC technology to force the creation of tiers in a system.
- Use SOA where possible to help force vertical scalability.
- Control your resources.
- Author in administrative capability.
- Seperate OLTP processing from reporting.