Hi, former cofounder of Bitnami here. I left VMware quite a while ago, so not involved with this. The technical team at Bitnami is still top notch and great people. I am quite baffled at this business decision.
jauntywundrkind 203 days ago [-]
Is there a company more "Take what you can, give nothing back" than Broadcom? Probably not.
Broadcom's continued ability to perform well while only serving ever more upmarket areas, & cutting everyone else loose (& generally giving no figs) is fantastically impressive.
colechristensen 203 days ago [-]
Broadcom is just private equity buying products to bleed dry. Nobody thinks VMware is the future, but the folks that use it are enterprises with deep pockets who are slow and reluctant to change so you can multiply the price by big numbers and get paid big while your dying acquired product meets its end.
ghaff 203 days ago [-]
VMware's lock on enterprise virtualization simultaneously made it essentially impossible for anyone else to compete like-for-like using a different platform and probably also doomed VMware's attempt to start pivoting to containers.
snapplebobapple 202 days ago [-]
We were pretty successful moving to proxmox. They dont have the support some companies want but xcpng does. There are half decent options out there for corp use.
ghaff 202 days ago [-]
There are. I worked for a company that had a good KVM-based enterprise virtualization alternative with support. But they never had great commercial success with it displacing VMware. I understand they're having a lot more luck with a kubevirt-based option today post Broadcom acquisition of VMware.
snapplebobapple 202 days ago [-]
If you have the resources to deal with kubevirt (read you are large enough for the increased efficiency across larger installations to overcome the higher cost of kubernetes labor) it's pretty decent. There are a shocking number of sub 5 location places out there that just need 2 low end boxes to virtualize active directory, tenable or equivalent scanner and a few other things that should be choosing xcpng or maybe proxmox if they are doing the analysis rationally (lol).
sneak 203 days ago [-]
Oracle.
nine_k 203 days ago [-]
In fairness, Oracle keeps developing JVM and Java rather nicely, and keeps it open enough. I had expected worse.
okanat 202 days ago [-]
Java has a much stronger open source community with lots of corporate players. If Oracle tried to close the doors on it, everybody can pivot away in much shorter time than Vmware.
pjmlp 202 days ago [-]
Where were all those players when Google torpedoed Sun?
The large majority of work done in OpenJDK is by Oracle employees.
Had it been for most of those players, Java 6 would have been the last version.
okanat 201 days ago [-]
I don't exactly get what you mean by "Google torpedoed Sun".
Corporate players came into play after Oracle acquired Sun. The fear that Oracle would do the same as LibreOffice pushed players like IBM to have their own Java distributions.
Of course Oracle having more support for OpenJDK is not surprising. However, the open nature and existing players already make it easier to fork / replace Java compared to Vmware.
pjmlp 201 days ago [-]
Sun did not sue Google because they already lacked the money to do so.
What Google did with Android, it is hardly any different from Microsoft with J++, only that there the courts had another outcome.
Android with a Java subset and Kotlin, is hardly any different outcome than .NET with C#.
Corporate players came in, after money was available again, after the acquisition.
"James Gosling Triangulation's Interview on Google vs. Sun"
If Google actually cared about Java, they missed their opportunity to acquire Sun, own Java, do whatever they felt like doing with it for Android, and the rest of the industry, and best of all, they would never had to bother with any lawsuit.
Given how much the so called existing players contributed to save Java while Sun was going under, that is whishful thinking.
whoIsYou 203 days ago [-]
nobody familiar with broadcom or how they are run should be even remotely surprised by this decision
ridruejo 203 days ago [-]
It’s mostly that they don’t understand their own users and potential customers in this particular case of Bitnami. There are so many other ways to increase revenue without alienating the core developer base. Enterprise want stability, breaking changes is a poor way to convince someone to pay you.
stackskipton 203 days ago [-]
Is there other ways that are just as easy?
Last company was pretty heavy free user of Bitnami charts for various things but biggest being Redis clusters. I can't imagine they could convert everything into a cluster using their own charts before this kicks in. Very possible they end up tossing at least a year worth of licensing towards Bitnami.
ridruejo 203 days ago [-]
Yes. Whatever money you get with this is going to be small and short-lived. The big money is in compliance. That is a GTM problem, not a technical one.
burnt-resistor 203 days ago [-]
I was a service provider of Zimbra and had great relations with VMware folks on Page Mill many moons ago. One my friends helped move VMware HQs within PA just out of college.
Fuck Wall St. greedy morons at Broadcom. Hubris will educate them the hard way as they fade in relevance.
b112 203 days ago [-]
I take daily walks, and sometimes walk that campus. It always baffled me that it was bigger than my home town.
All gone now. Sad.
remram 203 days ago [-]
This announcement is a little hard to read. They make it seem that the current images under docker.io/bitnami/* get deleted on August 28? But individual chart READMEs seem to say that images will move during a period starting on August 28 and ending two weeks later? But looking at https://hub.docker.com/u/bitnamilegacy images have been copied already?
> Starting August 28th, over two weeks, all existing container images, including older or versioned tags (e.g., 2.50.0, 10.6), will be migrated from the public catalog (docker.io/bitnami) to the “Bitnami Legacy” repository (docker.io/bitnamilegacy), where they will no longer receive updates.
What are users expected to do exactly?
carrodher 203 days ago [-]
The complete history of Bitnami container images has been copied to the "bitnamilegacy" repository. New tags will continue to be synced there until August 28th. After that date, "bitnamilegacy" will no longer receive updates, and images in the mainline "bitnami" repository will begin to be removed over a period that may take up to two weeks.
Once the cleanup is complete, the mainline "bitnami" repository on DockerHub will contain only a limited subset of Bitnami Secure Images (at this moment available at "bitnamisecure"). These are hardened, security-enhanced containers intended for development or trial use, providing a preview of the full feature set available in the paid offering.
From the bottom of the post I know what they are hoping users will do:
> Suppose your deployed Helm chart is failing to pull images from docker.io/bitnami. In that case, you can resolve this by subscribing to Bitnami Secure Images, ensuring that the Helm charts receive continued support and security updates.
They don't want to give instructions that are too helpful. They want your company CC to be the easiest way to fix the problem they created.
gangstead 203 days ago [-]
Looks like it's $5k/month, minimum 12 months for "secure" images.
> All existing container images, including older or versioned tags (e.g., 2.50.0, 10.6), will be moved from the public catalog (docker.io/bitnami) to the Bitnami Legacy repository (docker.io/bitnamilegacy). This legacy catalog will receive no further updates or support and should only be used for temporary migration purposes.
This sucks, I used to like the Bitnami container images (didn't need the Helm charts) because the images were consistent and consistently nice (documentation, persistent storage, configuration, sizes), but now I need to move off of those.
Basically, I'll need to move to the regular upstream images for:
* web servers (Apache2 because it's well suited for my needs, but the same would apply to Nginx and Caddy)
* relational DBs (MariaDB, though I'm moving over to MySQL 8 for any software that needs it due to their 11 release having compatibility issues with MySQL drivers; as well as PostgreSQL)
* key value stores (Redis)
* document stores (MongoDB)
* message queues (RabbitMQ and NATS)
* S3 compatible blob stores (MinIO and SeaweedFS)
* utility containers (like Trivy)
(either that, or I'll need to build them myself if the Dockerfiles remain available)
I'll stay away from Broadcom as much as possible.
Edit:
> Helm charts and container images' open-source code will continue to be maintained up-to-date and accessible on GitHub under the Apache 2 license.
I knew this would happen eventually. The images always looked nice, but were so hopelessly entangled in the Bitnami world there was no chance of forking them, or easily migrating away. Good thing I dodged that bullet… never trust a commercial vendor that trades you convenience for interoperability.
mrweasel 203 days ago [-]
To me the images always looked overly complex, to the point where I frequently felt more at ease just doing an image from scratch myself. They never felt like a good fit for production systems.
I also know a ton of people and project who are now sort of screwed, because they can not possibly maintain a fork do to the Bitnami complexity, but there's also a reason why they didn't just do their own image.
This did feel inevitable.
wjimenez52711 202 days ago [-]
[dead]
kubelsmieci 203 days ago [-]
> MariaDB, though I'm moving over to MySQL 8 for any software that needs it due to their 11 release having compatibility issues with MySQL drivers
Could you tell more?
KronisLV 203 days ago [-]
Stumbled upon issues when updating from an older MariaDB 10 release to MariaDB 11 when some Go software was trying to connect to it using a MySQL driver. Seems like people have similar issues with other stacks as well as well: https://bugs.mysql.com/bug.php?id=111697
I could just use MariaDB drivers where available, but honestly MySQL seems more popular and the MariaDB SPAC and layoffs soured my view of them; ofc PostgreSQL is also nice.
janjongboom 203 days ago [-]
The removal (or moving) of the Bitnami images from Docker Hub is going to break a ton of systems that depend on them. I helped set up https://www.stablebuild.com/ some years ago to counter these types of issues, it provides (among other things) a transparent cache to Docker Hub which automatically caches image tags and makes them immutable - underlying tag might be deleted or modified, but you’ll get the exact same original image back.
Still gonna break everyone’s CI until they manually update the tag. (And who guarantees that these tags will stay alive after they pull this)
mrweasel 203 days ago [-]
This is exactly why so many of us have advocating for private registries and copies of every image you run in production. Pulling straight from Docker Hub was always a risk.
dpkirchner 203 days ago [-]
Maybe this will finally break me of my habit of using helm charts, period.
skissane 203 days ago [-]
I’ve never used Helm charts. I learned K8S in a shop in which kustomize is the standard and helm is a permitted exception to the standard, but I just never felt any reason to learn helm. Am I missing out?
Sometimes the limitations of kustomize annoy me, but we find ways to live with them
letmeinhere 203 days ago [-]
Would you like to count the number of spaces that various items in your manifests are indented and then pass that as an argument to a structure-unaware text file templating engine? Would you like to discover your inevitable yaml file templating errors after submitting those manifests to the cluster? Then yes, you are really missing out!
raphinou 203 days ago [-]
A couple of years ago I was using https://kapitan.dev/ which I found really good at the time when using jsonnet files to generate the configs. I haven't used it for some time though.
thayne 203 days ago [-]
I really, really, wish we could move away from yaml for tools like this.
IshKebab 203 days ago [-]
If YAML is a foot-gun, templated YAML is a face-cannon.
9dev 203 days ago [-]
I never understood why people didn’t serialize from JSON if they run a transformation step on the YAML anyway. Read JSON, alter in your favorite language, dump YAML as the last step, deploy. Instant prevention of a lot of sadness.
Yet somehow, all we have is YAML templating?
stackskipton 203 days ago [-]
Kubectl will handle JSON without converting it to YAML. So if you are doing this, then just do kubectl apply -f deployment.json
thayne 199 days ago [-]
So why doesn't helm output to json instead of yaml, and avoid all the problems with significant whitespace?
Finster 194 days ago [-]
crickets
shepherdjerred 203 days ago [-]
CDK8s works really well. I'm sad it hasn't really taken off.
Helm gives you more than enough rope to hang yourself with. At $dayjob we barely use 3rd party helm charts, and when we do we eventually run into problems with clever code.
We do package our own helm charts, not in the least because we sign contracts with our customers that we will help them run the software we're selling them. So we use package docker and helm artifacts that we sell in addition to running locally.
So we write some charts that don't use most helm features. The one useful thing about Helm that I don't want to live without is the packaging story. We seem to be the only people in the ecosystem that "burn in" the Docker image sha into the Helm chart we package, and set our v1.2.3 version only on the chart. This means we don't have to consider a version matrix between our config and application. Instead we just change the code and config in the same git sha and it just works.
progbits 203 days ago [-]
We just set chart version equal to image version, they live in the same repo and are released and built together (and the chart is only published after successfully publishing the image, so it's always valid). The chart allows to override the image version but we almost never do that, it's for emergencies.
Replacing with hash is a neat idea, might start doing that too.
bigstrat2003 203 days ago [-]
I wouldn't say you're missing out. If kustomize works for you, keep using it. I personally use helm because I cannot for the life of me wrap my head around kustomize. I've looked at tutorials, read the docs, and it just doesn't make sense to me. Helm, on the other hand, immediately clicked and I was able to pretty effortlessly write charts for our use. It's just a case of different preference in tools, imo.
cmckn 203 days ago [-]
Kustomize feels like less of a hack to me, without the gotpl madness, but it’s way more painful to get something done in my experience. I’ve landed on just writing real code to craft the objects I want (using the actual types, not text), if I absolutely can’t get by with static manifests.
mdaniel 203 days ago [-]
Every time I try to get into Kustomize, I feel it just has a documentation problem. It's written in Ph.D.ese without suitable examples
But, if it helps, my mental model of Kustomize is "it's a sequence of JSON Patch [1] operations"[2] which makes it absolutely stellar for mutating someone else's helm chart[3] (or yaml) since you can target anything for updating to your needs
My secondary complaint is that even JetBrains don't have good support for it, which makes working with them extra hard mode
1. having the ability to create a release artefact helm chart for a version, and store that artefact easily in OCI repositories.
2. being able to uninstall and install a chart and not have to worry about extra state. Generally in Kustomize people just keep applying the yaml and you end up in a state where there’s more deployed than there is in the kustomize config
jauntywundrkind 203 days ago [-]
One thing I haven't seen mentioned in comment. Dunno if Kustomize has something here. But: Helm is a shit but at least some kind of composition tool. Some way to have resource of various types associated to some top level idea.
Very very little else seems to bring this basic sense to Kubernetes. Metacontroller kind of could do that. Crossplane's whole business is this, but it's been infra-specialized: but the Crossplane v2.0 release is trying to be much more generally useful. https://docs.crossplane.io/v2.0-preview/whats-new/ . Would love other examples of what does composition in Kube.
znpy 203 days ago [-]
Kustomize is nice but you’re missing out on objects lifecycle management.
Kustomize had the issue that it would leave objects dangling in the cluster and you had to manually clean them up of you removed them from your kustomization file.
pestaa 203 days ago [-]
If you use the kustomize controller from the FluxCD project, you can set it to prune unmanaged objects.
In true GitOps, I think it's should be default on.
skissane 202 days ago [-]
This doesn't happen for me, due to ArgoCD–the kustomize YAML is in a PR, and when it merges to the main branch, ArgoCD automatically deploys it. And yes I've found ArgoCD removes most objects when they are deleted from Git.
0xbadcafebee 203 days ago [-]
Some people like that Helm:
- Makes it possible to go from zero to fully running k8s integrated components in 5 seconds by just running 'helm install --repo https://example.com/charts/ mynginx nginx' (very useful: https://artifacthub.io/)
- Gives the ability to transactionally apply k8s configs, and un-apply them if there is a failure along the way (atomic rollbacks)
- Stores copies/versions/etc of each installation in the server so you have metadata for troubleshooting/operations/etc without having to keep it in some external system in a custom way.
- Allows a user who doesn't know anything about K8s to provide some simple variables to customize the installation of a bunch of K8s resources.
- Is composeable, has templates, etc.
So basically Helm has a lot of features, while Kustomize has... one. Very different purposes I think. You can also use both at the same time.
Personally I think Helm's atomic deployment feature is well worth it. I also love how easy it is to install charts. It feels a bit like magic.
bo0tzz 203 days ago [-]
> zero to fully running (...) in 5 seconds by just running helm install
Realistically, a plain helm install without any values rarely if ever gives you the deployment you need, so you have to study the chart anyways.
> rollback on failure
This is hardly unique to helm.
> history metadata without (...) some external system
In 2025 you should probably be using gitops anyways, in which case the git repo is your history.
0xbadcafebee 203 days ago [-]
> a plain helm install without any values rarely if ever gives you the deployment you need
works for me most of the time
> This is hardly unique to helm.
So what? The guy was asking what is nice about Helm vs Kustomize. Does Kustomize have rollbacks?
> In 2025 you should probably be using gitops
Gitops is literally just "hey I have some configs in Git and I run some command based on a checkout", i.e. infrastructure as code in a git repo. Gitops does not track live server metadata and deployment history. I don't get why people over-inflate this idea.
What do you mean by atomic deployment? There are no transactions in the Kubernetes API. Helm has to make one request for each object it creates or modifies, like any other client.
I believe(!) that the "rollback" that helm attempts to put back all the mutated objects, which it can - in theory - do because it maintains the previous state in the Secret objects that contain the rendered(?) and the values for the prior revision
try:
for obj in manifest_objects:
kubectl_apply(obj)
revisions.push(manifest_objects)
except:
old_revision = revisions.pop()
for obj in old_revision:
kubectl_apply(obj)
type deal
ntqz 203 days ago [-]
Grafana's Tanka is a very underappreciated tool if you have to do something similar to Helm.
davidham 203 days ago [-]
I work at Grafana, and Jsonnet powers our whole k8s infrastructure. It can get a little baroque sometimes but overall it’s tremendously powerful, and it’s fun to work with.
imglorp 197 days ago [-]
Most on this thread are viewing helm from a user perspective: "I want to install X and I can use somebody's chart for it or I can use another tool."
There is another category of users who want a way to mange multiple vendor offerings in a consistent manner into their clusters. If they're all packaged with Helm, the user can have standard process and tooling to do that. It's done for K8s apps what containers did for executables.
Is it great? No, see the grief and pain in sibling threads. Are there alternatives? Sure. But Helm is sort of a standard at this point, warts and all.
I work for a vendor that sells to the second category usually, my chart has some 45 images with some intricate hooks for install and upgrade, subcharts, multiple namespaces, etc. You'd be hard pressed to repackage our stuff for every release we give you.
cheshire_cat 203 days ago [-]
Why do you want to stop using helm charts? Genuine question, as I'm new to Kubernetes and helm.
chuckadams 203 days ago [-]
Write a few Helm charts and you'll understand why people want to stop using it. `nindent` will become a curse word in your vocabulary. It's a fine tool at the user level, but the DX is an atrocity.
cbzbc 203 days ago [-]
What are you planning on moving to ?
dpkirchner 203 days ago [-]
I'm using either opentofu(terraform) or plain yaml. I'm not a huge fan of HCL but at least it is structured and easily manipulated without worrying about whitespace.
hbogert 199 days ago [-]
easily manipulated? How?
chuckadams 203 days ago [-]
Probably kustomize, as my needs are simple. If I care to get fancy, I’m pondering giving Yoke a try.
davidham 203 days ago [-]
I used kustomize to build an ArgoCD install at a previous company, and I was impressed at how powerful it was. Our setup was pretty involved, and kustomize was able to handle all the per-environment differences easily, and the code was easy to work with.
theteapot 203 days ago [-]
What's wrong with `kubectl apply -f xxx.yaml`?
physicles 203 days ago [-]
We use kustomize because we have four environments that run basically the same stuff (dev with k3s, test, and two cloud regions). If we didn’t use kustomize, we’d be forced to reinvent it to avoid duplicating so much yaml.
202 days ago [-]
bigstrat2003 203 days ago [-]
I mean, I have written a few (like 5-10?) and I don't understand either. I find that Helm is quite a nice tool which does its job very well.
EdwardDiego 203 days ago [-]
Golang string templating in a whitespace sensitive config language suuuuucks.
I might use Helm charts for initial deploys of operators, but that's about it.
Kustomize is, IMO, a better approach if you need to dynamically modify the YAML of your resources and tools like ArgoCD support it.
NewJazz 203 days ago [-]
Consuming one that is well written isn't too much pain, IME. But writing or modifying one can be really annoying. Aiui the values.yaml has no type schema, just vibes. The whole thing is powered off using text templating with yaml (a whitespace sensitive language), which is error prone and often hard to read. That's basically the main issues in a nutshell, it may not sound like much, but helm doesn't exactly do a whole lot and it does that limited set of stuff poorly.
Ah, I must have met some lazy charts then. Thanks for the correction. Still, it seems like that schema would end up a little inconvenient to integrate into your editor for writing the templates...
mdaniel 202 days ago [-]
Oh, yeah, but who can blame them because writing JSON Schema files by hand is some onoz
There are likely other "give me a schema for this example JSON/YAML file" but almost certainly wouldn't come with the nice {"description":""} blocks, nor the {"required":false} that an annotated .yaml can offer
> a little inconvenient to integrate into your editor for writing the templates...
Another way that JetBrains tooling shines, because it automatically turns on JSON Schema support for the chart when it has one, no extra # schema=file://... dumbness required
NewJazz 202 days ago [-]
That is when you are writing the values when using the chart though, right? Yeah that's not too hard.
I was talking about the go templates that make up the actual chart. Ensuring they only use string values for annotations for example seems like a hard problem to solve. Even just showing the type and description from the schema seems nontrivial.
mdaniel 202 days ago [-]
I don't exactly follow which part you're talking about, but yes JetBrains propagates the type and description from the JSON Schema into the golang templates inside the manifest files, same as it does with any type completion. They are reflected as their JSON Schema types, not golang's types, which I could imagine is potentially confusing to someone used to golang's view of the world but is for sure considerably better than "hurr, the type is whatever you say it is" which will be the case for values.yaml files without an accompanying .schema.json file
---
As for the "only string values for annotations," I think you mean patternProperties:
{
"$schema": "http://json-schema.org/draft-07/schema",
"type": "object",
"properties": {
"annotations": {
"type": "object",
"description": "this is the description of the annotations key itself",
"additionalProperties": false,
"patternProperties": {
"^[a-z][a-z0-9./]+$": {
"type": "string",
"description": "holds the value of the annotation"
}
}
}
}
}
and if I put the following, then the 123 gets flagged as a schema violation
annotations:
alpha: 123
as does
annotations:
_: xxx
0xcafebabe: denied
---
If you mean schema checking on the output, that is checked by the OpenAPI built into Kubernetes itself, so yes, doing something silly in golang templates will not, by itself, check the result - that's one of the major limitations of Helm's moronic choice of using a text templating language for a structured file format
NewJazz 201 days ago [-]
Oh, OK. I didn't realize it made them visible in the golang templates.
I suggest checking out Anemos (https://github.com/ohayocorp/anemos), the new boy in the town. It is an open source single-binary tool written in Go and allows you to use JavaScript/TypeScript to define your manifests using templates, object oriented approach, and YAML node manipulation.
On that note, I'm already looking at migrating my codebase off of Spring. Just testing the waters with Quarkus, Helidon, Micronaut, Pekko, Vert.x, and plain Jakarta EE right now.
lapusta 203 days ago [-]
Red Hat effectively killed their JBoss/Middleware team and the rest of it moved to IBM https://www.redhat.com/en/blog/evolving-our-middleware-strat... Quarkus and other tools were pushed to CommonHaus/Apache. I believe Vert.X was also mostly developer by RH team, although moved to Eclispe Foundation a decade ago.
Oracle also ended up somehow sponsoring 2 frameworks: Helidon & Micronaut.
I'd bet Spring is still the safest choice next to Jakarta EE standards that all are built on top of nowadays.
EdwardDiego 203 days ago [-]
Yeah my old colleagues who work on Kroxylicious are now IBM. I keep asking them if they're wearing a blue tie to the office yet, they still don't think it's funny.
latchkey 203 days ago [-]
I still see Gavin working on JEE.
EdwardDiego 203 days ago [-]
I quite like Micronaut, especially the ability to use its compile time DI as a standalone library in a non-Micronaut app.
Quarkus is pretty similar, but is built on top of Vert.x so a lot of the fun of Vert.x (don't block the event loop!) is still present. It also does compile time DI.
_1tan 203 days ago [-]
Are there any indications or just a feel?
bags43 203 days ago [-]
Company where I work had huge risk audit.
The second highest risk is using USA based cloud with 66/100.
The first one was using Spring Boot everywhere 77/100. Till the end of 2025 we need to have migration path to something else with 2 PoCs done.
jchmbrln 203 days ago [-]
I’m completely out of the loop. What’s going on with Spring Boot?
radicalbyte 203 days ago [-]
The VMware apocalypse.
heisenbit 203 days ago [-]
One does not need VMware for SpringBoot so?
xienze 203 days ago [-]
Spring’s corporate steward is VMWare, and Broadcom bought VMWare, ergo Spring is subject to Broadcom’s whims.
Not spring boot, but spring, is owned by VMware. Sure spring is under a free license but if upstream enshittifies, community forks would be required.
mindcrime 203 days ago [-]
And as popular and widely used as Spring is, that would 100% happen. To me at least, I wouldn't count this as a particularly huge risk. But in an enterprise setting, with mandatory auditing and stuff, I can understand why there would be a requirement to at least pre-identify alternative(s).
terminalbraid 203 days ago [-]
> Not spring boot, but spring, is owned by VMware
How do I reconcile this statement with VMWare holding the copyright which you will find unambiguously littered in the official Spring Boot repository?
Since you contend the contrary, who does in fact hold the copyright?
203 days ago [-]
xienze 203 days ago [-]
Probably a bit of overreaction given that Broadcom is now in charge of Spring. At the end of the day it’s a wildly popular open source project — it has a path forward if Broadcom pulls shenanigans.
That said, I have noticed that the free support window for any given version is super short these days. I.e. if you’re not on top of constantly upgrading you’re looking at paid support if you want security patches.
203 days ago [-]
jcrben 203 days ago [-]
What was the actual risk of using SpringBoot tho?
ntqz 203 days ago [-]
License changes - BSL or closing the source
If there's no money in it for them - reduction of staff or funding leading to slower releases and bugfixes
Moving some features like Spring Cloud / Spring Integration, or new development behind a paywall (think RHEL)
Big users (like Netflix, Walmart, JPMorgan, LinkedIn/Microsoft, etc) would likely be able to pay for it (until they moved off), but smaller companies and individual developers not so much
bbkane 203 days ago [-]
I think it would be more of a Redis situation - steward changes the license, someone large enough to maintain a fork creates one, and everyone moves to the fork. In Redis's case, Amazon forked it into Valkey.
Spring is so widely used that there are multiple "large enough" companies who could do this
somehnguy 203 days ago [-]
What's the actual risk though? Just saying it's the riskiest at 77/100 doesn't mean anything.
- reducing headcount of people -> slow security patching + not following industry standards
- all eggs in one basket :)
- cut from major clouds (Azure Spring apps)
moorow 203 days ago [-]
Bitnami images have been problematic for a little while, especially given their core focus on security but still resulting in a CVE 9.4 in PgPool recently that ended up being used in the underlying infrastructure for a bunch of cloud hosts:
That's what Bitnami Secure Images comes to solve. Bitnami regularly updates its images with the latest system packages; however, certain CVEs may persist until they are patched in the OS (Debian 12) or the application itself. Additionally, some CVEs remain unfixed due to the absence of available patches. In vulnerability scanners like Trivy, you can use the `--ignore-unfixed` flag to ignore such CVEs.
In the case of Bitnami Secure Image, the underlying distro is PhotonOS, which is oriented to have zero CVEs.
moorow 203 days ago [-]
I mean I understand that's the goal, but in this specific CVE it looks like the issue was introduced in Bitnami's own scripts sitting on top of everything, so a ideally-zero-CVE underlying OS isn't going to solve that problem at all.
It also seems like this set of changes was made in this specific way to forcibly disrupt anyone using the existing images, many of which were made off the backs of previously existing non-bitnami open source projects, so I assume you can understand why people are annoyed.
But again, anyone with any knowledge or experience of Broadcom saw this coming, so...
Youden 203 days ago [-]
"Helm charts and container images' open-source code will continue to be maintained up-to-date and accessible on GitHub under the Apache 2 license."
Doesn't this mean everything is still available, just in source form instead of binary? Could a situation like AlmaLinux/Rocky Linux etc. spin up where folks build a community-supported set of binaries from source?
sseveran 203 days ago [-]
This is going to cause some disruptions. What are the alternatives out there to bitnami charts?
carrodher 203 days ago [-]
The source code for Bitnami containers and Helm charts remains publicly available on GitHub and continues to be licensed under Apache 2.
What’s changing is that Bitnami will no longer publish the full catalog of container images to DockerHub. If you need any image, you can still build/package it yourself from the open-source GitHub repositories.
tranatyl 201 days ago [-]
What about the bitnami:minideb base image?
Or the stacksmith files necessary to build certain images?
Without access to these resources, it will not be possible to rebuild the images, will it?
carrodher 200 days ago [-]
Projects like Sealed Secrets and minideb remain unaffected by these changes. Container images for both projects will continue to be released on Docker Hub (docker.io/bitnami) as usual, without any modifications.
The source code will continue to be available for containers, allowing you to build them from source and future versions as well. The Stacksmith tarballs will also remain available.
The planned action is to stop providing the already built containers on Docker Hub.
I don't know why but Artifact Hub never shows up in Google search when you search for "web site with helm charts". Hopefully this gives it a boost.
ethan_smith 203 days ago [-]
Check out Artifact Hub, the CNCF-hosted charts from projects like Prometheus/Grafana, or the official k8s-at-home charts as solid alternatives to Bitnami.
gchamonlive 203 days ago [-]
My first thought was Linuxcontainers but I think they just maintain docker images, not helm charts
chrisandchris 203 days ago [-]
They're all open source - fork the repo and start collectively maintain them.
gchamonlive 203 days ago [-]
That doesn't really answer the question, does it?
jahsome 203 days ago [-]
You asked for an alternative and that seems like an alternative to me.
gchamonlive 203 days ago [-]
It's not and I wasn't the one who asked
jahsome 203 days ago [-]
K
203 days ago [-]
sbstp 203 days ago [-]
RabbitMQ next?
js4ever 203 days ago [-]
Great more enshitification! Broadcom is destroying everything they touch
jacquesm 203 days ago [-]
That's nonsense. RPi would not exist if not for Broadcom.
happycube 203 days ago [-]
The current Broadcom (Avago) is literally not the Broadcom that RPi came from. Not that old-Broadcom was great, but...
okanat 203 days ago [-]
RPi doesn't exist due to Broadcom. It exists despite Broadcom.
Using RPis can be a huge PITA, if you'd like to do something a bit more complex with the hardware. HDMI, the video decoders are all behind closed doors with blobs on top of blobs and NDAs.
RPi SoCs are some of the weirdest out there. It boots from the GPU ffs.
wpm 203 days ago [-]
Yeah Broadcom had a load of unsellable SOCs they needed to off load
xyst 203 days ago [-]
But who will think of the shareholders?! \s
I’m surprised anybody works at bcom these days.
tammyharrisburg 195 days ago [-]
[dead]
mfreeman451 203 days ago [-]
this blows.. i have to use bitnami charts for a bunch of stuff, have for a while..
iotapi322 203 days ago [-]
That's fine , their repmgr postgres repository was a joke.
remram 203 days ago [-]
"Discontinuing this library of 120 things for everyone is fine, *I* didn't like *one of them* I won't say why"
Rendered at 08:08:00 GMT+0000 (Coordinated Universal Time) with Vercel.
Broadcom's continued ability to perform well while only serving ever more upmarket areas, & cutting everyone else loose (& generally giving no figs) is fantastically impressive.
The large majority of work done in OpenJDK is by Oracle employees.
Had it been for most of those players, Java 6 would have been the last version.
Corporate players came into play after Oracle acquired Sun. The fear that Oracle would do the same as LibreOffice pushed players like IBM to have their own Java distributions.
Of course Oracle having more support for OpenJDK is not surprising. However, the open nature and existing players already make it easier to fork / replace Java compared to Vmware.
What Google did with Android, it is hardly any different from Microsoft with J++, only that there the courts had another outcome.
Android with a Java subset and Kotlin, is hardly any different outcome than .NET with C#.
Corporate players came in, after money was available again, after the acquisition.
"James Gosling Triangulation's Interview on Google vs. Sun"
https://www.youtube.com/watch?v=ZYw3X4RZv6Y&t=3462s
"James Gosling on Android and Java"
https://www.youtube.com/watch?v=IT__Nrr3PNI&t=6245s
If Google actually cared about Java, they missed their opportunity to acquire Sun, own Java, do whatever they felt like doing with it for Android, and the rest of the industry, and best of all, they would never had to bother with any lawsuit.
Given how much the so called existing players contributed to save Java while Sun was going under, that is whishful thinking.
Last company was pretty heavy free user of Bitnami charts for various things but biggest being Redis clusters. I can't imagine they could convert everything into a cluster using their own charts before this kicks in. Very possible they end up tossing at least a year worth of licensing towards Bitnami.
Fuck Wall St. greedy morons at Broadcom. Hubris will educate them the hard way as they fade in relevance.
All gone now. Sad.
From ticket https://github.com/bitnami/charts/issues/35164:
> Now – August 28th, 2025: Plan your migration: Update CI/CD pipelines, Helm repos, and image references
> August 28th, 2025: Legacy assets are archived in the Bitnami Legacy repository.
From README https://github.com/bitnami/charts/blob/4973fd08dd7e95398ddcc...:
> Starting August 28th, over two weeks, all existing container images, including older or versioned tags (e.g., 2.50.0, 10.6), will be migrated from the public catalog (docker.io/bitnami) to the “Bitnami Legacy” repository (docker.io/bitnamilegacy), where they will no longer receive updates.
What are users expected to do exactly?
Once the cleanup is complete, the mainline "bitnami" repository on DockerHub will contain only a limited subset of Bitnami Secure Images (at this moment available at "bitnamisecure"). These are hardened, security-enhanced containers intended for development or trial use, providing a preview of the full feature set available in the paid offering.
- Bitnami: https://hub.docker.com/u/bitnami - Bitnami Legacy: https://hub.docker.com/u/bitnamilegacy - Bitnami Secure Images: https://hub.docker.com/u/bitnamisecure
From the bottom of the post I know what they are hoping users will do:
> Suppose your deployed Helm chart is failing to pull images from docker.io/bitnami. In that case, you can resolve this by subscribing to Bitnami Secure Images, ensuring that the Helm charts receive continued support and security updates.
They don't want to give instructions that are too helpful. They want your company CC to be the easiest way to fix the problem they created.
https://aws.amazon.com/marketplace/pp/prodview-pwqgz3mnvxvok...
You can always follow the "contact sales" form and see if they give you a higher or lower number than that.
But damn oh damn does Broadcom feel like a good fit for this statement.
> All existing container images, including older or versioned tags (e.g., 2.50.0, 10.6), will be moved from the public catalog (docker.io/bitnami) to the Bitnami Legacy repository (docker.io/bitnamilegacy). This legacy catalog will receive no further updates or support and should only be used for temporary migration purposes.
This sucks, I used to like the Bitnami container images (didn't need the Helm charts) because the images were consistent and consistently nice (documentation, persistent storage, configuration, sizes), but now I need to move off of those.
Basically, I'll need to move to the regular upstream images for:
(either that, or I'll need to build them myself if the Dockerfiles remain available)I'll stay away from Broadcom as much as possible.
Edit:
> Helm charts and container images' open-source code will continue to be maintained up-to-date and accessible on GitHub under the Apache 2 license.
Hmmm: https://github.com/bitnami/containers/tree/main/bitnami/mari... and https://github.com/bitnami/containers/commit/7651d48119a1f3f...
I also know a ton of people and project who are now sort of screwed, because they can not possibly maintain a fork do to the Bitnami complexity, but there's also a reason why they didn't just do their own image.
This did feel inevitable.
Could you tell more?
I could just use MariaDB drivers where available, but honestly MySQL seems more popular and the MariaDB SPAC and layoffs soured my view of them; ofc PostgreSQL is also nice.
Sometimes the limitations of kustomize annoy me, but we find ways to live with them
Yet somehow, all we have is YAML templating?
https://cdk8s.io/
We do package our own helm charts, not in the least because we sign contracts with our customers that we will help them run the software we're selling them. So we use package docker and helm artifacts that we sell in addition to running locally.
So we write some charts that don't use most helm features. The one useful thing about Helm that I don't want to live without is the packaging story. We seem to be the only people in the ecosystem that "burn in" the Docker image sha into the Helm chart we package, and set our v1.2.3 version only on the chart. This means we don't have to consider a version matrix between our config and application. Instead we just change the code and config in the same git sha and it just works.
Replacing with hash is a neat idea, might start doing that too.
But, if it helps, my mental model of Kustomize is "it's a sequence of JSON Patch [1] operations"[2] which makes it absolutely stellar for mutating someone else's helm chart[3] (or yaml) since you can target anything for updating to your needs
My secondary complaint is that even JetBrains don't have good support for it, which makes working with them extra hard mode
1: https://www.rfc-editor.org/rfc/rfc6902.html
2: it's a very "functional programming language" mental model https://kubectl.docs.kubernetes.io/references/kustomize/kust...
3: https://kubectl.docs.kubernetes.io/references/kustomize/buil...
1. having the ability to create a release artefact helm chart for a version, and store that artefact easily in OCI repositories. 2. being able to uninstall and install a chart and not have to worry about extra state. Generally in Kustomize people just keep applying the yaml and you end up in a state where there’s more deployed than there is in the kustomize config
Very very little else seems to bring this basic sense to Kubernetes. Metacontroller kind of could do that. Crossplane's whole business is this, but it's been infra-specialized: but the Crossplane v2.0 release is trying to be much more generally useful. https://docs.crossplane.io/v2.0-preview/whats-new/ . Would love other examples of what does composition in Kube.
Kustomize had the issue that it would leave objects dangling in the cluster and you had to manually clean them up of you removed them from your kustomization file.
In true GitOps, I think it's should be default on.
- Makes it possible to go from zero to fully running k8s integrated components in 5 seconds by just running 'helm install --repo https://example.com/charts/ mynginx nginx' (very useful: https://artifacthub.io/)
- Gives the ability to transactionally apply k8s configs, and un-apply them if there is a failure along the way (atomic rollbacks)
- Stores copies/versions/etc of each installation in the server so you have metadata for troubleshooting/operations/etc without having to keep it in some external system in a custom way.
- Allows a user who doesn't know anything about K8s to provide some simple variables to customize the installation of a bunch of K8s resources.
- Is composeable, has templates, etc.
So basically Helm has a lot of features, while Kustomize has... one. Very different purposes I think. You can also use both at the same time.
Personally I think Helm's atomic deployment feature is well worth it. I also love how easy it is to install charts. It feels a bit like magic.
Realistically, a plain helm install without any values rarely if ever gives you the deployment you need, so you have to study the chart anyways.
> rollback on failure
This is hardly unique to helm.
> history metadata without (...) some external system
In 2025 you should probably be using gitops anyways, in which case the git repo is your history.
works for me most of the time
> This is hardly unique to helm.
So what? The guy was asking what is nice about Helm vs Kustomize. Does Kustomize have rollbacks?
> In 2025 you should probably be using gitops
Gitops is literally just "hey I have some configs in Git and I run some command based on a checkout", i.e. infrastructure as code in a git repo. Gitops does not track live server metadata and deployment history. I don't get why people over-inflate this idea.
Please check https://opengitops.dev/
I believe(!) that the "rollback" that helm attempts to put back all the mutated objects, which it can - in theory - do because it maintains the previous state in the Secret objects that contain the rendered(?) and the values for the prior revision
type dealThere is another category of users who want a way to mange multiple vendor offerings in a consistent manner into their clusters. If they're all packaged with Helm, the user can have standard process and tooling to do that. It's done for K8s apps what containers did for executables.
Is it great? No, see the grief and pain in sibling threads. Are there alternatives? Sure. But Helm is sort of a standard at this point, warts and all.
I work for a vendor that sells to the second category usually, my chart has some 45 images with some intricate hooks for install and upgrade, subcharts, multiple namespaces, etc. You'd be hard pressed to repackage our stuff for every release we give you.
I might use Helm charts for initial deploys of operators, but that's about it.
Kustomize is, IMO, a better approach if you need to dynamically modify the YAML of your resources and tools like ArgoCD support it.
Ironically (in the context of this submission) Bitnami has a "--schema" option to their README generator, which is why so many of their charts ship with .schema.json files: https://github.com/bitnami/readme-generator-for-helm/tree/2....
There are likely other "give me a schema for this example JSON/YAML file" but almost certainly wouldn't come with the nice {"description":""} blocks, nor the {"required":false} that an annotated .yaml can offer
While digging up that link, I also spotted the tag line in their GitHub org which is hilarious https://github.com/bitnami#:~:text=trusted%20by%20ops
Another way that JetBrains tooling shines, because it automatically turns on JSON Schema support for the chart when it has one, no extra # schema=file://... dumbness required
I was talking about the go templates that make up the actual chart. Ensuring they only use string values for annotations for example seems like a hard problem to solve. Even just showing the type and description from the schema seems nontrivial.
---
As for the "only string values for annotations," I think you mean patternProperties:
and if I put the following, then the 123 gets flagged as a schema violation as does ---If you mean schema checking on the output, that is checked by the OpenAPI built into Kubernetes itself, so yes, doing something silly in golang templates will not, by itself, check the result - that's one of the major limitations of Helm's moronic choice of using a text templating language for a structured file format
You can read a comparison with Helm here: https://www.ohayocorp.com/anemos/docs/comparison/helm
P.S. I am the author of the tool.
On that note, I'm already looking at migrating my codebase off of Spring. Just testing the waters with Quarkus, Helidon, Micronaut, Pekko, Vert.x, and plain Jakarta EE right now.
Oracle also ended up somehow sponsoring 2 frameworks: Helidon & Micronaut.
I'd bet Spring is still the safest choice next to Jakarta EE standards that all are built on top of nowadays.
Quarkus is pretty similar, but is built on top of Vert.x so a lot of the fun of Vert.x (don't block the event loop!) is still present. It also does compile time DI.
The second highest risk is using USA based cloud with 66/100.
The first one was using Spring Boot everywhere 77/100. Till the end of 2025 we need to have migration path to something else with 2 PoCs done.
How do I reconcile this statement with VMWare holding the copyright which you will find unambiguously littered in the official Spring Boot repository?
Since you contend the contrary, who does in fact hold the copyright?
That said, I have noticed that the free support window for any given version is super short these days. I.e. if you’re not on top of constantly upgrading you’re looking at paid support if you want security patches.
If there's no money in it for them - reduction of staff or funding leading to slower releases and bugfixes
Moving some features like Spring Cloud / Spring Integration, or new development behind a paywall (think RHEL)
Big users (like Netflix, Walmart, JPMorgan, LinkedIn/Microsoft, etc) would likely be able to pay for it (until they moved off), but smaller companies and individual developers not so much
Spring is so widely used that there are multiple "large enough" companies who could do this
- license change -> restricting features behind a paid tier (https://spring.io/blog/2025/04/21/spring-cloud-data-flow-com...)
- reducing headcount of people -> slow security patching + not following industry standards
- all eggs in one basket :)
- cut from major clouds (Azure Spring apps)
[pgpool] Unauthenticated access to postgres through pgpool · Advisory · bitnami/charts https://share.google/JcgDCtktG8dE2TZY8
In the case of Bitnami Secure Image, the underlying distro is PhotonOS, which is oriented to have zero CVEs.
It also seems like this set of changes was made in this specific way to forcibly disrupt anyone using the existing images, many of which were made off the backs of previously existing non-bitnami open source projects, so I assume you can understand why people are annoyed.
But again, anyone with any knowledge or experience of Broadcom saw this coming, so...
Doesn't this mean everything is still available, just in source form instead of binary? Could a situation like AlmaLinux/Rocky Linux etc. spin up where folks build a community-supported set of binaries from source?
What’s changing is that Bitnami will no longer publish the full catalog of container images to DockerHub. If you need any image, you can still build/package it yourself from the open-source GitHub repositories.
The source code will continue to be available for containers, allowing you to build them from source and future versions as well. The Stacksmith tarballs will also remain available.
The planned action is to stop providing the already built containers on Docker Hub.
I don't know why but Artifact Hub never shows up in Google search when you search for "web site with helm charts". Hopefully this gives it a boost.
Using RPis can be a huge PITA, if you'd like to do something a bit more complex with the hardware. HDMI, the video decoders are all behind closed doors with blobs on top of blobs and NDAs.
RPi SoCs are some of the weirdest out there. It boots from the GPU ffs.
I’m surprised anybody works at bcom these days.