A customer recently asked me what , in my opinion, was the best recipe for a successful OpenStack installation? With 20 years experience of data centre deployments (hardware and software) I can honestly say that  my answer has hardly changed over time. It’s still the basics that get over looked.

I’ve spent the past two years deploying Helion OpenStack around the world in Banks, Pharmaceuticals and Retailers and the following post highlights what I believe to be the ingredients for a successful OpenStack deployment (or any other cloud platform for that matter).

Stakeholders – Executive Sponsorship

It’s vital when deploying a cloud solution which will traverse many departments (a.k.a. silos) like networking, storage, security etc., that the project has an Active/Engaged sponsor that sits at the top of all of these silos. Ideally the CIO, COO and head of HR would be involved to develop a clear strategy to review how this new technology will impact their current processes and staff. In order to truly leverage the benefits afforded to a business by the transition to a cloud model these processes will need to change dramatically within an enterprise.

Unfortunately, what tends to happen is that only one of the silos buys the solution and thinks that they should own it all. They will fail! Technology is the easy part – people and process is what matters.

What should happen, and again this is only my personal opinion, is the creation of virtual teams from across the silos. Train these folks up on the entire solution keeping them focused on their SME (subject matter expertise) area. It should not take long for them to see the benefits of working together and hopefully realise the potential of OpenStack at the same time. It’s also a good stepping stone in the direction of a continuous integration and continuous deployment (dare I say DevOps) operations model. Although initially we’re covering the silos within the operations teams it’s a very similar process to bring the developers on-board. These folks tend to be very enthusiastic about the cloud model of operation as they have been spoilt by AWS for the last 5 years…shadow IT, that’s another story!

Open Source Confusion – Realistic Scope

Believe it or not, on more than one occasion in the past couple of years during OpenStack installations I’ve had customers looking for their “Ceph” storage or their “Docker” containers unaware that these are not a part of native OpenStack but entirely different products in their own right. It’s very important to hold a cloud workshop with customers early in the engagement cycle [that should be before the sales team has landed any hardware on site] and review their fundamental requirements – again as mentioned earlier – it’s back to basics. Don’t just probe the IaaS requirements, seek the ultimate business requirements. There will be times when OpenStack can’t meet a customers requirements, or features are still experimental – ensure that the customer understands this. Explain how the OpenStack community operates, releases every 6 months, blueprint submission process and so on. This workshop is also your chance to determine which stakeholders are missing and seek their involvement.

Rock, Paper, Scissors, VMware

If the customer is hell bent on getting rid of VMware and thinking that OpenStack is the solution tread very carefully. VMware makes a very good and powerful hyper-visor with many more high availability features than are available with the default KVM hyper-visor. There’s no reason today why you can’t have both types of hyper-visor within an OpenStack cloud – I’ve tried this feature with Helion OpenStack 3.0 and it works very well.

Listen very carefully to the customer’s expectations – if they are mentioning things like cost saving or pure lift and shift of applications – run away now. However, if they are talking about cloud native applications and transformation programs to address their legacy applications then yes – this is the correct mindset.

OpenStack Skills Shortage

Trying to find experienced OpenStack engineers is like…..

Though this skills shortage may be short lived, (with the current rate of adoption of OpenStack clouds) it is a real concern for many customers. However, there are two very easy ways to address this challenge:

Option 1

Stop limiting yourself to looking for people with OpenStack skills – a good linux administrator will pick up OpenStack with minimal training. If they know their way around linux (including network namespaces), have a basic understanding of databases and message queues then OpenStack will be a breeze. [ Note to recruitment companies: Same statement could be used for the “unicornesque” (technical term) DevOps engineer]. Don’t expect an OpenStack operator to be a developer – they shouldn’t have to be!

Option 2

Three words – Managed Private Cloud. Lots of companies offer this service including HPE. If you are going cloud native and PaaS is what you really need why not just outsource your private cloud now?

Lead with PaaS – OpenStack will follow

When buying a car we don’t buy the engine first, followed by the chassis, interior and so on, until we finally have enough components to facilitate driving  from A to B – the primary directive for buying the car.

So it confuses me today why we seem obsessed with buying an IaaS solution first and then trying to fit a PaaS solution on top of it. I believe that customers should start with their PaaS requirements. This is usually where the developers, the true business requirements and the money tends to sit.

Not only that but customers can test drive (boom, boom) most PaaS platforms today without ever having to buy a single piece of hardware. Once the business and the developers know what they need from a PaaS solution it’s much easier to ensure the underlying IaaS is fit-for-purpose.

Conclusion

To be successful in an OpenStack engagement is no different than any other IT project. Once you can tick off the following checklist everything else should be business as usual –

• People
• Process
• Technology

Like I said – nothing new here – the same ingredients were required 20, 30 and 40 years ago.

It’s also fundamental that everyone understands the difference between Cloud Native and Tradition styles of application. [A tell-tale sign that someone does not understand these principles is when they try to compare VMware to OpenStack.]

Finally, I found the following three books very helpful in illustrating some of the basic concepts around virtual teams, cloud native and devops:

• The Phoenix Project
• Continuous Delivery
• The Mythical Man-Month

 

 

Thank you, Happy Stacking!