> Maybe that is the answer ?? The fact that the middle-situations(lamp apps with low-med traffic) tutorials dont exists means i dont need it ??
SRE for 15 years with FAANG (MAGMA?) scale experience; I would argue this, yes. That's a little over 2 requests per minute. If you're cloud hosting then you could get away with single tiny hosts for your front end and DB, like t3.small on AWS, and Cloudwatch alarms for monitoring. If you need extreme HA or burstability even with this low rate, a managed load balancer (e.g. AWS ALB) with a few target webservers will do the trick and let you swap them out as needed without taking down the site. A DB read replica will give you redundancy there as well. This is all 20-year-old tried and true tech. You'll set it up once and it will run for years without trouble.
Once you introduce Kubernetes you've got a whole 'nother beast to feed, especially if it's self-managed, and you'll pay dearly if it's not (like EKS). For your scale, it would be kind of like buying a full sized semi truck to haul stuff for a corner store. You'd be better served with a small pickup or minivan.
Of course you don't need an "at scale" excuse to learn new tech. In which case I agree there's a dearth of practical tutorials that aren't just "here's a Helm chart." Part of this is because managing a stateful service like MySQL on K8s is not straightforward; there's a lot of ways to do it, most of them are wrong, new ways get introduced every few years, and even people who claim they've solved the issue are probably sitting on a time bomb of their own making and have just gotten lucky.
Our platform team got into k8s for some reason at my company. Because it’s enterprise there’s never really the “millions of requests per second” sort of problems because every deployment is single tenant. We have experienced k8s engineers who I guess we’re just using the tools we know, but wow it’s been such a hassle and has caused so much toil. Right now we’re having trouble scaling back ends for parallel jobs with k8s, which is a problem we easily solved with regular tooling in the past pre-k8s.
On enterprises, k8s solves a different kind of scaling problem. You tend to have hundreds of apps that are business critical and need to be managed.
K8s provides a consistent way to package, deploy with HA and monitor those apps. Ideally it replaced tons of ad-hoc scripts and confluence pages that are very poorly maintained.
SRE for 15 years with FAANG (MAGMA?) scale experience; I would argue this, yes. That's a little over 2 requests per minute. If you're cloud hosting then you could get away with single tiny hosts for your front end and DB, like t3.small on AWS, and Cloudwatch alarms for monitoring. If you need extreme HA or burstability even with this low rate, a managed load balancer (e.g. AWS ALB) with a few target webservers will do the trick and let you swap them out as needed without taking down the site. A DB read replica will give you redundancy there as well. This is all 20-year-old tried and true tech. You'll set it up once and it will run for years without trouble.
Once you introduce Kubernetes you've got a whole 'nother beast to feed, especially if it's self-managed, and you'll pay dearly if it's not (like EKS). For your scale, it would be kind of like buying a full sized semi truck to haul stuff for a corner store. You'd be better served with a small pickup or minivan.
Of course you don't need an "at scale" excuse to learn new tech. In which case I agree there's a dearth of practical tutorials that aren't just "here's a Helm chart." Part of this is because managing a stateful service like MySQL on K8s is not straightforward; there's a lot of ways to do it, most of them are wrong, new ways get introduced every few years, and even people who claim they've solved the issue are probably sitting on a time bomb of their own making and have just gotten lucky.