awesome-paas VS e2core

Hey there. Firstly, Congratulations on the progress. From the screenshot, I can tell you the UI/UX is great. I have been maintaining Awesome PaaS [1]. Overtime, I have started feeling this space has become commoditised. Because of containers, kubernetes etc. this has been an explosion in the number of tools in the space, however in your case, because of the django/python niche you might have something. In my opinion, very few early stage apps fit into PaaS model, most of the orgs have so much customization that it hard to fit them into your platform. I guess with Django as framework specialization this won't be a problem. Goodluck, with your endeavours.

[1] https://github.com/debarshibasak/awesome-paas

There's been a number of these projects out there. I think the biggest part developers misunderstand when building these is that your target audience either knows AWS enough to build all of this with Terraform / CDK, or they don't know enough about AWS to know which tool they need to use to get done and they use something like Elastic Beanstalk or Amplify. Unfortunately the market for something in the middle is almost non-existent.

You will literally be joining a market that's already over saturated with "Deploy your apps 100x faster/easier/better/safer/secure" platforms. Here's a running list of ones that exist: https://github.com/debarshibasak/awesome-paas

My argument is that most of the small business and startups struggle to make revenue from get go. Asking for revshare, when it is day-0/day-1 kind of situation can hit the startups, small business, individuals really hard.

To me the your model looks very close to a royalty structure. Which is bad on books if you have seen "Shark Tank". It can be a fun place to host apps for indie hackers.

Another argument is that, Major cloud providers give away a lot of credits for various services. It can go upto $100k. I would even argue that you don't need devops or specialized team from you are a small org, startup and your operations are small.

Anyways, Looks like a fun project would love to list you on my Awesome Paas[1] list.

[1] https://github.com/debarshibasak/awesome-paas

> If one writes Go or Rust, there are much better ways to run them than targeting WASM

wasm has its place, especially for contained workloads that can be wrapped in its strict capability boundaries (think, file-encoding jobs that shouldn't access anything else but said files: https://news.ycombinator.com/item?id=29112713).

> Containers are still the defacto standard.

wasmedge [0], atmo [1], krustlet [2], blueboat [3] and numerous other projects are turning up the heat [4]!

[0] https://github.com/WasmEdge/WasmEdge

[1] https://github.com/suborbital/atmo

[2] https://github.com/krustlet/krustlet

[3] https://github.com/losfair/blueboat

[4] https://news.ycombinator.com/item?id=30155295

One of the first things we've used it for internally is to run one-off isolated tests on WebAssembly modules instead of feeding them through a production Atmo[0] instance. It basically serves as a dumb pipe for feeding data in and out of a Wasm module.

0: https://github.com/suborbital/atmo

Excited to see Atmo on there 🙂 https://github.com/suborbital/atmo

My open source focus for this year is building Atmo, and there is one aspect of the process that I would like to highlight. Since early 2020 I knew roughly what I wanted to build. The specifics of that thing changed over time, but the core idea of a server-side WebAssembly platform was consistent all throughout the year. I didn't write a single line of code for Atmo until late October, even though that was what I wanted to build the entire time. I want to talk about why.

I am also open to any and all contributions from the community. I am more than happy to meet with anyone interested in working alongside me to build these capabilities so that I can help get you started developing Atmo, Vektor, Grav, Hive, and Subo. Developers with no experience working with WebAssembly, distributed systems, web services, or Go are encouraged to join and I will do whatever I can to help you learn what's needed to contribute. Open Source is not just about developing in the open, it's also about helping others learn.

With SUFA systems, multiple ASGs are created, each designated as a capability group. Each capability group is given access to the resources required for the associated function namespace to operate (such as the datastore or secrets), and can then scale independently of one another. Since the application's functions are decoupled entirely from one another, it's possible for some functions to run on the host that receives the request, and functions from particular namespaces to be meshed into other capability groups. A SUFA framework such as Atmo is responsible for handling the meshed communication, completely absorbing the complexity.

The SUFA pattern was designed in concert with Atmo, which is an all-in-one framework upon which SUFA systems can be built. Atmo uses a file known as a 'Directive' to describe all aspects of your application, including how to chain functions to handle requests. You can write your functions using several languages to be run atop Atmo, as it is built to use WebAssembly modules as the unit of compute. Atmo will automatically scale out to handle your application load, and includes all sorts of tooling and built-in best practices to ensure you're getting the best performance and security without needing to write a single line of boilerplate ever again.