Author

So you understood OpenStack, its components and how applications play an important role in the cloud. Before revealing to you how to be successful with OpenStack, there is another important piece I want you to understand.

The next marketing buzzword that everybody mentions nowadays is DevOps. As you might understand, DevOps is an acronym that stands for "Development" and "Operations".

The goal of DevOps is to improve service delivery agility, promoting communication, collaboration and integration between software developers and IT operations. Rather than seeing these two groups as silos who pass things along but do not really work together, DevOps recognizes the interdependence of software development and IT operations.

In an ideal world, through the use of continuous integration tools and automated tests, a group of developers could bring a new application on-line without any operations team. For example, Flickr developed a DevOps approach to support a business requirement of ten deployments per day. Just for your own information, this kind of approach is also referred as continuous deployment or continuous delivery.

Discussing development and agile methodologies is not within the scope of this publication, but this is one thing you have to understand and keep in mind, no matter if you are an IT manager, developer or system administrator.

If you decided to embrace the cloud in full and you are thinking of adapting your application to take advantage of it, then every single aspect of IT have to be carefully analyzed. Development, whether you do it internally or outsourced, must be taken into consideration. Also the way your company has been organized has to change: did I mention before Cloud is a huge shift?

So you have read about OpenStack and you are really eager to implement it. But let us step back and understand why you are willing to embrace the cloud. You might think of several reasons, but -- judging by my experience -- everything comes down to two root causes:

• You are looking to take advantage of the fast provisioning of the infrastructure, either for savings, speed, or both
• Your applications may have varying demand patterns, resulting in the need of increased computing power during some periods.You may want to take advantage of the scaling capabilities of Cloud to fire up new instances of key modules at peak periods, shutting them down when not needed, freeing up infrastructure resources for other tasks and reducing the TCO

Most of the customers just want a fast provisioning mechanism of the infrastructure. Do not get me wrong, this is perfectly fine and OpenStack gets the job done.

But you will get the full benefit of the cloud when you'll have an application that might be in need of resources on-demand. Think about a sports news portal when the World Cup is on, the invoicing and billing at the end of the month or a surge in the need to process a data from devices.

Would it not be nice, given the detected increasing loads, to have the application scale automatically to cope with the requests? Believe it or not, it is not magic and it is totally feasible. Netflix did it and I can name a lot of other SaaS systems that are doing it. There is only one constraint: you have to be in control of the source code of your applications. If you bought your application “as is”, contact your vendor, but there are few chances that you can follow this pattern.

In case you have the source code, you can adapt your application to take full advantage of your new environment. In this scenario, you will have to intervene more into your code as you will need to ensure that the application can take full advantage of the environment, reconfiguring load balancers, dynamically allocating resources and etc. There are some “tricks” that an application has to adopt to be “cloudish”, but is outside of the scope of this publication.

It’s quite common that a customer might decide to have a phased approach to the cloud, starting to take advantage of the fast provisioning and then transforming the application to adapt it to the cloud. The cloud is a long journey and it can be successful, are you ready for it?

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.

Swift – Object Storage

Object store allows you to store or retrieve files. It provides a fully distributed, API-accessible storage platform that can be directly integrated into applications or used for backup, archiving and data retention.

Note: Object Storage is not a traditional file system, but rather a distributed storage system for static data such as virtual machine images, or photos, e-mails, backups and archives.

• Proxy server (swift-proxy-server) accepts incoming requests, like files to upload, modifications to metadata or container creation; it also serves files and provides container listing
• Accounts server manage accounts defined within the object storage service.
• Container servers manage mapping of containers, folders, within the object store service.
• Object servers manage actual objects, files, on the storage nodes.

Also replication services run to provide consistency and availability across the cluster, audit and update.

Ceilometer - Telemetry

The required steps to bill for usage in a cloud environment are metering, rating and billing. Because the provider's requirements may be far too specific for a shared solution, rating and billing solutions cannot be designed as a common module that satisfies all possible scenarios. Providing users with measurements on cloud services is required to meet the "measured service" definition of cloud computing.

The Telemetry module was originally designed to support billing systems for OpenStack cloud resources. This project only covers the metering portion of the required processing for billing. The module collects information about the system and stores it in the form of samples in order to provide data about anything that can be billed.

The list of metrics is continuously growing, which makes it possible to use the data collected by Telemetry for many more purposes other than billing. For example Heat can autoscale resources when Ceilometers triggers an alarm, for example adding more front-end web servers when CPU utilization is more than 70% for 5 minutes.

Other projects

Although the former ones are the most relevant, there are three other projects worth mentioning:

• Trove is a database-as-a-service provisioning relational and non-relational database engines. It allows an agnostic access to databases, currently supports MySQL and PostgreSQL, but vendors like Oracle and Microsoft might provide a Trove plugin for their databases in future.
• Ironic (Bare Metal Provisioning), is an incubated OpenStack project that aims to provision bare metal machines instead of virtual machines. Ironic is currently in use by HP Helion.
• Zaqar (Multiple Tenant Cloud Messaging), is a multi-tenant cloud messaging service for Web developers. Zaqar was formerly known as Marconi.
• Designate provides a DNS as a Service for OpenStack.