Book Review: Cloud Computing Design Patterns 33
| Cloud Computing Design Patterns | |
| author | Thomas Erl, Robert Cope, Amin Naserpour |
| pages | 592 |
| publisher | Prentice Hall |
| rating | 9/10 |
| reviewer | Ben Rothke |
| ISBN | 0133858561 |
| summary | Provides well-explained vendor-agnostic patterns to the challenges of providing or using cloud solutions from PaaS to SaaS. |
The authors build on the notion that for anyone who wants to architect a large cloud solution, they need to have a broad understanding of the many factors involved with the real-world usage of cloud services. Because cloud services are so easy to deploy, they are often incorrectly misconfigured during roll-out and deployment. The authors write that its crucial have a strong background in cloud services before doing any sort of a rollout. Because it's often so easy to deploy cloud services, this results in far too many failed cloud projects. And when the project is poorly implemented, it can actually cause the business to be in a far worse point from where it was before the cloud rollout.
The authors deserve credit for writing a completely vendor agnostic reference, even though there are many times you would appreciate it if they could suggest a vendor for a specific solution. Some of the more interesting patterns detailed in the book are:
- Hypervisor clustering – how can a virtual server survive the failure of its hosting hypervisor or physical server?
- Stateless hypervisor – how can a hypervisor be deployed with a minimal amount of downtime, while allowing for quick updating and upgrading?
- Trusted platform BIOS – how can the BIOS on a cloud-based environment be protected from malicious code?
- Trusted cloud resource pools – how can cloud-based resource pools be secured and become trusted?
- Detecting and mitigating user-installed VMs – how can user installed VMs from non-authorized templates be detected and secured?
The book is replete with these scenarios, and each scenario includes downloadable figures that effectively illustrate the mechanisms used to solve the problem.
Chapter 3 provides a number of first-rate architectural ideas on how to design a highly resilient cloud solution. Much of the promise of the cloud is built on scalability, elasticity and overall optimization. These chapters show how to take those possibilities from conceptual to a working implementation.
Cloud failures are inevitable and chapter 4 details how to build failover, redundancy and recovery of IT resources for the cloud environment.
Chapter 9 is particularly important, as far too many designers think that since the underlying cloud abstraction layer is highly secure, everything they build on top of that will have the same level of security. The book details a number of design patterns that are crucial to ensuring the cloud design is securing that data at rest and is resistant against specific cloud attacks.
With a list price of $49.99, the book is a bargain considering the amount of useful information it provides. For anyone involved with cloud computing design and architecture, Cloud Computing Design Patterns, is an absolute must read.
Reviewed by Ben Rothke.
You can purchase Cloud Computing Design Patterns from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page. If you'd like to see what books we have available from our review library please let us know.
Zoology for programmers (Score:4, Insightful)
Re: (Score:3)
The point is to take a bunch of individuals' knowledge and experience and combine them into something greater and consumable by the inexperienced. There's much lost in the translation, and the dangers of cargo-culting is well-known, but that's the purpose of digging into patterns.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
I like your zoology analogy. I would like to add that naming things is useful and important.
Years ago, I presented a 5-10 page design for a software component to my manager and the company architect. I had a nice document with diagrams and all that. After about 10 minutes in the meeting of presenting some stuff, the architect patiently said something like "So you plan on using a builder pattern, using chain of responsibility to dispatch the events. Sounds good, go for it!" He called for the meeting to
No filler? (Score:3, Insightful)
"filler at the end with numerous appendices of publicly available information"
"how can a virtual server survive the failure of its hosting hypervisor or physical server?..."
So they moved the filler to the start of the book? Everything about this book seems to be filler since there is no such thing as a 'cloud'. Shared hosting and virtual servers have been around forever, everything about it has been worked out.
Pure marketing jargon (Score:2)
The "cloud" is as much of a new thing as "web 2.0" was.
It's just a new name for something old.
In this case, it just means "someone else's computer".
Re: (Score:2)
I disagree.
Firstly, there's a difference between "public cloud" and "private cloud," where 'public' implies "someone else's computer," but given this, and given that you can do private clouds, clearly the ownership of the hardware is not the defining characteristic for "cloud."
Rather, I'd argue the definition for "cloud" has to include -- perhaps more importantly than any other part of the definition -- the ability to request a resource from the system via an API and get it automatically (barring resource c
Filler appendices and introduction to the problem? (Score:2)
Filler appendices and introduction to the problem? What about over 30 pages of autopromo?
Testimonials. Reviews. Forewords By Famous People I'd Never Heard About. Award nominations. Blurbs. Thanks to Famous People for Help.
If I see the book needs so much space to convince the reader it's any good, it means the actual content definitely isn't good enough to sell the book.
...which is why I quit buying books since... (Score:2)
>> These books end up being well over 800 pages without a lot of original information...filler at the end with...publicly available information. ...which is why I quit buying technical books since I got that second monitor.
Oh oh, there be dragons ahead (Score:1)
The last "Design Pattern" movement, per "GOF" and OOP, was overall a disaster. People started shoe-horning their code into these patterns without rhyme or reason.
A good book on code and system design collects a thorough list of points to discuss, typically the pro's and con's of each design choice. But, ultimately lets the reader plug in their organization's own goals and priorities to select the best choice.
In other words, "here's a list of things to consider and questions to ask."
Any design methodology t
Artificial Intelligence (Score:1)
"Far too many technology books take a Hamburger Helper approach, where the first quarter or so of the book is about an introduction to the topic, and filler at the end with numerous appendices of publicly available information. These books end up being well over 800 pages without a lot of original information, even though they are written an advanced audience. In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn't a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Using that approach for the cloud, in Cloud Computing Design Patterns, authors Thomas Erl, Robert Cope and Amin Naserpour have written a superb book that has no filler and fully stocked with excellent and invaluable content."
5 to 1 that was generated by a bot. Any takers?