了解为什么基础架构作为代码难以解决,而无代码低码是未来

Infrastructure-as-code (IaC) is a very well known and popular technology for cloud infrastructure provisioning using principles of application development i.e. writing code (a programming language). While IaC is emulating application development, the technology has several limitations in the way it is built and works. These make the operationalization of IaC at scale to be challenging. In this blog we will discuss the following:

基于代码的基础架构(IaC)是一种使用应用程序开发原理(即编写代码(一种编程语言))进行云基础架构配置的众所周知的流行技术。 当IaC模拟应用程序开发时,该技术在其构建和工作方式方面存在一些限制。 这些使IaC的大规模运营具有挑战性。 在此博客中,我们将讨论以下内容:

  1. Highlight the shortcomings of IaC as compared to the mainstream application development and its evolution.

    突出显示IaC与主流应用程序开发及其演进相比的缺点。
  2. Outline the changes that are needed to fix the issues and show how today’s IaC will evolve to a no-code or low-code pattern.

    概述解决问题所需的更改,并说明当今的IaC如何演变为无代码或低代码模式。
  3. Highlight an example implementation with DuploCloud of such a no-code/low-code implementation and show how it is eliminating 90% of the code that needs to be written as part of native terraform by using DuploCloud Terraform plugin (provider).

    突出显示一个使用DuploCloud的无代码/低代码实现示例,并说明如何使用DuploCloud Terraform插件(提供程序)消除需要作为本机Terraform一部分编写的90%的代码。

IaC与应用程序代码 (IaC vs. Application Code)

Although people describe IaC as writing code for infrastructure, there are some fundamental differences between the two. Let us explain how:

尽管人们将IaC描述为编写基础结构的代码,但两者之间存在一些根本的区别。 让我们解释一下:

  1. Missing application centric abstractions.

    缺少以应用程序为中心的抽象。

Over decades, in mainstream programming we have evolved from basic imperative programming in C language to object oriented (C++) to managed code (Java/.NET) to interpreted languages (Python) and now No-Code/Low Code (AWS Honeycode). With each evolution new abstractions are added. IaC on the other hand hasn’t seen the same enhancements as it evolved from Bash/Powershell to Chef/Puppet to Terraform/Ansible in the last 20 years.

数十年来,在主流编程中,我们已经从C语言的基本命令式编程发展到面向对象(C ++)到托管代码(Java / .NET)到解释语言(Python)以及现在的无代码/低代码(AWS Honeycode)。 每次演变都会添加新的抽象。 另一方面,IaC在过去20年中没有看到从Bash / Powershell到Chef / Puppet到Terraform / Ansible的增强。

Image for post
vs
Image for post
Evolution of Mainstream Application development vs the Evolution of IaC
主流应用程序开发的演进与IaC的演进

The key abstractions IaC (Terraform for example) provides are modules, providers and state management. Loosely speaking, modules are like a function with input and output parameters while providers are cloud API connectors. These are still very primitive abstractions as compared to what you can do in a programming language. There is no notion of application, microservice or a security standard that you could specify in the code. Cloud resources are exposed as-is to the DevOps engineers who now have to explicitly specify each and every resource in fine-grained detail. This leads to large code bases to create even basic deployments. Let’s take a look in the context of a network topology in AWS:

IaC(例如Terraform)提供的关键抽象是模块,提供程序和状态管理。 松散地说,模块就像具有输入和输出参数的函数,而提供程序是云API连接器。 与您可以使用编程语言进行的操作相比,这些仍然是非常原始的抽象。 您没有在代码中指定的应用程序,微服务或安全标准的概念。 云资源按原样公开给DevOps工程师,他们现在必须明确地详细指定每个资源。 这导致大量代码库甚至可以创建基本部署。 让我们看一下AWS中的网络拓扑:

Practical Example: Every new account needs to setup a network topology in AWS. We create a VPC with a given CIDR, with the subnets split into the desired number of Availability zones. Each AZ should have one private and one public subnet. Deploy a NAT gateway in each Availability Zone for outbound traffic from the private subnets.

实际示例:每个新帐户都需要在AWS中设置网络拓扑。 我们使用给定的CIDR创建一个VPC,并将子网划分为所需数量的“可用性”区域。 每个可用区应具有一个专用子网和一个公用子网。 在每个可用区中部署NAT网关,以接收来自专用子网的出站流量。

While a programmer would expect a one line function call like CreateInfrastructure(string Region, string CIDR, int AzCount) But, today what we need to do is write 1,000 lines of code!!

虽然程序员希望像CreateInfrastructure(string Region,string CIDR,int AzCount)这样的一行函数调用但是今天,我们需要做的是编写1000行代码!

See these cloud formation templates to do the same https://github.com/widdix/aws-cf-templates/blob/master/vpc/vpc-2azs.yaml

