RE: Why the VSTS Logical Datacenter Designer (er, Deployment Designer) Sucks

Thanks Joel, your reply is spot on.  I’m excited that others are evaluating the Visual Studio Distributed System Designers, and encourage you all to keep asking questions to get clarification of the value proposition and design goals of our product.  That said, I’d like to focus on some key points made by Joel about what the Logical Datacenter designer provides, vs. what it doesn’t.  Then I’ll respond specifically to Barry’s question, but clearly some context setting is required first.



A core design tenet of the first release of Visual Studio Team Edition for Software Architects (VSTESA) with respect to the Logical Datacenter diagram was that we wanted to stray far away from physical network diagrams.  While physical diagrams are useful for network infrastructure architects, unfortunately they provide little or no value to the software developer or architect.  Furthermore, those types of diagrams are static, represent scale, and provide more physical information about the datacenter than the developer requires or can leverage.  Rather, we focused on a model that conveys configuration and communication information for hosting environments or “application servers (eg: SQL, IIS, etc)”.  In this way a developer or architect can rationalize and reason about the application requirements of the target runtime environment (eg: “application services”).  Fundamentally, when an application is deployed, the primary concern is that the configuration and services of the hosting environment supports the requirements of the application and are properly configured.


The reasons for the logical model are as follows:


1)      The developer cannot rationalize/examine/configure the connections to and from processes that host application by simply looking at a big box that represents a machine either a logical type of server or physical box.  For example, if IIS, SQL, and Enterprise services were on a single box, it would be extremely difficult to determine and specify the security configuration between IIS, SQL, and Enterprises services.  How would you know for example that your COM+ components are running inproc with IIS out of proc? When your app is deployed to IIS do we assume inproc, and when we deploy to another box do we assume out of proc?  The same applies for SQL.; do we assume it’s on the WebServer?  Is the SQL server accessible outside of the box and available to other applications?  Also, how would you be able to configure the endpoint for the database connection?  


This ambiguity is exactly the problem we tackled in the Logical Datacenter.  We wanted to provide a view of “inside” the box, so you could discretely configure the desired services.  In other words, if we could provide a view of application services and desired configuration to support the applications, it really doesn’t matter then how they are physically distributed.  More importantly your application design is inherently optimized for distribution!  The last point about the logical datacenter diagram is that it is a scale-invariant abstraction over the services available on machines in a real datacenter, and it can be created such that only the relevant part of the datacenter that supports the types of applications under development (eg: ecommerce, intranet, b2b, etc) are required to be represented.


As far as zones, they are representative logical boundaries that can translate into VLANs, firewalls, security boundaries, etc.  Adding logical servers inside zones imply their configuration is supported and compatible with configuration policies within the zone as well as connectivity inside and outside of the zone.  You wouldn’t for example combine two logical servers from different zones onto one physical machine as their configuration and connections would be incompatible with the policies set forth by the datacenter.


When it comes to physical deployment, your app design has already accounted for the logical boundaries and connections and it’s really an ITPro choice now how to deploy it.  If all of these services are configured on a single box or multiple boxes, your app should still be guaranteed to run.  While we absolutely agree and acknowledge that a common scenario is for the developer to say, “these applications must be deployed on a single machine,” there are several solutions for this using the logical datacenter, and there is indeed a strategy for deployment moving forward in future releases…but more on this later while I continue to set context.  Hopefully this diagram will convey the main points.



2)      What usually fails in the deployment lifecycle of distributed applications are configuration issues and missing services on the target server, and a general failure to capture all configuration requirements.  When an application is moved from dev, to test, to pre-production into production there needs to be a complete representation of the application and its configuration requirements.  In the Logical Datacenter, we have SDM models for each application server that we support in the Whidbey release. This model represents the exact configuration meta-data of a real web server and doesn’t mix the configuration of other services or other network devices.  For example, the IISWebserver supports three protocols, http(s), FTP, and SMTP; (refer to the SDM SDK on examples on how to enable FTP, and SMTP protocols and models).  It also contains WebSite configuration to “host” Web Applications.  The definition of the WebServer does not allow it to host, for example, databases.  The database is a different model with its own set of protocols.


On the application designer, we support SDM models for Web Applications and configuration for Web Applications.  For example, all of the System.Web namespace a.k.a. web.config settings are modeled and round tripped from the project system back to the SDM model.  The value of the Deployment Designer is when you bind a Web Application to a WebServer, you choose the website, and the application pool (optional) to bind.  The configuration of the Web Application and the configuration of the WebSite settings are then checked via our constraint engine to ensure the configuration is compatible.   Furthermore communication pathways are checked to ensure the proper connectivity is available.


The application developer can reconfigure, or rewire their application, and redeploy it on the same logical datacenter to determine if it the new configuration is supported.


