I promised you at the beginning that I would have revealed the “secret ingredient” to deploy a successful OpenStack project. Let me begin with two examples.
The first one belongs to a well-known European telecommunication provider. Like every other telco, they have a complex internal structure and when someone from the internal team proposed OpenStack as a possible solution, the upper management decided that it was not “enterprise enough” and that they had to stick to a certified stack that included, amongst others, VMware and Oracle.
The time needed to deploy a single virtual machine was around 40 days, because of all the process it had go through. A system engineer was receiving daily complaints from the developers, who in turn were under pressure from the marketing team to deploy new campaigns faster to the market.
This person decided to form an “unofficial team” of very skilled people, stole some decommissioned old machines and created an OpenStack cluster in two regions. He made some internal meetups to educate the developers and the internal people on how to embrace the OpenStack philosophy and how an application can leverage the underlying platform to take advantage of elasticity and scalability.
The unofficial experiment had an unexpected success and most of the new applications were deployed on this platform. Although this bypassed all the internal rules and processes, the upper management could only take note of the status-quo and approve it officially.
The system administrator is now the leader of this “SWAT group”, that is composed of only 11 people and runs now 50% of the company internal applications.
The second story I want to share with you is about an American financial institute. Following a conversation with the CEO of a premier vendor, the CTO of this bank decided to embrace OpenStack and switch over from VMWare. He asked his management to go and execute the change. The office in charge of the IT architectures had to review all the processes in place and start talking with the departments of the company. Like many big companies, this enterprise is divided in several departments (network, security, system administrators, middleware, …) and in the following months a large number of meetings went through all the departments. OpenStack was deployed in 8 months using the existing corporate policies and following the standards and best practices that were in place. Despite all the efforts, the processes of delivering a new application to internal customer went from 90 days to 75 days. As OpenStack itself was perfectly working, the upper management did not understand what went wrong and could not justify the investment to the CTO.
What is the moral of the story then? The reality is that OpenStack is just a technology and it enables you to do more if you embrace its philosophy. This requires a company to change deeply in the way IT is conceived, and to become even more productive and agile.
If you are not willing to change your internal processes and department divisions, you will not enjoy the full benefits of OpenStack. Meanwhile, if you look at the other example, the telco was so successful because nobody believed on the project at the beginning, therefore the system administrators were free to bypass all the internal schemas.
This approach, with a proper internal awareness program, made the project a great success.
Of course it is not all black and white, there are several shades of gray in between and not each company was created equal.
I hope I gave you the tools to have a clean and vendor-neutral idea of what cloud is and what benefits it can bring you, but you will have to find your own recipe to be successful in deploying OpenStack.
