挑战
Haufe集团成立于1930年，最初是一家传统的出版商，现已发展成为一家媒体和软件公司，其95%的销售额来自数字产品。多年来，该公司从“地下室里有硬件”发展到外包其基础设施运营和IT。最近，从税务专家的互联网门户到人事培训软件等新产品的开发，对速度、可靠性和可扩展性提出了更高的要求。“我们需要能够更快地行动，”解决方案架构师马丁·丹尼尔森说。“我们真的希望能够适应工作负载。”
解决方案
当微软Azure在欧洲可用时，Haufe集团开始了其云原生之旅；该公司需要为其桌面应用程序进行云部署，并提供带宽密集型下载服务。“在那之后，不同的项目尝试了不同的东西，”丹尼尔森说。两年前，霍尔格·莱因哈特作为首席技术官加入Haufe集团，并迅速将传统的基于主机提供商的方法重新定位为云优先和API优先战略。
该战略的核心部分是强烈要求通过Docker在整个软件部署生命周期中采用基础设施即代码。该公司现在正准备在微软Azure和亚马逊云服务上使用Kubernetes编排技术，上线两项生产服务。该团队还在努力将他们的一款核心Java企业桌面产品分解为微服务，以便在云中实现更好的可演化性和动态扩展。
影响
丹尼尔森说，有了适应工作负载的能力，团队“将能够在晚上将容量缩减到大约一半，从而节省30%的硬件成本。”此外，更短的发布时间也产生了重大影响。“以前，我们必须提前至少一周宣布我们何时想发布，因为有一份很长的清单列出了你必须做的事情，”他说。“通过采用云原生，我们拥有了自动完成所有这些事情的基础设施。现在，我们可以在半小时内完成一次新的发布，而不是几天。”
然而，到了20世纪90年代，该公司的领导人意识到未来是数字化的，并且值得称赞的是，他们能够将Haufe集团转型为一家媒体和软件公司，该公司现在95%的销售额来自数字产品。“在这样做的德国公司中，我们是最早的采用者之一，”Haufe集团的解决方案架构师马丁·丹尼尔森说。
现在，他们正在为像Kubernetes这样的中型企业拥抱云原生技术开辟道路。“像Ticketmaster和谷歌这样的大公司做得很好，初创公司也做得很好，因为它们更快，”丹尼尔森说。“我们处于中间的庞大公司中，拥有大量的遗留系统、大量的结构和大量的文化，这些都不容易适应云技术。我们只有1500人，但我们有数百个面向客户的应用程序。因此，我们正在做的事情对于我们这样规模甚至更小的许多公司都将具有相关性。”
许多遗留的挑战源于简单地追随时代的技术趋势。“我们过去做的是完全的DevOps，”他说。在20世纪90年代和2000年代，“这意味着你的硬件在地下室。然后，在10年前，当时的炒作是外包应用程序操作，外包一切，并精简你的IT部门，以消除所有这些硬件的干扰。这不是我们的专业领域。我们不想成为基础设施提供商。现在，这会产生反弹。”
Haufe集团开始感受到痛苦，因为他们正在开发更多新产品，从税务专家的互联网门户到人事培训软件，这些产品对速度、可靠性和可扩展性提出了更高的要求。“现在，我们的工作流程中断了，从编写概念到开发，再到将其移交给生产，然后再将其移交给你的主机提供商，”他说。“然后，当事情变糟时，我们不知道哪里出了问题。我们绝对想要重新掌控，我们想要更快地行动。适应工作负载是我们真的希望能够做到的事情。”
这些需求促使他们探索云原生技术。他们首次涉足云领域是在微软Azure中进行部署，因为欧洲开始提供用于具有内置下载服务的桌面产品的部署服务。这种带宽密集型服务的托管费用太高，因此该公司转向了云。“在那之后，不同的项目尝试了不同的东西，”丹尼尔森说。
两年前，霍尔格·莱因哈特作为首席技术官加入Haufe集团，并迅速将传统的基于主机提供商的方法重新定位为云优先和API优先战略。该战略的核心部分是强烈要求通过Docker在整个软件部署生命周期中采用基础设施即代码。一些实验比其他实验走得更远；关于敏感数据的德国法规阻碍了一些工作负载迁移到Azure和亚马逊云服务。“由于我们的历史，德国对个人身份数据等事情非常严格，”丹尼尔森说。
随着德国Azure主权云（由德国T-Systems提供商运营的Azure克隆）的到来，这些实验焕发了新的活力。随着符合德国隐私法规的Azure.de的可用性，团队开始认真考虑在Docker中将生产负载部署到云中。“我们在过去两年里一直在使用容器，我们真的掌握了它们的工作原理，”丹尼尔森说。“但这始终用于开发和测试，而不是在生产中使用，因为我们不完全理解它的工作原理。对我来说，Kubernetes绝对是解决这个问题的技术。”
与此同时，丹尼尔森构建了一个API管理系统，旨在支持CI/CD场景，而这些方面在现成的API管理产品中是缺失的。基于Mashape的Kong网关，它以wicked.haufe.io的形式开源。他将wicked.haufe.io与他的产品团队一起使用。
否则，丹尼尔森说他的理念是“不要总是试图重新发明轮子。选择现有的东西，99%的时间它就足够了。如果你认为你真的需要自定义或额外的功能，也许要三思而后行。我发现这个云原生框架如此令人惊奇的一件事是，一切都联系在一起。”
目前，Haufe集团正在生产中使用Kubernetes进行两个项目。其中一个是用于研究立法和税法的新的移动应用程序。“我们需要一种方法从遗留核心中提取功能，并在上面放置一个带有API网关的应用程序——很多需要容器移动的部分，”丹尼尔森说。因此，该团队将构建管道从“部署到你可以在其上部署任何东西的旧的庞大机器”转移到Kubernetes集群，在那里将有自动的CI/CD，“具有功能分支和过去有些繁琐的所有这些东西。”
这是一个概念验证的努力，而证明就在结果中。“每个人都对我们在一周内取得的成就印象深刻，”丹尼尔森说。“我们只是做了这些集成，以确保我们了解Kubernetes的工作原理。如果你能围绕某件事创造乐观和热情，那就赢了一半。如果开发人员和项目经理知道这是可行的，那么你基本上就完成了。”莱因哈特补充说：“你需要创造一些非常明显、快速的胜利，才能克服现状。”
对部署速度的影响是显而易见的：“以前，我们必须提前至少一周宣布我们何时想发布，因为有一份很长的清单列出了你必须做的事情，”丹尼尔森说。“通过采用云原生，我们拥有了自动完成所有这些事情的基础设施。现在，我们可以在半小时内完成一次新的发布，而不是几天。”
对成本的潜在影响是另一个好处。“托管应用程序非常昂贵，因此迁移到云是我们真的希望能够做到的事情，”丹尼尔森说。有了适应工作负载的能力，团队“将能够在晚上将容量缩减到大约一半，从而节省30%的硬件成本。”
同样重要的是，丹尼尔森说，还有额外的灵活性：“当我们试图移动或修改真正关键的应用程序时，通常很难验证我们想要采取的路径是否会顺利进行。为了验证这一点，我们需要重现环境并真正进行测试，这成本太高，而且对于传统主机提供商来说根本不可行。云原生使我们能够进行有风险的更改，并以具有成本效益的方式对其进行验证。”
随着两个成功测试项目的消息在公司内部传开，人们对 Kubernetes 的兴趣也日益浓厚。“我们希望能够支持我们的开发人员运行 Kubernetes 集群，但我们目前还没有达到这个程度，所以我们允许他们这样做，只要他们意识到这是他们自己负责的事情，”Danielsson 说。“所以这也是为什么我们也在关注诸如 [托管 Kubernetes 平台] CoreOS Tectonic、Azure 容器服务、ECS 等服务。这些类型的服务对于那些想要利用云原生但又没有 IT 部门或相关结构的的中型公司来说会更加重要。”
Danielsson 表示，在未来一年半的时间里，公司将致力于将他们的一款旧版桌面产品（一个用于研究立法和税法的 Web 应用程序，最初用 Java Enterprise 构建）迁移到云原生技术。“我们目前正在进行微服务拆分，以便我们可以独立部署不同的部分，”他说。主要网站（为客户提供免费内容）也在向云原生迁移。
但是，在实现这些目标的同时，Danielsson 认为存在更大的文化挑战需要不断解决。向新技术的迁移，更不用说向 DevOps 的转变，对员工来说意味着很多变化。“过去的职责相当固定，”他说。“你有开发人员，你有项目负责人，你有测试人员。而现在你进入了像测试自动化这样非常非常重要的事情。测试人员不再进行点击测试，他们必须编写自动化测试。如果你真的想全面采用 CI/CD，所有这些小部分必须协同工作，以便你有信心进行签入，并且知道这个签入将部署到生产环境，因为如果我搞砸了，一些测试将会失败。这是一件非常强大的事情，因为无论你做什么，无论何时将内容合并到主干或主分支中，它都会上线。而这就是你是否能留住人，或者他们是否会尖叫着逃跑的时候。”Danielsson 理解，有些人可能需要更长的时间来适应新的方式。
“文化不是你可以强加给人们的东西，”他说。“你必须自己去实践它。你必须去宣传它。你必须一次又一次地展示它的优势：这就是你如何做到，这就是你能从中得到什么。”为此，他的团队为员工安排了为期一天的研讨会，邀请外部专家来讲解从 API 到 Devops 到云的一切内容。
对于每一个尖叫着逃跑的人，还有许多其他人被吸引进来。“让他们入门，让他们真正对这些东西感兴趣，”Danielsson 说。“通常它会流行起来。我们现在有以前你永远不会想到的人在喊着‘Docker Docker Docker’。看到他们意识到他们的 Python 库之外还有一个世界真是太酷了。看到他们真正使用 Kubernetes 真是太棒了。”
最终，Reinhardt 说，“一项战略的执行需要文化、结构和技术的协调一致。只有当这三个维度保持一致时，你才能成功地将转型为微服务和云原生架构。只有这样，云才能在产品创新速度更快和运营成本更低方面带来回报。”