Original Article: "Laf Cloud Development Platform and Its Implementation Principles"
Platform Engineering Offline Meetup Beijing Station 2023-09-13
Laf is a cloud platform that I really like. Here is an offline sharing session about it, and I will give a brief introduction.
Summary of Product Features
Ready-to-use application resources, including computing resources, database resources, log network storage, and all other resources required by applications. No need to prepare any environment, including computer and physical environments.
The goal is to shorten the development process as much as possible and reduce the development threshold. If it takes a day to deploy an environment for an application, we may have already made a demo, put it online, and sent it to users or group members for testing.
Open source attitude. All source code of Laf is open source, and the components we use are also open source. It does not include any vendor bindings and can run on any cloud without any worries.
Technical Implementation Introduction
- Node programming language
- Storage selection: minIO, open source and horizontally scalable
- Database selection: MongoDB
- Gateway: apisix, seamless modification of dynamic routes, rich plugins, open source and open
- Development using IDE or CLI
- Create an application and connect to the Laf server
- Create an application instance through k8s, using the node runtime
- Allocate databases and storage
- Application creation and startup
User Traffic Workflow
- Call cloud functions or APIs
- Traffic goes to the gateway, which finds the appID and runtime
- Determine the function name, execute it, and return the response
Comparison of serverless implementation solutions
- One approach is to start a pod for each request for processing. Each time, it is a completely new environment. Scaling up and down is relatively simple, but cold start is more complicated, and it does not support long connections.
- Laf chooses a long connection memory solution, which has no cold start. The container always runs and naturally supports long connections. Scaling up and down is achieved through k8s's hpa, and the technical implementation of scaling up and down can be complex.
There are some details that I didn't understand because I haven't done them, so I won't mention them.
- Call the node vm module, process it into a script object, cache it in memory, and call the cloud function to get the script object from memory and execute it
- There is no compilation process
- When making an HTTP call, get the compiled result from memory, process the context, and execute the code
- When directly calling a cloud function, it will recognize whether it is a cloud function during the require process and handle it as a node_module
Object Storage Section
Use MinIO to store buckets and implement multi-tenant isolation with access policies
MongoDB itself has a user management mechanism, creating user permissions for isolation.
If there is a surge in traffic, will it affect the platform? For MongoDB traffic, it can be split and checked for request frequency limits. It can be discarded or billed based on database usage.
Use apifix to handle dynamic routes.
Cloud functions, applications, and storage buckets are all allocated through it with second-level domains.
Mainly analyzes problems through AI, understands document knowledge points, and writes code accordingly.
- Business code implementation
- Document usage issues
- Other issues
Other Future Capabilities
Introduce sealos to implement cloud resource invocation.
Other details are ignored.
🏠 Official Website Link
🐙 GitHub Address
📑 Visit Laf Documentation
🏘️ Visit the Forum
It provides a comprehensive introduction to the basic capabilities of Laf. As a user, many knowledge points are easy to understand.