In my last article on orchestration, I talked about the issues with the current workflow design. Although intuitive and easy to get started, it’s really inefficient and hard to handle for complicated workflows. A natural follow up question is, “is there any better way to design workflows?”
Like everything else, there is hardly an approach that is better than others in every aspect. The alternative approach, coding, may not be as intuitive as the visualized flow chart approach, but it’s highly productive. So the quick answer for the above question is yes if you can combine them together.
Bothered by SLOW Web UI to manage vSphere? Want to manage ALL your VMware vCenters, AWS, Azure, Openstack, container behind a SINGLE pane of glass? Want to search, analyze, report, visualize VMs, hosts, networks, datastores, events as easily as Google the Web? Find out more about vSearch 3.0: the search engine for all your private and public clouds.
Of course, you don’t want users to design a same workflow twice with flow chart and coding. On high level, either flow chart or coding is just a view of underlying workflow model that are bound by a schema. If you make a change with one of the views, it has to be seamlessly reflected in the other. Then, you can use drag-and-drop flow chart while getting started, and switch to text based editing/coding afterwards when you get familiar and want to move fast. Even you mainly use editing/coding, you can sometimes switch back to flow chart for a high level visualization.
It may sounds too good to believe. It would surely take more time and thoughts to make it happen. A similar idea has been used in Eclipse IDE already.
As you may have known, Eclipse IDE has a great extensibility framework on which you can build plug-ins [BTW, VMware borrowed the same idea for its vSphere Web Client]. For each plug-in, there is a configuration file, plugin.xml, which defines extension points.
When getting started with the plug-in, developers use form based GUI. After a while, most developers switch to the pure xml text editor for most of the work. My personal experience is the xml editing is much faster than clicking through the GUI. I do switch back to GUI after editing mostly for validating my free editing.
Here are the two screen shots that better explain what was talking about. The first is the form based GUI for adding extensions; the second is the pure text editor for plugin.xml file.
Following the same idea, the orchestrator can provide a pure text editor with which developers can modify the workflow model file. The risk there is what if a developer breaks the schema with invalid keys and values there. It should be easily taken care of with error checking. The bottom line is that it does not get saved unless it’s validated.
I know it’s not as easy and simple as the plugin.xml in Eclipse IDE. But I think it’s a must have for better productivity, and whoever gets it done in product will surely have enormous advantages over its competitors.