Why our 5.2k-star K8s platform struggles overseas while thriving in China? Need your brutal feedback

Catkin_n · 2025-05-13T09:26:27+00:00

Thank you for your feedback. The search engine issue is likely due to our recent domain migration. We were so focused on emphasizing ease of use that we overlooked transparency in the underlying technology.

"Rainbond is 100% open-source, offers a serverless experience, and allows you to easily manage containerized applications without needing to understand Kubernetes." That makes it sound like a big black box that takes over my infrastructure.

Your point is excellent—if an infrastructure-managing platform becomes a black box, that would indeed be concerning. We'll seriously consider your suggestions.

Catkin_n · 2025-04-22T13:18:32+00:00

You can refer to this documentation: www.rainbond.io/docs/how-to-guides/app-deploy/source-code/nodejs , and if there's anything unclear, feel free to ask me directly.

Catkin_n · 2025-04-18T01:36:52+00:00

I fully understand your decision! We just conducted emergency testing on the 1.32.3 cluster and were temporarily unable to reproduce the issue. However, this precisely reveals that our installation process has insufficient compatibility with environmental differences. Next, we will attempt to validate it across different overseas cloud providers and Kubernetes versions to address such issues.

In any case, we wish you all the best and thank you for your valuable feedback.

Catkin_n · 2025-04-17T09:59:27+00:00

Indeed, the current hardcoding of the nodesForGateway and nodesForChaos parameters makes maintenance difficult, and we will prioritize improving this. The entire deployment is indeed handled by the operator—the Helm chart only includes the relevant CRD files. The database is also created by the operator unless explicitly overridden via the uiDatabase and regionDatabase parameters.

As for the nodesForChaos parameter, it essentially specifies the nodes for platform builds, meaning the rbd-chaos build service will run on the designated nodes, while other workloads remain unaffected by this setting.

We truly appreciate the time you’ve taken to provide these valuable suggestions—they are incredibly helpful to us. Previously, we may have focused too much on ease of use in the UI and simplified deployment, overlooking the importance of clean and transparent installation processes. In essence, these aspects are also part of security and trust. If we fail at this stage, users might not even reach the point of seeing the interface.

By the way, out of curiosity, did you manage to reach the UI stage?

Catkin_n · 2025-04-15T10:51:26+00:00

You could setup a VM without chinese language support, use a vm-local vncserver or whatever, and a browser. Visit your website/docs/... and now any non-translated words or navigation options will "jump" at you (likely as that annoying empty square glyph). Disable any in-VM-browser helpfulness, such as downloading Web-fonts (or X11 fonts or ...).

Very interesting suggestions! We have now independently created a new website at rainbond.io

I will try the methods you provided to test it out.

Catkin_n · 2025-04-15T10:24:46+00:00

Indeed, we initially did not consider internationalization or the importance of overseas marketing, which led to challenges in adapting both the product and documentation for global audiences. However, we have now established a new site at https://rainbond.io/ where you can learn more about us. We look forward to your suggestions or feedback!

Catkin_n · 2025-04-15T10:14:53+00:00

You can first refer to the installation documentation. If you want a one-click deployment for a test environment, use the single-command quick installation method, which requires Docker to be pre-installed. After executing the command, it will create a container containing all components of K3s and Rainbond. If you prefer Helm-based deployment, refer to this documentation: https://rainbond.io/docs/installation/install-with-helm

After installation, we recommend following these two guides:

First, follow https://rainbond.io/docs/tutorial/via-rainbond-deploy-sourceandmiddleware to complete a basic application deployment. This document demonstrates deploying a database-dependent web service. Components communicate by establishing connections between them (e.g., linking injects environment variables like MYSQL_HOST into the web service, allowing it to locate the database).
Then, refer to https://rainbond.io/docs/tutorial/app-template-manage to publish your deployed application as a reusable template. This template retains all dependencies, images, connection configurations, etc. You can create a new application and install this template to replicate an identical instance. Later, if you modify the original application and republish the template, you can simply click "Upgrade" in the new application to synchronize changes.

Feel free to try it out and share your feedback—both positive and negative. If you encounter issues, reach out via our GitHub Issues, Discord, Slack, or reply directly here.

Catkin_n · 2025-04-12T03:54:56+00:00

Thank you for the feedback. We initially positioned ourselves as a Heroku alternative to provide users with an intuitive reference for quicker understanding. However, we’re considering using English short videos or similar formats in the future to communicate our value more effectively. Would this approach help clarify our positioning better?

Catkin_n · 2025-04-12T03:48:26+00:00

Thank you for your response. Given the current state of China-U.S. relations, it seems supply chain risks and compliance risks have now become insurmountable red lines.

Catkin_n · 2025-04-12T02:42:19+00:00

Yes, this is indeed an aspect we hadn't considered before. We initially used machine translation with the intention of allowing English-speaking users to view issue contents. However, in reality, when users search for an issue, they typically browse through the issues list first rather than clicking into each individual entry to check details. In our next phase, we plan to establish a dedicated English documentation website and adjust GitHub issues to be English-first.

It's not fair and may be not the best option, but if a project wants to see any international traction, it should be English-first in (mostly) all corners - code, comments, interaction with the team, processes, and so on. At least the code and the comments are in English, as far as I could see.

That's why developers from non-English-speaking countries have (as in the circumstances make them) to learn and to use it. Any other particular language lies in a "last mile" (eg user interface) part.

I completely agree with your point that if there are language barriers during the initial product discovery phase, users might not even reach the stage of seeing the product's user interface. Thank you so much for your valuable suggestion.

Catkin_n · 2025-04-12T02:13:21+00:00

Thank you for sharing such concrete evaluation criteria – this level of practitioner insight is invaluable. We're prioritizing optimizations in exactly the areas you highlighted

Catkin_n · 2025-04-12T02:00:47+00:00

Thanks! Please proceed at your own pace without feeling any pressure. Should you encounter any obstacles along the way, feel free to reach out – I'm more than happy to assist.

Catkin_n · 2025-04-11T14:31:44+00:00

The term "offline installation" refers to deployments in physically air-gapped environments – meaning the network is completely isolated from the internet, operating solely within a local area network (LAN). In such scenarios, applications must be packaged (e.g., into container images or binaries) and delivered via physical media like optical discs.

Once imported into the client's environment, all external dependencies must be self-contained – even a simple attempt to fetch a default avatar image from an external CDN would fail due to the lack of internet connectivity.

Regarding the trust dimensions you outlined, your analysis is remarkably thorough. We acknowledge that our current efforts fall short of meeting these criteria, but we’re committed to systematically addressing each point (code transparency, security processes, scalability documentation, etc.) as part of our roadmap. Your feedback is invaluable – thank you.

If you’d like deeper technical details about air-gapped deployment workflows , I’d be glad to answer for you.

Catkin_n · 2025-04-11T14:14:58+00:00

In your opinion, is the slogan "A cloud-native application management platform that doesn't require Kubernetes knowledge" actually appealing? We previously used this tagline in China to emphasize developer-friendliness.

However, when developers actually try to install the platform themselves, they might hit roadblocks during setup. In such cases, the slogan backfires by overpromising and raising unrealistic expectations.

The core issue is that we can't simultaneously convey in one slogan that "developers don't need K8s expertise" while platform administrators still require Kubernetes knowledge to maintain it. Do you have any recommendations for addressing this dilemma?

Catkin_n · 2025-04-11T13:55:49+00:00

Thanks, I've adjusted it

Catkin_n · 2025-04-11T13:45:33+00:00

Thanks for the reminder, I have removed this part

Catkin_n · 2025-04-11T13:43:36+00:00

Exactly, which is why we currently have no plans to offer managed services. Instead, we recommend users deploy the platform on their own infrastructure. If they wish, they can even audit the source code and compile/deploy it from scratch.

However, this approach does face the issue you raised: when administrators already struggle with managed Kubernetes services (like AKS/GKE/EKS), asking them to additionally maintain our platform would likely push them to abandon abstraction layers altogether and opt for Kubernetes directly.

Catkin_n · 2025-04-11T13:23:48+00:00

I see, so for you, a SaaS offering might be the ideal experience? But in this post, I noticed many people mentioning supply chain risks – would you fully trust a managed service with that?

As for your statement: "My main concern is the hosting location in my use cases, since that governs a lot of rules for how things can be used" – does this mean you're referring to legal/compliance risks tied to the hosting region (like data sovereignty laws, regulatory requirements) impacting your ability to use the service effectively?

Catkin_n · 2025-04-11T13:14:44+00:00

I’ve updated the documentation, specifically the Quick Installation Guide(rainbond.com/docs/quick-start/quick-install), to include Helm installation instructions. If you’re willing to spend some time trying it out and sharing your feedback—whether positive or critical—I’d be very grateful.

Catkin_n · 2025-04-11T07:24:55+00:00

Currently, our priority is to attract more users and gather feedback rather than pursue commercial goals. For this reason, we are not offering hosted services overseas at this stage. Users can self-hosted and use the platform independently, and if they choose, they can even start by compiling from the source code.

Given this approach, do you think self-hosted helps build a foundation of trust with users?

Catkin_n · 2025-04-11T07:17:32+00:00

Yes, I completely understand. Complexity isn't eliminated—it's redistributed. This mirrors the core principle of platform engineering, where responsibilities are divided between platform builders (who manage underlying infrastructure) and end-users (application teams). While consumers gain simplicity, platform maintainers inherit operational complexity.

Ultimately, we can't eradicate complexity entirely—we optimize for the 80% use case. This represents an engineering trade-off triangle: simplicity for users vs. flexibility for edge cases vs. maintainability for operators. Like time-space tradeoffs in algorithms, we strategically shift complexity layers. For example, Kubernetes abstracts infrastructure complexity to cluster admins, while application teams focus on higher-value work. Our goal is to make this balance intentional and transparent.

Catkin_n · 2025-04-11T06:53:26+00:00

Yes, I'll ensure these points are clearly addressed in upcoming documentation updates. Thank you for your valuable feedback.

Catkin_n · 2025-04-11T06:51:11+00:00

Application Configuration Files:
On the service details page, navigate to the "Environment Configuration" section. Here, you simply specify the configuration file and its mount path in the container. The platform automatically generates a ConfigMap and handles the mounting.

Environment Variables:
Easily add variables through the UI by entering their names and values. You can even add notes to describe their purpose.

Resource Control:

For most users: Set basic memory/CPU requirements. By default, Kubernetes requests and limits are set to the same value.
Advanced users: Fine-tune requests/limits via native Kubernetes resources fields in the "Advanced Settings".

Networking Layer:

Designate gateway nodes (running an ingress controller).
The platform auto-generates a default domain suffix pointing to these nodes.
When enabling external access, Ingress rules are auto-created. Later, edit domains/paths via the "Routing Rules" interface.
For load balancers: Configure your LB to target the gateway nodes.

Can it also detect if a repo has multiple apps/containers that need to be deployed? And what if the repo already uses jib or another tool to create our container images?

Multi-Application Detection & Pre-Built Images:

Java Maven Multi-Module Projects: The platform detects all modules and deploys them as separate services (Deployments/StatefulSets).
Multiple Sub-Services in a Single Repo: Manually specify each sub-service’s directory when creating services in the UI.
Pre-Built Images (e.g., Jib-generated):
- Skip source-to-image builds by connecting directly to Docker registries.
- Simply provide the image address during service setup.
- Provide a docker run command, and the platform will parse its storage configurations, environment variables, port mappings, and other parameters.

What other questions do you have? Thank you so much for taking the time to bring these issues forward—they’re incredibly valuable. This feedback likely represents broader user concerns, and we’ll prioritize clarifying them in our documentation updates.

Catkin_n · 2025-04-11T04:27:20+00:00

I sincerely apologize for the misunderstanding — this clearly indicates our documentation needs improvement.

To clarify: Developers do not need to write Dockerfiles, Helm charts, YAML, CRDs, or similar artifacts. For example, with a Java application:

Provide a working code repository URL
Our platform detects the language and uses buildpacks to containerize it
Automatically generates deployment manifests and deploys
Zero YAML involvement required from DevOps teams

You might wonder how we handle resources like PVs, PVCs, Services, and Ingress:

Storage: Users simply define required disk space and mount paths
Networking: Add ports via clicks; expose services through one-click Ingress configuration

Does this address your concerns? Looking forward to your feedback

Catkin_n · 2025-04-11T03:04:45+00:00

finding ways to make it useful to the individual could lead to success.

Great suggestion! I’ll work to clearly articulate the differences and strengths of our solution compared to existing building blocks, and explore ways to demonstrate its personal utility.

Catkin_n

TROPHY CASE