21–30 of 58 posts
Isn't this just a podcast website, or is there something more to it? Why on earth would a podcast website need Kube?
There’s a very active news feed with submissions, commenting, newsletter subscriptions and management, a blog, episode requests, live streams, etc.
Check out the source to see what all the app does:
>>> We no longer provision load balancers, or configure DNS; we simply describe the resources that we need, and Kubernetes makes it happen. This is (part) of what keeps me in the stone age. You are provisioning load balancers and DNS - but just one step removed through k8s And my prior is that we need to understand that, be aaare of it, have a model of what is going on to help develop and debug. And so it feels a bit…
i think the idea is that k8s does away with having to glue all those pieces of infra together, not that you lose understanding of how it all works together. part of the headache with managing infra is that it rots over time... things come and go (sysv to systemd, apt/snap/whatever, config files change, things break). it's easier to keep up to date on k8s than all the disparate parts of the OS and provider-specific AP…
Does this imply there is a cloud abstract layer that should come (assuming all providers can put aside commercial interests etc)
And is k8s the simplest possible abstraction? And if not - what is?
>>> We no longer provision load balancers, or configure DNS; we simply describe the resources that we need, and Kubernetes makes it happen. This is (part) of what keeps me in the stone age. You are provisioning load balancers and DNS - but just one step removed through k8s And my prior is that we need to understand that, be aaare of it, have a model of what is going on to help develop and debug. And so it feels a bit…
In the unhappy path, sure, you need someone who knows how to debug networking issues, and in some cases it’s going to be harder to debug because of the layers of indirection. But the total amount of toil is significantly reduced.
A bad abstraction doesn’t carry its weight in complexity. A good abstraction allows you to ignore the lower levels most of the time without missing something important; I’d put k8s firmly in the latter category.
Isn't this just a podcast website, or is there something more to it? Why on earth would a podcast website need Kube?
Without some additional insight that I don't have, it does seem that this is an enormously over-engineered "solution" for a website -- I've NFI why it requires 99.99% uptime!
Perhaps they look it as a goal or challenge, an opportunity to showcase their knowledge and skills to potential customers, or, hell, maybe they just enjoy that kind of thing? If that's the case, I completely understand and can even relate (my home network is a textbook example of an "over-engineered solution": close to a dozen "enterprise-class" servers in the basement, ~35 various subnets, VMware Enterprise Plus clusters, BGP for anycast, and so on).
AFAICT, though, this is just some developers running a blog and podcasts aimed at other developers? I mean, we're not exactly talking about a "mission critical" web site that's going to result in death and destruction the next time it goes down or Linode shits itself, right?
Or am I missing something?
--
EDIT: I've read through the rest of the comments now ...
> This is for fun, to some degree ... We don’t really need this setup. One, it’s about learning ourselves, but then also sharing that ... It’s fun to do.
... and I completely understand!
Isn't this just a podcast website, or is there something more to it? Why on earth would a podcast website need Kube?
Some things I noticed:
* The internal network is not private. But people don't realise it. You share a /16 with other Linodes. So many open databases, file shares and other services in there.
* Block storage performance is really poor, around 100 iops. Same as a SATA disk from 10 years ago.
* No proper snapshot / image functionality.
* Linode Kubeternetes Engine was based on Debian Oldstable when it launched.
* Excessive CPU steal, even on dedicated cores. 25% CPU steal is considered normal. Over 50% happens a lot.
* Problems with their hosts. I can only guess what the reason is but 4 to 8 hours of unannounced downtime of a VM happend to me 6 times in the past 2 years.
Yes, support is friendly. But my international phone bill is huge because the fastest way to get them to do something is to call.
Isn't this just a podcast website, or is there something more to it? Why on earth would a podcast website need Kube?
Not knowing what changelog.com is, I was wondering the same thing... from the header of the page, I could tell that there's a blog, a podcast, and a newsletter. Without some additional insight that I don't have, it does seem that this is an enormously over-engineered "solution" for a website -- I've NFI why it requires 99.99% uptime! Perhaps they look it as a goal or challenge, an opportunity to showcase their knowle…
1. We're great engineers because we can set and maintain such an impressive set-up.
2. We're terrible engineers because all of this could probably done one server for dynamic content + S3 for dynamic content. Or not even S3, maybe just some Cloudflare or Akamai caching.
Of course, like the posters above, I could be missing something due to my outsider/consumer view of changelog.
I'm disappointed that blogs and podcasts keep promoting Linode. I currently maintain about 30 Linodes and I have been doing so for the past 2 years. Some things I noticed: * The internal network is not private. But people don't realise it. You share a /16 with other Linodes. So many open databases, file shares and other services in there. * Block storage performance is really poor, around 100 iops. Same as a SATA dis…
>>> We no longer provision load balancers, or configure DNS; we simply describe the resources that we need, and Kubernetes makes it happen. This is (part) of what keeps me in the stone age. You are provisioning load balancers and DNS - but just one step removed through k8s And my prior is that we need to understand that, be aaare of it, have a model of what is going on to help develop and debug. And so it feels a bit…
If it's a sufficiently robust abstraction, you don't, you just learn the abstraction. Kubernetes has reached that point for many folks.
I no longer have a detailed mental model of how my compiler or LLVM works, I just trust that it does. When was the last time you needed to (or were capable of) debugging a bug in your compiler? A couple of human generations of work went into making that happen.
Note that it turns out compiling code well, or making a reliable orchestration system, is an enormously complex problem. At some point, the complexity outstrips the ability of even generalists in the field to keep up, yet the systems keep getting more reliable.
So in these types of cases, you can either do it yourself poorly (you're an amateur), do it yourself well (congrats, you've become an expert), or delegate.
This isn't really limited to computing. I delegate maintenance on my car to a mechanic, while I'm pretty sure a generation ago, everybody (in the US) changed their own oil and understood how the carb worked. Times change.
I'm disappointed that blogs and podcasts keep promoting Linode. I currently maintain about 30 Linodes and I have been doing so for the past 2 years. Some things I noticed: * The internal network is not private. But people don't realise it. You share a /16 with other Linodes. So many open databases, file shares and other services in there. * Block storage performance is really poor, around 100 iops. Same as a SATA dis…
With all these negatives, there must be a really compelling reason to stay. What is it?
We are moving everything away. Most of our servers are with another provider already. And we haven't had any similar issues there. I've never called them!
And I forgot to mention the connectivity issues at Linode. When the whole London datacenter was unreachable for 2 hours we lost some customers.