How Midway Serverless Enables Seamless Multi‑Cloud Application Migration

Overview

Midway Serverless v1.0 has been released, and many users have tried it and provided feedback. The project is open‑source on GitHub and invites stars.

Anti‑corruption Layer

Midway Serverless adds a special anti‑corruption layer that allows the same code to run on different platforms, providing runtime adaptation. This layer is now available not only for functions but also for traditional applications, enabling rapid migration to cloud platforms and taking advantage of elastic containers.

Usage Example

Using a traditional EggJS application as an example, adding a f.yml file at the project root and running f deploy publishes the app.

service: my-egg-demo  # name of the application when published to cloud platform

provider:
  name: aliyun        # cloud platform, e.g., aliyun, tencent, etc.

deployType: egg       # type of deployed application

The process is simple, and the underlying runtime adaptation is the same as for functions, achieving a single codebase that works across multiple platforms.

Difference from Platform‑Specific Migration Solutions

Since version 1.1, Midway Serverless offers a migration solution to serverless containers that is cross‑platform, unlike platform‑specific solutions such as Alibaba Cloud’s customRuntime or Tencent Cloud components.

It shares the same cross‑platform approach as the function part, requiring little or no code modification.

It reuses the runtime adaptation capabilities of functions, which are open‑source and easy to debug or extend.

The solution is generic and can be easily adapted to private deployments or other application frameworks.

Limitations

Platform gateway restrictions (timeout, POST size, file upload) remain the same as for functions.

Large application packages should use platform‑specific storage solutions (e.g., Alibaba Cloud NAS, Tencent/AWS Layers).

Stateful parts inside the function container must be handled by the application itself.

The container runs in a single‑process model; stability relies on the elastic container.

Long‑running or scheduled tasks won’t trigger without traffic and need alternative solutions.

Non‑HTTP protocols such as sockets are not supported.

Conclusion

After the function system is released, the focus returns to integrating functions and applications so that each can play its strongest role in different scenarios.