借用华为的朱雀名称作为这个裸金属服务的工程名称，主要是提供物理机资源管理的一全套工具集，包含管理API/流程处理的Scheduler/装机指令执行的Agent/带外驱动的Driver/镜像构建等等。
写这个开源工程的初衷是因为国内很多大厂还在使用OpenStack Ironic的来处理裸金属管理，一直对 OpenStack 相关的整体架构不太感冒，觉得系统架构缺乏一致性，依赖复杂，调用关系混乱，数据结构粗糙，当然它还是完成了对应的功能。相比熟悉它/开发它/维护它的技术人员付出的成本而言，给业务带来的贡献和付出的整体成本而言，完全不对等。一个依赖OpenStack Nova/Ironic的产品级别的项目，越是到后期，内部的研发付出的成本越来越高， 可以从华为内部邮件的熵减理论来描述这个过程任正非签发内部文：警惕“华为中年危机”，全面建立熵减机制，避免重蹈“巨头衰败”覆辙。对应我们的应用系统，也应该是个熵减的过程，才能让系统持续的提供更强的生命力。国内大多数企业还使用OpenStack原生的很多组件作为基础资源管理的服务，我理解更多的原因是还没有那么大魄力或者自信，或者是受限于环境/制度等等制约。我想说的是，只要把基础原理弄清楚，同时团队的目标/技术都满足的情况下，建议还是使用自研的核心更有亲和力的系统来服务自身业务。
本人就是一普普通通的Java/Python相关的技术工程人员，没有太深的理论基础，因为工作的原因长期使用Linux，接触了比较多的相关生态，最近几年一直在物理机相关的产品线上贡献自己的微薄力量。算是不自量力来实现这个裸金属管理服务，希望对工作在类似场景下的同学能有所帮助。有任何意见及建议，欢迎通过Github或者电子邮件（linuxcoming@qq.com）沟通。
资源总是有限的,不管是公司/团队/个人皆是,最简单最可靠的才符合各方长期利益.
开源有非常好的一面,集合全球开发者的才智为社会的发展填砖加瓦,可以让更多人免费开放的使用相关技术,但是毕竟这么多人,一定需要优秀的决策模式,优秀的流程管理,以便让项目有可靠的质量,可扩展的能力,一致的架构设计,还有就是可维护性.俗话说有人的地方就有江湖,说起来容易,做起来难.落到实际总会被某些因素牵着走,或者大量的人员被动跟随.即使很开放,又面临百花齐放,意见分歧严重.所以对于一些关键性的决策有些时候其实很难的.每个思潮都带来一种设计模式,引入对应技术的依赖,尤其是庞大的社区,比如OpenStack,所以大家再看各个工程的依赖的时候就发现,太庞杂了.设计和实现的人同具体的使用方的诉求有时候其实不是很匹配的,这么庞杂的环境,要让使用方持续性使用和维护,成本是一定不低的.所以我们希望砍掉不必要的依赖,能用一个工具解决的事情,绝对不引入多个工具来实现.保持简单,
从OpenStack的实现来看,有HTTP调用,有RPC调用,有MQ消息,同一个组建和外部交互有各种不同的形式,同步流程我们使用HTTP/RPC中的一种不就好了,异步流程,我们使用MQ将逻辑解偶,由异步机制去完成不就好了?尽量保持单向通信,一定要双向通信也尽量保持简单性,保证系统结构清晰,保持稳定,保持独立.类似jetty的实现将不同功能的在不同组建中实现,既简单又又独立性,akka也是一样,我可以简单用,也可以复杂用,但并不妨碍整个系统中的结构/稳定/独立.
组建化和插件化是系统设计中的常用方法,需要对组建合理抽象,提供可编程的插件API.
maven的约定大于配置理念,elasticsearch下载下来后可以直接使用,也可以深度优化后,建立规划化机群使用,这些都是便于实践的组建或者服务,组建与组建之间松耦合.减少和环境的相关性,便于使用者快速理解和上手.提供业界标准的编译/安装/部署流程,以便使用者可以根据以往的经验,快速完成整个过程,而不是要新起炉灶,重新开始,经验是可以积累的,这样才能将效率最大化.比如常规的开源软件make三部曲,任何语言的应用就可以按该模式来提供编译/安装/部署的支持.
上述原则都是我们希望在suraku中来实践的,一定有做的不够好的地方,欢迎批评指正.