Openstack Cloud Application Development

Openstack Cloud Application Development

English | 2015 | ISBN: 978-1-119-19431-6 | 168 Pages | PDF, EPUB | 13 MB

Leverage the power of OpenStack to develop scalable applications with no vendor lock-in
OpenStack Cloud Application Development is a fast-paced, professional book for OpenStack developers, delivering comprehensive guidance without wasting time on development fundamentals. Written by experts in the OpenStack community from Infoblox, Gigaspaces, GoDaddy, and Comcast, this book shows you how to work effectively and efficiently within the OpenStack platform to develop large, scalable applications without worrying about underlying hardware. Follow along with an OpenStack build that illustrates how and where each technology comes into play, as you learn expert tips and best practices that make your product stronger. Coverage includes OpenStack service primitives, networking within the OpenStack Ecosystem, deployment of Virtualized Network Functions for Enterprises, containers, data protection, and much more.
If you need to get on board quickly, this professional book is your ideal roadmap to OpenStack development.

  • Understand all aspects of OpenStack technologies
  • Follow an example build to drill down into critical elements
  • Learn the OpenStack best practices and insider tips
  • Leverage the full capability of IaaS at a professional pace

OpenStack is supported by dozens of major technology companies, compatible with Amazon Web Services, and can be used alongside or on top of VMWare vSphere and other similar technologies. It frees developers from the confines of hardware and vendor lock-in while providing a reliable, fast, and easy platform for developing scalable cloud applications. OpenStack Cloud Application Development is an expert-led guide to getting the most out of OpenStack, designed specifically for the professional developer.


Cloud Infrastructure Deployment Models

In addition to the functionality provided by a cloud, there are several different deployment models for clouds. Public clouds are the ones familiar to most developers. These cloud services are made available to the general public for a fee. The fee is generally on a usage basis, enabling organizations to utilize their operating budgets rather than their capital budgets. The customers have no need to maintain or operate the hardware or cloud infrastructure, leaving that responsibility completely to the cloud operator.

Amazon Web Services (AWS) is currently the largest public cloud and dominates the industry. Microsoft and VMware also operate public clouds, and a number of service providers do as well. Rackspace, in particular, provides an OpenStack-based public cloud, and is one of the primary contributors to the OpenStack project.

Private clouds, on the other hand, are internal to an organization. They represent the evolution of the traditional corporate data center. Only internal customers within the enterprise, and perhaps close partners, use private clouds. The corporate IT department or a contractor will purchase, setup, and maintain the hardware and software for the cloud. The cloud infrastructure may use chargeback to distribute costs among the business units, but the cloud itself is still dedicated to the single enterprise.

Organizations may operate private clouds for a number of reasons. The cost of a private cloud, if well run, may be less than utilizing the public clouds. Additionally, many industries have security or regulatory reasons that disallow the use of a public cloud for many workloads. These organizations are required to run those workloads in a private cloud. See Figure 1.2 for a look at the structure of public, private, and hybrid clouds.

What Is OpenStack?

OpenStack bills itself as a “cloud operating system.” Fundamentally, it solves the IaaS problem. It provides the ability to abstract the physical compute, storage, and networking resources into pools. Those resources can then be divvied up among users in a secure way. Users only need to pay for what they are using, rather than having to provision their applications for peak load.

OpenStack is a collection of open source software projects, backed by a non-profit organization, the OpenStack Foundation. These projects work together to provide a consistent API layer, while enabling the actual services to be provided by a variety of different vendor or open source implementations. At the core, these services include the functionality you need to run a cloud, that is, the ability to spin up virtual machines, the ability to allocate, manage, and share storage among those machines, and the ability enable these machines to communicate with one another securely over the network.

All of these services are accessible via RESTful APIs, as well as command-line interfaces and a web-based user interface called Horizon. Horizon is convenient for setting up things on an ad-hoc basis, but doesn’t offer the full capabilities of the APIs—and of course the APIs and CLI tools can be easily scripted.

A default installation of OpenStack will include “reference” versions of each service. For example, by default an OpenStack cloud will use the Kernel-based Virtual Machine (KVM) hypervisor to manage virtual machines. One of the most important aspects of the OpenStack architecture, however, is the driver or plugin-based nature of each service. With this design, you can use an implementation other than the reference one. In your cloud, you can swap out KVM with ESXi, Xen, or other hypervisors. The APIs used to launch and manage VMs remain the same, regardless of the underlying hypervisor. This same concept extends across OpenStack services, enabling the same APIs with different service implementations.

This level of flexibility behind the scenes, while providing a consistent API, is one of the keys to the success of OpenStack. Users can build their applications and automation on top of OpenStack, without having to worry that they are locking themselves into a single backend provider of computer, networking, or storage. The APIs won’t change even if they swap out the backend.

