A new book aims to help anyone who has a private cloud on the drawing board make it a reality.
Michael Solberg and Ben Silverman wrote “OpenStack for Architects,” a guide to walk you through the major decision points to make effective blueprints for an OpenStack private cloud. Solberg, chief architect at Red Hat, and Silverman principal cloud architect for OnX Enterprise Solutions, penned the 214-page book available in multiple formats from Packt Publishing. (It will also be available on Amazon in March.)
Superuser talked to Solberg and Silverman about the biggest changes in private clouds, what’s next and where you can find them at upcoming community events.
Who will this book help most?
MS: We wrote the book for the folks who will be planning and leading the implementation of OpenStack clouds – the cloud architects. It answers a lot of the big picture questions that people have when they start designing these deployments – things like “How is this different than traditional virtualization?”, “How do I choose hardware or third-party software plugins?” and “How do I integrate the cloud into my existing infrastructure?” It covers some of the nuts and bolts as well – there are plenty of code examples for unit tests and integration patterns – but it’s really focused at the planning stages of cloud deployment.
What are some of the most common mistakes people make as beginners?
BS: I think that the biggest mistake people make is being overwhelmed by all of the available functionality in OpenStack and not starting with something simple. I’m pretty sure it’s human nature to want to pick all the bells and whistles when they are offered, but in the case of OpenStack it can be frustrating and overwhelming. Once beginners decide what they want their cloud to look like, they tend to get confused by all of the architectural options. While there’s an expectation that users should have a certain architectural familiarity with cloud concepts when working with OpenStack, learning how all of the interoperability works is still a gap for beginners. We’re hoping to bridge that gap with our new book.
What are some of the most interesting use cases now?
MS: The NFV and private cloud use cases are pretty well defined at this point. We’ve had a couple of really neat projects lately in the genomics space where we’re looking at how to best bring compute to large pools of data – I think those are really interesting. It’s also possible that I just think genomics is interesting, though.
How have you seen OpenStack architecture change since you’ve been involved?
MS: We talk about this a bit in the book. The biggest changes happening right now are really around containers. Both the impact of containers in the tenant space and on the control plane. The changes in architecture are so large that we’ll probably have to write a second edition as they get solidified over the next year or two.
Are there any new cases you’re working with (and still building) that you can talk about?
BS: The idea of doing mobile-edge computing using OpenStack as the orchestrator for infrastructure at the mobile edge is really hot right now. It is being led by the new ETSI Mobile-Edge Computing Industry Specification Group and has the backing of about 80 companies.
Not only would this type of OpenStack deployment have to support NFV workloads over the new mobile 5G networks, but support specialized workloads that have to perform at high bandwidth and low latency geographically close to customers. We could even see open compute work into this use case as service providers try and get the most out of edge locations. It has been very cool over the last few years to have seen traditional service providers taking NFV back to the regional or national data center, but it’s even cooler to see that they are now using OpenStack to put infrastructure back at the edge to extend infrastructure back out to customers.
Ben, curious about your tweet – “You must overcome the mindset that digital transformation is a tech thing, rather than an enterprise-wide commitment”…Why do people fall into this mentality? What’s the best cure for it?
BS: The common misconception for a lot of enterprises is that technology transformation simply takes a transformation of the technology. Unfortunately, that’s not the case when it comes to cloud technologies. Moving from legacy bare metal or virtualization platforms to a true cloud architecture won’t provide much benefit unless business processes and developer culture changes to take advantage of it.
The old adage “build it and they’ll come” doesn’t apply to OpenStack clouds. Getting executive sponsorship and building a grassroots effort in the internal developer community goes a long way towards positive cultural change. I always advise my clients to get small wins for cloud and agile development first and use those groups as cheerleaders for their new OpenStack cloud.
I tell them, “bring others in slowly and collect small wins. If you don’t go slow and get gradual adoption you’ll end up with accelerated rejection and even with executive sponsorship, you could find yourself with a great platform and no tenants.” I have seen this happen again and again simply because of uncontrolled adoption and the wrong workloads or the wrong team was piloted into OpenStack and had bad experiences.
Why is a book helpful now — there’s IRC, mailing lists, documentation, video tutorials etc.?
MS: That was actually one of the biggest questions we had when we sat down to write the book! We’ve tried to create content which answers the kinds of questions that aren’t easily answered through these kinds of short-form documentation. Most of the topics in the book are questions that other architects have asked us and wanted to have a verbal discussion around – either as a part of our day jobs or in the meetups.
BS: There are a lot of ways people can get OpenStack information today. Unfortunately I’ve found that a lot of it is poorly organized, outdated or simply, incomplete. I find Google helpful for information about OpenStack topics, but, if you type “OpenStack architecture” you end up with all sorts of results. Some of the top results are the official OpenStack documentation pages which, thanks to the openstack-manuals teams are getting a major facelift (go team docs!). However, right below the official documentation are outdated articles and videos that are in the Cactus and Diablo timeframes. Not useful at all.
What’s on your OpenStack bookshelf?
MS: Dan Radez’s book was one of the first physical books I had bought in a long time. I read it before I started this book to make sure we didn’t cover content he had already covered there. I just finished “Common OpenStack Deployments” as well – I think that’s a great guide to creating a Puppet composition module, which is something we touch briefly on in our book.
BS: Looking at my bookshelf now I can see Shrivastwa and Sarat’s “Learning OpenStack” (full disclosure, I was the technical reviewer), James Denton’s second edition “Learning OpenStack Neutron” and an old copy of Doug Shelley and Amrith Kumar’s “OpenStack Trove.” Like Michael, I’ve got “Common OpenStack Deployments” on order and I’m looking forward to reading it.
And what is the “missing manual” you’d like to see?
BS: I would love to see “Beginner’s Guide to OpenStack Development and the OpenStack Python SDK(s)” I know enough Python to be dangerous and fix some low-hanging bugs, but a book that really dug into the Python libraries with examples and exercises would be pretty cool. It could even contain a getting started guide to help developers get familiar with the OpenStack development tools and procedures.
Are either of you attending the PTG and/or Boston Summit?
BS: I’ll be at the PTG, as a member of the openstack-manuals team, I’m looking forward to having some really productive sessions with our new project team lead (PTL) Alexandra Settle. We’ve already started discussing some of our goals for Pike, so we’re in good shape.
I’ll also be at the Summit in Boston, I’ve submitted a talk entitled “Taking Capacity Planning to Flavor Town – Planning your flavors for maximum efficiency.” My talk centers around the elimination of dead space in compute, storage and networking resources by deterministic flavor planning. Too many enterprises have weird-sized flavors all residing on the same infrastructure which leads to strange-sized orphan resources that are never consumed. On a small scale the impact is minimal but companies with thousands and tens of thousands of cores can recover hundreds of thousands of dollars in wasted CAPEX simply by planning properly.
MS: I’ll be at the Boston Summit – more for catching up with my colleagues in the industry than anything else. You can find me at the Atlanta OpenStack Meetup most months as well.
The authors are also keeping a blog about the book where you can find updates on signings and giveaways.
Cover photo by: Brian Rinker