云解决方案与基础设施
我们构建随业务增长而扩展的云原生基础设施。从初始迁移到持续优化，我们的云工程师确保您的系统高性能、安全且经济高效。
我们交付的成果
- 云架构设计和迁移策略
- 使用 Docker 和编排工具的容器化部署
- 用于快速可靠发布的自动化 CI/CD 管线
- 用于可复现环境的基础设施即代码
我们的方法
- 评估当前基础设施和性能瓶颈
- 根据工作负载需求选择云服务提供商
- 零停机策略的分阶段迁移
- 成本优化和性能监控
平台
- AWS — EC2, S3, Lambda, RDS, CloudFront
- DigitalOcean — Droplets, Kubernetes, Spaces
- Docker 与容器编排
- Terraform 和基础设施即代码
从审计到切换：一次迁移如何进行
我们首先像会计师查账一样审读您的现有基础设施：哪些在运行、花了多少钱、故障时会波及什么。这次审计会产出一份分阶段的迁移计划，在我们触碰任何生产环境之前，每个阶段的回滚点都已写入文档。数据库借助复制机制最后迁移，因此最终切换只是一次 DNS 变更，而不是一场豪赌。
我们构建的一切从第一天起就以代码定义。服务器、网络、DNS 和部署管线都保存在版本控制的配置中，因此再建一套环境只需一条命令，也不会有什么东西依赖于某台 2019 年被人手工配置过的服务器。系统稳定后，我们会搭建成本和性能监控，并在三十天后进行一次复盘，捕捉那些只有真实流量下才会暴露的意外。
应该选择 AWS 还是 DigitalOcean？
如果您的工作负载是一个带数据库、流量可预测的 Web 应用，选 DigitalOcean：运维更简单，账单大约只有 AWS 同等方案的一半。而当您需要 DigitalOcean 所不具备的托管服务时——细粒度的 IAM、Lambda、SQS、多区域故障转移，或企业客户要求的合规控制——则选 AWS。我们每天都在这两个平台上运行生产系统，因此我们的建议来自实际观点，而非合作分成。
我们的自有产品 Rukrok、Komerce 和 Chargly 正运行在这套架构上，根据各自需求分布在 AWS 和 DigitalOcean 之间，所以上述取舍来自我们自己的账单。大多数客户以为自己需要 Kubernetes，其实大多数并不需要。负载均衡器之后放几台 Docker 主机，配上托管数据库和自动备份，就能覆盖出人意料多的场景，而且一名工程师就能运维。
与我们的云团队合作是什么样子
迁移项目通常按固定范围执行：审计完成后，我们对整个迁移给出报价，并将阶段划分和回滚点写入协议。持续性的基础设施工作则采用按环境规模定价的月度服务包，涵盖监控、补丁、成本复盘，以及告警时的响应承诺。无论哪种方式，您都能在 Slack 上直接联系到实际干活的工程师，而不是排进一个被上千客户摊薄的工单队列。
我们刻意让您保留随时解约的能力。因为每套环境都可以从版本控制的代码和成文的运维手册中复现，任何称职的 DevOps 工程师都能接手我们的工作。有些服务商靠晦涩难懂制造锁定，我们更愿意靠持续创造价值留住客户。项目进行期间的每周摘要会告诉您发生了什么变更、花了多少钱，以及我们接下来的建议。
我们标准化使用的工具
打包用 Docker，因为在笔记本上能跑的容器，在生产环境也会以同样的方式运行。基础设施即代码用 Terraform，同时覆盖 AWS 和 DigitalOcean，让环境靠声明而不是靠记忆。管线用 GitHub Actions 或 GitLab CI；数据库几乎在所有场景下都选择托管的 PostgreSQL 或 MySQL 而非自建；监控则追求朴实、文档完善，而不是一块没人看的仪表板。
在 AWS 上我们主要使用 EC2、S3、RDS、Lambda 和 CloudFront；在 DigitalOcean 上则是 Droplets、托管数据库和 Spaces。当可移植的替代方案同样好用时，我们会避开那些主要为了加深平台依赖而存在的服务。这种克制意味着更小的账单和更容易的退出。当某项专有服务确实物有所值时，我们会使用它，并在文档中明确写清将来迁离它需要付出什么。
为什么选择 Kodenique 的云解决方案与基础设施
Rukrok、Komerce 和 Chargly 运行在与我们为客户部署的完全相同的 AWS 和 DigitalOcean 架构上。
当您不需要 Kubernetes 时我们会直说；许多工作负载用 Docker 主机加托管数据库运行成本更低。
迁移分阶段进行，触碰生产环境之前先将回滚点写入文档，数据库借助复制机制最后迁移。
一切都可以从版本控制的代码中复现，所以您永远不会被某台“雪花服务器”锁定，也不会被我们锁定。