Application Configuration for Highly Scaled-out BizTalk Groups

Microsoft BizTalk Server is a product we have worked with for well over a decade now, and is still a solid product for on-premise integration solutions.  The Enterprise Edition of BizTalk can also be scaled up to handle significant workload, and it has a food configuration story in Enterprise Single Sign-On (ENTSSO).

Enterprise Single Sign-On has at its core a database that holds encrypted secrets, and this is the data store that sensitive data used in the configuration of BizTalk send and receive ports is held.

ENTSSO has an additional benefit in that it can be used to store application config for BizTalk solutions as well.  Consider the following schematic of a highly scaled-up BizTalk installation, typical of what we have worked with in some of our larger clients:

The benefit of using ENTSSO for app config is that each of the nodes in the BizTalk Group all point to the same configuration store, the SSO database (SSODB) that is deployed as part of the BizTalk installation.  We can actually hook into this to give us applicati0on configuration that can be used directly in orchestrations and pipelines.

In the BizTalk world there is a famous tool by Richard Seroter (https://seroter.wordpress.com/2007/09/21/biztalk-sso-configuration-data-storage-tool/, https://seroter.wordpress.com/2010/07/06/updated-ways-to-store-data-in-biztalk-sso-store/ ) that builds on SSO to give it an application interface.  You can build configuration providers on top of this so that SSO data appears in your application as seamless configuration, with the benefit that it is managed in a single place and all nodes will refresh their config on a regular basis.

In a large enterprise application we might have other servers that participate in the application.  The most common of these are web servers that are hosting web services / web APIs that BizTalk is integrating with and orchestrating, and application servers that are running Windows services that perform background processing for the application.

We might find that these servers also need to consume some of the same config data that the BizTalk application uses.  Fortunately, we can also install the SSO client onto these servers as well, so that our additional servers happily consume the configuration data and benefit from the centralised management, consistent programming model and automatic refresh that we have built into the BizTalk group.

If we update the schematic, we might find we have something like this:

So far so good, we have a highly scaled environment with centralised configuration data.  However, BizTalk groups will always run into limits of scale at some point.  This will usually manifest itself either as CPU / disk overload in the message box database or CPU / memory overload on the BizTalk servers.  When this happens it is very difficult – and very expensive – to achieve further scale, both in terms of architectural change and in hardware.

A better way to achieve scale is to regard a BizTalk Group as a unit of scale.  Ideally, architect this in at an early stage in the application.  Ensure that work being fed into BizTalk can be load balanced between more than one group, so you can horizontally scale the BizTalk databases, and you can also take a group down for maintenance without leading to loss of service.

In this scenario you will want to be able to scale the web servers and application servers as well.  There is a crunch issue here though:  the ENTSSO configuration service that we used in the previous schematic to provide a centralised configuration store for all of our application is tied to the SSODB deployed within a single BizTalk Group.  Which SSO database do we connect to?  How do we manage the fact that there is no longer a single configuration store, but one per BizTalk Group?

As we scale out through additional groups, and to be able to deploy / retire groups as unit of scale as part of a flexible infrastructure, we need to solve the conundrum of how to configure the applications across our estate.

At 345 Systems we’ve been through all of this pain with large-scale banking systems capable of processing tens of millions of payments per day.  We’ve hot these very limits in the scale-out of BizTalk, and we have encountered the pain of non-centralised configuration in a mission critical enterprise.

This is where we got the nucleus of the idea for cloco, our Cloud Configurator.

Developers:  You need a configuration programming model that can be surfaced easily in BizTalk and other applications, with a deployment framework so that your development lifecycle drives your configuration store.

Administrators:  You need to be able to manage, view, update and revert changes to configuration.  You need to ensure that configuration is secure from tampering and information disclosure.

Architects:  You need reusable building blocks to use as a bedrock for your applications.
cloco, our Cloud Configurator, gives you all of this and more.

Above, we discussed the fact that it is possible to use ENTSSO as a configuration store for applications.  We did not recommend it, nor did we say that the programming model for this configuration would be easy.  We did not say that the centralised administration of configuration would have a nice UI or validation tooling.

When we created cloco we envisaged a programming model that is as easy as possible for .Net programmers.  We wanted to create a framework where you simply reference our assembly, create a class that defines your configuration data, create a JSON-serialized document containing your configuration, and that’s pretty much it.

We’re really proud of what we’ve managed to achieve with cloco, because we know how much time and effort you can spare by hooking into a configuration framework that’s designed with developers and administrators in mind, rather than hooking into a subsystem that was designed to be an invisible subsystem deployed as part of a product.
We’d love you to try out cloco to see if it can help your applications.