3)      There are fundamentally four layers of a deployed application; the application itself (your dlls, exe’s files, etc); the application services and runtime frameworks they depend on (IIS, SQL, MSDTC, NetworkLibriaries, etc), the OS and networks that that they run on (W2K, XP, VLANs, etc) , and finally the physical machine (disk array, ram, etc).  Each of these layers can be modeled discretely for the purposes of capturing all configurations, runtime, and hosting requirements for the entire application such that they can be deployed, configured, managed, and monitored.  It is this separation of concerns that allows multiple roles (Architect, dev, ITPro, and Ops) to operate on the data for their specific needs such that each role doesn’t have to be concerned with information in the application model that doesn’t address their primary concern (remember my comment about the “traditional infrastructure diagram” not being useful to a developer).  Similarly therefore, does the developer really care that a VLAN is set for a particular subnet?  Does an IT Pro really care what operation signatures are present on WebServices?  Does an Ops guy really care about what function the application provides?  Each of these roles plays a very important part of software development lifecycle and we are endeavoring to create an integrated suite of tools that support that lifecycle by adding configuration at these discrete layers.


In VSTESA, we have built out the model for the Application, and Application Hosting (“logical Servers”), and in future releases we will most definitely build the next critical piece (or missing link as Joel calls it) which is to map the Logical Server (application services configuration) onto physical machines and deploy the applications onto those services.  We are all working closely together to deliver on the DSI strategy, and we are exited about the product we’ve built today, and in the prospects of completing the entire process that we’ve started for our customers.




Now to your question:

 “From my Application Diagram, how do I create a deployment diagram that shows my web application and database being deployed on the same box“.


“Deployed on the same box” implies that two application servers (IIS and SQL eg: the dbms) are installed on one physical machine, and that the database and the web applications are to be deployed and installed on this same physical machine.  Does that mean deployment for this particular configuration, or does that mean for production only, or test, or all deployment topologies?  The point is that the decision to deploy applications to physical machines is generally an IT Pro’s decision, while it is certainly true that development can make assertions that they *must be deployed* to the same physical server due to latency issues, etc., the decision of how they are physically deployed is really determined by a number of factors, availability of machines, versions of services on machines, etc.  That said, physical deployment is not the scope of the deployment diagram (perhaps inappropriately named and we should reconsider deployment validation diagram or something that indicates that we’re validating configuration and service dependencies before we actually deploy).  What is of paramount importance however is that the configuration of the application services must exist on the physical machine *when* the application is deployed regardless of which machine or how many machines.  The focus on the Logical Datacenter diagram is ensuring that the application requirements and policies of datacenter regarding configuration are met.  The discrete unit of deployment (the app type you are deploying) has desired configuration model described and embodied in the Deployment Diagram.


Let’s say for my test environment I only have two machines, and my application consists of a Windows Client, a Web Service, and a database.  I decide to put my Windows Client and Web Service on machine A, and my Database on machine B.  But for my production environment, I actually have three servers where each is deployed discretely to one machine.  The logical model doesn’t have to change to support any physical environment.  The “application definition” and its requirements of the hosting environment doesn’t change, if it does, then it’s a new application definition and that’s another story altogether.


A couple of things you can do to represent all services on a single machine:


You could create a zone and call it “MyLogicalAppMachine”.  Within that zone you can drop in IIS and SQL and connect them together.  You can even add a comment in the zone that says these applications and services must be deployed together on one machine.  You could even go as far as restricting what kinds of “logical severs” can be contained within your “MyLogicalAppMachine”. If the comment isn’t a rigid enough specification, you can add a custom setting called “collocation:boolean” for example to the zone via the settings and constraints editor and set it to true. You can configure the application services “logical servers’ within the “Zone”, add the “MyLogicalAppMachine” to the toolbox via the option in the diagram menu, and use that abstraction each time you want to represent a “Logical Machine type”.  When you bind applications and generate your deployment report, these settings will be available to you to script a deployment (in future releases we’ll provide alternative deployment options to scripting) and will inform the script writer (assuming he knows to look for this “collocation” setting) to put these services on a single machine.  Even doing this doesn’t guarantee the ITPro won’t deploy them on two different machines (assuming your organization is such that they make those kinds of decisions, which is sometimes but not always the case), nonetheless you will be able to document your desired deployment in this way.


There are also some very interesting options and configuration that can be accomplished with our SDK, I encourage you to check that out as well as you can model you own types of “logical servers” and create your own hosting relationships (what you will and will not allow to be dropped onto the box).


I hope this helps clarify your questions.


Alex Torone (

Lead Program Manager

Visual Studio Team Edition for Software Architects

Comments (0)

Skip to main content