Each year I order a couple of books even though I have no idea if they will be books which contain content I can actually use. The reasons to buy these books varies: The title might look promising, there is a lot of buzz about a book or it can be as plain and simple as me liking the cover of a book. Brian Suhr’s book belongs to the first category, the title looked promising. Such a strategy can result in picking bad books of course.
This book is not a book that does not deliver though. After having read Architecting EUC Solutions I would say this book is quite the opposite to me, an EUC compendium ‘par excellence’ if you will. A book you need in your back pocket and on your desk when you work in EUC. I realize that calling this book a compendium is wrong. This book isn’t “a concise compilation of a body of knowledge“ (Wikipedia), or what else and Brian may not be by definition a body of knowledge, but he does share his vast knowledge with his readers. To be honest I am still baffled with how much he actually shares, and that is the sole reason why I call this book a compendium anyway. Any points mentioned in this book should come up during your hunt for a design or architecture.
The structure of the book:
Introduction
Chapter 1 – Developing Your Strategy and Roadmap
Chapter 2 – Use Cases
Chapter 3 – Starting the design process
Chapter 4 – Pilots and Proofs of Concepts
Chapter 5 – Desktop Assessments
Chapter 6 – Virtual Desktops
Chapter 7 – Physical PCs and Laptops
Chapter 8 – Desktop as a Service
Chapter 9 – Application Management
Chapter 10 – User Profiles
Chapter 11 – Portal
Chapter 12 – Disaster Recovery
Chapter 13 – Networking
Chapter 14 – Operations
Chapter 15 – Infrastructure
Chapter 16 – Security
Chapter 17 – Endpoints
Appendix – Infrastructure Design Example
The highlights in this book for me:
This book contains a lot of highlights to me. I could easily write a part about each chapter but then you might as well read the book.
A lot of engineers, designers, architects look at things from a technical performance option only. Why not try in from another viewpoint? Chapter 1 has a part which deals with how important it is to marketing your EUC solution. After reading this part it should be obvious how important choosing the right POC or Pilots are because these will offer the first experience of your EUC solution to the users. As such I would advise you to read chapter 4 after you have read chapter 1.
Chapter 2 explains Use Cases. If you have never had to deal with End User Computing, this chapter really is a must read. It explains why in EUC Use Cases are right up there with Goals, Requirements, Constrains, Assumptions and Risks. If you do not define your Use Cases properly, you will end up with sprawl, and I have to say, the consequences of sprawl in EUC are worse than in a server environment. I speak from experience.
Chapter 4 which deals with POCs and Pilots is a very interesting read. The way companies treat POC’s and Pilots is often totally wrong. In this chapter Brian explains the reason why a lot companies have failed POCs and Pilots and how you potentially could execute them successfully. This chapter has made me rethink my own strategy and point of view and I ended up changing both on points where I thought I could benefit from doing so. This part of the book is generally applicable across IT design/architecture.
Chapters 6, 8 and 9: Behind all the marketing hype of VDI Brian offers a very sobering perspective on VDI. I would advice you to read these chapters together. If you are considering or are in the process of deploying an EUC solution based on VDI and/or DAAS, make some time and read these chapters.
Chapter 15 deals with infrastructure. If you are looking for a storage angle or a CPU or memory angle, than this chapter should really interest you. Very high consolidation ratios in VDI are possible, but it really depends on the requirements of the solution you are trying to deploy. Brian offers some insights into what consolidation ratios he advises based on customer experience (*). If you have questions about the hardware you will use to create your EUC solution on top of, this is also handled in chapter 15. Brian gives a good list of pros and cons of traditional infrastructure vs Conversed and Hyper-Conversed Infrastructure. Together with Chapter 16 this is probably the chapter that will be most recognizable by infrastructure architects.
Why this book stands out from the crowd:
This book reads like the author did create a mindmap about EUC (with and all the ins and outs, do’s and don’ts) and after creating the map took the decision to create a book based on the map he created. As a bonus he decided to share his own discoveries and best practices.
Where at first I was a bit annoyed that this book is not a strictly technical or theoretical book (as most of the books about design and architecture which I have bought are) after reading about 30 pages I made a 180 degrees mental turn. I realized that Brian wanted this book to be different. The focus in this book is not the creation of a technical design for an EUC, but how to design an EUC solution. The technical part is a supporting part for the business requirements, which in real life it should be. It should support and service the business it has been deployed for. The moment I realized that the goal of the book is solution driven (The title actually should have been an obvious giveaway from the cover onward), I really wanted to read this book from cover to back.
Brian works for Nutanix, so is this a vendor specific book? It hardly is. There is a design scenario at the end of the book which is based on Nutanix hardware, but it really could have been any hardware. Brian also shifts from VMware to Citrix to Microsoft and to other vendors where ever and whenever it fits the book. I would personally say that this book is as vendor agnostic as you can write a book about EUC without doing damage to the content because you tried to avoid mentioning vendors.
Conclusion:
If you are working in EUC or have to design an EUC solution, or if you are an aspiring architect, I really recommend this book. This book might not show you what documentation you need to create for an EUC architecture or how to create the documentation, but it shows you how to think about and how to design an EUC solution. It shows you what is important when thinking about EUC.
If you are used to deploying EUC solutions or infrastructure, this book might generate a lot of “I know this already” popups in your head. But be honest to yourself: do you merely recognize the things Brian writes about or do you actively act accordingly to the content of this book all the time?
For me personally, I have to say that Brian nailed it. This book has a very welcome and different angle from the other books I have read about design and architecture and is no less true or of less value.
Kim
(*) As a couple of side notes: About 2 years ago I did have a storage sizing discussion and CPU + RAM discussion at work. After initiating a couple of boot storms during the POC, I was able to prove that the requirements for VDI based on linked-cloning with non-persistent desktops are totally different than a server deployment. About 6 months ago I have had different discussions at work where consultants came in and advised a 19 to 1 vCPU to pCPU ratio for a solution where the requirement is to create a complete desktop and laptop replacement (including: Office 2010, every used application, all internet access, VOIP, Video conferences, etc). I am glad to see that the consolidation ratios I advised back then (way way lower than 19 to 1) match what Brian advises to use.
Leave a Reply