起源

自 OpenStack 社区成立以来，Horizon 一直是 OpenStack 默认的用户界面（UserInterface）。Horizon 作为 OpenStack 最为重要的项目之一，承担了普通用户、管理员等等不同角色的使用者的操作入口。

但是 OpenStack 是一个纯技术社区，Horizon 也在出生伊始就秉承了技术社区所自带的属性，无论从交互到使用方面都带有浓浓的技术风格，因此，如果想要通过 Horizon 进行操作，完全没有问题，游刃有余；但一旦放到实际的生产环境中，它的弱点便立刻显现出来。

• 信息展示不友好，由于 OpenStack 自身 API 的局限性、Horizon 自身的设计问题等等，导致其在展示信息时仅仅只是机械地将所属信息展示，毫无关联性。
• 定制能力差，虽然 Horizon 项目本身的架构提供了扩展模式，可以很方便地添加各个不同的服务操作界面，但想要将其产品话过程中本土化时，亦或在提供其它扩展功能时，就显得有些力不从心了。
• 无法高效集成刚需功能，例如计费等等功能，就没有办法集成中每一个服务界面中。
• 性能速度太慢，每次刷新页面或更新操作都需要等待半天，影响效率
• 设计和交互落后，每次使用就像在拨弄一个初级制造品，而不是一个成熟的工艺产品。
• 不提供自服务功能，如工单、审批等等。
• 无法提供差异化解决方案，由于 Horizon 本身时一个社区项目，因此所有公司或者和个人都可以使用，但也是因为这个原因导致其无法提供任何差异化的服务与功能。
• 其它。

正是由于种种原因导致我们在实际使用过程中，它更像一个原型产品（prototype product），只能用于某些功能或者服务的功能性验证，而不能作为一个最终的产品交付给客户。

在 UOS 产品体系中，包括了部署工具、管理平台（User Interface）、运维监控工具等。因此，我们期望给客户提供更加丰富齐全、功能更为强大的管理平台，因此 UOS Halo 孕育而生。它的出现可以解决客户以下几个痛点：

• 满足不同客户多样化的需求，在实际生产中，由于客户使用环境和需求的多样性，对管理平台也提出了更高的要求，需要不断地升级已满足客户日新月异地需求。
• 虽然 Halo 可以被视作管理平台，但也同样可以看作是一种全新的开发平台，通过培训，用户可以在平台之上开发自己的功能。
• 经过五年的行业积累，UnitedStack 对私有云更为熟悉和了解，因此产品更适合客户的需求，在我们的产品中，已经包含了过去几年，不同行业不同背景客户的需求和痛点，并在产品中解决了这些痛点，因此比 Horizon 更好地服务客户。
• 无论性能、交互、界面、功能等等都比 Horizon 优秀很多。
• 作为一款成熟的产品，Halo 除了能够与 UOS 产品紧密的结合，还能适配标准的 OpenStack 环境，因此无论是用 Fuel、DevStack、TripleO 还是手动搭建，都能与 Halo 无缝的整合。