Application Dependency – Upstream and Downstream Definitions

NOTE: Check out the latest on application dependencies with this post

One of the objectives on the VCAP-DCD exam is to be able to demonstrate and build Entity Relationship Diagrams (ERD) and define the upstream and downstream components. What I wanted to discuss with you was how you, my peers, interpret application dependencies and define what you consider as upstream and downstream components.

After my exam I researched it just to check that I’d got the answer right but if what I’m reading through my research is correct, it’s completely the reverse of what I had done in the exam and thus got it wrong.

This specifically in the VCAP-DCD exam is Objective 2.2 in the exam blue prints for 5.0, 5.1 and the latest 5.5 version.

In the blueprint you are given a link to the following pdf:

VMware link

It also says “Product Documentation” which is vague and not very helpful when you are trying to look at specifics but hey ho.

I’ve read and re-read through this document and can not see a definition of what the upstream/downstream relationships are so further investigation was required. You would have thought that this would be easy to find as VMware are excellent at documentation and knowledge bases! I also asked my instructor of my VMware Design Workshop course and he too confirms there are conflicting answers to this and at the time of writing; was unable to give me any solid answer.

If you google or bing search this topic you will find peoples interpretations to how to approach this when looking at it from an IT perspective. Just about all other examples I’ve seen back my interpretation up but Yes the only one that should matter for the exam is VMware’s opinion but it it’s still wrong in reality. There I said it, I actually disagree with VMware and not something I’d say or take likely. What worries me is that I really hope I’m wrong in understanding VMware’s interpretation of what the upstream and downstream components are and why. This is why I’ve taken to this blog to justify my own interpretation and perhaps question VMware’s stance on it.

After much painful research and trawling on google (other search engines are available) I found what appears to be the VMware’s answer to the definition at least it purports to be by the vExpert and it appears to be repeated in a few other blogs.

“In upstream and downstream relationships anything that happens downstream can have an adverse affect on upstream configuration items.”

Sorry but I disagree with this and maybe I’m looking at this too literally but here we go.

A river or stream runs from the highest elevation to the lowest elevation i.e. From top to bottom aka from upstream to downstream. So if we were to chuck some sort of dye upstream it would flow downstream and turn in to the dye’s colour. Therefore the upstream has a direct impact on the downstream. So if were to put the dye in the downstream portion of the river/stream what would be the affect on the upstream section of the river? Bugger all is the answer you’re looking for!

So lets take this into the world of technical dependencies. If for example we have a multi-tiered application like a website. Let’s say Lets assume I’m using part of the LAMP stack to provide this service. In order of reliance we have the http://www.vbikerblog that runs on an Apache server. This Apache server relies on two application servers Tomcat. Each of these Tomcat servers needs a data base and therefore we have two mySQL servers to support this.

All of these components rely on DNS as well as vSphere but I’ve not put these in for the sake of simplicity.


Now if you look at the way I’ve done the hierarchy you will see that mySQL is at the bottom and the end result vBikerblog website at the top.

Some of my research has led me to a few analogies on how to explain upstream and downstream relationships and one of them is think of a house. A house has foundations at the bottom and a roof at the top with in this case a lower and upper floor. If the foundations fail then the whole house comes down. If the roof fails you still have a house and an upper and lower floor all be it a draughty and wet one but you still have a house.


So if we consider the mySQL as the foundations and the website the roof this would fit quite well in this analogy and make good logical sense. However VMware don’t see it like this. From my interpretation they deem the website as the upstream component and the mySQL as the downstream component. In short this is completely opposite to what I consider logical sense so I’m trying my best to get my head around why they’ve gone down this road. I would actively encourage you the reader to leave your opinion and explanation in the comments to help me and maybe others out here. There’s some very smart cookies at VMware so there must be a reason but as to why I can’t see for the moment so please do feedback!

