IT Architect and highly skilled in IT Security, he has a broad background in the Open Source world. He has worked as a consultant for companies such as Red Hat, Canonical, Sun and IBM, in addition to being Managing Director of the Swiss multinational GARL. He also deals with technologies about CloudStack and OpenStack, for which he has written a reference manual.
Earlier in this publication I mentioned that the promise of OpenStack is the interoperability among different components from different vendors or open source projects. As a matter of fact, each of the components described in the previous page can be easily replaced with projects or products from each vendor.
At the time of writing, the only project that has no valuable alternative among vendors is Keystone. Keystone acts as a service registry and user repository, therefore plays an important role in OpenStack. While it was conceived to have internal users like Amazon does, the development is shifting towards an HTTP interface to existing identity systems, such as LDAP or SAML.
Also Horizon, the web dashboard, has few chances to be replaced, as its colors and logos can easily be customized to be adapted for everyone. Some other dashboards exist for OpenStack, but usually the company who needs a different web interface goes for a customized development on top of the OpenStack APIs.
Projects in which it makes sense to adopt a plugin approach are Nova, Neutron, Swift and Cinder. Let us review in a table what are the most relevant open source and proprietary technology for each component (please keep in mind that this list can vary).
|Ceph||IBM (Storwize family/SVC, XIV)|
|NFS (any compatible)||SolidFire|
|Dell EqualLogic/Storage Center|
|Linux Bridge||VMWare NSX|
|OpenContrail (Juniper OpenSource)||Alcatel Nuage|
|Swift project||EMC Isilon OneFS|
|Hadoop with SwiftFS/Sahara|
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:
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.
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.
Although the former ones are the most relevant, there are three other projects worth mentioning:
GURU advisor will be at the Mobile World Congress in Barcelona from February 22nd to 25th 2016!
MWC is one of the biggest conventions about the worldwide mobile market, we'll be present for the whole event and we'll keep you posted with news and previews from the congress.Read More