When I first began learning vRealize Automation, it took me long time to understand how it operated. From Fabric Groups to Compute Resources, Business Groups to Endpoints - I was lost.
After uncounted whiteboard sessions with my good friend Nathan Wheat, I had a solid relationship diagram drawn up. With one set of questions answered, another twenty or so sprung up to take their place. Little did I realize just how far down the rabbit hole I would go over the course of the next three years. As I continue to learn more about vRealize Automation, I find myself reverting back to the same principles used to build that diagram. Identify relationships, understand which services are used when, and look at the flow of a request through the system and then dig more deeply into the relevant areas of the system. For the way I think, a solid understanding of both the logical elements and the services that are responsible for them is key to designing, implementing, operating and extending the environment.
I hope this helps you to gain a level of confidence when working with vRealize Automation.
In this section we are going to take a look at what holds vRealize Automation together. The components that you deploy, what is going on inside of them and how they interact. We will look at the flow of a request as it moves through the system, and then dig into the logical constructs with which you are possibly already familiar. By the time you have finished this section, you should be comfortable with all the terms that are going to come up in later sections, as well as having a solid understanding of how each piece of the puzzle fits. This is incredibly important when it comes to designing and operating the platform.
The components of vRealize Automation could also be referred to as the application roles. Read on to learn about the functions of each component, and the ways in which they interact.
The Web Server
The Model Manager
The DEM Orchestrator
The DEM Worker
The Proxy Agent
Next up, we will take a look at the constructs that exist within the vRealize Automation platform. These are the object that you would configure to set up the platform for your own needs.
I’ve heard it said many times that design is as much an art as it is a science. I prescribe to that on a number of levels, but most espscially when you are considering the “form” of design. The role of standard templates and approaches for design is important when you are working for a consultancy who makes money out of services, but nothing helps you to truly own a design like creating the flow of the document and engagement yourself.
In this section, I will share with you my approach to vRealize Automation design. It isn’t the only way, and as I just mentioned is reflective of the way that I think about the product. I will be going through this in some fairly excruciating detail, so be prepared! As always, I love to discuss and debate different approaches as well as different considerations that I haven’t taken into account - so hit me up on twitter if you want to do through any of these points in more detail.
Without further ado, here is my philosophy of design.
It’s challenging to look at an architecture document that is nicely laid out and reconcile it with the process that you take to create it. The following figure is a representation of my approach to design, specifically for vRealize Automation.
Figure 3.1 - The Design Process
Looks nice and clean doesn’t it? The truth is, this is a very stylised example of what actually happens. Each step in the process becomes iterative, as you speak with different stakeholders and gather different use cases and requirements. People ask what makes a good architect - one aspect is the ability to present this disparate information in a clear, logical manner.
The following dot sections will take you through these pieces until we get to Implementation - that gets a section all of it’s own.
Ideally, the first thing to uncover are the business requirements. Doing so provides you with a lot of context about the end state of the project, and to understand how the executive sponsor will measure the project - or be measured themselves. Sometimes getting this type of information out of the technical team on a project can be difficult. If possible, you should spend some time with the project sponsor/executive sponsor in order to get the background and discover this. If you aren’t able to get access to this person, then you can use a process called “The Five Whys”. The idea is that if you ask “why” five times then you can get to the root cause. I’ve found that it works equally well to help get to the business requirement that underpins a given requirement. It strikes me that this is amusingly similar to “the three question form” in Austin Powers.
Another angle is to get to the “money”. Keep asking why until someone answers “to make us more profitable”. Move back one response from that and you have the Business Requirement. It may be to bring product to market faster, or reduce operational costs. Most projects that I have worked on have three or four Business Requirements. If you have more than that, take a critical look at them and consider if they are more technical than business oriented.
Having captured the Business Requirements, the question becomes “how do we make that happen?”. Underpinning the Business Requirements, we have Use Cases. These tell a story about the desired behaviour of vRealize Automation - what you may hear referred to as Functional Requirements.
It’s important to remember that Use Cases should be determined by the consumers of the platform, not the administrators. If you build a platform for administrators rather than consumers, then your platform will rarely see use. Yes, that’s a soapbox that you see in the background. The exception to this (one of them) is of course that the administrators have use cases too - monitoring, management, failover to name a few. The key is to write Use Cases from the viewpoint of interacting with the solution.
So what exactly does a Use Case look like? Here is a simple example of how to build one, and some of the questions you need to ask in order to tease the appropriate levels of information out during a workshop, and more clearly articulate the Use Case. Some creative licence is used here to make the point more clearly.
“Users should be able to request things from a catalog.”
Some questions to fill this out a little more: * Which users? Is this going to be open for all parts of the organisation or constrained to particular business units? * How do the users authenticate to the platform? * What things will be in the catalog?
“Users in our dev and QE teams log into the catalog using their AD credentials. They then request either a LAMP or jBoss deployment.”
- Where do these environments get deployed to? Do you have separate dev/test/staging/production environments?
- Does anyone need to validate a request for a new deployment in any of these environments?
- Is the topology and resource requirement of these deployments fixed or can they be modified by the user at request time?
- How long should these deployments exist for before they are torn down automatically?
At this point you can see that we may fork into multiple use cases. Pre production and production requests are likely to have different requirements when it comes to approval policies, and also leases. Different environments may be unique clusters within a single vCenter, or there may be a vCenter per environment. Each catalog item may have a different requirement depending on the licensing model of the OS/application in question. While this detail doesn’t go into the Use Case, it sometimes helps to see how the Use Case impacts the underlying platform design considerations. A real world example of this is a customer who licensed particular clusters for Windows, and others for RedHat. This piece of information was critical in describing how the platform would behave when considering placement options. Let’s see how aswering the above questions affects the Use Case.
“Users in our dev and QE teams log into the catalog using their AD credentials. They then request either a LAMP or jBoss deployment, and select to deploy it to dev. They provide a lease time between 7 and 30 days, and the request is fulfilled.”
“Users in our dev and QE teams log into the catalog using their AD credentials. They then request either a LAMP or jBoss deployment, and select to deploy it to prod. The request is submitted for approval, and if it passes the review then it is deployed. Being a production system no lease/expiry is defined.”
Now we are getting somewhere! This is giving us some decent information to work with, and an understanding of the core capabilities that the solution needs to provide.
How much detail should you go into with Use Cases?
The more work you do with Use Cases, the less rework you will need to do once the platform is up and running. Did you not discover that users need the ability to choose which site to deploy to? Network/Storage selection? Were you meant to adhere to some custom hostnaming scheme? Should you be providing the requesting user with a local account on the machines you provision? Do we assign IP addresses? Do workloads need to be backed up? You’ll note that these questions are largely about “should it do a thing” as opposed to “how do we do a thing”. If you are talking to consumers then the “how” is not something that they are likely to know. Of course, there are always exceptions - such as domain specific integration details that they may know about. Remember that not only do Use Cases provide the input to your Coneptual Design, they also translate to your Requirements. All of this information is relevant, and will help you when it comes to designing your solution.
Having gathered all of your Use Cases, it is now time to begin working on a pretty picture to represent what capabilities are required to underpin them. Before you do so, you will first need to distill the Use Case data down to the base concepts that they entail.
In a lot of cases, you will have the following to work with: 1. Authentication 2. Authorization 3. Service Catalog 4. Governance 5. Workload Lifecycle 6. Service Costing 7. Resources 8. Monitoring 9. Management 10. Third Parties
Figure 3.2 - A Conceptual Diagram
Your project may have more, or less capabilities that are required to meet your Use Cases. For the large majority of engagements, this list is a very solid starting point.
You’ll notice that at this point there is no mention of specific technologies. This is intentional. In theory, a list of Use Cases and even a Conceptual Design could be created prior to going to market for a solution. In theory…. In practice tenders are full of function/feature requirements, and it is your job as an architect to create this. If you are pursuing a VCDX then you want to demonstrate your ability to articulate the difference between conceptual, logical and physical design.
Requirements, Assumptions et al
Before you can extend your Conceptual Design into a Logical Design, you need to capture some additional information.
Consider for a moment any one of the capabilities in Figure 3.2 and ask yourself - what technology do we have available that can perform this function? Does it do it well? Are we in a position to use something else?
In this way, you begin to uncover your requirements, constraints, assumptions and the associated risks. I say begin, because while this section is listed towards the top of the design process, it actually threads through the entire design. It is not as though you can ask your customer “what are your requirements” and be handed a list. How can customers who have never used the product say “we need 36 Reservations”? They cannot - it is up to you to walk them through the design process and ask questions (and explain) in order to uncover what is required.
Here are a few examples of the relationship between requirements, constraints, assumptions and risks.
RQ: All workloads must be backed up.
CN: Backup software is Commvault Simpana.
AS: Backups use VADP snapshots.
RK: Backups will only be crash consistent.
RQ: Service availability must be 99.9%
CN: Availability of services is bound by all points of integration.
AS: All dependent services can meet availability requirements.
RK: Downtime of a single component will take the service offline.
Not all requirements introduce constraints, assumptions and risks. On the flipside, an assumption will always introduce a risk until it is confirmed one way or the other.
While it is recommended to list all RACRs towards the start of the design document, it is very nice as a reviewer to see constraints, assumptions and risks documented with the design decision that led to them being uncovered.
|column heading||oimage heaing|