Keeping Pace with Cloud Innovation
One of the biggest challenges organisations face when transitioning to a hybrid cloud delivery model is balancing the competing requirements of:
- Technical,
- Operational, and
- Financial
In a traditional data centre model, each of these business functions were managed as individual towers of responsibility. However, as organisations transition to a new Hybrid Cloud Operating Model, it is imperative that the desired outcomes of each are well understood and empathetic to the delivery of a single outcome – digital transformation.
Let me explain. As I have highlighted previously, Financial Governance is the keystone to a successful cloud transition. I reference Cloud here in the context of an Operating Model and not a technology offering. Cloud is consumption based, where you only pay for what you have consumed. Unlike the more traditional CAPEX model, operating expenditure is a lot harder to manage and a lot harder to govern. Consequently, if Cloud is not well governed from a Financial viewpoint, then Technical innovation, no matter how promising, will quickly be curtailed. There is no greater ‘poison pill’ to progress than budget overrun.
This is where the issue of compromise takes centre stage. Buttonwood has worked hard to ensure that we continue to deliver the most powerful Cloud Management Platform (CMP) on the market, wrapping policy around native cloud services (SaaS, IaaS and PaaS) to seamlessly address organisational need for top down Financial, Operational and Technical control. If we were simply delivering a CMP that conformed with the lowest common denominator (VMs) this wouldn’t present as an issue as there is little innovation in spinning up VMs. However, Buttonwood was developed to support native cloud services (such as Availability Sets, Scale Sets, SQL Azure, HDInsight, Application Load Balancer, Managed Disk, Redis Cache etc) and as such we need to be able to model each offering to ensure that we are able to provision and cost services for a defined lease period before deployment. This capability is the cornerstone of our 360 degree approach to cloud governance and financial transparency for increased business confidence.
The need to model each service, however, often raises the question of agility. How are we able to move quickly if a service hasn’t been modelled yet? It’s a great question, and while we have more than 90% of Enterprise ready services modelled, there may be a need to consume a ‘discrete’ service quickly. To answer this question, we are announcing native support for ARM Templates; the Azure Domain Specific Language (DSL) used to orchestrate Azure cloud services. This new ARM capability will ensure customers can meet their Technical requirements while seamlessly aligning much needed Financial and Operational control.
To help you understand how we have implemented ARM support we have developed a quick video introduction for you consumption. We have also detailed, the key concepts below including:
ARM Template Node
The ARM Node developed by Buttonwood allows customers to copy or consume (GiT Artefact) an ARM Template from within our graphical composer. The example below highlights how we incorporate a previously developed ARM script that orchestrates a PostgreSQL service within Azure. To ensure that the service can be fully costed we have also incorporated an ability to cost the service. This costing parameter is then be used to calculate an estimate for full blueprint and ensure alignment with our governance processes.
ARM Parameter File
ARM templates support a second Parameter file to enable dynamic versioning of the outcome. Buttonwood leverages this framework to broaden the input options to include all relevant Buttonwood variables as well as run-time specific values that are derived from user or API input;
ARM Output
Finally, to ensure we support the full functionality of the ARM template, you can use our output functionality to trap output values that have been defined from within ARM itself. The output value is then available to the application architect to be blueprinted to help orchestrate complete full stack solutions. In this example, we are using the DB-HostName parameter as in Input into both the Puppet Class as well as the Bash Script to build and connect to the newly created Postgres database.
ARM Output Variable
Puppet Parameter
Linking to Output Parameter
I hope you are as excited about this new capability as we are? To find out more about this, or any other Buttonwood capability contact us.
Comments