AI X Serverless X Programming Language

[jianzs]

Goals

Using a unified programming interface and workspace to unify abstract applications and infrastructure, further abstracting this programming interface through natural language through AI to combine application backend and infrastructure code to quickly build and deliver cloud applications.

The project name maybe

• fly-lang/fly
• air-lang/air
• ark-lang/ark

Pain Points

• Infrastructure such as cloud and Kubernetes is becoming increasingly complex, and existing IaC tools such as terraform, cdk, help, etc. cannot and require a more advanced abstraction. Developers inevitably fall into a fragmented process between application and IaC.
• Even existing Serverless products such as AWS Lambda require developers to handle these processes. For example, when executing code within AWS Lambda functions, I must understand that the required dependencies are bundled together, uploaded as a zip file to S3 and deployed through Terraform (or manually uploaded, which is very boring and container error prone).
• The same applies to Kubernetes Serverless products such as Knative. Not only do I need to understand the installation and use of Knative, but I also need to install the MySQL database on K8s myself and hardcode it into my code. When I was developing, Knative was unable to provide me with assistance, which required me to maintain two databases and ensure that when I went online, I used the prod database. Moreover, to understand the more specific operation of the product, it is necessary to deploy components such as Grafana, Prometheus, Fluent bit, and enable them to coordinate their work. I would like to switch to the MySQL service provided by Alibaba Cloud in the future, and I also need to modify my source code and republish it.
• Existing next-generation IaC tools such as Winglang or Infra from Code technology either lean towards IaC, making it difficult to write code that meets the requirements due to fragmented programming experiences, or write Infra through annotation configuration. In fact, application development users should not have cared about these things, they should simply import cloud APIs to implement their functions. When I build professional software, I want most of my time to be spent within the functional domain of my application, instead of non-functional mechanics of the platform I use.
• Pain Points of Application Runtime e.g., Layotto, it may lose terraform/pulumi integration. Layotto项目规划和展望 mosn/layotto#976

User Story

As a developer, I just want to develop and complete my application (usually some server applications or FaaS functions) without installation, understanding and writing IaC, or even understanding infrastructure concepts such as containers, or understanding and switching complex environments or permissions. Everything that follows can be handed over to automation. I only see my application work and easily complete observable tasks such as log and metric. For example, as the developer of kcl playground, every time I develop an upgraded version of kcl playground and create a Docker image, I always have to click on the platform or write terraform code to automatically send it. These things are boring and I don't want to do them and I don't want to learn docker and terraform/pulumi.

Overview

• One Infra and App Config Abstraction including APIs e.g. storage, function etc.
  • Infra: Multi-Cloud and Kubernetes Abstraction
  • Solving App Dependency on Infra by Combining Abstract Methods
• Deploy-less and No configuration Code
  • There are no infra related configuration codes in the user interface, and we need to use intermediate generation to hide them.
• API Registry
  • Through centralized management of APIs, one is to reduce the cost of API production and consumption, and the other is to use fine-tuning data as AI generation models.

Features

Design

Engine

Workflow

API

Roadmap

• 2023.08: Make a decision: POC idea and big direction set, name
• 2023.09: Top level design confirmation and PoC start: Expect to provide developers with programming interface and engine layer capabilities, selling points, problem solving, targeted users, boundaries, scenarios, etc. can be determined, and specific synchronization solutions and coding implementation can start
• 2023.10: Feasibility verification: feasible for a scenario/workload
• 2023.11: PoC improvement: Horizontal expansion and iteration of some capabilities based on PoC, laying the groundwork for some scenarios in December
• 2023.12: Horizontal Scenario Improvement: Prepare some materials, find partners and potential users to provide feedback, prepare for open source, and set goals for the next 24 years

Reference

• What is the biggest pain point of a DevOps engineer? https://www.reddit.com/r/devops/comments/1606cd1/what_is_the_biggest_pain_point_of_a_devops/
• Winglang: https://www.winglang.io/
• Darklang: https://darklang.com/
• Vercel: https://vercel.com/
• fly.io: https://fly.io/
• Backstage: https://backstage.io/
• Laf: https://github.com/labring/laf
• Shuttle: https://www.shuttle.rs/
• Pulumi: https://www.pulumi.com/
• Terraform: https://www.terraform.io/
• Terraform CDK: https://developer.hashicorp.com/terraform/cdktf
• Crossplane: https://www.crossplane.io/
• AWS CDK: https://aws.amazon.com/cn/cdk/
• Layotto: https://mosn.io/layotto/#/
• Dapr: https://dapr.io/
• Knative: https://knative.dev/docs/
• System Initiative: https://www.systeminit.com/
• IDX: AI Based Web Dev Workspace by Google: https://idx.dev/
• AMPT: https://getampt.com/
• Nitric: https://nitric.io/
• JSII: https://github.com/aws/jsii
• Infrastructure from code: https://www.infoq.com/news/2023/02/infrastructure-code-cloud-manage/#:~:text=Infrastructure%2Dfrom%2DCode%20(IfC,source%20code%2C%20without%20explicit%20description.
• Rethinking IaC: https://nathanpeck.com/rethinking-infrastructure-as-code-from-scratch/
• Layotto Pain Points: Layotto项目规划和展望 mosn/layotto#976