项目管理渐进明细和范围蔓延_云蔓延的兴起，必然性和危险

项目管理渐进明细和范围蔓延

First, what is cloud sprawl?

首先，什么是云计算蔓延？

Cloud sprawl is the lack of controls against the expansion of an organization’s cloud instances, services or providers.

云蔓延是缺乏针对组织的云实例，服务或提供程序扩展的控制措施。

有什么危险？ (What are the dangers?)

While instances and services are managed differently than providers, the lack of effective controls on any of these is a cause of concern for organizations.

尽管实例和服务的管理方式与提供者的管理方式不同，但是对于其中的任何一种缺乏有效控制的问题引起组织的关注。

A lack of visibility and control around the volume and types of instances and services offered by a Cloud Service Provider (CSP) is dangerous from a cost perspective as any unnecessary or untracked usage that is not contained can pose a serious financial burden. In addition to the financial aspect, if an organization is using a variety of different services and instance configurations that also may lack the knowledge or controls to ensure that all of these resources are being used safely and effectively.

从成本的角度来看，对云服务提供商(CSP)提供的实例和服务的数量和类型缺乏可视性和控制力是很危险的，因为未包含的任何不必要或未经跟踪的使用都可能造成严重的财务负担。 除财务方面外，如果组织正在使用各种不同的服务和实例配置，这些服务和实例配置也可能缺乏知识或控制手段，无法确保安全有效地使用所有这些资源。

On the other side, cloud sprawl as it concerns providers can be even more difficult to manage. This can take the form of sprawl across a number of CSPs, a large number of accounts within a single CSP, the usage of unsanctioned CSPs, or unsanctioned accounts for an allowed CSP within an organization. We often refer to the last cases as Shadow IT. Shadow IT assets often represent a risk to organizations by their nature of being unknown unknowns.

另一方面，由于云蔓延到供应商，可能变得更加难以管理。 这可以采取散布在多个CSP，单个CSP内的大量帐户，未批准的CSP使用或组织内允许的CSP的未批准帐户的形式。 我们通常将最后一种情况称为Shadow IT。 影子IT资产通常是未知的性质，因此对组织构成风险。

为什么会有Cloud Sprawl？ (Why do we have Cloud Sprawl?)

There’s no single cause of cloud sprawl, but we can look at some of the most common contributing factors.

没有云蔓延的单一原因，但是我们可以看看一些最常见的促成因素。

The first factor, and perhaps the most unavoidable, is Mergers and Acquisitions (M&A). If company A uses AWS and purchases company B, a GCP shop, company A now needs to align and put in place policies and management procedures for both AWS and GCP. This issue can be even more difficult if during the merger the IT and security teams for the acquisition are downsized or if the existing tooling in place only support a single CSP.

第一个因素，也许是最不可避免的因素是并购(M＆A)。 如果公司A使用AWS并购买了公司GCP的商店B，则公司A现在需要为AWS和GCP调整并制定策略和管理程序。 如果在合并过程中IT部门和安全团队的规模缩小了，或者现有的工具仅支持单个CSP，则此问题可能会更加困难。

Technology Leaders are another factor that contributes to cloud sprawl. I’ve worked for engineering leaders in the past who were dead-set on transitioning from one CSP to another for a wide variety of reasons ranging from product offerings, compliance purposes, or a perceived financial advantage (usually short-term credits). Luckily (and IMO rightfully) these leaders faced a lot of push back on these plans from others in the organization.

技术领导者是导致云蔓延的另一个因素。 过去，我曾为工程负责人工作，他们出于从产品提供，合规性目的或公认的财务优势(通常是短期信用)等多种原因而陷入从一个CSP过渡到另一个CSP的问题。 幸运的是(和国际海事组织是正确的)这些领导者在组织中的其他人面前面临着许多反对这些计划的压力。

Shifting priorities and diverse requirements are another reason we see cloud sprawl emerge. As a smaller company grows it may find the offering at a different CSP compelling enough that it will begin using multiple CSPs in tandem or begin shifting from one to the other. At a small scale this is manageable enough, but as the company continues to grow this can become untenable.

优先级的变化和需求的多样化是我们看到云蔓延的另一个原因。 随着小型公司的成长，它可能会发现采用另一种CSP的产品具有足够的吸引力，以至于它将开始同时使用多个CSP或开始从一种转移到另一种。 在较小的规模上这是可以管理的，但是随着公司的不断发展，这可能变得难以为继。

Similarly, if an organization has multiple business units with very different technical needs it is also possible that they will take divergent paths in regards to CSPs. Imagine a data science team running large ML jobs across massive data sets. They likely will use a vastly different tech stack and have different requirements than an engineering team primarily building web applications.

同样，如果一个组织有多个业务部门，而这些业务部门的技术需求相差甚远，那么他们在CSP方面也可能会走不同的道路。 想象一下，一个数据科学团队跨大量数据集运行大型ML作业。 与主要构建Web应用程序的工程团队相比，他们可能会使用截然不同的技术堆栈并有不同的要求。

Finally, the last reason for cloud sprawl is vendor lock-in. While on the engineering side, vendor lock-in is typically thought of as building a solution with a technology that is not readily available from other providers. Early on this was a very real concern, cloud providers did not have anything near parity in their product offerings. However, now, while the top 3 CSPs do have some differentiators, many of their services offer portability to different platforms.

