StartReady.com Appliances last episode ;-(

StartReady.com Appliances

Welcome back. Three weeks ago I started blogging about StartReady. . In a couple of episodes I’m sharing some of the things these guys are doing. In the first episode I discussed the more general overview of their architecture and choices they made. The second episode was all about the unattended deployment and configuration of OCS., and in the third episode we discussed the remote management architecture and the way they used Hyper-V for virtualization.

In this last episode I had an interview with Menno. Menno is responsible for the design and architecture of the Application Layer and the orchestration of the deployment process, based on Windows Workflow Foundation.,.

Can you first tell me something about the architecture of the Application Layer and choices you had to make?

I joined the StartReady team just after the scoping of the Appliance Architecture had started. In that period, we had the vision of the end product in mind, but the technical design was still undetermined. This gave us a greenfield approach, with no real constraints in place. We only had a short list of the characteristics of on appliance, as mentioned in the first episode. So, when I joined the team, some basic decisions were already made and therefore the design of the Application Layer was quite straight forward. The challenges were in the details, as always. For example, we had to make a decision on the functional boundaries of the Application Layer: where does its responsibility begin and where does it end? We were dealing with steps that could both be performed by the Application Layer and Power Shell Scripts. During the Agile Development Process, some of the steps moved from Application Layer to PowerShell and vice versa. We did stick to the fundamental idea though, that we wanted to do as much as possible using managed code. The Power Shell scripts are powerful in performing administrative tasks, but they do not adhere to basis development standards like source control, debugging, etc. So where ever we could, we wanted the Application Layer to be in control.

Because StartReady is building a standard platform (aka the Appliance Factory) for deploying all kinds of Microsoft based appliances, I designed a generic architecture for the Application Layer and its workflow engine. We based the Application on the generic MVC pattern, so the overall application consists of several layers. At the top we have the Presentation Layer that contains the logic for the GUI. Below that, we have the Business Logic Layer (BLL). This layer contains all the logic for getting the information from the Presentation Layer and, after doing some validation, communicating it to other layers. For example, when the user has finished answering the questions in the Wizard, the BLL saves these answers in the configuration file, and sends it to the database. The actual communication with the database happens in a separate layer, called the Data Access Layer (DAL). Another task of the BLL is starting the Workflow. After sending the configuration file to the StartReady database, it is also sent to another layer, called the Configuration Layer. In this layer the configuration file is copied to a location on the hard drive and the correct Mapper is selected. I’ll talk about Mappers in more detail later on. Between these layers there are several web services that handle the communication between the website, the database and the workflow.

So the architecture is designed to serve the configuration and deployment of different appliances?

Yes, in the beginning we primarily focused on building our architecture for the deployment and configuration of OCS. But we also kept in mind that our architecture needed to serve a Search appliance. And when we started building the Search appliance, it was a matter of configuration, and not of development, to realize a new Application Layer. And this really shortened down the development time. In the end, we got such a generic architecture, that we now can introduce totally new Appliances, without much effort.

Interesting. Can you give me an example on how you setup this generic architecture?

Yes. In general, the installation and configuration of a server product is based on settings and human workflow. So, we base our architecture on XML files for the settings-part. We now have a file that is appropriately called the Configuration File. In this central file we exchange the customers settings information between the Application Layer, the PowerShell Scripts and our database.

So, all the customers configuration information is exchanged and stored in XML files?

Yes that’s correct. And to make this generic setup work for all sort of appliances, we introduced a XML file called, the configuration Mapper. Let me explain this. On one side we have the information gathered from the customer that is stored in Configuration File. On the other side we have the Configuration Mapper file. This file maps the customer data to a specific appliance deployment. So, when we deploy an OCS appliance the Mapper file describes which information is required from the customer and where the information is used during the deployment.

Every step in the workflow is anchored in this Configuration Mapper. For example, one of the steps in our process is copying a folder from one location to another. Of course, we could simply hard code this step in our Application Layer and let the code copy what’s described in the Configuration File. But we abstracted the concept of ‘copy’ to a higher level. What we did, was describing these kinds of process steps in the XML. In my example we added ‘copy’ as a process step and added the parameters needed to perform this step. In this way we reuse process steps in our deployment process. This makes it fairly easy to setup the Application Layer for a totally new appliance.

Ok, that’s some cool stuff. I can imagine that the data gathered from the customer needs to be validated at some point in time. Otherwise, the parameters will fail the steps during the process. How do you manage this?

In this case the magic is done in the Configuration File. It describes which information is mandatory. Not every requested information is mandatory. Take the proxy server for example. Not every customers has a proxy server in its domain. But when it is present, our appliance needs this information. We encountered this situation during a test setup. When we tried to validate our license key over the internet we didn’t receive a response. This was caused by the customers proxy server. We now have extra checks build in for these kind of situations. When the validation through the internet isn’t working, we ask the customer whether he has a proxy server. We then use the provided configuration to validate our license key again.

In the first episode I have learned that you use Windows Workflow Foundation (WWF) to orchestrate the deployment. Can you explain to me how WWF helps you in your architecture?

WWF helps us to model the deployment process. It really breaks downs the complexity of the process into manageable pieces. We have one main workflow which orchestrates the total deployment of an appliance. Depending on the type of appliance, we have a fixed number of steps in the main workflow. The minimum for a workflow is 2 steps: a generic start-step and an end-step. In between these two generic steps we have to handle the installation of several virtual machines. The number of virtual machines depends on the appliance. Every virtual machine has its own workflow process, and consists of several steps, like mounting the disks, copying software, doing some secret stuff J, unmounting the disks and finally start the sysprepped virtual machine. After starting the virtual machine the PowerShell Scripts are automatically kicked off. At this point PowerShell takes over the action and reads the Configuration File and uses the information needed for the configuration and deployment of this specific virtual machine. Via a WebService PowerShell reports back the status of the deployment. When the script is finished it reports back a final status message. The workflow now knows that the virtual has finished and returns to the main workflow which kicks-off the next virtual machine.

So, if I understand you correctly, the installation can get into a situation that it stalls and waits endlessly for the virtual machine to report back its status?

Theoretically you are right. But to prevent this situation, we have also build error handling into the PowerShell scripts. So when an unexpected situation occurs during an installation or configuration the script raises an error to the workflow and the customer receives a message describing the action he or she should take. Detailed error messages are also stored in our database and in the event log of Windows Server.

That makes sense – is that also the reason why you have chosen to use WWF? And can you give me some advantages and disadvantages of using WWF?

A big disadvantage is the broadly available knowledge and experience in working with WWF. It’s a relative new product and the available information on the internet is still a little bit light. The main reason for using WFF lies in the low level plumbing it handles. It really helps reducing the complexity of building your application. You can develop little chunks of code and test it straight away without depending on other steps in the process. For example, one of the steps is mounting a disk. From a developers perspective you can really focus on this piece of code and harden it for the job it has to do. Next to that it handles the complex things like state-management: in our situation this results in the situation that a customer can close the Installation Wizard without stopping the installation process. Just opening the site again and it tells you the current step.

Have you ever considered an alternative for WWF and what was it?

Because the project was on a pretty hard deadline it was risky to adopt new and unknown technologies. So, with the discussion on workflow, we looked at WWF and also considered alternatives. An alternative is building the code from scratch and specifically design it for our needs. Of course, technically this is doable, but is it worth it? To make the right decision, we choose to do a proof of concept with WWF. We did a workflow exercise which we wanted to successfully end within 3 days. To our astonishment, within 1 day, we were able to determine that we could reach all our goals with WFF. It is a very sophisticated platform that makes the make-or-buy decision a no-brainer. And in this case buying is nothing more that downloading.

So with all these things currently in place, what’s your roadmap for future development?

Well, at this point I can mention two features that are under development. First of all we are now in the middle of testing the maintenance website for the OCS appliance. With this website every customer can maintain options for OCS users. You can enable users for OCS, and set specific user functions like telephony and federation. Next to that we are developing a Prerequisite Scanner, that the customer can run prior to the installation of the Appliance. It tells us whether the IT environment is suitable for our Appliances. We are publishing this tool on our website soon.

Menno, thanks for your time and your clear answers.

Well, this was the final episode. During the last couple of weeks I’m became more and more convinced that the concept of delivering IW related products as an appliance is a great idea. And I’m really impressed how professional the technical team of StartReady is handling things. Last week I visited their technology center and witnessed an OCS deployment. It’s really weird to see such a complex product being installed in just one and a half hour!

Again I would really thank Jeroen van Vliet for having the time with me to write these episodes!

And I just found out that StartReady is also present on the Microsoft World Wide Partner Conference in Houston. So for whom is interested in meeting Lucas Wensing or Jeroen van Vliet contact them by e-mail (jeroen@startready.com and lucas@startready.com) and make an appointment with them.

If you are interested in a combination of the UC appliance and a e-take off SharePoint 2007 project contact e-office (arjan.van.eijk@e-office.com).

For more information check out their website on http://www.startready.com