You know what I love about vCAC? It’s the overlap of business logic and technology.
Because of that, the design considerations get super interesting. It’s not just about consolidation ratios, containment, path selection policies and NIOC. It’s about all the stuff you’ve come to know and love about vSphere design plus understanding who is going to not just just passively consume the system, but actually interact with it regularly. It’s about understanding the lifecycle of the workloads, mapping out concurrent workload profiles under multiple use cases and then switching tack completely to take a look at how access should be broken down. What does a Business Group map to in this organisation? How many Approval Policies should there be? What steps should there be in each policy? What actually triggers an approval? Which service provider is the right one based on the SLOs for the application sets? What other external providers do I need to integrate with – ITSM systems, config/state management systems, IPAM… the list goes on.
In this series of posts I’m primarily going to focus on the design elements within vCAC. I’m sure I’ll jump across and discuss more familiar concepts like availability, security and performance at some point too. I’ll be writing Requirements up as “Use Cases”, which is a great way to describe an input, output and the expected flow to get from one end to the other. Once I have a few of those together, I’ll start looking at how you need to design and implement vCAC to deliver the requirements.
As I write up posts, they’ll be added to the list below. Hope you find it useful!