A Tale of Two Architects – A Review

I just finished two really great books on architecture, that really necessitate sharing with all of you. These two books were written for very different purposes and with very different voices, but I found them both to be enjoyable reads with educational content.

VDI Design Guide: A comprehensive guide to help you design VMware Horizon, based on modern standards

Johan van Amersfoort

The title doesn’t exactly roll of the tongue, but honestly that might be my biggest issue with this book…

My team has a small, but challenging VDI environment, so I placed an order the day this book was released and immediately tore into that lovely amazon box when it arrived. It’s been a running joke in the infrastructure and virtualization worlds for some time now that “this is the year of VDI!” Perhaps the fact that this prognostication hasn’t come to pass is due to the complexity to running a well functioning VDI environment. Seriously, just think about all the various components that make up a VDI environment: your core infrastructure Hypervisor/SAN/Network/Security/Compute, the client, the delivery model, nevermind what’s actually in the guest! Johan does a really great job of walking through all of these components and so much more in his first book.

The style of the book emulates the VCDX design methodology. I am not, nor ever will be, a VCDX but I found his explanation of the methods to be much more engaging than in other tomes. What I mean by this is that there are some architecture books out there that are extremely dogmatic and really are just guides towards attaining a certification. Johan on the other hand does such a nice job walking the reader through the various design and architecture phases that I’d strongly consider giving this book to any burgeoning architect, whether they cared about VDI or not.

Now don’t let me fool you, that this is all method and no meat, because that would be a tragedy. Like I mentioned at the outset, my team has some VDI challenges, and with the authors thorough and detailed dissection of all the various components of a VDI infrastructure, we had immediate technical takeaways. Johan walks through all the components that make up a VDI environment, providing his recommendations for why you may want to go in a specific direction, and just as importantly why you may not!

I’ve been told on a couple of occasions that I have a unique voice when I write. Given that, I have to say I thoroughly enjoyed Mr. van Amersfoort voice through this book. As it was pointed out during his recent visit to the Datanauts podcast reading this book was like sitting down with a colleague and chatting through a technical issue. It truly made it one of the most fun technical reads I can remember.

All in all if you’re interested in VDI or general Architecture principles, do yourself a favor and pick up Johan van Amersfoort’s first book.

You can find Johan at @vdidesignguide & @vhojan

IT Architect Series: The Journey

Melissa Palmer

