我理解不管是传统的“云”还是现在所谓的cloud native,本质上是将传统软件开发和基础平台的gap通过新的技术手段给弥补起来,但对于本身的体量问题,比如inbound/outbound流量,架构只能解决更好的利用率问题,但如果利用率达
CI/CD工具主要是进行代码的扫描、打包、QA部署、QA(自动)测试、(准)生产部署等。有一定并发性能要求及状态可视化要。一般开源方案以jenkins为主,通过Pipeline调用各自插件或shell脚本进行对应工作。商业方案也主要涉及以
ASIS:目前主流开源的服务发现框架包括spring cloud相关、dubbo等。K8S平台运行在其之下,若整合需要定制开发。PCF源生支持Spring Cloud体系。对于服务发现本身而言k8s使用了服务器端的HA和服务发现而非spring等通过客户
不同paas会有不同的实现方式,k8s的实现可以参考水平扩展参考:https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/垂直扩展参考:https://github.com/kubernetes/autoscaler/tree/master/vertic
如果涉及开源产品二次开发,整体思路:- 企业业界经验- 社区影响力- 开源控制力
在2016年的时候,领导问过我这个问题,我的回答是:如果资源有限,建议docker swarm:入手快,结构相对简单,但高级功能需要二次定制开发。如果作为战略方向,建议K8s:完善的模型,体系化的社区,但有一定学习成本。 如今2018年,印证了我
在这方面我理解需要注意公有云的特点:体量、弹性,但是同时需要注意的是企业数据敏感性和安全性。故首先需要定义:哪些数据可以放在公有云上?数据的体量,访问量tps有多少?哪些数据需要主机厂数据中心直接运营?访问量tps有多少
对应用而言容器定义了一种新的黑盒交付模式。其实传统VM通过自动化运维手段也能做到类似功能,但容器相对VM较为轻量,在基础资源利用率上具有比较大的优势。同样由于轻量,其scale out的弹性可用性会比虚机高,相对更容易应
硬件生命周期管理不是我擅长的领域。但我理解服务器生命周期管理涵盖了计算能力的规划,交付,运营和淘汰四个阶段。由于服务器generation更新导致计算力有较大提升,故对早期generation的MA总会平衡其计算力和成本。一般根
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30