You can certainly roll your own setup and get the minimal functionality _you_ need. Thats the general "build vs buy" question.
Dokku itself comes with a ton of functionality and is actively developed separate from your app. It's been built for thoughtful extensibility (one person in this story mentioned adding TCP/UDP support in a day, as an example) so if it doesn't do what you want, you can add it. We also provide a "curated" experience that handles things based on years of working on other deployment tools (and not just simply cloning the Heroku CLI and experience, though it has had a very deep influence). If our workflow and experience are what you want, its there today.
With something you build/maintain, the system is often simpler. Maybe one or two tools with a couple hundred lines of code, all fairly grokable. If you need to extend it, you know exactly where and can do so. In fact, thats how a lot of Dokku alternatives come out - someone didn't like our codebase or setup and decided to write something else[1]. Building your own deployment stack is often how most companies start - roll your own against tooling that is close-by or familiar.
The unfortunate thing is you now own that experience, so if you need functionality, you need to build it, which can be distracting from your actual business goals (unless you're a deployment tooling company, in which case this totally makes sense!). Would you rather spend 10 hours working on a feature for your customers or hacking together a version of review apps? If this is for your own home cluster, maybe that makes sense, but even then, I'd assume most people _should_ just want to deploy their app and move on vs work on that tooling.
All that said, if Minikube + Ingress and a few yaml templates work for you, go to town. Feel free to try us out if you want a more curated experience :)
- [1] Piku is an example where they wanted ARM support and we didn't have it yet, while the Caprover developer wanted something that works with Swarm.
I’m curious to know how your experience with Optaplanner has been. As I understand you model your problems quite differently and it is more of a search for a good enough solution using metaheuristics?
I think Optaplanner has its own DSL, but we use the Java/JVM API: a 'solution' is just a normal JVM object, which references other objects in the usual way. Certain fields are annotated, which tells Optaplanner that it can mutate/alter them.
Implementing the domain objects is pretty natural. The only part that feels weird is that solving is completely based around mutation; whilst that's pretty idiomatic for Java, it feels a bit alien in Scala (I previously worked mostly in Haskell, and haven't written Java in over a decade).
There's a bunch of configuration boilerplate; including the following, which is the only Java code in the whole project (and almost looks like a parody of "Enterprise Java"!):
class Config {
public static ScoreDirectorFactoryConfig config =
(new ScoreDirectorFactoryConfig())
.withEasyScoreCalculatorClass(ScoreCalculator.class);
}
IIRC, this had to be Java due to some weird self-referential interface that makes Scala's type-checker explode.
We can give each solution both a "hard" score and a "soft" score, where the soft score will be sacrificed if it improves the hard score. We use the hard score to count errors which make a solution invalid (e.g. trying to assign two people to the same seat); and the soft score as a weighted sum of mismatched seat attributes (e.g. it would be nice to stay facing the same direction; but not crucial).
Once the problem has been defined, it can be sent to a bunch of solvers; we use simulated annealing with a timeout. Since it's an anytime-algorithm, we can adjust the timeout to however long we're prepared to wait.
To avoid "obvious" problems in Optaplanner's results, we send them through a simple hill-climbing loop to ensure we're at a local maximum.
Obviously not? Just because France doesn't buy natural gas themselves, they import so much electricity based on natural gas from its neighbors. So they are defacto dependent on natural gas as they can't supply electricity enough with nuclear and are thus in such much much worse energy political situation as prices will continue to surge.
This is what I found "In 2020, France exported a total of nearly 78 terawatt hours of electricity. Meanwhile, electricity imports to France amounted to nearly 35 terawatt hours in total that year."
nuclear is only useful for base load you cant shutdown a reactor in hours, thats why france imports a lot of gas (the same goes for germany, its the fastest way to scale energy, burn more gas, its even easier than with coal.)
France is by far the leader when it comes to the fraction of electricity produced by nuclear reactors; however it never ever could phase out fossil fuels, nor could or can do it at a realistic cost.
