This page is just a container for a youtube video. I suggest updating this HN link to point to the video directly, which contains the same links as the page in its description.
Why not support the author's own website? It looks like a nice website
Readit Newsyebyen commented on Building LLMs from the Ground Up: A 3-Hour Coding Workshop magazine.sebastianraschka... · Posted by u/mdp2021
yebyen commented on Weaveworks is shutting down linkedin.com/posts/richar... · Posted by u/candiddevmike
This is basically a build vs buy discussion. Businesses have generally concluded they should only build things that give them a strategic advantage and buy other services to maintain focus on their sources of competitive advantage. Eg in the case of k8s, it's not just spinning it up, it's securing it, patching, monitoring, etc. It's for this reason the majority of orgs shouldn't run it themselves.
However some balance is needed. Orgs may want to do exploration since it may not be obvious where competitive advantage can come from, or like you say perhaps hybrid makes sense, using it only in non prod.
I agree that it makes more sense to buy your Kubernetes on an organizational basis because one should not reinvent the wheel, and taking advantage of a commoditized service is only possible if you work with a competent broker.
However I am wary of the capacity of skills vendors to take advantage when you come to depend on them, even when their intentions are good and all ideals aligned. Being able to deliver the limited Kubernetes experience for yourself in low-stakes contexts, where you can depend on it because you know how it works, well enough to administer in a pinch, but availing that also in a pinch you're not the bottleneck to solve a problem, because you use the managed broker in all the places where it matters, feels like a sweet spot to me.
I don't want to pay money to a broker every time I spin up a new experiment for the duration of the experiment =/= I don't want to perform experiments.
That's where I see the disconnect that "Leadership" may fail to understand. You can provide a service at low marginal cost to take some of the load off your people, and that might also have the effect of stopping any experiments that fall beneath a certain threshold as "not worth the cost" - all because we settled on getting something for cheap that should have been free.
Then again, dodging all those diversions might have been a part of the strategy...
yebyen commented on Weaveworks is shutting down linkedin.com/posts/richar... · Posted by u/candiddevmike
I wasn't writing a critiqued essay. It's perfectly reasonable to assume 80% of orgs don't have the scale, core competencies or justifiable need to be managing container clusters themselves.
Also, no need to assume. I specifically said "use something managed".
IMO "use something managed" gets reduced to "we shan't run Kubernetes on-premises" which ends up meaning "we won't learn anything about failure modes until it's too late to think about mitigating them"
Which might be in line with what you said about
> 80% of orgs don't have the scale, core competencies or justifiable need to be managing container clusters themselves.
But also, would at least have some potential to be solved and much more cost effectively, or maybe at least grown past, if they would just spend some energy on deploying Kubernetes internally; even if we can't or won't afford an entire team dedicated to doing only that, (and even if we commit to using only managed services for production anywhere and everywhere.)
In my experience the way some places reflexively avoid it like it's a trap to be stayed out of, winds up being a bit like a self-fulfilling prophecy "we're not doing Kubernetes" - I empathize with the person who you triggered, even if now we're up to two walls of text from just a simple comment, I feel triggered too.
yebyen commented on Weaveworks is shutting down linkedin.com/posts/richar... · Posted by u/candiddevmike
So what's going to happen to the sock shop now?
LOL you'll have to get your socks somewhere else. The microservices demo is officially deprecated and archived:
https://github.com/microservices-demo/microservices-demo
I have seen others are still using it but not officially from anyone at Weaveworks
yebyen commented on Weaveworks is shutting down linkedin.com/posts/richar... · Posted by u/candiddevmike
> and had more than doubled the number of new product logos in 2023
That is a curious KPI.
It makes sense if you take in context that Flux, the most visible and well-known product of Weaveworks, is a donated CNCF open source project, and that companies like Microsoft, VMWare, AWS – can all engage with it directly, or by forking, or by building support for it directly into their own products.
How do you place a value on Microsoft building Flux into Azure Arc? I know it isn't worth $0 but do they actually need a contract with anybody (at Flux or Weaveworks) in order to go on doing that - no. They don't need one.
yebyen commented on Weaveworks is shutting down linkedin.com/posts/richar... · Posted by u/candiddevmike
It has been 100% fine for me, was easiest to deploy, very easy to encrypt all network communication. Has been anything but a dumpster fire, will likely wait it out a see what happens with the plugin, rather than switch to something else.
I still use it, shamefully, ex-Weaveworks employee - there is a fork I can recommend which has a live maintainer, actively interested in keeping it up:
https://github.com/rajch/weave/tree/reweave
If you use Weave net still, definitely follow his work and consider learning to build the image, so you can keep it ahead of CVE scanners. (You are using a CVE scanner in your clusters, right?)
yebyen commented on Weaveworks is shutting down linkedin.com/posts/richar... · Posted by u/candiddevmike
Based on the last time I looked: good handling of dependencies between builds (e.g. the ability to do an "edge build" where for any change in a given project, you check whether that will break your other projects when they upgrade to depend on that), advanced scheduling, plugins that integrate all sorts of random tools into your build views.
I have been away from Jenkins for a while, that all sounds like stuff I never used, (thanks!)
yebyen commented on Weaveworks is shutting down linkedin.com/posts/richar... · Posted by u/candiddevmike
I think it's worth giving praise for their contributions to Flux.
In my network, I'm the only one using ArgoCD. Supposedly they're equals, but it always made me curious to try Flux.
Are there any statements about the future of Flux and other open source tools, and whether the remaining community has enough resources to maintain development, or if they will reduce their contributions to only fixing critical bugs?
Flux has a pinned discussion for nearly a month now, to be as upfront as possible, without being able to disclose anything that might be privileged information, but anticipating that the news would get out about our backer sooner or later (aiming to avoid 100 threads about the same topic)
https://github.com/fluxcd/flux2/discussions/
tl;dr: Flux is a graduated CNCF project and not going anywhere
yebyen commented on Weaveworks is shutting down linkedin.com/posts/richar... · Posted by u/candiddevmike
This.
We looked at weaveworks and its competitor both as a product and an investment (mid 6 figure usage). Our big issue was that we had a lot of smaller teams doing different things and not one or two featured items raking in the majority of our revenue.
These solutions work if you have a bunch of snowflake workloads by design (or bad design).
> a bunch of snowflake workloads by design (or bad design).
That's a really interesting characterization of WGE, and I can't say I disagree much (my personal opinion as an ex-Wyvern/OSS Engineer DX @ weaveworks)
yebyen commented on Weaveworks is shutting down linkedin.com/posts/richar... · Posted by u/candiddevmike