This is the final in my three part post; the first discussed how our expectations of how we consume things has changed, while the second discussed how we can use stack designer to deploy a complete sandboxed environment based on approved organisational policies and configurations.
This final post will provide more detail on the infrastructure layer and how we instantiate the underlying topology as required for applications.
If we continue with the assumption made in part two, that we are developing the latest business application, then developers will need infrastructure. What the developers don’t need is to learn all the intricacies and low level details of deploying the said infrastructure; they are busy writing code (at the end of the day this is what they are good at and paid to do).
In the previous example we used the following topology; 
We could start to create custom workflows within the automation tool, UCS Director, which meets all the requirements, however this can take time and be difficult to manage.
One of the features of UCS Director is something called ‘application containers’, this shouldn’t be mixed up with Linux containers (term was used before Docker made Linux containers popular). They allow you to easily and quickly create a logical grouping (template or container) of virtual machines, bare metal servers, network components and security. Policies are associated and defined by the various subject matter experts, thus making it easier for other areas of the organisation to just consume, rather than getting tangled up in a subject they are not an expert in. A number of types of ‘application containers’ exist in traditional infrastructure – Dynamic Fabric Automation (DFA), or Application Centric Infrastrcuute (ACI)
One of the advanced ‘application containers’ is a plugin called ‘Virtual Application Container Services’ (VACS). It provides a secure segmentation of applications on shared infrastructure using best-in-class virtual security services. The following image shows the individual components that make up VACS with UCS Director orchestrating and automating the deployment including the configuration.
We can now make it easy to consume infrastructure templates without needing to understand all the terminologies or how to configure individual components. As these templates are defined by the subject matter experts the relevant policies can be assigned ensuring compliance to organisational requirements. It also means that the development team (continuing our previous assumption) can quickly instantiate or delete environments for their development lifecycle, and these environments can reflect what production would look like.
When using each of the individual components I have discussed over the last few weeks they can bring great benefit to an organisation when combining them into an end-to-end solution which drastically increases the value. That’s why I think making use of Cisco Enterprise Cloud Suite, and letting Cisco do the integration work, can help your transition into this new world as well. As well as gaining ‘day 0’ efficiencies Cisco Enterprise Cloud Suite can help business and organisations achieve;
- End-to-end hardware and software solution
- Out-of-the-box installations and content
- Accelerated application development and deployment
- Support for existing and next-generation applications
- On-demand consumption of both private and hybrid environments
I hope that you have found this series useful and informative. If you would like me to blog about a component in more detail, please leave a comment below. If you would like to know about something else related to data centre and cloud automation/programability again feel free to leave a comment and I will look into writing a new post.
Authors