请参阅这些云形成模板以执行相同的https://github.com/widdix/aws-cf-templates/blob/master/vpc/vpc-2azs.yaml

https://github.com/widdix/aws-cf-templates/blob/master/vpc/vpc-nat-gateway.yaml

https://github.com/widdix/aws-cf-templates/blob/master/vpc/vpc-nat-gateway.yam l

Enhancements like Terragrunt are a step in the right direction, but still this large amount of code can be error-prone and more importantly, makes changes harder.

Terragrunt等增强功能是朝正确方向迈出的一步,但仍然 大量的代码容易出错,更重要的是,使更改变得更加困难。

2. IaC neither provides built in best practices nor allows the user to add them!!We may want to write a custom function that would perform a set of best practice validations before creation of a Virtual Machine or a network compliance checker library that can be invoked to validate all security group rules. None of this is possible in IaC.

2. IaC既不提供内置的最佳实践,也不允许用户添加它们! 我们可能想编写一个自定义函数,该函数将在创建虚拟机或网络遵从性检查程序库之前执行一组最佳实践验证,这些虚拟机可以被调用以验证所有安全组规则。 在IaC中,这都是不可能的。

IaC does not have user defined functions like a normal programming language

IaC没有像普通编程语言一样的用户定义功能

For the 2020 Cloud Threat Report released by Palo Alto Networks, it was identified that around 200,000 potential vulnerabilities in existing Infrastructure-as-code templates [https://en.wikipedia.org/wiki/Infrastructure_as_code]. To fix this problem, customers run governance tools on top of provisioned infrastructure or static analysis on IaC to catch these issues (See Cloud Custodian and Turbot) to make sure that the certain controls are met.

对于Palo Alto Networks发布的2020年云威胁报告,发现现有的基础架构即代码模板[ https://en.wikipedia.org/wiki/Infrastructure_as_code ]中存在大约200,000个潜在漏洞。 为了解决此问题,客户可以在预配置的基础架构之上运行治理工具,或者在IaC上运行静态分析以捕获这些问题(请参阅Cloud CustodianTurbot ),以确保满足某些控制要求。

3. IaC is not an orchestrator: Infrastructure is not a one time build but rather a continuous operation. Every time a small change needs to be added, one needs to go through a lot of existing code, send a code review request, handle comments, test code and finally make the change. Making changes in IaC is akin to going to your database and changing the specific rows and columns and knowing exactly what to change. In order to build a fully automated infrastructure, multiple functionalities and tools have to be stitched together. Figure 2 shows an example taxonomy of DevOps functions on AWS that need to be orchestrated.

3. IaC并非协调者:基础架构不是一次性构建,而是持续运行。 每次需要添加少量更改时,都需要遍历大量现有代码,发送代码审阅请求,处理注释,测试代码并最终进行更改。 在IaC中进行更改类似于转到数据库并更改特定的行和列,并确切知道要更改的内容。 为了构建完全自动化的基础架构,必须将多种功能和工具结合在一起。 图2显示了需要编排的AWS上DevOps函数的示例分类。

Image for post
Figure 2: Taxonomy of DevSecOps functions in AWS Cloud
图2:AWS Cloud中的DevSecOps功能分类

Imagine the amount of code a human has to write to build a working solution that implements this taxonomy using a language like IaC which does not even have basic abstractions and a notion of user defined functions

想象一下,人们必须编写大量代码才能构建使用IaC之类的语言来实现此分类法的可行解决方案,该语言甚至没有基本抽象和用户定义功能的概念

Hence, beyond a programming language like IaC, one needs a long running platform that remembers the complete context of a system and allows incremental changes. Today, in most organizations, DevOps engineers form this orchestration/platform layer.

因此,除了像IaC这样的编程语言之外,人们还需要一个长期运行的平台,该平台能够记住系统的完整上下文并允许进行增量更改。 如今,在大多数组织中,DevOps工程师形成了业务流程/平台层。

4. Hard to find both development and ops skill in the same person: IaC has created this a unique skill set requirement which is a combination of programming and operations. It aims to combine the developer role and operations role into a single individual. The fact is that a large majority of IT teams do not have a programming background and it is hard to learn. The developers on the other hand can write code but they seldom understand the building blocks of an infrastructure like a VPC, VNET, Access Policy and so on. We ultimately end up in a situation where either the infrastructure is not secure or the code is complex with a lot of repetition and lack of modular structure.

4.很难在同一个人中同时找到开发和运维技能 :IaC创造了一项独特的技能要求,即编程和操作相结合。 它旨在将开发人员角色和运营角色合并为一个人。 事实是,大多数IT团队都没有编程背景,很难学习。 另一方面,开发人员可以编写代码,但他们很少了解VPC,VNET,访问策略等基础结构的构建块。 我们最终会遇到以下情况:要么基础架构不安全,要么代码很复杂,重复很多,缺乏模块化结构。

如何增强IaC (How To Enhance IaC)

Now that we have seen some of the limitations of IaC, let’s look into how to fix some of these for basic automation use cases. We can’t fundamentally change IaC to become a full fledged language, so we will discuss solutions that can work with and around IaC.

现在,我们已经了解了IaC的一些局限性,下面让我们研究如何针对基本的自动化用例修复其中的一些局限性。 我们无法从根本上将IaC更改为完整的语言,因此我们将讨论可与IaC一起使用的解决方案。

  1. Adding Application Centric Abstractions: We need an abstraction or a policy model that appeals to the most broad set of use cases, is not overly restrictive and is extensible to the rapidly evolving cloud services, security landscape and consumer needs. We take inspiration from two most popular policy models:

    添加以应用程序为中心的抽象:我们需要一种抽象或策略模型,以吸引最广泛的用例集,并没有过度的限制,并且可以扩展到快速发展的云服务,安全格局和消费者需求。 我们从两种最受欢迎​​的政策模型中汲取了灵感:

  • Infrastructure-as-a-service (a.k.a cloud): Cloud brought us constructs like Virtual Networks for example which abstracted away the nuances of VRFs, VLANs, and routing protocols. Similarly EBS volumes abstracted away nuances of storage arrays and NAS boxes. The concept of micro-segmentation using security groups that could be applied to Virtual Machines hides nuances of port ACLS.

    基础架构即服务(又名云):例如,云为我们带来了诸如虚拟网络之类的结构,该结构抽象了VRF,VLAN和路由协议之间的细微差别。 同样,EBS卷也消除了存储阵列和NAS盒的细微差别。 使用可应用于虚拟机的安全组进行微分段的概念掩盖了端口ACLS的细微差别。

  • Kubernetes: Here we were introduced to application level abstractions like deployment set and ingress controllers which hid underneath the details of load balancers, service discovery, service healing and high availability.

    Kubernetes:在这里,我们向您介绍了应用程序级抽象,例如部署集和入口控制器,它们隐藏在负载均衡器,服务发现,服务修复和高可用性的详细信息中。

One of the abstraction that makes a lot of sense in cloud is either a notion of a project or a tenant, which represents a group of resources that work together to represent a group of micro-services and are handled by a single team. Another one can be a set of rules or policies that should always be met during deployment.

在云中有意义的抽象之一是项目概念或租户,租户代表一组资源,这些资源一起代表一组微服务,并由一个团队来处理。 另一个可以是在部署期间应始终满足的一组规则或策略。

2. Automated Code Generation: Since IaC is simply a declarative infrastructure description, there is no reason why a lot of low level code can’t be auto-generated using a higher level intent or application blueprint as input. The inputs can be:

2.自动化代码生成:由于IaC只是声明性的基础结构描述,因此没有理由不能使用更高级别的意图或应用程序蓝图作为输入来自动生成很多低级代码。 输入可以是:

  • Application blueprint that shows the list of resources or even services that need to work together

    应用程序蓝图显示需要协同工作的资源或服务列表
  • Compliance controls that needs to be met like PCI, HIPAA, SOC2

    PCI,HIPAA和SOC2等需要满足的合规性控制

Based on these inputs, one should be able to auto-generate low level IaC.

基于这些输入,人们应该能够自动生成低电平IaC。

3. Add Orchestrator Bot: IaC cannot do active orchestration or lifecycle management of resources. To support these use cases, we need to add an orchestration layer that executes the final changes required in the infrastructure layer and constantly drives the system to goal state. Imagine an intelligent bot that can implicitly stitch together the various DevOps functions from building a network infrastructure, provisioning of resources, deployment of application, setting up logging, monitoring and alerting and providing a CI/CD framework. All compliance controls would be implicitly built into the workflow.

3.添加Orchestrator Bot: IaC无法对资源进行主动编排或生命周期管理。 为了支持这些用例,我们需要添加一个业务流程层,以执行基础结构层所需的最终更改并不断将系统驱动到目标状态。 想象一下一个智能机器人,它可以将各种DevOps功能隐式地组合在一起,这些功能包括构建网络基础架构,资源配置,应用程序部署,设置日志记录,监视和警报以及提供CI / CD框架。 所有合规性控制都将隐式内置到工作流中。

3. Adding Developers Self-service with guardrails: Developers want to focus on building applications and know what basic infrastructure components they need. IT wants to focus on operations and security and control the changes made at the infrastructure level. Since one can auto-generate code, we should be able to provide high level controls to developers where they can go and ask for resources like VMs, load balancers without risking any security controls. Since developers don’t want to write Terraform code and understand security, a no-code approach can satisfy the use case for both developers and DevOps teams. For Developers, the bot provides no-code self-service and secure infrastructure setup, while for the operators it provides a no-code/low-code interface to auto-program automation stack based on their guidelines and company policies.

3.为开发人员添加带有护栏的自助服务:开发人员希望专注于构建应用程序,并知道他们需要哪些基本基础架构组件。 IT部门希望专注于运营和安全性,并控制在基础架构级别进行的更改。 由于可以自动生成代码,因此我们应该能够为开发人员提供高级控制,使他们可以去那里寻求VM,负载均衡器之类的资源,而不会冒任何安全控制的风险。 由于开发人员不想编写Terraform代码并了解安全性,因此无代码方法可以满足开发人员和DevOps团队的用例。 该机器人为开发人员提供了无代码自助服务和安全的基础架构设置,而为运营商提供了无代码/低代码界面,可根据他们的准则和公司政策为自动编程自动化堆栈提供服务。

DuploCloud无代码自动化平台 (DuploCloud No-Code Automation Platform)

At DuploCloud we have built a no-code automation platform that fixes some of the limitations of IaC while auto-generating the low level IaC output for teams that need them. It is an orchestrator that receives application requirements as high level specifications and creates underlying infrastructure automatically while meeting all guidelines of the well architected framework and desired compliance standard. The platform implements all the functions outlined in Figure 2 and handles all compliance controls out-of-box. Lower level infrastructure-as-code is auto-generated.

在DuploCloud,我们建立了一个无代码自动化平台,该平台可解决IaC的某些局限性,同时为需要它们的团队自动生成低级IaC输出。 它是一个协调器,可接收应用程序要求作为高级别规范,并自动创建底层基础结构,同时满足精心设计的框架的所有准则和所需的合规性标准。 该平台实现了图2中概述的所有功能,并开箱即用地处理了所有合规性控制。 自动生成较低级别的基础结构即代码。

“Using the UI one can take the no-code approach to build complex infrastructures, for larger setups DuploCloud’s terraform provider provides the higher level abstractions that reduce manual code by over 90%. “

“使用UI可以采用无代码方法来构建复杂的基础架构,对于较大的设置,DuploCloud的terraform提供程序提供了更高级别的抽象,可将手动代码减少90%以上。

You can watch out the demo video below to see an example of building a complex infrastructure using DuploCloud that would have otherwise taken tens of thousands of lines of IAC.

您可以观看下面的演示视频,以观看使用DuploCloud构建复杂基础架构的示例,否则将花费数万行IAC。

结论 (Conclusion)

  1. Infrastructure as code technologies like Terraform, CloudFormation for building infrastructure automation have a very specific and limited use case.

    基础架构作为用于构建基础架构自动化的代码技术(例如Terraform,CloudFormation)具有非常特定且有限的用例。
  2. IaC is not really equivalent to writing code as we know in case of application development. Many key abstractions and capabilities are missing in these technologies to really manage any infrastructure at scale.

    在应用程序开发的情况下,IaC并不真正等同于编写代码。 这些技术缺少许多关键的抽象和功能,无法真正大规模地管理任何基础架构。
  3. Building a modern day cloud infrastructure using terraform is like building a complex web application using C language. As the public cloud continues to evolve at a rapid pace with hundreds of new services added each year and companies adopt cloud with hundreds of running workloads, the current automation techniques don’t scale.

    使用terraform构建现代云基础架构就像使用C语言构建复杂的Web应用程序一样。 随着公有云的持续快速发展,每年增加数百种新服务,并且公司采用具有数百种正在运行的工作负载的云,当前的自动化技术无法扩展。

The only way to build and manage secure infrastructure with agility is to add a layer of orchestration on top and using that to provision and change infrastructure resources. This layer needs to understand the high level intent and policies that need to be met.

构建和管理具有敏捷性的安全基础架构的唯一方法是在业务流程之上添加业务流程层,并使用它来配置和更改基础架构资源。 该层需要了解高层意图和需要满足的策略。

Ultimately, we are going to move to no-code or low-code approaches to handle the scale and policy requirements. This is a change we are seeing for regular application development also and IaC is even more primitive when it comes to doing complex tasks and orchestration.

最终,我们将转向无代码或低代码方法来处理规模和策略要求。 对于常规应用程序开发,这也是我们所看到的变化,而在执行复杂任务和业务流程时,IaC甚至更为原始。

As we have seen in many other technologies, it is not a question of “IF” but “HOW FAST” will people adopt it!

正如我们在许多其他技术中所看到的那样,这不是“ IF”的问题,而是“ HOW FAST”会被人们采用!

翻译自: https://medium.com/@duplocloud/understanding-why-infrastructure-as-code-struggles-at-scale-and-nocode-lowcode-is-the-future-42ce45a10795

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
©️2021 CSDN 皮肤主题: 深蓝海洋 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值