技术辩证法之——传统运维如何在以容器为代表的下一代技术架构中找到自己的位置？

在华讯的客户群体中，既有多年从事基础架构运维的老兵，也有众多刚入行的新人，既有对云技术精通的大神，也有刚刚接触云的小白。然而，面对快速变化的技术架构、琳琅满目的新技术和工具，以及既熟悉又晦涩难懂的新概念，人们总会对技术演进的历史车轮产生一系列深刻的思考：如何在技术变革中规划自己的职业生涯？企业和组织如何利用技术变革的机遇提升竞争力？个人的职业规划如何能为企业的技术战略做出贡献并实现共赢？ 近年来，在为客户提供服务的过程中，尤其是在针对亚马逊云科技客户的MSP服务项目中，华讯团队不断在实践、总结和反思，从新IT综合服务商的视角，为上述问题提供了自己的答案。 ## 一、容器技术的真正价值 关于为什么要引入容器技术，人们总是从开发或运维角度给出诸多优点。这些讨论往往聚焦于特定的技术需求领域，如应用打包、配置管理、自动化和标准化等，但很少从整体视角看待容器所带来的意义。容器技术在资源、环境、应用三大类基本IT问题中，都能发挥其独特价值。容器技术的强大生命力在于其提供了一个通用的生态，让不同领域的商业厂商和开源社区都能以一致的方式解决特定问题。 因此，我们认为容器、容器集群及管理平台并非仅仅是虚拟化的另一种形式，而是一种全新的统一架构语言。这种语言将三大基本IT问题域统一起来，让所有人都能在同一套体系下构建技术栈，使用一致的概念进行沟通与协作，共同构建完整、高效的IT系统。 ## 二、谁来主导容器建设？如果开发未使用容器，运维是否需要关注？ 基于对容器价值定位的理解，我们认为容器规划和应用不应仅限于开发部门。运维和系统部门在容器体系建设中也需要发挥重要作用。容器体系的建设应从企业整体视角出发，各部门共同参与规划。这样才能发挥容器的真正价值，确保基于容器构建的新IT体系能按预期运作，同时为每个部门带来收益而非负担。 运维部门应更主动地拥抱新技术架构，发现其中的价值。缺乏运维参与的容器化和容器建设实践，效果和成功率可能会大打折扣。 ## 三、容器会让现有工作失去价值吗？ 从某种意义上说，是的。任何技术终将被取代，这是技术生命周期的基本规律。然而，这并不意味着新技术可以完全取代人解决所有问题。在三大基本IT问题中，创造性和不确定性较高的工作仍然存在，且在可预见的未来无法被机器完全取代。 换个角度来看，物理资源、环境平台和应用这三大类IT问题是不会改变的。新技术和架构使交付和运行更加简单高效，但我们仍需关注规划、构建、策略制定和沟通协作等工作。容器统一架构语言并未让这些工作消失，反而提供了更高效灵活的工具帮助我们实现目标。 ## 四、如何在容器这样的新技术架构下划定工作边界？ 基于前述讨论，显然，任何人和团队都不应将自己的工作隔离于容器集群之外。如果能回归到我们工作目的本源，而不局限于技术架构本身，那么这个问题便可以迎刃而解： 如果你的工作是资源管理，那么容器集群的节点配置、存储卷配置等仍是你的工作内容。亚马逊云科技提供的EKS、ECS服务为容器环境的资源管理提供了丰富的功能，行业标准的API让运维人员能够灵活的应对各种复杂多变的资源配置调度工作； 如果你的工作是网络管理，那么容器集群网络插件的配置、负载均衡和代理实现服务访问发布的配置等仍是你的工作内容，亚马逊云科技提供的VPC CNI Plugin，ELB, ALB Ingress Controller等服务和功能使容器环境可以很容易的与云网络进行对接和统一管理； 如果你的工作是安全管理，那么容器集群的RBAC配置、网络策略编写等仍是你的工作内容，亚马逊云科技提供的IAM, WAF，CloudWatch，IAM Roles for Service Accounts (IRSA)等功能为容器集群的安全提供了良好的基础，同时与社区一致的标准也让EKS可以很容易使用第三方的容器安全产品； 如果你的工作是应用运维，那么应用部署配置、Pod健康检查配置、生命周期管理策略等仍在工作范围内。亚马逊云科技提供的CloudFormation, ECR, CodePipeline, CodeCommit, CodeBuild, CodeDeploy等服务让容器环境中的应用运维更方便快捷，同时，与社区一致的标准API也让EKS与常见的GitOps开源工具可以进行无缝的集成。 ## 五、亚马逊云科技如何帮助实现容器规划？ 亚马逊云科技为构建容器技术体系提供了丰富选择。托管容器服务简化了构建容器集群的过程，降低了迁移成本。云资源的弹性伸缩能力、丰富的购买选项、免费控制平面均有助于降低容器建设成本。经亚马逊云科技优化和严格测试的托管容器集群服务也更符合企业生产要求。 ## 六、容器与无服务架构 容器技术和应用已然非常成熟，那么我们不妨再进一步，看看以亚马逊云科技Lambda和一些列Serverless服务为代表的“无服务架构”。 容器技术以其轻量化、可移植性和快速启动等特点，为开发人员提供了一种创建、部署和运行应用程序的高效方式。而无服务架构则进一步将关注点从底层基础设施的管理上转移到了业务逻辑和代码的开发上，让开发人员能够更快地响应业务需求。 那么，容器技术和无服务架构在实际应用中是否会冲突？实际上，它们可以相互支持、共同发展。某些场景下，容器技术可以为无服务架构提供基础设施，如在支持自定义运行时环境的无服务平台中使用容器。而在其他场景下，无服务架构可以与容器技术并行使用，它们共同构成一个灵活、高效且易于维护的应用程序部署体系。在实际应用中，根据具体业务需求和场景，企业可以灵活选择容器技术、无服务架构或者二者结合的方式来实现最佳的部署策略。在未来的技术发展中，容器技术和无服务架构将继续并行发展，为应对日益复杂的业务需求和技术挑战提供有效的解决方案。 ## 总之，容器管理平台是一个比原先虚拟化平台和云平台更为宽泛的工作范围。任何人和团队都不应被隔离在容器管理平台之外，而是应在容器管理平台内划定工作边界，继续完成原有的开发、集成、资源管理、网络、安全、业务可持续性等一系列基本IT工作目标。容器统一架构语言在某种意义上成为了一种“工作边界即代码”的解决方案。 通过这种设定，我们发现不同团队和岗位的工作范围和目标其实并未改变，唯一变化的是所有人都在使用统一的架构语言和工具，让原本不同职责工作的技术边界消失，沟通协作变得更加直接、敏捷、高效。人类文明的发展，一向都是一项新技术会消灭一些工作，但是也会创造更多新的工作，对技术人来说，这样的机遇与挑战一定是个永恒的主题。