OpenStack is frequently used in enterprises for private clouds, though there are some public cloud services that are based on it. There are also companies that will create and operate a private OpenStack cloud for you within their data centers. In this case, the hardware is not shared with other customers, so you have the predictability and security of the private cloud but do not have to find and hire the experts to maintain it.

Even in private cloud environments, OpenStack is a multi-tenant cloud platform. This means that multiple users or groups of users—tenants—can utilize the physical resources of the cloud, while keeping all of their virtualized resources private. For a tenant, the OpenStack environment appears, for the most part, to be theirs and theirs alone. But for the operator, the underlying physical resources and software systems are shared. In OpenStack, tenants are also sometimes referred to as projects.

In a multi-tenant OpenStack cloud, each tenant is allocated a quota for the various types of resources that may be used. The quota provides a maximum limit for that tenant for that particular resource. You will have a quota for CPUs, memory, storage, networks, subnets, and floating IPs, among other resources. This prevents any single tenant from consuming all of the resources.

Why OpenStack?

There are a number of cloud management platform options out there. The most obvious and dominant player is VMware with their vRealize suite of software. So, why should you take your time to learn about OpenStack rather than vRealize, AWS, Azure, CloudStack, or any of the other solutions?

About 15 years ago, IT professionals faced a very similar set of questions about Linux and proprietary UNIX systems. Solaris, HP-UX, AIX and their competitors were solid, well known, and widely deployed products, whereas Linux was a graduate student’s project that was difficult to install and operate and was fairly immature, with driver and other compatibility issues. It was not clear at all at the time that spending effort learning and understanding Linux was worth it. History though, has proven that such a choice would have been the right one. All of those expensive, proprietary UNIX implementations have lost their value proposition—they really don’t have much that is unique to offer anymore. Linux has continued to grow and has taken over most of the environments where those systems once thrived.

This isn’t just a simple analogy. There is a relentless pressure in this industry to reduce costs, and to increase the velocity of feature delivery—deliver more, faster, and cheaper. The way to achieve “more, faster” is standardization. This is the same basic principle as building libraries and frameworks in programming. A standard architecture behaves in a predicable manner, providing core services on which you can rely and build. There is no need to repeat the process of developing that architecture over and over, allowing you to focus on the new functionality.

The way you achieve “cheaper” is to make those standards open and free. This combination of open and standard leads to commoditization—essentially the development of interchangeable components that are the same regardless of the manufacturer or vendor. Commodities imply a lot of competition, and there is little or no product differentiation for which to charge extra. This drives down the costs dramatically.

Linux has both of these characteristics—open and standard—in UNIX-like operating systems, and that is why it won. Not because it was better, but because it was cheaper and faster to use as a base for building new functionality. Linux is just one example, of course. This story has repeated over and over in the technology industry. With machine architectures we have the x86 platform, and standard architectures for memory, disks, and serial bus-based peripherals.

In fact, if you take the broader view, you can see that the commoditization has continuously moved up the value chain. It started with hardware, moved to operating systems, and these days even sophisticated databases and distributed system components are being commoditized. In databases, we used to have Informix, DB2, Oracle, Sybase, and others. But MySQL and PostgresSQL are open and standard, and they have completely dominated the low-end of the database market. Oracle still leads in the high-end, and is able to provide value in those more specialized environments, but as the open source products improve, the space for the proprietary vendors constricts.


OpenStack is built on a loosely coupled architecture. Each component is built independently and runs its own services. These services may be distributed among a number of different machines with different responsibilities. This enables scaling of particular functions, by adding machines with particular roles. It also enables redundancy; a highly available deployment will contain several of each type of machine.

Software Architecture

Individual components interact with one another via well-defined application programming interfaces (APIs)—typically based on representational state transfer (REST) conventions, though in some cases using remote procedure calls (RPC) or notifications over a message bus. Typically, these services will maintain data in a relational database—usually MySQL or PostgreSQL. The message bus and database are shared across services, but the interactions between those services remain clearly delineated. This enables different services to grow and change independently from the others, so long as they provide backward-compatibility in the APIs.

Each of the major services—compute (Nova), networking (Neutron), block storage (Cinder), etc.—have several internal processes and components. Generally, they will each have an API service that provides an HTTP-based RESTful API. This API service will communicate with the other components via the message bus.

The Horizon service is a web-based UI that interacts with the various services. Similarly, there are command-line tools to interact with each service. These tools are optional; you can build your own interface directly to the service APIs if you wish. Horizon and the official CLI clients do not have any special access; everyone uses the same APIs. Each client really only needs to be informed of the location of Keystone, the identity service. This service contains a catalog of all services and API endpoints available in the OpenStack platform.