概要

2022年2月23号，StormForge宣布正式上线该产品的第三个核心解决方案Optimize Live，专注于生产环境Kubernetes集群的性能优化。

2022年4月22号，StormForge博客发文详述了该团队在二月份Cloud Field Day 13上的一场分享活动，分别从全局概述，产品演示，客户案例及组委会反馈几个方向介绍了产品自身及外部的评价。

StormForge是一个由数据科学，机器学习和运维开发领域工程师在2015年成立的专注于云原生Kubernetes大规模资源管理的团队，提供以应用性能和资源利用率为牵引的运维优化解决方案。

StormForge是CNCF全局版图中持续优化领域的项目之一。

持续调优

概括来说StormForge提供三类解决方案，分别是

●性能测试即服务 Performance Testing as a Service

●非生产环境K8S优化 Optimize Pro

●生产环境K8S优化 Optimize Live

性能测试即服务 Performance Testing as a Service**

分钟级生成上万条数据请求和百万次用户同步访问的仿真用例，并轻松集成到已有的CI / CD流水线中来进行主动式，自动化地负载测试。应用性能左移，完成持续开发，持续性能优化，持续运维地全链路闭环，确保发布前应用已处于稳定性和性能的最优态。

性能测试即服务，万物轻量化SaaS模型的产品包装皆可即服务，DevOps已经将敏捷框架的开发和部署揉成了闭环的最佳实践，性能压测这件事情也已经在有能力，有资源的团队中集成落地，但不乏有“手头紧”，任务重的团队难以有专人专事来搞这个，那么线上的风险和稳定性事件地发生想必也会随之而来，在拥抱云原生的团队中更是如此。没测试集成，没测试用例的现实情况也就出现了奔着K8S应用性能优化去的StormForge来满足该领域的市场需求，况且性能左移的负载测试尤其针对高保应用来说无疑ROI最高。有需求 + 肯买单 = 产品。

非生产环境K8S优化 Optimize Pro

基于客户配置的期望业务目标和平台机器学习模型，快速地完成非生产环境Kubernetes集群的实验构建和场景模拟，搭配平台自身的性能测试服务或三方工具完成负载调试，随后通过集群中部署的Controller完成对容器化应用配置项地持续自动化调优。

容器化应用的资源需求大小决定了购买云机器的大小，尽管业务稳定性是第一考量，往往会过度置备资源以免不足，但对于中小团队来说，每一核每一小时都是实实在在的账单，能省何乐而不为。客户可以选择首要保障的，和业务强耦合的追踪指标的目标值（指标Metric可以是平台默认，也可以是客户自定义在监控中观测的指标），配合前文的负载测试方案对更新后的资源需求值（CPU Request / Limit等）进行回归校验，随后就是往复地自动化调参 + 测试 + 校验，最终就是在发布前已完成性能（核心围绕资源需求量）地调优。蚂蚁主站当前在应用开发部署阶段仅有容器规格4C8G和8C16G两种默认模版的选择，但后续也有针对生产应用托管后的VPA画像来进行规格地调优。场景不同，重点不同，针对外部公有云上的中小团队来说，财务优化仍是高优先级。

生产环境K8S优化 Optimize Live

StormForge最新一次迭代推出的解决方案，基于客户集群现有的生产监控数据（例如Prometheus，DataDog，Dynatrace等三方服务商沉淀的数据），利用算法驱动的决策引擎产出优化推荐，随后可以手动或配置自动化任务去完成更新。

如今的云原生环境，应用，基建和流量时刻都在变化，监控解决方案的引入已经很好地简化了数据追踪和观测的复杂度，而该方案地推出就是实现洞察和执行的闭环，和非生产环境方案的主要差异也在于这个是基于真实观测数据，而后者则是基于负载测试数据。蚂蚁主站容量管家的VPA画像与此相似，月度的变更周期相较于StormForge的频率低了很多，但先天和监控团队的深度融合使得在数据输入层面上的丰富度远大于此类外部SaaS服务商，从而在决策输出上也会更为精准。但不可否认，外部市场仍然处于开放状态，StormForge的产品演进方向也否定了需求量的萎缩趋势。

生态融合

StormForge为Kubernetes量身打造，完美和云原生社区的多类型产品先天融合，以合作共赢的方式帮助客户在降低风险和提升运维敏捷性上做改善。包括但不局限于和下列各域产品的契合；

云服务商：AWS｜Azure｜GCP｜IBM

容器平台：OpenShift｜VMWare Tanzu｜Rancher Labs｜D2iQ

CI / CD：Jenkins｜GitHub｜circleci｜cloudbees｜GitLab

监控平台：DataDog｜New Relic｜Dynatrace｜Prometheus｜AppDynamics

编程语言：Java｜Python｜Dot NET｜GO

云原生架构从基础设施的角度实现了对上层微服务架构的业务体系在DevOps和CI/CD上的完美支撑，生态内不同模块的差异性工程上有成熟的方案可以较好地实现屏蔽，生态地完整性也催生了多样，精细化地项目出现，每家每户各司其职，做好专注领域内的事情，一起做大做强。

后续思考

作为CNCF全局版图中持续优化领域的项目之一，StormForge做着性能测试即服务的生意，将性能左移，集成到了云原生应用的DevOps流水线中的上游。而近期推出的专注于生产环境监控数据的Optimize Live解决方案转移到了相对下游，补齐了全链路的Kubernetes参数调优组合方案。

测试即服务对外部云原生社区采用微服务架构的团队来说的确是需求的满足，对内的研发团队来说性能是开发阶段默认的考量，资源需求量的合理配置有固定的模版选择，缺少一定的灵活性，但不是没有成本考量，只是转移到了团队层面兜底，外加后续的调参优化，况且场景的不同也决定了侧重点的不同。倘若要进行更优地财务管理，那么精细化容器维度的资源请求刻画也是一种选择。