I picked up this book solely because I’ve enjoyed Melissa’s blog (https://vmiss.net) for some time. In the review above, I alluded to having read some bad architecture books, so I intentionally went at this book with no expectations. I have to come right out of the gate and say that this book was one of the most interesting technology books I’ve read, in that it talked about technology very little. The subtitle for this book reads “A guidebook for anyone interested in IT architecture” and a guidebook is really what Melissa gave us.

The premise to this book is to help anyone interested in technology or a burgeoning IT practitioner understand just what an Architect is and what it takes to get to be one. I can speak for no one but myself and my observations over the past 20 or so years in IT, but it seems that many systems architects just kind of eventually land in that role. They get good in one area, and maybe good in another. After some time they end up being the smartest gal/guy in the room. This is not the book to help with that sort of an endeavor and I love it! In writing this book Melissa provides a path, that worked for her en route to VCDX, on how to take a more active approach to becoming a solution provider. A sampling of the topics covered include, “Learning New Skills”, “Infrastructure Areas of Expertise” and “Architectural Building Blocks”. The format is more about the journey rather than a prescriptive roadmap. In fact throughout the book, the reader is encouraged to take a step back and see how the information shared fits within their role and worldview.

While I really enjoyed the approach and Melissa’s voice, my knock on this read is that it could use a copy edit. If you are someone who has ever joined in on the “On Premises” debate, please approach this book knowing that there is some small amount of errata present. As a wanton comma abuser, I’m certainly not throwing stones and I hope this doesn’t stop you from picking up the book; the content contained within absolutely makes up for any grammatical oopsies.

The primary content of the book clocks in at just under 200 pages. If you already are or aspire to be an architect you are going to read technical guides that are way longer than this! Just like with her blog, Melissa’s personality carries through this book. It’s obvious that a passionate person wrote this piece, in an effort to help others, all the while maintaining a sense of self. A perfect example is when discussing assumptions towards the end of the book, Melissa creates an analogy where she uses the word ‘chicken’ ten times in a paragraph. I literally laughed out loud, to which my wife responded “Is your geek book amusing dear?” Yes, yes it is.

Many IT practitioners discount some of the “softer” skills required in a business environment. It’s in this vein where I think the book really shines. If you are someone who has a hard time communicating in either written or verbal form, you are probably going to have a hard time obtaining an architect level role. Melissa spends a significant portion of the book emphasizing what these skills actually are, why you need them and tips on how to improve them. I’m thinking about getting a couple more copies of the book for some folks who could really us some self-reflection in this area…

Obviously anyone with aspirations of reaching an architect level would benefit from picking up this guide. If I were a college professor teaching folks what it was like to work in IT and to give them a broad perspective, I’d have them read this book. As someone who’s worked in an architectural role, I learned a number of things as well, meaning even seasoned IT pros can benefit from picking this up. Reading this book over the past few days, it became obvious that Melissa cares about people and the solutions they provide, so by that token perhaps we could all benefit from the reflective approach conveyed throughout this book.

You can find Melissa at @vmiss33 & @ITArchJourney

VMware library

The entire vSphere community (myself included) seems to be in a flutter over the release of the long awaited Host Resources Deep Dive by Frank Denneman and Niels Hagoort. For me this recently resulted in a tweet-thread to see who had bought the most copies (I lost). The upside to this whole thing is I came across Mr. Ariel Sanchez Mora’s (you should follow him @arielsanchezmor) VMware book list. I love book reviews, so with Ariel’s permission I’m stealing his idea! In fairness you should really go check out his page first, but make sure to come back! Without further ado, here’s the best of my VMware library.

 

Certification

Like many people, this is where I started. I’d heard horror stories about about the VCP, so after taking Install, Configure, Manage I bought my first book, coincidentally (or not) written by the instructor of my class. I immediately followed it up by adding the second piece to my library.

The Official VCP5 Certification Guide (VMware press) by Bill Ferguson

VCP5 VMware Certified Professional on vSphere 5 Study Guide: Exam VCP-510

(Sybex) by Brian Atkinson

I think that in terms of the earlier books, I’d give the edge to the Sybex version. It covers the same fundamentals as the official guide, but goes much deeper.

Just last year while at 2016 I was wandering around the expo floor at VMworld 2016, bumming from failing my VCP6 (it was expected, but disappointing nonetheless), and I walked straight into a book signing for the new VCP6-DCV cert guide. It was destiny or something like that

VCP6-DCV Official Cert Guide (Exam #2V0-621) (VMware Press) by John Davis, Steve Baca, Owen Thomas

Here’s the thing with certification guides; the majority of the material doesn’t change from version to version. DRS is DRS is DRS (not really, but the fundamentals are all there). If you’re just getting started, or able to get a hand-me-down version of an earlier version you’ll still be leaps and bounds ahead of folks who haven’t read the books. They can be a good way to get a grasp on the fundamentals if all you’re looking to do is learn. To that end, if you’re goal is to pass the test, you can’t go wrong with picking up an official certification guide. I know the VCP6-DCV guide provided an invaluable refresher for me.

For more on the VCP-DCV, please check out my study resources.

Hands On

Learning PowerCLI (Packt publishing) by Robert van den Nieuwendijk

I didn’t realize until just right now that there was a second edition of this book released in February of this year! Regardless, this book is a great way to get started with PowerCLI, however it’s more of a recipe cookbook than a tutorial. If you need a getting started with PowerShell book, look no further than:

Learn Windows PowerShell in a Month of Lunches by Donald Jones and Jeffrey Hicks.

This is the guide to get started with PowerShell. Honestly I think the authors should give me commission for how many people I’ve told to go buy this book. It’s not a vSphere book, but if you want to be effective with PowerCLI, this book will help you on your way. It breaks the concept up into small manageable chunks that you can swallow on your daily lunch break.

DevOps for VMware Administrators (VMware press) Trevor Roberts, Josh Atwell, Egle Sigler, Yvovan Doorn

“DevOps” to me is like “the cloud”. It means different things to different people. In this case the book focuses solely on the tools that can be used to help implement the framework that is DevOps. Nonetheless, it’s a great primer into a number of the most popular tools that are implemented to support a DevOps philosophy. If you’re struggling with automation and/or tool selection for your DevOps framework, there are far worse places to start.

Mastery

Mastering VMware vSphere series

The gold standard for learning the basics of vSphere. This title could just as easily appear under the certification section, as it appears on almost every study list. A word of warning, this is not the book to learn about the latest features in a release. That’s what the official documents are for. You may notice that I linked an old version above, and that’s because the latest version was conspicuously missing nearly all of the new features in vSphere 6. That being said, it’s another standard that should be on all bookshelves.

VMware vSphere Design (Sybex) Forbes Gurthrie and Scott Lowe

Age really doesn’t matter with some things, and while that rarely pertains to IT technologies, good design practices never go out of style. This thought provoking book will help you learn how to design your datacenter to be the most effective it can be. I’d recommend this book to anyone who’s in an infrastructure design role, regardless of whether they were working on vSphere or not.

It Architect: Foundation in the Art of Infrastructure Design: A Practical Guide for It Architects John Yani Arrasjid, Mark Gabryjelski, Chris Mccain

And then on the other hand you have a design book that’s built for a specific purpose and that’s to pass the VCDX. Much of the content is built and delivered specifically for those who are looking to attain this elite certification. This is a good book, but as someone who has no intention of ever going after a VCDX, I expected something a bit less focused on a cert, and a bit more focused on design principles. If unlike me you have VCDX aspirations, you definitely need to go grab a copy.

VMware vSphere 5.1 Clustering Deepdive (Volume 1) Duncan Epping & Frank Denneman

I really don’t care if this was written for a five year old OS or not. If you want to learn about how vSphere makes decisions and how to work with HA/DRS/Storage DRS/Stretched Clusters, this is an essential read. Put on your swimmies because you’re going off the diving board and into the deep end!

I’m just going to go ahead and leave a placeholder here for the aforementioned VMware vSphere 6.5 Host Resources Deep Dive. Having heard them speak before and read their other works, I expect this book to be nothing less than mind blowing.

If you liked this, please check out my other book reviews.

Thanks for visiting!

The Order of the Phoenix – The Prequel

No, unfortunately this is not about some recently found JK Rowlings manuscript, it would probably be much more captivating if it was, but rather I just finished reading The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps which you could call the prequel to the Phoenix Project. Although I don’t think it was the authors intention, you could look at the Phoenix Project as a case study and Implementing ITIL as the install guide. One seeks to create understanding via a narrative, while the other is a prescriptive method for implementation.

At first it may seem hard to believe that the same authors who in 2015 published The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win wrote a book about Implementing ITIL. After all, a poorly implemented ITIL strategy can result in layers of bureaucracy and a slowdown of all IT operations. Combine this with the image that many people have of DevOps as a cowboy or shadow IT movement and the two books at a glance appear to make for odd bedfellows.  In reality ITIL and DevOps can and should be partners in creating a more effective IT organization that serves to meet the needs of the business at increasing velocity. They both can lead to the same results of providing faster turnaround, greater visibility & security, lower failure rates and less firefighting, so why shouldn’t these two frameworks coexist?

Before going much further, I think it make sense to take a lesson from the authors and provide a few definitions for the sake of conversation.

• 

  My ITIL pin, awarded to those who’ve passed an ITIL qualification exam

  ITIL as stated in Wikipedia is “is a set of practices for IT service management (ITSM) that focuses on aligning IT services with the needs of business.“. It’s a way to define a standard set of processes and controls around IT service. As the authors are fond of pointing out it can also be used as a universal IT language to define processes, but the true power of ITIL is in cleaning up a messy ITO.

• DevOps is often looked at as more of a culture or movement than a framework, but it seeks to more tightly integrate the Development and Infrastructure (or Operations) side of IT organizations. Where ITIL is extremely metric driven, DevOps is often very focused on tooling. In the context of DevOps, the Development side of the equation includes traditional Developers as well as Test, QA, integration, etc. Operations refers to what I’d prefer to call the Infrastructure team: Sys Admins, DBA’s, Release and so on.
• I think it also would also help to define an IT organization or ITO. In terms of the book, they reference Development, testing, release, QA, operations and the traditional Infrastructure groups all as parts of an ITO. In smaller companies these may be broken up into disparate groups, however you just as often see them combined as a larger ITO body. In full disclosure, my opinion and experience show that having these functions all combined within an ITO creates for better harmony (aka less finger pointing), and enhanced cooperation right out of the gate without taking into account the prescribed recommendations in the Handbook.

Now that we are speaking the same language, the Handbook presents a simple framework for how to turn your ITO into a highly functioning organization. The book is broken down into four steps to help guide you on your journey towards being a high performing IT organization.

For those of us in the trenches it can be daunting to try and figure out how to start. When you are constantly fighting fires it can be hard to see a way forward. The first step prescribed in the Handbook is “Stabilize the Patient”. I prefer to call it “stop the bleeding” because often IT practitioners are prone to death by 1000 cuts. It’s hard to look at process improvement when you have to read 1000 emails a day (not an exaggeration), fix the latest crisis du jour, deal with the Executives pet project, manage vendors and the list goes on and on.

The premise of Step 1 is pretty simple and it’s stated pretty bluntly in the first sentence “Our goal in this phase is to reduce the amount of unplanned work as a percentage of total work done down to 25% or less.“. Now if you’re like me the immediate reaction is “HOW THE HELL CAN I DO THAT!”. And the simple answer is: Change Management. I’m pretty sure there was a collective groan from anyone who may be reading this page. The reason that many people react that way is because we’ve all seen change management done badly. I’ve seen change management run the gamut from honor system spreadsheets, to long droning and monotone CAB meetings. The reason they fail is because they are not focused on the spirit.

If you’ve read any of my previous posts, you’ll know that I’m a proponent of a business first and technology second mentality. In the Introduction to the guidebook a lot of attention is focused on the fact that to succeed you have to have a culture and belief system that supports and believes in three fundamental premises:

• Change Management is paramount and unauthorized change is unacceptable. When you consider that 80% of failures are caused by change (human or otherwise), it’s quickly apparent that all change needs to be controlled.
• A culture of Causality. How many outage calls have you been on when someone has suggested to reboot the widget “just to see if this works”? Not only does this approach burn out your first-responders and extend outages, but you never get to cause and therefore resolution with this approach. My favorite phrase in the book: “Electrify the fence” goes more into that, which we’ll discuss soon.
• Lastly, you must instill the belief in Continual Improvement. It’s pretty self explanatory: you fought hard to get to this point and if you’ve already put in this level of effort you obviously want to see the organization continue moving forward. If you’re not moving forward, then everyone else is catching up.

Now you can’t just have an executive come in state that “We have a new culture of causality” and expect everyone to just get on board. It’s a process, and by successfully demonstrating the value that the process brings, people will come on board and begin embodying the aforementioned culture. What you do need your Executives to get behind and state to the troops, is that unauthorized or uncontrolled change is not acceptable. They say it over and over in the book, the only acceptable number of changes is Zero.

But how do you get people to stop with the unauthorized changes?

• You need a change management process. You must must MUST have a change process, and it can’t be burdensome.
• There has to be a process  for emergency changes. Don’t just skip the whole change approval process for emergencies, because then you set a precedent that says you can avoid the process when it’s important enough. Once you’ve done this you’ve created an issue where everyone thinks their issue is an emergency.
• Consider having a process for routine, everyday activities with normal levels of risk that get auto-approved. The important part is that they are tracked and that …
• The people implementing the changes are accountable. They are accountable for following the process as well as for executing on the change. Many people don’t want to follow change processes, so they won’t. You have to have a means to monitor, detect and report on changes. Once you have this in place, people can truly be held accountable.

And why do you want to go through this process of reducing unplanned and unauthorized change? The number cited in the book is that 80% of all outages are caused by change. Reducing unplanned changes reduces outages and the duration of outages. Less outages means less firefighting. A formal process that MUST be followed, drops the number of drive-by’s that your engineers have to appropriately deal with as all changes are going through the process.

Lastly, going through a change process forces the change initiators to think intentionally. Someone I respect immensely had me read Turn the Ship Around! last year (another book I’d highly recommend), and in this book there is a concept of acting intentionally. You state to your teammates “I intend to turn the speeder repeater up to 11.” By stating the actions you are about to take, you are forced to think about them and what their results may be. It can also slow you down a touch when you’re about to just make a “harmless little update.” By acting intentionally through the change process, you consider (and hopefully document) exactly what you’re going to do, what the outcome will be, how you’ll test, and what your rollback plan is. All of these acts will provide for higher quality changes, fewer outages and ultimately provide more time for your engineers to focus on the remaining steps in the handbook.

Now by the time you’ve gotten through step one, I’d argue that the heaviest lifting is done, and you’re hopefully learning more about ITIL as you go. The remaining steps that the authors detail in the Handbook share a lot of commonalities and are where you can really find opportunities to start blending the best parts of ITIL and DevOps into your own special IT smoothie.

Step 2 is pretty straightforward. You have to know what you have in order to effectively support your business. You must create an inventory of your assets and your configurations. Honestly this step can be summed up pretty succinctly: Go build a CMDB and and asset DB, otherwise you’re subject to drift and you can’t hold people accountable for their changes. It’s the bridge between Step 1 where you have to know how the environment is setup and configured, and between Step 3 where you begin to standardize.

Now bear in mind that when this book was originally written, DevOps hadn’t been coined as a term yet, but you can see it as a precursor with the title of Step 3 “Establish a repeatable build library”. In 2017 the benefits of this are pretty obvious. If you have a standard build, you can hand that release process off to more junior members, or ideally have the process automated. By having your builds standardized and your configurations documented, your environments are not pets, they are cattle. With a standardized environment your outages are likely to be more infrequent, but when they do occur the time to resolution will be dramatically smaller because you have a known footprint.

I did struggle a little bit with section 2 & 3. Section 2, “Catch and Release” is six pages long and consists mostly of the benefits having a known inventory will provide. It’s obvious that the authors find this point important enough to break it, but if it were an easy task everyone would already have the information and documents the authors specify.

This isn’t necessarily a knock on the authors, as it’s a twelve year old book, but section 3 “Establish a Repeatable Build Library” is a bit dated and heavily focused on the ITIL processes. No doubt having your process repeatable is very important, but as we’ve already pointed out in this day and age velocity matters and for this you have to have tooling and automation in place. Again it’s certainly not a knock on the authors, it’s just that you may be able to find better, more modern guides on how to achieve a build system in 2017.

The final section is really interesting to me as it’s part summary, part recap, and part advisories on the pitfalls to watch out for. Any topic on “Continual Improvement”, the heading of section 4, will obviously have a focus on data and metrics. Typically in an ITO metrics revolve around system or availability metrics like is the system up, is the database running too hot, etc, whereas the authors advise looking at more qualitative and performance metrics. After all the goal is to control the environment, and reduce administrative efforts so that your knowledge workers can spend more time working on value-add efforts. As you read this section it’s easy to see that many of the ideas in the “Continual Improvement” section are the seeds which the Phoenix Project grew out of. The biggest takeaway for me is that to become a highly effective ITO, you need less six-shooters and cowboy hats and more process roles and controls. Only by controlling the environment can you actually expect predictable results.

The book effectively wraps up with a summary of the objective “As opposed to management by belief, you have firmly moved to management by fact.” If you’re struggling to obtain this goal, The Visible Ops handbook may be a good place to start, just be prepared to augment it with up to date technologies and data.

Get Out of I.T. While You Can.

With a little conscious deliberation, the next book I decided to read after The Phoenix Project was Get Out of I.T. While You Can.  I guess the first clue about this book should have been that there is no description of the book on amazon, only bite size snippets of praise(aka name drops). It’s a very quick read at about ~100 pages of actual content. The first half of the book is fairly decent, but quickly devolves into strategies for advancing your career instead of advancing your organization. The message that I most deeply associated with from The Phoenix Project, that of taking an Outside-In approach to IT, is supposed to be the central theme of this book.

It’s a concept that IT has struggled with, IMHO. Often people with a background in IT rely on their technological skills, their intelligence, their ability to understand a facet of our digital world that many struggle with. When at a social engagement and asked what they do the response is typically “I’m in IT.”

Unfortunately that answer is wrong. It’s holding both the individual and the organization back. The person who says “I’m in IT.” doesn’t identify with their org, they identify with technology. Now don’t get me wrong I can’t think of anyone I’ve interacted with in this field who doesn’t like to geek out on some widget, BUT if their primary priority isn’t the success and growth of their organization, then they are missing opportunities.

My friend Scot Barker (@sbarker) is someone whom I’ve gone to on multiple occasions for advice and guidance. As providence should have it he recently relayed his experiences about exercising this concept in a very eloquent fashion.  He relays the story of how engineers at at a company he worked for “.. spent 2-3 months, on-site at the customer, learning nothing about engineering or how the products were built. Nope, they learned how to do the job the customer does every day.” Through this experience “They always had customer input on what was needed and how a certain feature needed to work” and therefore hit what should be the #1 priority of the organization: solve the problems of our customers and make their lives better.

Now this is not an easy task for many classical IT folks. Disruption is the industry term dujour these days, and it applies not just to software or industries, but also to IT. Those who can accept that IT needs to evolve past a traditional rack and stack, keep the lights on mentality will find themselves furthering themselves and their organizations. Taking an Outside-In approach is a critical foundational element to being successful on this journey. Only by knowing where your Organization has been, where it is going and what it’s aspirations are, can you be most valuable.

As I mentioned before it’s not an easy path to walk, but once you’re on it I think you’ll find it to be rewarding. I know I have. If you have thoughts or stories to relay on this topic, I’d love to hear from you.

The Phoenix Project

From the moment that I arrived in Vegas for VMworld 2016 I started hearing about this book The Phoenix Project. At first I thought that my ears were playing tricks on me when I heard that it was a DevOps novel. This weird reality sunk in when during the opening day keynote address John Spiegel,  IT manager at Columbia Sportswear spoke about the virtues of this book. (segment begins right around 51min)

Given all the chatter around this book, I ordered it from my seat before Mr. Spiegel had even left the stage. The primary message from Mr. Spiegel and the session in general was “treat IT as a factory, focusing on efficiency’s, optimizations”. This is obviously a very important message, but I’d argue that anyone who works in IT and hasn’t recognized, learned, embodied this message, or at a minimum isn’t working towards it…  well… there’s probably other fundamental messages that should be more relevant to them.

There is an underlying theme to the presentation, Mr. Spiegel’s talk and in this book that resonated very strongly with me and that is is to take an Outside-In approach to IT. Instead of focusing on a technology or a framework as many in IT are prone to do, we need to look at the problems (and successes) that people throughout the Organization experience. Take that newfound knowledge to figure out how we can use technology to positively affect their experiences and therefore positively drive the goals of the business. Once articulated it’s a pretty simple concept to internalize: if you don’t know the business, its positives and its problems then how can you possibly be most effective in helping the Organization move forward?

One particular individual in The Phoenix Project recognizes this reality in a rather dramatic fashion and goes from the stereotypical vision of “IT as the department of ‘no'” to one who actively seeks engagement. He takes the empathetic approach of trying to understand both the pains and successes of his business and how he can use his technological skills to affect change for the positive. There is a realization that by attempting to apply strict dogmatic InfoSec principles he just may slow things down. Once his mindset shifts to an Outside-In approach, he’s able to get a far greater level of cooperation, able to implement more of the principles he cherishes, all the while moving the business and his personal/career objectives forward at a faster pace!

The inside out approach is just one piece of this fantastic book. The novel format is one that I haven’t seen in IT improvement books before, and it certainly makes for an engaging read. Don’t mistake this book for a deep-dive into any frameworks or technologies. Rather it creatively addresses many of the common challenges which need addressing in order for you to develop a high performing IT organization. If you’re looking for a guide on how to begin implementing a DevOps framework and culture in your organization, then disregard the sub-title as this probably isn’t the best book for you.

If you’ve ever been bogged down in the quagmire of firefighting, been unable to break the cycle of finger pointing, struggled to come up with fresh approaches to  the struggles of working in a large IT org or even if you’re just someone who works with IT, then this book should be a must read for you.

PS: If you’ve found this interesting, perhaps you’d like to check out my thoughts on Implementing ITIL written by the same authors.