标签：har 复杂 pac ansible keycloak 话题 基金会 镜像 ted
七年之痒这个词，大家经常说，不过起源，估计就不是谁都清楚。这是梦露的一部影片的名字，后来大家发现无论是企业，家庭，甚至政府，都在第七年时间段上面临各种麻烦。
OpenStack存在的问题，其实已经不是痒，就挠一下。基本上是已经无药可救。
逐步没落
我是2010年七月份，入职世纪互联云快线公司，开始搞云计算，公司是IDC，所以也就非常关注美国的IDC领头羊Rackspace，那时候在美国，Rackspace云计算是排名第二的，基本上是中国IDC的学习偶像。
非常巧合，我入职的时候，Rackspace和NASA推出OpenStack的项目。所以也就从哪个时候，一直跟着这个项目，一直走到2017年7月份，OpenStack的china Day，真的整整七年。见证了OpenStack整整7年，从零开始到巅峰，走向下坡路的过程。
现在已经离开OpenStack整整一年，回过头来看看，OpenStack到底有啥问题，遇到什么麻烦呢？屁股决定脑袋，我现在的屁股，应该也可以让我说的清楚一点。
经常有朋友问我未来OpenStack的发展趋势，我就用这张OpenStack邮件列表数量统计图来回答这个问题
邮件列表
图片来源：https://openstack.markmail.org/
现在邮件列表的活跃度，2016年到达巅峰，逐步在下降。基本上也是可以代表OpenStack的热度和发展状况的。这种下降的趋势，其实目前来看，还是很难逆转。
OpenStack社区真正干活，写代码的人，数量多少呢？估计已经不超过20人在全职干活。应该不到巅峰时刻的百分之十。
都不挣钱
其实我思考过，OpenStack存在的各种问题，不过归根结底，就是厂商根本就不挣钱。以前一个笑话，就是OpenStack最大的赢家是OpenStack基金会，每年入账1000万美金。
用开源软件来实现企业的盈利，这个无论是国外还是国内，都是非常有挑战性的问题。历史上，linux内核，就红帽实现的盈利。Hadoop的生态圈，至少有2家公司上市。那么对于OpenStack厂商来说，基本还是零。
国内的OpenStack市场，如果从2015年算起，经历了3年的发展和摸索，国内的OpenStack创业公司，基本都已经沦落为高级人力外包的公司。整个OpenStack的市场规模，也不足以支撑OpenStack创业公司的估值。这也导致从2016年，mirantis放弃Pure OpenStack厂商后，国内的厂商也都已经都布其后尘。
从现在看来，OpenStack创业公司上市套现的机会越来越少，也就导致OpenStack投资者也就没啥好日子。
很多朋友抱怨OpenStack很多不成熟的地方，不过说实话，就算把OpenStack做的完美，其实也是无法解决当前的困境，无法盈利。国内OpenStack厂商，最有想法，产品思维的两个厂商，是最先阵亡的，刻通和有云。
TC不作为
OpenStack基金会成立，专门有一个TC，技术委员会，负责OpenStack的技术方向，经过几年的发展，基本已经成为的养老院和老油条。
从2015搞的big tent，大帐篷项目，就是信心过于膨胀，项目从10个暴涨到50多个，不到1年的时间，问题就暴露出来。
谁都不能保证自己的决策不出错，但是出错，不做调整，就是作死。自从2016年Mirantis退出后，OpenStack大量项目出现没人玩的情况下，TC没做任何的事情。
一直到今天，OpenStack项目还是在不断增加，项目参与人手在不断减少。大量的僵尸项目，没人愿意站出来当丑人，直接把项目砍掉。
对比CNCF基金会，目前据说有500多个项目在排队等待孵化批准，批准进入孵化阶段门槛都是非常高，更别说毕业。
企业用户收益差
这点上，在我做容器，paas后，感受更加深刻。对于IaaS来说，他应该是可以给企业带来的效率的提升，资源的节省。不过这个如果和vmware比起来，就基本没啥优势。
国内的私有云市场，主要的客户群体是政府和国企。使用OpenStack的目的，并不是为了提高企业的竞争力，而是更多为了自主创新。
真正尝试使用OpenStack的企业，带来最大的好处，估计是技术人员的能力得到很大的提升。但是给企业的本身带来哪些改变呢？资源的节省，效率的提升，其实公司是没有感觉的。
企业目前使用资源的方式，还是资源创建者和使用者分开，无法真正实现自服务。运维负责创建虚拟机，开发者负责使用。
当用户无法在使用OpenStack中真正受益，那么放弃就是早晚的事情。
其实我当初走PaaS的时候，对PaaS能给企业带来什么好处，还是有疑问的。不过经过不到半年的使用，就能真正感受到Docker，PaaS平台给企业带来的好处，效率的提升，资源的节省，真的一个数量级别的提升。
K8S and PaaS
容器，Docker对OpenStack来说，其实还不能构成威胁。但是K8S，和PaaS的成熟，确实让OpenStack看不到未来。
很多用户受到IaaS，PaaS，SaaS三层架构的影响，认为PaaS就应该跑在IaaS上面，当年一位朋友，还专门去找新浪的SAE部门的老大，确认新浪的PaaS是跑在IaaS上，还是物理机器上。
其实根本不用纠结这个问题，PaaS和IaaS其实是一个松耦合的，PaaS完全可以直接跑在物理机器上。
我经常问容器厂商一个问题，到目前为止，哪些应用是无法跑在容器上的。必须要跑在VM上呢？其实真的没有，或者真的很少，很少。
Snap4
未来的企业数据中心，很可能是PaaS，K8S的天下。
OpenStack其实就算不犯任何的错误，在k8s出现后，其实都很难改变他的下坡路的趋势，无非是让下降平滑一点而已。
技术不是问题
最近好几篇文章，讨论OpenStack，说OpenStack技术复杂，有哪些短板。其实我 是看着OpenStack过来的。我可以说，目前阶段的OpenStack，技术上，还是过得去的。
几大核心项目，提供计算，存储，网络的功能，还是很稳定的。借助OpenStack容器化部署工具，kolla，不仅仅把OpenStack部署好，日志EFK都会部署的很好，目前kolla的社区普罗米修斯已经基本整合好了，再打磨一个版本，应该就用了。
长期用户纠结所谓升级的问题，也顺利解决，甚至可以实现某个组件的降级，例如neutron，你可以上以前版本，因为sdn兼容的原因。
我曾经很霸气回答友商提问，你的OpenStack和我的有啥区别问题。我说我给用户提供的OpenStack，让用户自己可以升级。
kolla即使做的那么优秀，我整整参与了2年，也无法挽救OpenStack的衰退。
Posted by 陈沙克 at 2:24 AM Tagged with: openstack
闲聊应用商店
云计算 No Responses ?
Sep
10
2018
公有云的公司讨论的两大热门话题，我想第一是计费，第二应该就是应用商店。IaaS厂商都在想办法做一个应用商店，很可惜，基本都失败了。
当年我曾经也是一个产品经理，调研过各大厂商的应用商店。这里我就做一个总结
虚拟机年代
镜像
把应用放到镜像里，这是最容易想到的应用商店，虚拟机启动后，做的配置，技术上还是可以实现。AWS在2010年的时候，应该就是差不多这种情况。
AWS上有大量的应用的镜像，你启动后，就可以使用，看起来是很方便。不过其实也就是自己使用，很难满足复杂的场景，基本都是 all in one。而且软件的版本，是一个噩梦，一个版本一个镜像，真的受不了。
脚本
很多人自然就想到，base的镜像都是一样，在虚拟机启动的时候，运行相关的脚本，来部署相关的软件。cloud-init，基本就是这个用途。
在国外的网络速度的情况，基本不是问题。不过在国内，基本就没戏了。而且这种方式，还是单机版本，复杂点，就基本没办法。
开发模式
有专门针对开发者的应用商店，因为开发者，有不同版本的需求，就简单lamp为例，php版本，mysql的版本，apache的版本，排列组合太多了，如何解决这个问题呢？
把软件都放到虚拟机里，用户选择需要什么版本，就启动相应的组件。这方面，bitnami做的应该是最好的。这家公司，从2011年开始到现在，做了8年，也在不断改进。
Agent模式
为了应用商店能投入生产，能部署复杂的应用，支持灵活的定义，web和数据库，可以合并部署，也可以分开部署。那么就有人想到使用agent来实现。
rightscale，国外著名的云管厂商，就是通过植入一个agent，来对虚拟机进行应用的部署，类似配置管理工具，这样就非常灵活，基本可以实现软件的全生命周期的管理。
通过agent，你可以实现对应用进行监控。那么对于IaaS来说，如果所谓弹性扩展，只考虑cpu，内存，那么是很胡扯的。
Posted by 陈沙克 at 11:22 PM Tagged with: openshift, openstack
OpenStack和Kubernetes相似的地方
云计算 No Responses ?
Sep
10
2018
我也算是折腾了一年的OpenShift，OpenShift，就是Kubernetes的一个发行版，我的感觉，其实他们相似的地方还是很多，对我的改变并没有想象那么大。
下面总结一下他们的相同的地方
看不到对手
无论是OpenStack还是kubernetes，都是在重围中杀出来，一骑绝尘，根本看不到对手。
OpenStack干掉CloudStack，Eucalyptus，OpenNebula。
Kubernetes，干掉swam ，messos
都是压倒性的优势胜出。
区别就在于，OpenStack胜出以后，就迷失了方向，往自己不擅长的边缘计算，最终只能是一条不归路。
K8s胜出后，社区的想法还是很多，还保持1年4个版本的迭代。
一个是python最大的开源项目，一个是Go语言最大的开源项目。
基金会管理
OpenStack专门成立基金会管理，不过基金会不涉及技术方向，技术方向有专门的TC，技术委员会管理，当big tent，大帐篷策略后，TC的用途也就不大，而且TC混日子的人也多了。
OpenStack官方目前有60多个项目，其实大部分都是僵尸项目，停留在实验室阶段，根本就没生产使用案例。真的能用的项目，应该不超过15个。
k8s，其实也归属CNCF基金会。吸取OpenStack基金会的教训。对项目是加入，孵化，毕业，有了严格的流程。这个可以很好避免。
OpenStack技术设计的时候，很纠结规模优先还是功能优先。公有云为主，还是私有云为主。这个也导致一直无法明确。
我的理解，K8s的功能，逐步的玩企业级发展。无论是用k8s支持有状态的应用，还是让k8s管理vm，方向都非常明确。
架构
看完OpenStack的架构演变过程，再看k8s，感觉相似的地方很多的。
Nova==CRI-O
cinder=CSI
Neutron=CNI
计算，存储，网络，都搞一个，无论是OpenStack，还是k8s，基本都是一样的玩法，让厂商都能参与进来。
目前k8s上没有统一的身份认证，就没有keystone，k8s上，没提供镜像仓库，就没有glance。
事实上也是有一堆的应用，对于OpenStack组件
keystone+ldap=keycloak+ldap
glance=Quay or harbor
部署
大家都感觉OpenStack很复杂，如果和k8s比起来，其实算是简单的。k8s的部署，单单是一个双向的证书，都能让你折腾一个半天。
但是用户一般感觉k8s比较简单，一个原因，就是k8s自己做的部署管理工具比较成熟。目前红帽的OpenShift，已经采用全容器化的部署方案部署OpenShift，并且容器的管理，也是在Openshift上，真的比较完善。升级的问题，也就变得很简单。
OpenStack目前部署方案的方向也是容器化部署，不过还无法实现用k8s来管理，只能通过ansible来管理。
对我来说，
kolla-ansible 部署OpenStack
openshift-ansible 部署OpenShift
都是通过ansible来实现。
标签：har 复杂 pac ansible keycloak 话题 基金会 镜像 ted
原文地址：https://www.cnblogs.com/hellsino/p/9688390.html
