I recently spent some time on vCenter Orchestrator and really liked it with nice integration with vSphere Web Client, even though the Web Client has to improve quite some before it can overtake the standalone vSphere Client.Coming from the programming background, I find the workflow design is pretty easy to understand. Although targeted mostly for people with no programming background, workflow has in fact stronger typing than typical scripting. That may explain why having programming background helps a lot to quickly ramp up on workflow development.
At the same time, I find the way workflows are defined is a bit interesting and less efficient than coding if you have been programming professionally for a while. I think there are two contributors: terminologies and GUI. The following two sections I will elaborate the differences and hope you find it helpful if you take on workflow design someday.
Lost VMs or Containers? Too Many Consoles? Too Slow GUI? Time to learn how to "Google" and manage your VMware and clouds in a fast and secure HTML5 App.
Workflow vs. Programming Terminologies
At its heart, designing orchestration workflow is programming. The following table summarizes the different terminologies used in both worlds and how they are mapped between each other.
|Workflow||Function (or method in OOP)|
|Workflow inputs||Function parameters|
|Workflow outputs||Function return|
CASE Reborn With A New Face?
If you’ve worked in software industry long enough, you may remember the Computer-Aided Software Engineering (CASE) which was popular at the turn of 80s to 90s in last century. It visualizes programming with drag-and-drop widgets on a canvas. It didn’t last long before it went dead as a generic programming tool (some people also categorize the UML tool as CASE, BTW, but it’s mainly for design not for generating working code). Why? It’s not convenient and productive at all compared with writing code directly.
That doesn’t mean CASE is totally dead. The workflow designer picked the technology (flowchart in particular) again but in a narrowed down context of automation. It’s not only VMware vCenter Orchestrator uses the GUI flow chart as main design tool, but also almost all the workflow products do. So the following discussion is not limited to vCO but also all other products using the flow charts.
The pain points of using the flow chart come from the visualization of programming. For every simple step in the workflow, you have to drag and drop an element and click through a few forms. Things get really complicated when you have a step that requires data in and out. As mentioned early, workflow is strong typed. The action element, for example, defines what to pass in and out. The workflow caller has to bind these with attributes which must be defined if not yet. This can take much more time to get done than one line of code with programming. Yes, code is not intuitive but it’s highly efficient.
Having said that workflow has its benefits with the structures around it for example, ecosystem, versioning, packaging, distribution, integration with other products. I will discuss tips and tricks on how to make your workflow development more productive in the future posts.