So back to this example then. If you take VMware’s approach which way do the arrows point? Well I think they would be pointing from top to bottom and with my and other’s approach vice versa. If this is the case then it goes against logic and many other industries interpretations so why it’s this way I don’t know. I really hope that this entire post is waste of time and that I’ve got the wrong end of the stick perhaps but it’s nice to get it off my chest anyway!

In conclusion to my virtual disagreement I feel that this desperately needs to be clarified by VMware with document and perhaps some instruction on how to map the dependencies with clear defined definitions. Building entity relationships can be a critical part of the design process and so if we are all doing in a conformed manner then this will mitigate any ambiguity between customers and professionals alike.

If VMware to use their method as I think I understand it, then they need to use a different terminology from upstream and downstream as its my opinion that it is not logical the way they explain it and I’m not alone in thinking that either.

I guess at the end of the day when it comes to your documentation and how you explain it to the customer they understand the context and explanation but we could do without the confusion among fellow VM professionals.

Please feel free to leave your comments and explain what I might not be seeing or justify the VMware approach or anything that would help your fellow virtual professionals. Ideally I’d like to be pointed to the VMware document defining this in black and white so post the link if you can!  🙂 Please note that I have posted an update to this subject which will clarify this much clearer so check it out!

Comme Je Fus
(As I was)

Don Ward VCP 3.5,4,5.x


IT virtualisation professional since 2002 after serving 7 years in the British Army as a REME Corporal. Currently a Solutions Architect. I'm a dedicated husband, motorcyclist, proud father and owner of two beautiful border collies Monty and Mitch. Hobbies are: Motorcycles - Isle of Man TT/Road races and MotoGP/BSB/WSB Rugby Union Skiing DCS Flight Simulator -A10A/C and SU25 Frogfoot specialist Airsoft - Closer Quarter Battle

Posted in Operation Grandslam
7 comments on “Application Dependency – Upstream and Downstream Definitions
  1. Pascal says:

    I totally agree with you Ward, I also got totally confused by VMware’s vision of upstream/downstream. It was one of the items that made me fail the (I found very confusing) VCAP5.5-DCD exam.

  2. […] Applying dependencies; upstream and downstream; Good blog by vBikerblog on this Application Dependency – Upstream and Downstream Definitions […]

  3. […] Application Dependency – Upstream and Downstream Definitions HOL-SDC-1401 – Cloud Management with vRealize Operations (Experiment with vRealize Infrastructure Navigator for dependency mapping and what it should look like when you design them.) RPO, RTO, WRT, MTD…WTH?! Understanding Resource Pools in VMware vSphere VMware vSphere Data Protection Documentation VMware vSphere App HA Documentation Multipathing policies in ESXi 5.x and ESXi/ESX 4.x What’s That ALUA Exactly vSphere Resource Management […]

  4. […] Great blogs like –,, & […]

  5. Serge says:

    In reality it depends how you are looking at.
    Form technical support perspective your foundation is a database server. But from customer … Hmm, assume that behind Web Server you have a number of different applications and if a database for one of then is down then you still can use other applications, so the web server is foundation …

    • ward8124 says:

      Serge I agree. I think the main thing is that as long as it’s been explained to the customer and in clear in your design document it should never really be an issue. For a VMware DCD exam and possibly VCDX level design document, clarity is key so as long as everyone is following the same rules then we just need to stick with one or the other.

  6. popovicbozo says:

    If i got it right, there are two views on the same challenge. I will use analogy application dependency = service dependency. The critical distinction how to understand dependencies comes from understanding who asks a questions :What is the application dependency:? Is the service consumer or is it the service provider as i believe the dependency directions will differ.

    1. View is about the service consumption. Take your example, the service called “vbikersblog”. A change on upstream – where the customer consumes the service adversely changes the downstream.

    2. View is about service provider. If you from the service provider/operations/maintenance then change something to the database or application (patch or upgrade) – now upstream – DB can adversely affect the downstream Web – the service provided to the end customers.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: