Simplifying the developer experience for cloud-native developers is quite a hype topic. While there are products competing with NubesGen, we think our Philosophy behind leads us to a better product than most of the other solutions.
# Adapting to your needs
We don’t want to create a solution just for .NET developers, or Java developers. You should be able to use PostgreSQL with .NET or Azure SQL with Java. That’s why we’re not creating a templates repository, but a code generator. NubesGen already supports more than 15 000 unique configurations combinations.
# The best defaults for your needs
We know Azure, we know your framework and we even know undocumented settings. We want to put all our experience in NubesGen, so you have the best out-of-the-box experience possible. Sometimes, the Azure Product groups needs to make a choice about default values. Most of the times, they’ll choose the best common denominator across all languages, or all frameworks in a specific language. We can be more precise than Azure defaults, and thus give you a better experience.
# Your framework, your project, your rules
NubesGen is not an all-in-one generator. We will never be better than start.spring.io (opens new window) to generate Java Spring projects, we can’t be as versatile as
dotnet new. So, we do not want to generate actual code.
Our mission is to simplify the experience from code to production. Infrastructure as Code, Testing, CD/CI pipelines and developer experience tools are our sweet spot.
# No future regrets
While NubesGen is mostly targeting new cloud developers, we don’t want to spark regrets in the future because you used NubesGen in one of your projects. We have managed years-long IT projects, we’ve been here 😊. We are designing the code generated by NubesGen to be as flexible, modular and open as possible. For example:
- All Infrastructure as Code generation is using modules for composition.
- All GitHub Actions composite actions depends only on inputs and outputs, so you can replace them in the future if needed.