借鉴公司自身的经验,现在大部分软件都在云化的历程上:1)定标准 - 起点目标可以低一点,规范可以松一点,平台可以开放一点2)定目标 - 先上来,再优化,再优化3)定激励 - 先进要鼓励,落后要扶持,有错平常事,多总结经验。 先进必然淘汰
我不从招投标角度谈,单说上容器云,可以考虑8个步骤:1)负载分类 - 决定什么上容器云2)应用分解 - 决定哪些部分上容器,哪些保持在传统平台3)开发生产线搭建 - 形成自动化交付能力4)混合云集成 - 把容器和非容器环境对接5)延展新
企业容器平台建设,有九点需要注意:1)开放性 - 选择主流开放平台,考虑社区生命线有多长,不偏爱特定厂家特定技术堆栈。2)弹性 - 为大规模生产做准备,小步快跑,但志存高远。3)可用性 - 肩负应用的可用性及灾备任务,为应用开发减负
文档的角色是保持软件的可维护性:1)团队沟通,统一认识。2)传承知识,总结经验。这个跟敏捷本无矛盾,但是很多时候快速迭代于开发的活动,导致了文档和代码不一致,这样就没有“single source of truth",这才带来了敏捷和文档
容器是一种选项,有优劣势,有匹配场景,很难说普适所有应用。老核心跑的好好的,的确不需要硬上容器,而且不改造应用,也不一定能获取容器的优势。重点是老核心如果要引进新的功能,我们如何用代价较低的方式来对接?这时候也许容器
传统企业可能因为合规要求,数据安全,不能考虑用公有云,但私有云可以是考虑的选项。私有云也不说明只能是容器,客户有现成应用,有新应用,多种架构和多种负载都应该支持。在基于物理机或者虚拟机的传统应用交付过程,其实也可以
项目的执行方式,验收方式决定了是否适合做敏捷。核心银行业务,也因为监管和验收的要求,比较难用敏捷的方式执行,一般还是用传统方法开发。互联网相关,快速交付,快速迭代的比较适合敏捷。这里带出“多速IT”的话题,也就是客户
谢谢提醒,随时联系。我会转达并连接相关同事。私信。
bluemix用户如果用的是cf,也可以平顺迁移到icp。ibm自己内部就把大量用原来别的云堆栈的应用迁移到icp上,效果很好也很快看到成效。这些经验都是很有价值。
内部有做过一些测试,在客户现场也做过一些比较,ICP具体的优势在于紧跟社区路线,保持高度开放性,及所运行的负载的丰富性及兼容性。
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30