最后，云蔓延的最后一个原因是供应商锁定。 在工程方面，通常将供应商锁定视为使用其他供应商不易获得的技术来构建解决方案。 早期，这是一个非常现实的问题，云提供商在产品上没有什么可比的。 但是，现在，尽管排名前三的CSP确实有一些区别，但它们的许多服务都提供了可移植到不同平台的能力。

For many organizations there are also different forms of vendor lock-in, such as data volume. For organizations with many petabytes of data, the costs of moving this data is an exorbitant barrier in its own right. Employee skills can be another form of vendor lock-in. Regardless of how tempting the offer, if you have to do a lot of new hiring and retraining of personnel it can make moving difficult.

对于许多组织来说，供应商锁定也有不同形式，例如数据量。 对于拥有数PB数据的组织而言，移动数据的成本本身就是一个巨大的障碍。 员工技能可以是供应商锁定的另一种形式。 无论提议多么诱人，如果您必须进行大量新的雇用和人员再培训，都可能使搬迁变得困难。

控制云蔓延 (Controlling Cloud Sprawl)

We’ve seen how there are factors that add to cloud sprawl and other that make cloud sprawl elimination difficult. But how can organizations control cloud sprawl?

我们已经看到了有哪些因素会增加云蔓延，而其他因素则使消除云蔓延变得困难。 但是组织如何控制云蔓延？

1. Bringing shadow IT into the light

   将影子IT带入光明

Using asset discovery vendors can help define the total attack surface for an organization including on-prem and cloud. Cloud findings can be broken down by provider and audited against a companies known cloud assets to determine their untracked assets or providers.

使用资产发现供应商可以帮助定义组织的整个攻击面，包括内部部署和云计算。 提供商可以分解云发现，并根据已知的云资产对公司进行审计，以确定其未跟踪的资产或提供商。

If you’re looking to uncover your organizations unknown unknowns, Expanse is an invaluable tool for doing so. While other discovery tools like Shodan do allow you to discover new assets that belong to an organization, they don’t allow you to systematically find all shadow IT and easily audit it against your known inventory.

如果您想发现组织中未知的未知数，那么Expanse是实现这一目标的宝贵工具。 尽管Shodan等其他发现工具确实允许您发现属于组织的新资产，但它们不允许您系统地查找所有影子IT并根据已知清单轻松对其进行审核。

2. Define cloud-agnostic policies and governance

2.定义与云无关的策略和治理

The key here is that as much as possible you should be tracking these as generally as possible, and ideally with a common tool set. Ensuring that there is equality for CSPs in your methodology will help to prevent gaps in coverage.

这里的关键是，您应该尽可能全面地追踪这些信息，理想情况下，应该使用通用工具集进行追踪。 确保您的方法中CSP的平等性将有助于防止覆盖范围的差距。

Tools such as Prisma Cloud from Palo Alto are a great option in this space because they integrate with multiple CSPs and allow easier management at a high level.

诸如Palo Alto的Prisma Cloud之类的工具在此领域是一个不错的选择，因为它们与多个CSP集成并且可以更轻松地进行高层管理。

AWS Watch Tower is another attempt to control cloud sprawl, though only for AWS users. AWS can be difficult to manage with multiple accounts because they are independent entities and don’t have common controls. AWS Watch Tower attempts to create multi-account environments for easier management.

AWS Watch Tower是控制云蔓延的另一种尝试，尽管仅适用于AWS用户。 使用多个帐户可能很难管理AWS，因为它们是独立的实体并且没有通用的控件。 AWS Watch Tower尝试创建多账户环境以简化管理。

In addition to policy and governance, having VM tools and monitoring tools that can integrate with many different CSPs is also useful for allowing a single Security team to stay lean and effective.

除了策略和治理外，拥有可以与许多不同的CSP集成的VM工具和监视工具对于允许单个安全团队保持精简和有效也很有用。

3. Attempt to utilize cloud-agnostic technologies

3.尝试利用与云无关的技术

To avoid the traditional vendor lock-in, organizations should attempt to leverage cloud agnostic capabilities as much as possible. Being cloud agnostic does not mean that developers within an organization should use any or even multiple CSPs, but rather it provides more freedom in the future to move to a different CSP if necessary (perhaps during an acquisition) with less pain.

为了避免传统的供应商锁定，组织应尝试尽可能利用云不可知的功能。 不可知云并不意味着组织内的开发人员应使用任何甚至多个CSP，而是在将来(如果有必要)(也许在收购期间)以更少的痛苦提供了更大的自由，可以迁移到其他CSP。

Leveraging tools such as Docker and Kubernetes and Fn can useful here. These tools are awesome for a variety a reasons, one of which is that they provide DevOps and engineering teams with the flexibility to deploy their applications in any hosting environment.

利用诸如Docker和Kubernetes和Fn之类的工具在这里很有用。 这些工具之所以出色，有多种原因，其中之一是，它们为DevOps和工程团队提供了在任何托管环境中部署其应用程序的灵活性。

4. Consciously avoid increasing sprawl

4.自觉避免蔓延

This point is clearly easier said than done — but generally if faced with a decision to expand your cloud footprint to a new provider or add a new account to an existing provider you should try to imagine the impact this decision could have a few years down the road in terms of governance.

这一点说起来容易做起来难，但做起来难。但是，通常，如果面临将云覆盖范围扩展到新提供商或向现有提供商添加新帐户的决定，您应该尝试想象一下此决定可能会在几年后产生的影响。在治理方面。

翻译自: https://medium.com/ochrona/the-rise-inevitability-and-dangers-of-cloud-sprawl-267281a9c55

项目管理渐进明细和范围蔓延