en: refine homepage tagline, and fix link typo (KusionStack#137)

refine homepage tagline, and fix link typo

blog/2022-09-16-learn-from-scale-practice/index.md

@@ -1,5 +1,5 @@
 ---
-slug: 2022-lean-from-scale-practice
+slug: 2022-learn-from-scale-practice
 title: What We Learned From Large-scale Platform Engineering Practices
 authors:
   name: Xiaodong, Duo
@@ -16,7 +16,7 @@ This blog is based on the platform engineering and automation practice of [Kusio
 
 The concept of DevOps was proposed more than 10 years ago. From KVM to container to the cloud-native era, a large number of enterprises have invested in the DevOps wave to solve the dilemma of internal large-scale operation efficiency and platform construction efficiency. Most of them have fallen into some kind of Anti-Pattern based on an inappropriate understanding of DevOps, while some companies have explored their golden paths. I have experienced Anti-Patterns as shown in the figure below, where the Dev and Ops teams go their separate ways, or simply force the Dev team to handle Ops work independently. More typical classifications can be found [here](https://web.devopstopologies.com/#anti-types).
 
-![](/img/blog/2022-09-16-lean-from-scale-practice/devops-anti-pattern.png)
+![](/img/blog/2022-09-16-learn-from-scale-practice/devops-anti-pattern.png)
 
 There are various reasons for difficulties achieving DevOps at scale within the enterprise, especially for companies that maintain their infrastructure within the enterprise while adopting technology platforms on the cloud. Among which, the following situations are quite common:
 
@@ -37,7 +37,7 @@ Unlike small teams working on cloud-hosted Infra services and DevOps-as-a-Servic
 
 In fact, not everyone should be or could be an expert in this specific field, which turns out to be particularly hard as well. Even the experts from the platform technology team themselves are usually good at their own professional fields, especially nowadays confronting the wide adoption of cloud-native concepts and technologies, hundreds of thousands of application configurations brought by a large number of highly open and configurable platform technologies and the business complexity of the PaaS field as well as the requirements for high stability and unified governance. The purpose of platform engineering just lies in allowing application developers to participate in such large-scale DevOps work as easily and painlessly as possible. In Ant Group's practice, we tend to the following cooperative state, which is closer to Google's best practices in team structure and work mode. Platform developers and SREs become "Enablers" to support application developers to complete dev, delivery and operation in self-service. At the same time, the work results of application developers making applications deliverable and operational also become the basis for the ops team to handle application ops work. The SRE, application dev, and ops team periodically feedback the problems and pain points in the work process to the platform dev team to form a positive cycle.
 
-![](/img/blog/2022-09-16-lean-from-scale-practice/devops-cycle.png)
+![](/img/blog/2022-09-16-learn-from-scale-practice/devops-cycle.png)
 
 
 ## 2. Domain Language: A Pole of the Engineering Thought
@@ -46,14 +46,14 @@ Compared with a domain language there's no better way for open, self-service, do
 
 In the platform engineering practice of Ant Group, we have strengthened the client-side working mode. We write and maintain the models, orchestration, constraints and policies around the application ops life cycle in the shared codebase [Konfig](https://github.com/KusionStack/konfig) through the record and functional language [KCL](https://github.com/KusionStack/KCLVM). KCL is a static and strongly typed language for application developers with programming ability, and provides the writing experience of a modern high-level language with limited functionality around domain purposes. Under such practices, KCL is not a language just for writing K-V pairs, but a language for platform engineering development. Application developers, SREs, and platform developers conduct dev collaboratively based on Konfig. They write configurations, and [schema](https://kusionstack.io/docs/reference/lang/lang/tour/#schema) abstractions, [functions](https://kusionstack.io/docs/reference/lang/lang/tour/#function), [constraints](https://kusionstack.io/docs/reference/lang/lang/tour/#validation) and [rules](https://kusionstack.io/docs/reference/lang/lang/tour/#rule) which are frequent and complex in the PaaS field through KCL native functions, that is, writing stable and scalable business models, business logic, error-proofing constraints, and environmental rules. The Konfig repository becomes a unified programming interface, workspace and business layer, while the KCL-oriented writing paradigm, which is secure and consistent, with low noise, low side effect and easy to automate, are more beneficial for long-term management and governance.
 
-![](/img/blog/2022-09-16-lean-from-scale-practice/kcl-dev.png)
+![](/img/blog/2022-09-16-learn-from-scale-practice/kcl-dev.png)
 
 
 ## 3. Divide and Conquer: Deconstructing the Scaling Problem
 
 The idea of ​​divide and conquer is the key to solving the scaling problem, whose efficiency is reflected from MapReduce to Kubernetes. In the field of large-scale delivery and operation, the classic operation platform tries to use the built-in unified model, orchestration, and provision technology in a black-box product to deal with full-scale business scenarios. Such a practice can be started easily and quickly and turns out to be effective on a small scale. However, as the adoption rate of different business groups increases and different requirements are put forward, it gradually enters into a state of fatigue with the constantly growing platform technology.
 
-![](/img/blog/2022-09-16-lean-from-scale-practice/classic-plats.png)
+![](/img/blog/2022-09-16-learn-from-scale-practice/classic-plats.png)
 
 In Ant Group's practice, Konfig monorepo is the programming workspace opened by the internal engineering platform to developers, helping application developers to write configurations and policies around the application operation life cycle with a unified programming interface and tech stack, to integrate with existing and future platform and infrastructure, to create and manage cloud-native environments and RBAC-based permissions on demand, and to manage the delivery workflow through GitOps. Konfig monorepo provides an independent white-box programming space for different scenarios, projects and applications, whose intrinsic scalability comes from:
 
@@ -67,7 +67,7 @@ Konfig monorepo provides divide-and-conquer, composable engineering structure de
 
 The following figure illustrates a typical automated workflow with a Gitops approach in the Konfig monorepo, starting from application-oriented code changes and reaching the runtime through configurable CI and CD processes. Compared to centralized black-box products, this mechanism is much more open, customizable and extensible, through which there’s no more necessity of designing clumsy configuration management portals for different business scenarios, projects, and applications.
 
-![image.png](/img/blog/2022-09-16-lean-from-scale-practice/d-c-overview.png)
+![image.png](/img/blog/2022-09-16-learn-from-scale-practice/d-c-overview.png)
 
 
 ## 4. Modeling: Marginal Revenue and the Long Tail

i18n/en/code.json

@@ -271,7 +271,7 @@
     "message": "KusionStack"
   },
   "homepage.tagline": {
-    "message": "Programmable configuration technology stack"
+    "message": "A Unified Programmable Configuration Tech Stack"
   },
   "homepage.feature.kcl": {
     "message": "KCL"

i18n/zh-CN/docusaurus-plugin-content-blog/2022-09-16-learn-from-scale-practice/index.md

@@ -1,5 +1,5 @@
 ---
-slug: 2022-lean-from-scale-practice
+slug: 2022-learn-from-scale-practice
 title: 从规模化平台工程实践，我们学到了什么
 authors:
   name: 朵晓东
@@ -16,7 +16,7 @@ tags: [KusionStack, Kusion]
 
 DevOps 理念在 10 多年前被提出，从 KVM 到容器再到云原生时代，大量企业投入 DevOps 运动以期望解决内部规模化运维效率和平台建设效率的困境。其中大部分陷入过某种基于对 DevOps 朴素认知的 Anti-Pattern，同时也有部分公司探索出自己的路径。我经历过如下图简示的 Anti-Patterns，Dev 与 Ops 团队各行其是，或者简单的强制 Dev 团队独立完成 Ops 工作。在[这里](https://web.devopstopologies.com/#anti-types)可以找到更多更典型分类。
 
-![](/img/blog/2022-09-16-lean-from-scale-practice/devops-anti-pattern.png)
+![](/img/blog/2022-09-16-learn-from-scale-practice/devops-anti-pattern.png)
 
 企业内规模化 DevOps 难以推行的原因多种多样，特别是在企业内自持基础设施、同时采用云上技术平台的公司阻力最大。其中以这几种情况尤为常见：
 
@@ -37,7 +37,7 @@ DevOps 理念在 10 多年前被提出，从 KVM 到容器再到云原生时代
 
 事实上，不是所有人都应该或者能够成为这个领域的专家，这非常困难！实际上平台技术团队的专家通常也仅擅长自己的专业领域而已，特别是在云原生理念和技术广泛应用的今天，面向大量高度开放、可配置的平台技术带来的成百上千的应用配置，PaaS 领域的业务复杂性，以及高稳定性和统一治理的要求，而平台工程的目的正是为了让应用研发者尽可能简单无痛的参与到这样规模化的 DevOps 工作中。在蚂蚁的实践中，我们更趋向于以下这种合作状态，在团队架构和工作模式上更靠近 Google 的最佳实践。平台研发者及 SRE 成为 “Enabler” 支持应用研发者自服务的完成研发及交付运维，同时应用研发者使其应用可交付运维的工作结果也成为运维人员可以接手应用运维工作的基础。最终 SRE、应用研发及运维人员把工作过程中的问题和痛点反馈给平台研发者形成正向循环。
 
-![](/img/blog/2022-09-16-lean-from-scale-practice/devops-cycle.png)
+![](/img/blog/2022-09-16-learn-from-scale-practice/devops-cycle.png)
 
 
 ## 2. 专用语言：工程化方式的一极
@@ -46,14 +46,14 @@ DevOps 理念在 10 多年前被提出，从 KVM 到容器再到云原生时代
 
 在蚂蚁的平台工程实践中，我们强化了客户端的工作方式，将围绕应用运维生命周期的模型、编排、约束和策略稳定、可扩展的通过专用语言  [KCL](https://github.com/KusionStack/KCLVM)  编写维护在共享仓库 [Konfig](https://github.com/KusionStack/konfig) 中。 KCL 是一种面向有编程能力的应用研发者的静态强类型语言，提供现代高级语言的编写体验和围绕领域目的有限功能。在平台工程实践中 KCL 不是一种仅用于编写 K-V 对的语言，而是一种面向平台工程领域的专用语言。应用研发者、SRE、平台研发者面向 Konfig 协同研发，通过 KCL 原生功能编写应用配置，以及在 PaaS 领域更为高频和复杂的[模型](https://kusionstack.io/docs/reference/lang/lang/tour/#schema)抽象、[功能函数](https://kusionstack.io/docs/reference/lang/lang/tour/#function)和[约束](https://kusionstack.io/docs/reference/lang/lang/tour/#validation)[规则](https://kusionstack.io/docs/reference/lang/lang/tour/#rule)，即编写稳定、可扩展的业务模型、业务逻辑、防错约束和环境规则。Konfig 仓库则成为统一的编程界面，工作空间和业务层载体，而基于 KCL 的安全、低噪音、低副作用、一致的编写范式更有利于长期管理和治理。
 
-![](/img/blog/2022-09-16-lean-from-scale-practice/kcl-dev.png)
+![](/img/blog/2022-09-16-learn-from-scale-practice/kcl-dev.png)
 
 
 ## 3. 分治：解构规模化问题
 
 分治思路是解决规模化问题的钥匙，从 MapReduce 到 Kubernetes 无不体现其功效。在规模化交付运维领域，经典运维平台试图在统一的黑盒平台产品中，以内置的统一模型、编排、provision 技术来应对全量业务场景。这样的实践可以快速启动，在小范围内奏效，但随着不同业务主体采用率提升引入差异化需求，同时随着持续变化的平台技术逐渐进入疲态。
 
-![](/img/blog/2022-09-16-lean-from-scale-practice/classic-plats.png)
+![](/img/blog/2022-09-16-learn-from-scale-practice/classic-plats.png)
 
 在蚂蚁的实践中，Konfig  monorepo 是内部工程平台向研发者开放的编程界面和工作空间，帮助应用研发者以统一的编程界面编写围绕应用运维生命周期的配置和策略，从而编排和使用存量和新增的平台基础设施，按需创建管理云原生环境以及基于 RBAC 的权限，并通过 GitOps 方式管理交付过程。Konfig monorepo 为不同场景、项目、应用提供了独立的白盒的编程空间，其内生的扩展性来源于：
 
@@ -67,7 +67,7 @@ Konfig monorepo 提供了分治的、可组合的工程结构设计、代码组
 
 下图示意了一种 Konfig  monorepo 中 GitOps 方式的典型的自动化工作流程，从面向应用的代码变更开始，通过可配置的 CI、CD 过程触达运行时，这样的机制相比中心化的黑盒产品方式更加开放、可定制、可扩展，也免去了针对不同业务场景、不同项目、应用设计笨拙的配置文件管理 portal 的必要。
 
-![](/img/blog/2022-09-16-lean-from-scale-practice/d-c-overview.png)
+![](/img/blog/2022-09-16-learn-from-scale-practice/d-c-overview.png)
 
 
 ## 4. 建模：边际收益和长尾问题