Literally a roundtable discussion of several topics with aproximately ~8 attendees around the breakfast table that comprise our 'panel'.
BizTalk and Virtualization
7 out of 8 use BizTalk in virtualized non-production environments. That means all development, staging and functional test environments were virtualized.
7 out of 8 use Microsoft's Virtual Server product over VMWare.
Can you guess who the lone hold out was that doesn't use BizTalk in a virtualized environment? I'll give you a hint, its the same person who uses VMWare. No one had anything against VMWare. I got the feeling that some panelists would have preferred it given a choice. However, all voted with confidence that virtualization was a great thing with the caveat being Sql Server. With a high end SAN to back it up, I wonder if the sentiment would have still been the same.
Virtualized Development Environments
Spoke about the need about having such a wide range of tools and technologies available on the desktop that are not necessarily compatible. Brian Prince (a consultant and speaker at TechEd 2006) spoke in detail how their entire development environment is virtualized, even on the desktop.
Brians team, being consultants, may be working as many as two or three projects at once. Each project could have an incompatible technology stack with the other. In such a scenario virtualization saved the day. For each project a developer is working on, the developer will receive VHD representing each tier. E.g. Development Workstation, BizTalk (or other application server) and SQL. One of the keys is evidently giving the VM's each a new SID and with BizTalk, installing, but not configuring the instance until ready. So its effectively a manual post build step after the scripts create the virtual environment.
Sunny, from EDS, explained how they script most of the servers for a virtual environment, from domain controllers, database, and through application servers.
Being able to quickly turn out new 'environments' seemed to be a huge productivity gain, giving faster proejct startup times and consistent developer workstation builds.
Continuous Integration, Repeatable Builds and Deployment
All the talk of virtualization and scripting the build of consistent environments quickly turned into a discussion of how to turn out builds quickly. Opinions seemed to be that library and ASP.NET (including web service) builds continuous integration worked fine. This not ony includes component builds, but deployments to an integrated environment. Brian had the most advanced process, which also included notifying the test team of the availability of the new build along with the change sets that were deployed.
With BizTalk projects, a daily, or regularly scheduled build was more appropriate. The general consensus was due to complexity of the deployment. However, all agreed that getting the BizTalk build and deployment down was critical to the forward motion of a BizTalk project.
It was worth noting that 7 of 8 panelists were now using Team Foundation Server to some degree and MSBuild to build their projects.
Sessions
Access and Identity Management by Steve Swartz & Clemens Vasters (Microsoft)
I don't know how much of it was about Identity Managment and the Access mean data access, not access as in authorization. So, while the session wasn't exactly what I expected I enjoyed it nonetheless. These guys work very well as a speaking team.
ACID transactions in data access are extremly costly and doesn't scale. Consider using compensation strategies instead.
Key take aways were to consider how the data in the application (any application) was to be accessed. "Correct data architecture is the ultimate performance optimization"; in those times when I've truely encountered problems with peformance, they were traced to data access.
High Availability, Fault Tolerance and Scalability with BizTalk Server 2006 by Jay Lee (eBI Solutions)
I believe this talk was given by a different person at TechEd 2006, at least it had the same 'Failover and Recover BizTalk in less than 5 minutes' demo. Its impressive and makes one want to double check that it works in your environment.
The configurations for BizTalk to achieve high availability were right out of BizTalk documentation you can find online here.
In the slide deck, it appears that Jay had the master secret server installed on the SQL boxes.
MSI is the prescribed method for deployment; reminder to import the msi from one server and then run the msi on the remaining servers in the server farm. This can be automated.
Again, saw BizTalk in a virtual environment: 1 Active Directory VM, 1 SQL VM, 2 BizTalk VM on a laptop. Just what kind of laptop was he running?!?
There was a recurring theme throughout the conference, reinforced here, that BizTalk Developer and BizTalk Operations were two distinct roles. Essentially the Developer role is responsible for development, building, packaging and configuring bindings. The Operational role is responsible for deployment, health, performance and scalability of the system.
Lunch with Covast: Newest Developments in B2B
Interesting that Covast is moving more into the partner space rather than the competitor against BizTalk Server. They also discussed an integration appliance for B2B scenarios using EDI formats.
Effective Techniques for Handling Large Messages in Service Oriented Solutions by Thomas Abraham (Digineer)
Briefly talked about MTOM and streaming methods before jumping into a custom solution he had developed that addressed a specific business case. Essentially he had to transport PDF files and these PDF files could be large. Sucking them through BizTalk, as base64 encoded data peformed fairly poorly. Thomas's custom solution was to split the data on the way in, stream the PDF data to a file share, and then correlate the message identifier back to the PDF on disk at the end of the process. Kudo's for being creative. One audience member brought up disaster recovery and its true, this should work fine as long as the backup's of the database and the fileshare were in synch. Otherwise, there might be some data loss, but it should be relatively easy to reconcile depending on the volume of data.
Here is a quick chart of message sizes and their categories.
| Message Size | Size Category |
|---|---|
| < 10KB | Ideal |
| 10KB - < 100KB | Small |
| 100KB - < 1MB | Medium |
| 1MB - < 5MB | Large |
| > 5MB | Very Large |
Configuring, Building and Deploying BizTalk Applications in a Distributed Environment by Paul Gomez (ThinkBox Solutions)
Again, something of an identity crisis. ThinkBox Solutions shouldn't be confused with ThinkBox educational software (though they do have a Development Services group).
Paul had the hard luck of following a session that has already covered much of the material he was presenting. He discussed creating available BizTalk configurations that have already been covered pretty well.
The client solution that they had developed sounds fairly large (8 BizTalk Servers) and that definitely means that they've got issues around deployment.
Currently, ThinkBox uses NAnt (shelling out to BTSTask) to meet their BizTalk deployment needs. To help keep things streamlined, they deploy all bits to all boxes in the farm. This keeps the server builds conisistent, but allows for configuration of each node in the farm for its specific function, or role (Processor, Sender, Receiver).
Their security account management seemed overly complex with an account for each server role type (Processor, Sender, Receiver).
Prior to deployment to any integrated environment, they used the concept of a deployment staging server to configure bindings, etc.. This is the server that the binds will be exported from for use at deploy time.
Interestingly enough, they created their own direct submit adapter. This direct submit adapter simply submits a message to the message box. One thing that was odd, was that they had a pair of servers dedicated to running the host instances for this adapter. Something else to note is that in order to submit to the message box, each developer workstation had to be a member of the BizTalk workgroup.
Again, it was stressed that the Developer role is to develop and package the build (including bindings) and the Operational role to deploy, monitor, and tune. ThinkBox, like many organizations with a large deployment, has a dedicated deployment guru.
Where the discussion was weak was around the physical organization of the project structure for ThinkBox solutions, how they handled versioning, etc..
BPM Q&A Panel
Little to no discussion around Business Process Management; it was essentially a continuation of developer/architect Q&A on products and platforms. This could, and should, have been moderated better.
One problem might have been that the majority of the 'business people' seemed to have disappeared. I don't know if they bugged out early, or were just attending different sessions. I would have sincerely liked to have found a couple to engage in discussions of whats important to them in their business.
No comments:
Post a Comment