Recently I have been thinking a lot about the basic process we go through when designing an infrastructure solution, the choices we make, and why we make them.
These processes may be carefully structured within well-formed and trusted architectural frameworks, or they may be the sort of inherent thoughts that whiz through your mind when someone asks for your opinion on a pressing matter.
Regardless of the depth and scope of the project in front of you, I think the design questions you ask are often the same.
I have been reading what some VMware experts (along with other non-VMware related sources) have to say to this, and have tried to collate a list for myself. I looked to identify what it is we consider, without overloading it so it stays nibble, but documented nonetheless to clarify each step. As I said, these are scraped and cross-referenced from many people and sources (unfortunately too many to remember now), so I make no assertion that this all came to me in a glorious epiphany.
Here is what I have come up with so far. When looking at each decision within the design, these are the factors I would like myself to think through:
- what is the feature/component/technology and what is its place in the overarching solution
- options within the feature – why you need to make a decision
- assumptions
- requirements to use it (prerequisites)
- constraints when you do use it
- what is considered best practice (even though it may not be the right choice in this particular circumstance)
- impact of using (ramifications/consequence) – cost/availability/performance (including impact on other areas)
- positive (benefits) – justified?
- negative (drawbacks) – how to mitigate (if possible) – risks
- impact of not using (ramifications/consequence) – cost/availability/performance (including impact on other areas)
- positive (benefits) – justified?
- negative (drawbacks) – how to mitigate (if possible) – risks
What do you think? These are not the pieces to create a whole design, just the considerations for each and every decision. I’d love to hear your comments and suggestions for improving this.
Design Rule #1: Don’t start with a blank sheet of paper (ie. use patterns)
Design Rule #2: Don’t be restricted by what you use in Design Rule #1 (ie. don’t just copy)
Design Rule #3: Bring beer to at least one design workshop (but make sure the note taker is sober)
Design Rule #4: Have many short design cycles (ie. not just one big effort at the beginning)
Design Rule #5: There’s no such thing as “best” practice, apply scientific method (ie. design=hypothesis and build/test=experiment)
For us, requirements go beyond pre-requisites and right into the decision making process.
For example, if company Foo wants to virtualize a mission critical database that must have query responses of say no greater than 50ms and sustain approximately 100 transactions per minute then you need to make sure you account for that in the overall design. There are likely to be availability requirements around this too (maybe they need to use CCR or RAC for example.)
Other requirements might be security related such as PCI requirements. This puts rules in place for how you’re auditing, how it’s managed, what gets stored in the infrastructure, etc.
Those business requirements help us determine the right solutions to put in place (i.e. do we need chargeback? CapIQ? Enterprise Plus? SRM?) and then we worry about technology details.
The 5 rules listed by Steve Chambers are definite musts as well.
Heya i’m for the primary time here. I found this board and I in finding It really useful & it helped me out a lot. I’m hoping to give one thing back and aid others such as you aided me.