OpenStack是一种开源产品，得到了一大批志愿者和领薪代码贡献者的支持，它让人们意识到了一种全面审查的架构和一种深思熟虑的设计具有的重要性，这种架构和设计似乎贯穿着OpenStack峰会的主题。无论这种意识是切实存在的还是只是个人感觉，出席亚马逊re:Invent或谷歌I/O等大会的人士对于旗舰产品展现出来的关注度和责任感似乎不如他们在出席2015年5月OpenStack大会时展现出来的关注度和责任感。
伴随众多OpenStack峰会与会人士的这种个人投入而来的是，他们更加深入地了解每天做出的架构和设计方面的逐步决策具有的重要性，那是由于这些决策可能会对未来的版本发布带来影响。正因为如此，在评估每一个变动、更新、补丁和贡献时，既要顾及OpenStack使命声明，又要顾及OpenStack的基本设计准则。使命声明既简单又野心勃勃：力求开发出无所不在的OpenStack云计算平台，有望满足公有云和私有云(无论规模大小)的要求，为此要做到易于部署、能够大规模扩展。说到编写和部署代码，下面所列的几条设计准则来得更重要一点。这样一来，了解这些准则如何适用于OpenStack软件的发展道路显得至关重要。
可扩展性和弹性。第一条设计准则明确规定，“可扩展性和弹性是我们的主要目标;”第二条准则表明，限制主目标的任何组件都应该是可选的。这打造了一个令人关注的生态系统，其中有数百个大有帮助、不过随意性的插件。Dark Secret Software公司的首席执行官Sandy Walsh是名经验丰富的OpenStack软件开发人员，他说：“如果你看一下OpenStack代码，就会发现有许多可选的组件。一切基本上就是插件。”
异步性。等待响应、阻止入站传输会要了大规模企业系统的命。因而，OpenStack软件开发的第三条准则就是“一切都应该是异步的。”当然了，这也有其不足之处。大量耗用内存的应用程序会从异步操作中受益匪浅，而大量耗用处理器的应用程序将会饱受其苦。但是单一机器上的孤立性能并不是OpenStack的目标，大规模横向扩展性才是其目标。正因为如此，异步性是一个优先事项。Walsh说：“可扩展性和弹性是两个主要目标。这种系统一定要能够扩展。”
横向扩展。第四条设计准则认为，“所有代码应该能够横向扩展。”纵向扩展是个优点，但是编写随着越来越多的内存和处理器安装到机器上，可以相应扩展的代码并不需要大量的规划。另一方面，开发一个能够横向扩展的系统可能是个挑战，尤其是随着参与节点的数量增至三倍或四倍，更是困难重重。所有设计决策务必要牢记横向扩展这一条准则。
状态管理。企业Java应用程序遇到的最常见的性能问题之一就是，随意使用基于状态的变量，导致企业系统运行速度减慢，几乎不可能实现线性扩展。外设JVM语言已证明了使用不可变数据在可扩展性方面具有的好处，所以发现第四条准则是“使用无共享(SN)架构或分片(sharding)”也就不足为奇了。
一切都必须分布式。下一条准则就是“一切都要分布式”，尤其是“逻辑”。Hadoop等大数据成功故事一再证明了这个理念;如果能确保数据和逻辑能协同运行，而不需要网络调用，就能大大改善性能和可扩展性。
测试、测试、测试。最后，最终一条准则坚决主张开发人员必须“测试一切”，这不足为奇。要是没有经过一系列全面的测试，任何东西都不得进入代码库;未经测试就贸然提交的代码、补丁或特性改进根本得不到接受和认可。这与其说是一条准则，还不如说是标准的尽职调查，而这也是确保没有遗漏的好方法。
想法简单，执行复杂。如果这些简单的设计准则运用于异常复杂的问题，开发的OpenStack软件就会变得极其令人关注。一个典例就是OpenStack的分布式对象存储系统Swift的工作方式。SwiftStack的技术主管John Dickinson说：“借助Swift，你将存储的数据与用来存储数据的实际介质分离开来。相比较过去的数据存储策略，这正是让Swift成为全新策略的特性。”有了这种方法，开发方面的人员只需要操心将数据传送给Swift，将Swift当成它似乎就是一种公用资源。从操作的角度来看，这里要担心的唯一问题是，服务器和驱动器集群是否处于良好的工作状态。这种高度可扩展的方法日臻完善，运用OpenStack设计准则来处理这个难题：在基于云的系统中管理分布式数据。
虽然这些准则对OpenStack及其周边项目和插件的日常发展起到了关键作用，但有些经验或心得却是所有软件开发人员都可以借鉴的。测试、开发无状态应用程序、让可扩展性成为优先事项，以及考虑程序逐渐変得庞大后其性能将会如何，这些都是每一个软件开发人员都应该运用到本企业组织和软件项目的最佳实践。
