DevOps云解决方案2020的状态
每家公司都声称拥有云/混合DevOps平台，支持并支持开发人员远程工作。是时候整理混乱了。＊
在当今的数字时代，软件推动着商业创新。软件交付过程的成熟度、速度、质量和安全性已经成为软件驱动经济中的关键区别。COVID-19现实推动市场更快地采用远程开发人员访问IT。因此，软件供应商正在竞相启用和扩展云DevOps解决方案。越来越多的团队寻求采用端到端DevOps平台或者减少对多个供应商和工具基础设施所有权的依赖的工具包。但是企业需要什么呢云DevOps工具，以及应该考虑哪些关键的区别?
在这里，您将获得当前可用的云DevOps平台解决方案的高级概述，以及在您的云DevOps旅程中您应该从供应商那里获得什么。
＊该信息基于JFrog进行的研究，反映了截至2020年4月市场上可用的解决方案。
企业云DevOps转型需要考虑的6件事
虽然JFrog在每个公共云提供商和全球20多个地区都提供了云产品作为这些需求的解决方案，但在与任何单个供应商进行DevOps到云的数字转换时，您应该考虑以下6件事。
- - -端到端- - -
点解决方案可以在一个或几个特定的事情上做得很好。但是云中的端到端DevOps平台应该达到运行时，具有单一的策略和支持点。单独集成遗留的DevOps系统可能会产生意大利面条式的解决方案——包括CI/CD。保持简单和快速。重要的是，这还包括DevSecOps的安全性功能，或者它可能是一个不适合你的开始。
今天的开发人员正在寻找一种端到端解决方案和“一体化”的用户体验，但这并不意味着他们会在“最佳”方法上妥协。因此，DevOps平台提供商除了提供强大的生态系统集成和插件之外，还应该提供a类工具堆栈作为平台的一部分，以使开发人员的生活更轻松，尊重他们想要的选择自由。
端到端平台还要求供应商承诺提供真正的“单一浏览器解决方案”，而不仅仅是集成的捆绑工具。这可以确保用户从连接所有服务的单个UI获得完整的体验。
- - -2022年世界杯预选赛赛程表通用包管理- - -
必须支持你无数技术中的所有元数据和依赖项(如Docker、npm、Maven、PyPi，GolangNuGet,柯南等等-但也为20+多种类型你可能会在你的投资组合中找到)。针对单一或有限技术类型的点解决方案只会让您的开发团队感到沮丧，并要求您在组织中采用多个解决方案和存储库。大型企业不仅拥有无数的技术，而且还拥有长期遗留的部署的关键任务应用程序，必须通过本地、远程和虚拟存储库大规模地支持这些应用程序。
现代DevOps团队支持整个组织，并使越来越多的实体(有机的和非有机的)能够轻松地使用所有二进制类型的单一真相来源。
- - -完全混合:这里和那里100%相同- - -
这与是否有云解决方案无关。许多提供云解决方案的公司没有相应的预置/自托管选项，反之亦然。更多的公司仍然有完全独立的解决方案，提供不同的功能和不同的方法，彼此之间没有交流，这需要你学习一个新的产品、用户体验和用户界面。当您过渡到云环境时，两者都需要云计算和预置需要能够100%的时间以相同的方式工作，以确保平稳过渡(例如，当你经历一个云迁移并且在两个地方都需要相同的工具和功能，以保持业务运行)。这比听起来要复杂得多，需要相同的代码库、相同的QA流程、相同的架构以及跨环境的更多内容。您还应该寻找提供支持的提供商多区域和云为一个真正的混合解决方案，是可访问的。
- - -多重云- - -
大多数JFrog的企业客户在选择单一提供商时都有一个非常明确的策略:他们不允许自己冒险只在一个云上托管DevOps和远程it工作区。虽然您可能认为一个云就足够了，但您应该选择一个跨所有主要云提供服务的供应商。通过避免任何供应商锁定和提供最大的弹性，保持您的选择余地和心态的平静。(如果需要，这对于云之间的迁移策略也非常有用。)这种“DevOps民主”方法还为您的组织提供了一个弹性工作空间，可以扩展和扩展以实现真正的DR设置。
- - -安全- - -
DevSecOps不仅仅是一个流行词。这是一个要求。安全性作为支持所有包类型的管道的集成部分，现在已成为许多公司的一个项目。将离开是针对整个DevOps组织的，因此您应该考虑使其简单的工具。例如，云DevSecOps工具应该能够阻止包含漏洞的工件下载(或破坏构建)，这需要紧密集成到存储库中)。安全策略应该易于跨存储库定义和管理。任何云安全解决方案都应该允许您在整个DevOps管道中轻松识别漏洞的影响。
DevSecOps中一个经常被忽视的类别是开源许可遵从性问题。软件包不仅可能包含漏洞，还可能包含未知的许可问题。解决方案应该为这两种类型的策略提供扫描和补救。
确保您在这方面所做的任何选择都能满足所有这些需求，并对开发人员具有充分的可见性甚至在他们的ide中-以达到最大的效率和安心。
集装箱世界也带来了挑战。你的DevSecOps工具应该能够“打开”任何容器和扫描几个层，并与所有包寻找包含漏洞的依赖关系。这只能通过与二进制文件回购和工件管理工具的强大集成来实现。
扫描解决方案只与驱动它的漏洞数据一样好!无论是云计算还是自托管，你都不能在只包含市场报道的部分信息的数据库上妥协。DevOps平台应该始终努力领先于任何黑客和黑客保护从构建到生产的管道中的所有软件包。
- - -云计算CI / CD- - -
能够集中和简化所有流程的大规模工具是现代的必需品。管理每个项目和创建岛DevOps管道自动化会让团队效率低下和沮丧。
传统上，应用程序开发团队负责创建本地化的CI/CD自动化。这种方法为单个团队提供了短期收益，但最终会成为长期的约束，因为企业在其CI/CD实现中没有获得规模经济。
随着企业转向异构的现代架构、更小的部署单元、快速发布周期和多云拓扑，这种情况会进一步扩大。在这个美丽的新世界中，为每个部署单元构建特别的、定制脚本的管道并不是一种可伸缩的方法，并且会导致创建和维护成本高昂的自动化，这最终会成为更改的障碍。
一个现代的CI/CD提供商应该支持和扩展企业范围的工作流(又名“软件供应链”)，这些工作流跨越了当今所有流行的技术和架构，并跟上技术发展的步伐。它应该提供一种从预先包装好的积木(比如乐高积木)组装管道的方法，而不是从头开始开发。这些管道可以被模板化，并作为库在整个组织中共享，从而构建一个不断增长和改进的知识库。换句话说，您的CI/CD提供商应该在云中为您提供规模经济，并帮助您更快地交付代码。
比较基于云的端到端DevOps解决方案
现在有无数的工具可供从业者使用，选择最好的工具可能是一个反复试验的过程，如果您不做功课，就会花费太多的时间和精力。JFrog目前在AWS、Azure和GCP上提供云产品(并与之合作)，这可以使您灵活地专注于您的端到端DevOps管道。下面，您将发现“单独使用”某些解决方案如何使您的目标受到挑战或不完整的细节，而完全集成的云方法可能更完全地满足您的需求。
让我们来看看当今市场上最流行或最熟悉的选择，并将它们与什么进行比较JFrog在做什么．剧透:我们将在未来几周分别深入研究这些解决方案。
- - -JFrog vs GitHub- - -
来自微软的GitHub提供了一个端到端的解决方案，包括源代码、(一些)包管理和CI/CD管道——这些被称为GitHub动作。GitHub在SaaS方面比其自托管安装(GitHub Enterprise)更强大。除了支持自托管运行程序外，GitHub Packages和GitHub Actions目前只能作为SaaS提供，它们的自动安全更新功能也是如此。然而，动作和包只提供基本的API支持，它们的CLI仍处于测试阶段。
从存储库管理的角度来看，Github不是一个通用的解决方案，它只支持6种包类型(JFrog平台支持25种以上)，没有全局搜索功能，也不支持虚拟/远程回购。它们的安全功能仍处于萌芽阶段，不提供对工件和容器映像漏洞的深度递归扫描，不解决许可证遵从性问题，也不配置安全策略来触发不同的操作。
最后，GitHub的CI/CD解决方案不支持管道可视化，源代码存储库和管道配置之间的紧密耦合使得管道在企业和跨团队/应用程序协作和共享中的扩展变得困难。缺乏Docker层缓存或CI节点的自动伸缩，进一步使云原生交付更慢、更麻烦。
GitHub在源代码管理、OSS团队协作和小团队方面似乎最强，而其覆盖交付范围的企业功能仍在兴起。
- - -JFrog vs Azure DevOps- - -
Azure DevOps套件也由微软提供，提供了端到端的解决方案——从源代码(Azure Repos)到工件管理(Azure Artifacts)再到CI/CD (Azure pipeline)。还有Azure板，用于计划和跟踪团队内的工作，以及Azure测试计划，这是一个测试解决方案。
从一个构件管理Azure DevOps仅支持四种二进制或包类型，并且不提供用于扫描的持续安全解决方案软件漏洞或者违反许可证规定。
Azure DevOps为每个Azure订阅提供免费服务，或为OSS项目提供最多10个并行作业。虽然Azure pipeline可能是微软仅在Azure云上进行标准化的明显选择，但它对关注供应商锁定或(正确地)准备支持未来多云和混合环境的组织提出了挑战。
微软缺乏对混合环境的支持，on-prem/self-managed版本缺少SaaS版本的许多核心特性。自我管理版本不需要经常维护。
- - -JFrog vs AWS & JFrog vs GCP- - -
AWS和GCP通常被视为高质量的基础设施和市场提供商，它们提供一些与DevOps相关的服务和工具，但它们的解决方案并不打算提供开箱即用的集成或完整的DevOps平台。相反，主流云倾向于提供部署前的“最后一站”，而不倾向于在Devops周期中提供服务。虽然一些点解决方案，如简单的容器注册表和非常基本的CI/CD工具是可用的，但缺乏(或有限的)混合选项，有限或缺少软件包支持，可能的单一提供商锁定问题，缺乏企业级的内置DevSecOps或安全解决方案，缺乏扩展元数据和缺乏软件分发解决方案，使大多数企业在寻找全范围提供商时犹豫不决。
值得注意的是，AWS和GCP都不向开发人员提供包管理器(目前两者都只提供简单的包管理器)容器注册不支持Helm或通用、虚拟或远程存储库功能)，更不用说通用包支持了。2022年世界杯预选赛赛程表一个通用的，混合的，生态系统集成的包管理器，具有先进的复制功能和全球分发功能，是当今DevOps商店的必备工具，因为公司都在寻找容器，Kubernetes和整个工件生命周期的管理。因此，他们会发现这些主要供应商在许多领域都存在不足。
在核心层面上，主要云提供商的DevOps解决方案关注于与他们提供的通用服务(消息传递、数据库、API网关、存储等)的集成，以推动这些服务的更多使用。因此，这些服务在本质上大多是通用的，许多任务都留给了用户(关于工作流、元数据和可见性等)，以实现从代码到生产的真正的端到端管道。这种焦点的缺乏也可能影响所提供的成熟度和质量DevOps的工具，通常都停留在非常基本的层面。
从根本上说，AWS和GCP似乎都没有提供端到端的DevOps解决方案或编排和管道管理工具。这使得许多公司依赖于第三方或拥有自己的工具缺口——对于许多企业来说，这是一个不可扩展的解决方案。
大多数情况下，我们看到公司利用云提供商和JFrog等公司之间的合作关系提供端到端解决方案——通常是通过云市场。
- - -JFrog vs GitLab- - -
GitLab主要以GIT解决方案而不是DevOps平台而闻名，它提供的SaaS产品仅限于单个地区的单个提供商(GCP)。因此，虽然技术上可行，但企业可能很难采用这种有限的产品。也没有明显的SLA保证，导致任何企业都缺乏确定性。GitLab安全产品也处于起步阶段(尽管有所改进)，这给企业寻找针对关键任务工作负载的健壮解决方案留下了一个问号。此外，拥有多种SCM工具是非常普遍的，GitLab可能会限制使用各种源代码控制工具的企业的范围。随着GitLab解决方案迁移到云端，多个租户共享一个数据库资源，这就导致了可能的扩展和/或性能问题。
GitLab的优势主要是内部部署，云计算选项非常有限。虽然是一个坚实的平台，但GitLab在企业云可伸缩性、混合功能、SLA保证和SCM兼容性方面存在不足。
此外，GitLab不支持开发人员所需的许多包类型，这可能需要进一步的工具来支持不同的项目。这不是一个小缺点，而是满足了最重要的企业需求之一——同时大规模支持无数语言、系统、合作伙伴和技术类型的需求。当查看GitLab的演示时，虽然他们提供了一个基本的包管理器，但他们承认JFrog是包管理领域的领导者。作为任何DevOps管道的核心，像JFrog Artifactory这样的包/二进制管理器是关键技术，它允许公司实现企业规模、定制和自动化，并有效地满足最苛刻的sla。在全球范围内，许多公司需要支持高效复制、多种缓存选项、多种存储库类型(本地、虚拟和远程)、丰富且可查询的元数据等的混合多云工具。如果没有这个健壮的工件管理器作为关键部分，大多数企业将发现GitLab的产品无法满足企业工作负载。
此外，GitLab的平台增强策略似乎依赖于外部资源，即使是主要的功能更新。这可能会导致核心团队之外的人员增加，这些人可能没有长期的平台路线图、愿景或企业规模。
此外，GitLab产品体系结构本身依赖于单个服务器。该服务器必须支持在系统需求上有很大差异的DevOps工具，例如I/O和数据库负载、请求缓存和吞吐量、处理能力、可用性等。
将I/ o密集型、高请求率、零停机服务(如企业二进制管理器)与报告/数据显示为主的服务(如问题管理、wiki、代码审查和请求跟踪)混合在一起，通常会导致复杂的规模和性能问题，因为这些服务争夺相同的资源。2022世界杯阿根廷预选赛赛程
最后，SaaS缺少多云功能可能是希望跨云扩展或避免任何提供商锁定的企业所关注的问题。
那现在怎么办?
我们相信DevOps云解决方案真的应该拥有一切——在所有的云上，并应用于每个开发人员的环境。无论开发人员身在何处，都需要这种高水平的灵活性和健壮性。但这是JFrog的博客，所以这些事实都是基于我们自己的研究。我们欢迎您就这一主题提出意见和想法。
