Guiding design tenets behind OpenStack software

Vancouver -- As an open source product supported by an army of volunteers and salaried contributors, OpenStack evokes an awareness of the importance of a thoroughly vetted architecture and well thought out design that seems to permeate an OpenStack summit. Whether that awareness is real or simply perceived, attendees at conferences like Amazon re:Invent or Google I/O don't project the same level of personal commitment and responsibility to the flagship product as they have here at the May 2015 OpenStack conference.

With this personal investment so many at the summit have to OpenStack comes a greater understanding of the importance of incremental architecture and design decisions made today, given the potential impact these decisions may have on future releases. As such, every change, update, patch and contribution is evaluated with respect to both the OpenStack mission statement and OpenStack's basic design tenets. The mission statement is simultaneously simple and ambitious: To produce the ubiquitous OpenSource cloud computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable. The design tenets listed below become a bit more significant when it comes to writing and deploying code, which makes understanding how they apply to OpenStack software's evolution so important.

Scalability and elasticity. The first design tenet specifies that "scalability and elasticity are our main goals;" the second says anything that limits the main goal should be optional. This creates an interesting ecosystem where hundreds of helpful, yet discretionary plugins exist. "If you look at the OpenStack code, there are a lot of optional components. Everything is basically a plugin," said Sandy Walsh, CEO of Dark Secret Software and a well-seasoned OpenStack software developer.

Asynchronicity. Waiting for responses and blocking incoming transmissions will kill an enterprise system at scale. As a result, the third tenet of OpenStack software development is that "everything should be asynchronous." Of course, there are tradeoffs. Memory-intensive applications will benefit greatly from asynchronous operations, while CPU-intensive ones will suffer. But isolated performance on a single machine is not the OpenStack target as much as massive, horizontal scalability is. As such, asynchronicity is a priority. "Scalability and elasticity are the main goals. This thing has got to scale," Walsh said.

Scalability and elasticity are the main goals. This thing has got to scale.

Sandy Walsh, CEO, Dark Secret Software

Scaling across the horizon, The fourth design tenet holds that "all code should be able to scale horizontally." Vertical scaling is a virtue, but writing code that scales as more and more memory and processors are installed on a machine doesn't take a great deal of planning. On the other hand, creating a system that can scale horizontally can be a challenge, especially as the number of participating nodes hits triple or quadruple digits. All design decisions must keep horizontal scaling in mind.

State management. One of the most common performance problems enterprise Java applications run into is the liberal use of state-based variables, slowing enterprise systems down and making linear scalability almost impossible. Peripheral JVM languages have proven the scalability benefits of using immutable data, so it's no surprise to discover that the fourth tenet is to "use a shared nothing (SN) architecture, or sharding."

Everything must be distributed. The next tenet is to "distribute everything," especially logic. This philosophy has been proven time and time again by big data success stories such as Hadoop; ensuring that data and logic can work together without the need for network calls, which can greatly improve performance and scalability.

Test, test, test. And finally, it's no surprise that the last tenet makes the assertion that developers must "test everything." Nothing makes it into the code base without having an exhaustive series of tests; code, patches or feature enhancements submitted without tests simply won't be accepted. It's less of a tenet than it is standard due diligence, but it is a nice way to polish the list off.

Simple ideas -- complex execution. When these simple design tenets are applied to incredibly complex problems, the OpenStack software created becomes incredibly interesting. A prime example is the way Swift, OpenStack's distributed object storage system, works. "With Swift, you separate the data you are storing from the actual media you are storing it on," said John Dickinson, director of technology at SwiftStack. "It's the thing that makes it fundamentally new," when compared to past data storage strategies. With this approach, the development side needs to worry only about passing the data to Swift, treating Swift as though it were simply a utility. From an operational standpoint, the only concern here is that the cluster of servers and drives are in good working order. It's a highly scalable and extensible approach that has evolved over time by applying OpenStack design tenets to the difficult problem of managing distributed data in a cloud-based system.

Although these tenets are central to the ongoing growth of OpenStack and its peripheral projects and plugins, there are takeaways all software developers can use. Testing, building stateless applications, making scalability a priority and thinking about how a program will perform when it grows over time are all best practices every software developer should bring to his own organization and software projects.