info@metsi.co.uk Menu

Industry-leading Multicloud IT-as-a-Service solutions provider

Workflow Automation

We, at Metsi, have worked on numerous projects for large Enterprise based businesses, looking to automate their infrastructure using workflow automation.  The steps involved in creating Virtual Machines are recreated using Tasks within a workflow.

To understand what is required move from doing it manually to automating it in a workflow boils down to the questions of What? How much? Where? Which? In building a VM.

The manual way in VMWare’s vSphere involves a right click followed by a wizard of forms.

This then captures the name of the Virtual Machine you are building, Where it will be hosted for both compute and storage, What operating system, Which  network it will connect to, How much RAM, CPU and Disk space is required.

There are a number of rules to this –

  • each question must be answered
  • VMs must have unique names
  • The names can be used within the operating system and cannot contain certain characters and for Windows systems are limited to 15 characters
  • Most networking uses TCP/IP and therefore the VM will need to get a unique IP address within it’s network

In building a workflow automation strategy, these choices are made up front by the Architects within the business and most decisions will be built around an If Then Else decision or to borrow a programming term a Switch set of choices.

Switch(operating_system){
	case “windows”:
		connect_to_network = “win_network”;
		join_domain = “true”;
		break;
 	case “linux_redhat”:
		connect_to_network = “linux_network”;
		join_domain = “true”;
		break;
	case “linux_debian”:
		connect_to_network = “linux_network”;
		join_domain = “false”;
		break;

}

The above example shows a switch piece of code where a network and join domain choice is made based on the supplied value of the operating_system variable.

Using this kind of approach removes unnecessary choices from the end user, the person initiating the process.

In fact the start of the journey actually begins with the question Who? Who is allowed to make the request for the new Infrastructure and how much do they know about it all?

Typically the task of building IT Infrastructure falls at the feet of the IT department and for their user base to place requests on them to build Virtual or Physical servers.  The end user may just ask – can I have one? Or can I have a normal, big or small one? Then the rules for answering the questions are known to the IT team.

In building an Automated Workflow Automation process that builds the VM – the IT team need to build a form or a method of collecting the unknowns and feed that to the workflow tasks in order for the VM to build.

One of the tasks is to generate a unique hostname to be used in the process.  This may currently be done using Excel – the IT Admin loads up the hostname sheet – looks at the last name in the list – adds a new one to it using the next number e.g.

Win2012r201
Win2012r202
Win2012r203
Win2012r204 <- this is what will be used

This has it’s downfalls of course – if the spreadsheet is not updated then the process fails and an error will occur with a duplicate name.

A better way would be to store the names in a database – perhaps use an auto generated ID as the last digits in the name, and then add a row to get a new name in the process of the workflow.

The Database table is quite simple

CREATE TABLE `tbl_hostnames` (

`id` INT NOT NULL AUTO_INCREMENT,

`hostname_prefix` VARCHAR(13) NOT NULL,

PRIMARY KEY (`id`)

)

…with the data as shown above.  Then the value of the hostname is the value of hostname_prefix + id.

Now you may say but the id must be at least 2 digits and so you need a leading zero.  This is quite simple to fix – with an if statement

If(id < 10){

idstr = “0” + id;

} else {

idstr = id;

}

Then

hostname = hostname_prefix + idstr;

The code needs to be built into a Workflow Automation task that determines the hostname to use.  One approach we have used is to create an Apache/MySQL VM that hosts the above database and using PHP we query it and output the data in JSON format.  This then can be accessed using a standard http request in the form of a REST API call.

The process of making REST API calls sits at the heart of Workflow Automation projects, and enables us to store the choices that will be used in the build process.  This allows programmatically making choices based on the answers provided by the end user.  As an example – John Smith works in the Finance department and has been tasked with testing out a new version of a new accounting program that the company want to try.  The IT provisioning process has now been automated and his new Intranet page shows him a simple form.

The page is LDAP enabled and so hidden in the form is the value of John’s login ID (johns) – he is also in the Finance OU within Active directory and in our database we have a table that stores the costcode for the members of the Finance OU – so we retrieve John’s ID and OU membership and then use that to look up the costcode (this we will assign the VM to that costcode so that we can charge the finance department for their CPU, RAM and Disk space).

John selected a “medium” VM and so we have defined that to have 8GB RAM, 2x CPU and the Finance department only use Windows VMs – so that’s what John will get.  If Pete from the DEV team logged in – he would also get the choice of OS

 

 

As John is in Finance they use a network with a portgroup called finance_net and the choice of which network each department uses is also stored in our MySQL database and the query is made to determine the network to use based on the user’s OU.

Finance VMs are also hosted on a specific set of clustered servers and a set datastore.  The values of these are also stored in the database and retrieved within the workflow.  If they need to grow then the database can be updated or added to and the decision on which to use can be made programmatically.  This may involve a process to first query what is currently there and determine whether it has enough, and if not what to do about it.

As these automation workflows develop they can make decisions and self build infrastructure without the need for intervention. E.g.  If a datastore reaches 80% then go create another and use that new one.

As the data is stored in a database, this can also have a front end written to manage it.  This removes the need for programmers to manage the infrastructure and can all be done via a web page.

We have then developed this Workflow Automation into a tool called Simpla – which enables simple form creation to feed a workflow.  Check out this great tool at http://www.metsi.co.uk/apps/simpla

Get in touch if you want to discuss anything in this article or any other aspect of Automation

Get in touch

Are you interested in Metsi's solutions? Do you want more information about our offerings? Contact us today to schedule a meeting.

Contact Us

Top

This website uses cookies to enhance your browsing experience... moregot it