By Dominic Wellington
Cloud Solution Manager, BMC Software
THOUGHT LEADERSHIP WHITE PAPER
Why Workflow Tools Don’t Work as a
Cloud Management Platform
1
By all accounts, we’re now a few years into the formation of the cloud management software market. Full-service management vendors are battling for market share with upstart niche players, all aiming to become the governance layer on top of this highly dynamic environment of workloads we call cloud – private, public, hybrid, or otherwise.
Many of the players, focusing on the rapid provisioning aspects of cloud management (otherwise known as “day 1”), are utilizing generic workflow automation engines to offer quick wins and built-in flexibility. Microsoft (via “Opalis” acquisition), HP CSA (via “Operations Orchestrator”), ServiceNow (via its Virtual Lifecycle Management product), and ServiceMesh are just a few examples of solutions that rely heavily on a workflow engine as the primary brain of their cloud management solution. We’ve been using workflow engines for years. They’ve become the glue of the systems management space, connecting heretofore disparate tools together in a string of purposeful automation. They’ve helped to automate some of the most mundane tasks in IT – from password resets, to process restarts, to user account creation. It’s only natural that the vendor community would attempt to re-purpose this jack-of-all-trades technology into the key cog of a cloud management platform. After all, cloud management is nothing if not end-to-end automation, right?
There is no arguing that workflow engines such as the ones above have a role in your cloud management platform, but it is a mistake to suggest they can deliver the core business logic layer needed for a truly flexible & scalable cloud platform. The only way to meet these requirements is through a purpose-built policy-based system that can account for the decisions you need to make today and the ones you don’t know exist yet. If you fall into this trap, you will come to find that the total cost of ownership for workflow-based platform will far outweigh one that utilizes a policy based engine.
Don’t believe me? Let’s consider how your cloud management platform will handle the following 4 real-world scenarios that nearly every cloud platform implementation will encounter over the next 12-24 months.
PLACEMENT LOGIC
One of the core tenets of a cloud management platform is that it can determine where to place workloads that have been requested by the consumer. If it cannot do so in an automated fashion, then someone within IT must manually intervene to make the decision on behalf of the platform. At that point, your provisioning times have just gone from minutes to hours/days. Generally speaking, initial implementations take into account the following criteria for placement:
»
Criticality of the service – is the service being requested a key revenue generating app or a more commodity environment?»
Type of Environment – are you asking for a sandbox dev environment or a more production-oriented environment for load testing?»
Expected Service Level – are you expecting a certain level of availability?With platforms built on workflow engines, the decision criteria are often hard-wired into the decision process. But what if, over time, your decision criteria changes? For example:
»
A new service level – instead of just Bronze/Silver/Gold, you now want a Platinum?»
New criteria – make a placement decision based on who is requesting or when the service is needed»
Weighting between criteria – instead of weighting each criteria equally, you now want one of the above to factor more in the decision than others?»
New service offerings – perhaps on an exception basis, a key new service in the catalog should ignore one or two of the above criteria.How can the placement logic in the cloud platform keep up with these changes? What is the cost of coding & maintaining that logic if done in workflow?
RESOURCE PROVIDERS
The commoditization of the underlying IT infrastructure means more choice for workload placement. No doubt VMware has been the dominant resource provider in the enterprise virtualization market…but just as Android has taken market share from mobile giants Apple & Blackberry, so too we are seeing increased competition for market share by the likes of Microsoft Hyper-V, Openstack, Rackspace, Verizon Terremark, and others. In addition, customers are realizing that there is opportunity to get better efficiency from their existing assets, even if the market has branded them as “legacy” (think AIX with LPAR or zLinux). If you know who your resource providers are today, chances are you are kicking the tires on one or two additional ones. Why? Because the gap between resource providers is narrowing every day…and your cloud management platform has promised that it can successfully broker it all for you.
If this is the case, find out:
»
What is the real effort to add a net new provider into your platform?»
What will it take to support a new version of an existing provider?»
How will the provider fit into the placement logic discussed above? What if it’s a new provider on which you only want dev/test workloads running?More logic, more coding, more maintenance….
APPLICATION DEPLOYMENT ARCHITECTURES
Beyond the benefits of modularity, the beauty of service-oriented architectures is that they can be deployed in a variety of ways, each one sized to meet the needs of the consumer and the expected demand. Take, for instance your standard LAMP stack (Linux/Apache/MySQL/PHP). A developer might request a LAMP environment for sandbox development purposes and as such only requires a single instance architecture, where the entire LAMP stack is deployed to one server. However, that same application, when deployed into production, would likely be run in a multi-tiered architecture, with the web/application/database tiers broken up across multiple servers – with load balancers & firewalls thrown in for good measure. Still yet, you might have a 3rd architecture that falls somewhere in the middle, for QA system testing purposes.
Ask yourself – across all of the services in my catalog, how many variants of architectures exist? And as new applications & infrastructures (databases, anyone?) are added into the catalog, how does that impact your logic?
With workflow, each variant for each application must be modeled discretely, coded, & maintained. The development and maintenance workload adds up very quickly.
DYNAMIC AUTO-SCALING
All of the cloud management platforms on the market today have found a way to solve the rapid provisioning “day 1” challenge. As described above, some have done so by either narrowly defining what can be provisioned or limiting the options during provision. The next battle front exists in the “day 2” arena and no battle is as imminent as the one to be found around dynamic scaling.
The desired state is well known – a service, after being initially provisioned & configured – should automatically re-size itself for optimal performance, based on any number of capacity, performance, & business metrics. Grow the service with peak demand & shrink it when no longer needed. Easy, right? Not so fast…
3
Consider the following when determining what it will take to build the requisite scaling logic via workflow:
»
Which metrics should drive the scaling decision? Is it CPU, memory, transactional performance, time of month/quarter/ year?»
Do all metrics weigh equally for each application? A retail application will likely need to be more sensitive to transaction time & time of year than an app performing off-line computational models.»
Scale up or scale out? Performance standards can be met either by adding memory, CPU or storage capacity within the current footprint of a service or by adding net new instances to the overall footprint (e.g., additional web servers to a web farm). Which is the right choice for your application?While the above tasks may not be completely impossible with orchestration tools, it is important to realize that they all represent time-consuming development and maintenance projects. What’s more, companies may not realize that such development projects are under way, because they are managed within operations teams rather than as traditional development efforts. Because operations teams do not have the tools or expertise associated with long-term product development, the development project can easily become mired with cost and time overruns. Such projects can also be opaque from outside the operations department, exacerbating the ongoing discussions about how IT budgets are spent and what value the business gets from its investment.
Orchestration engines excel at stitching together different products and platforms, but they are a poor choice for core business logic because of the need for extensive development and ongoing maintenance of the workflows. As such, their place in a cloud strategy is in the integration layer, connecting the cloud management platform to other systems that may take advantage of automation or provide analytics. In this capacity they will provide the greatest value without turning into manpower, time and budget sinks.
Simply put – when vetting cloud management platforms, the scenarios described above should be put to the test. Find out whether a workflow tool is a key part of the policy layer, and if so, look beyond what is there today and test scenarios for the future. Find out what it will really take in manpower and skill set to get the job done, and keep that functionality available over time as requirements and environments evolve. Recognize that the market doesn’t have all of the answers – yet – and you need to be sure that what you have today will scale with you into the future.
BUSINESS RUNS ON I.T.
I.T. RUNS ON BMC SOFTWARE.
Business runs better when IT runs at its best. Tens of thousands of IT organizations around the world -- from small and mid-market businesses to the Global 100 -- rely on BMC Software (NASDAQ: BMC) to manage their business services and applications across distributed, mainframe, virtual and cloud environments. BMC helps customers cut costs, reduce risk and achieve business objectives with the broadest choice of IT management solutions, including industry-leading Business Service Management and Cloud Management offerings. For the four fiscal quarters ended June 30, 2013, BMC revenue was approximately $2.2 billion. www.bmc.com