当谈到企业成功过渡到的DevOps和云计算，关键是不只是技术的敏捷性，而且组织的灵活性，也被称为“文化”。
至少，这是康斯坦丁·冈萨雷斯最近，他在一个会话中谈到了Amazon Web Services (AWS)的首席解决方案架构师亚马逊网络服务重新:发明会议在拉斯维加斯。题为企业快车道，你的竞争对手不希望你知道，该会议安排冈萨雷斯与基督教Deger，欧洲汽车市场的现场总设计师AutoScout24，来讨论从在预先配置的数据中心中运行. net / windows的单片应用程序到在AWS云中运行在JVM/Linux中的微服务体系结构的过程。雷竞技电脑网站你可以在下面看到整个演讲的视频，但我想强调一些最有趣的结论。
+也在网络世界:有个足球雷竞技app任何云公司能否跟上亚马逊+
1.开发和Ops有不同的优先级
Deger表示，向云计算的旅程可能会在团队之间引发问题。例如，开发人员通常接受变化，而操作人员传统上争取稳定。“这两个咒语之间总是存在紧张关系，”他说。
2.更多的服务器是不是答案
Deger说，在转向云计算之前，这家总部位于慕尼黑的公司的传统架构与敏捷原则相结合，“多年来一直支持AutoScout24的发展。”
到现在为止还挺好。但是，工程师们不知道他们的应用程序是如何在生产中运行，“这样行动只会旋转起来新的服务器，以弥补任何性能问题。”本公司采用一票制，索取新的资源，他解释说，和工程师将指定他们需要什么，然后等待它的出现。没有人是幸福的。
3.对改变的渴望是不通用
“一小群心思变，” Deger回忆说，“但一大群反对它。”但是，当AutoScout24was出售给新的投资者，新的CEO认识到，“我们是很好的，但不是很大”，并给了该公司“一年来准备未来。”这意味着一切从吸引最优秀的人才转向更现代化的平台。
4.从小事做起，但要全力以赴
AutoScout24决定开始小，以避免铺天盖地的公司。当时的想法是把最初的变化实验，他说，应对更大的问题之前，向他们学习。
在升级基础设施的同时，该公司还在改进自动示波器24网站。Deger说，考虑到一次性改变这么多东西的风险，公司想知道是否有可以采取的中间步骤，把其他步骤留到以后。最终，这被拒绝了。迪格说:“我们需要做所有的事情。
5.缩放队很难
在2014年11月，Deger回忆说，一组开发和行动人的纺了一个AWS实例和运行.NET在戴尔PC到C＃在Mac上移动。这个新团队负责一切，从基础设施到应用交付。
作为这一进程的进展，Deger表示，公司憋足了那最初的团队，加入更多的成员，然后分裂成两到四个新的团队。这些分割的团队合作，分享知识，以及新车队学得很快新的工作方式。不幸的是，这个过程中破坏了现有的团队并没有让他们成为高性能。
6.确定您的核心IT原则
此外，新的团队成员始终没明白，原来的目标。
所以，AutoScout24想出了一套设计在船上帮助大家GET IT核心原则。这些原则包括两个战略目标，比如减少时间，以支持它们所需的市场和业务目标，以及建筑，设计和交付准则。
当Deger向观众展示这些原则时(你可以在下面的视频中看到)，他要求与会者不要复制这些原则供自己使用。他说，很多都是通用的，你自己很可能会想到类似的东西。他补充说，更重要的是，“有价值的部分是你必须提出自己的讨论。”
7.创建技术“行会”
AutoScou24采用了一种看起来很有魅力的德国方法，它还建立了所谓的“行业”，以围绕宏观架构、基础设施、QA等主题促进跨团队交流。Deger说，这些“自组织的共同目的小组”每周聚会一次。有些人做实际的工作，有些人做决策，其他人只是在需要的时候分享信息。
8.微服务体系结构反映了公司结构
引用康威定律，Deger指出，自治系统往往周围组织的业务能力。
“我们想要一个微服务架构，”Deger说，“这意味着公司也必须这样建立。”……我们想要构建产品，而不是项目，”并允许团队快速做出本地决策。
口头禅变成了：你盖了，你运行它。每个团队负责修复任何出错，从而导致弹性和强大的服务，他说，因为球队不希望出问题的时候在半夜被唤醒。
9.对正在进行的技术决策有一个计划
每个小组有权力做出自己的技术决策，但AutoScout24不想跟不同的技术炖结束。因此，尽管首次提出技术选择和他们周围建立加工新车队中，“当第三，第四和第五的球队来到船上，”他说，他们可以拿起这些选择。但他们不会被迫这样做，如果他们有一个很好的理由做不同的事情。当然，这些球队又将需要支持自己的技术决策。
10.服务器不是牛;他们是汉堡包
服务器正在变成牛，而不是宠物，迪格在这一普遍现象的基础上更进一步。他说，在AutoScout24，服务员是汉堡，不是牛:“我们对牛不感兴趣，只对肉感兴趣。”
他说，公司的服务器没有一个能经受住软件更新的考验，而AutoScout24正在研究一种容器化的方法，尽管这仍处于过渡阶段。
11.分级环境已经成为历史
舞台环境的设计看起来像生产，Deger说了，用来测试每一个新的软件版本。但在微服务的世界里，许多版本不同的表现在生产中比他们在测试中做的。
AutosScout24发现这是一个持续的斗争，以保持其暂存环境看起来像生产。花“了很多努力，” Deger说，“但我们不能确信它反映在生产发生什么作品。”
因此，该公司决定放弃它的临时环境，直接让所有新发行的产品。
移动到持续交付和不断更新，可能看起来吓人，Deger说，但是如果增加变化的数量，和你这样做是正确的，那么你的失败率居然下降。
12.“监控是新的测试”
测试仍然是重要的，Deger说，但在连续部署微服务的环境中，你不能轻易告诉变化将如何影响其他服务。尽管如此，该公司希望以“大胆，不傻，”他说，于是就用下生产负荷“金丝雀版本”，但不是真正的报告，创建被推广到用户之前，可以对问题进行监测阴影交通。
他说，监控应该包括业务kpi，而不仅仅是运营指标。例如，AutoScout24的工程师自己负责构建自己的仪表盘，把所有东西都放在一起，包括AWS的成本。
Deger总结说，持续监控在微服务领域尤其重要，因为您的环境一直在变化。
如果你想了解更多关于AutoScout24的云本地微服务架构之旅，以及它在此过程中发现了什么，请观看下面Deger和Gonzalez的完整演示视频。我发现它包含了对日益普遍的转变的有价值的见解。