If you don't care about downtime or reliability, sure.
Reliability through redundancy is simple, particularly when you aren't replicating multiple machines / machine images.
131–140 of 251 posts
If you don't care about downtime or reliability, sure.
Reliability through redundancy is simple, particularly when you aren't replicating multiple machines / machine images.
Earlier quoted context omitted.
> It's the worst, I don't even get to see my server logs because "that would mean giving you access to the entire thing". I'm not a k8s person but surely that has to be missing something. I'm pretty sure it's possible to configure access to logs, not to the entire thing (whatever that means). He's probably lazy and does not want to bother. Besides, you should have centralized logging using loki or something similar.…
Isn't that just because Kubernetes makes it unreasonably hard to configure access to logs like that?
Can the majority of webapps run on a single machine? Probably. Do most of your customers expect close to 100% uptime? Yes. Does one machine provide the uptime required by your customers? Most definitely not.
(Regular maintenance meaning OS updates needing a reboot, which happens like what? Once per month for a minute?)
Gonna throw out an anti-cirlcenjerk take: We know. Absolutely no one has ever said that your super basic webapp that has the latency requirements of "make sure it works", an SLO of "it's fine most of the time", and a code base under 10k lines of code worked on by one guy, needs these super complicated systems. Even FAANG will run internal services and dashboards on a single binary, but when every second of downtime c…
I can confirm. I've had quite a few projects that made it to the front page of HN and handled the traffic like cake. All of them ran on 5$ digital ocean droplets. I accept some projects are more resource expensive than others, but majority of the time you can get away with a bit of asynchronous responses + scheduler/queue to spread the load horizontally over time. Unpopular opinion: I blame the new age devops culture…
I think that the $5 tier is a little tight for a web app as opposed to a crud app, but 2x $40 tiers is enough for a decent amount of traffic, with one as a failover. The problem is that containers are excellent, and IMO there's a gap in the market between "I want to run one container" and "I want a fully managed k8s cluster"
Earlier quoted context omitted.
> It's the worst, I don't even get to see my server logs because "that would mean giving you access to the entire thing". I'm not a k8s person but surely that has to be missing something. I'm pretty sure it's possible to configure access to logs, not to the entire thing (whatever that means). He's probably lazy and does not want to bother. Besides, you should have centralized logging using loki or something similar.…
Isn't that just because Kubernetes makes it unreasonably hard to configure access to logs like that?
But doing proper users on k8s is hard. I suspect they just run with admin credentials and no real way to generate users.
Earlier quoted context omitted.
> All those things you (a developer) could mostly clone, slightly customize and ship both to a development k8s cluster and to a prod k8s cluster (with all the safety nets already in place). How did/does the devs create, test new code and debug issues? Can they do that locally on their local laptop? If so, how?
> How did/does the devs create, test new code and debug issues? Can they do that locally on their local laptop? If so, how? All those questions are irrelevant to how software gets deployed. Do whatever you want on your laptop.
The underlying orchestrator definitely affects how the software needs to behave and is definitely not irrelevant.
Earlier quoted context omitted.
> I've never come across a devops person who'd say "Hey, that sofware is too simple to prematurely scale for sudden spikes of irrational amounts of traffic, so why not just deploy it on a cheap vps?" Was a devops engineer at my previous job. We already had k8s clusters setup, pre-made CI templates and pre-tailored helm charts (along with monitoring and much more). All those things you (a developer) could mostly clone…
Yes you took the bait! > This was at a 100+ developers organisation. IMO the vast majority of software development happens in much smaller organisations than that. Dev Ops still matters there, and the requirements are different. I am working in an organisation with one and a half developers. I am lobbying that the third of fourth developer concentrates on Dev Ops here. It is very important. Look at the back up/recove…
not sure you're doing the right thing here. you might want to consider hiring some kind of linux guy that can can do some basic devops. or maybe hire some devops contractor that can work with you on a part-time basis and "curate" some specific aspects of your operations.
I've seen this done in the past: so you've got this consultant on retainer, and you tell them something like: "i've got this issue, can we do something about it? our constraints would be x y z" and the consultant would make 1-3 proposals (different approaches, different pricing levels, different ETAs etc) and then you agree on what gets done. The key aspect here is that a good devops consultant can get stuff done very quickly.
> It is very important. Look at the back up/recovery procedures at your organisation. Has there ever been a fire drill? Are you sure the back ups are sound? Can you recover? What if data corruption occurred a week/month ago. Have you a back up of the uncorrupted data?
Yes (to all questions). I ended up in working in heavily regulated environments. All the things you mentioned were not just niceties, but mandatory by legal requirements.
> That is a very unsexy aspect of Dev Ops, and without somebody dedicated to the job, your backups will not be any of those things.
That's basic system administration. Most devops engineers are former sysadmins.
Gonna throw out an anti-cirlcenjerk take: We know. Absolutely no one has ever said that your super basic webapp that has the latency requirements of "make sure it works", an SLO of "it's fine most of the time", and a code base under 10k lines of code worked on by one guy, needs these super complicated systems. Even FAANG will run internal services and dashboards on a single binary, but when every second of downtime c…
You don't even need to be at FAANG-scale for this. Once you have paying customers, you care.
I can confirm. I've had quite a few projects that made it to the front page of HN and handled the traffic like cake. All of them ran on 5$ digital ocean droplets. I accept some projects are more resource expensive than others, but majority of the time you can get away with a bit of asynchronous responses + scheduler/queue to spread the load horizontally over time. Unpopular opinion: I blame the new age devops culture…
The current DevOps culture comes from the FAANG guys who really are getting a bazillion requests per second. In the last decade I worked for Amazon, Avalara and Audible Magic. None of these could build an app around a Digital Ocean droplet.
But I think you're pointing out there are PLENTY of useful webapps that can run on a minimal system.
I'm just curious where the middle ground is. Cause I think we've all seen sites blow up after a reference on HN or SlashDot or whatever and by the time you get there the only thing you see is a stock error from the PHP engine saying "My MySQL Engine is Melting" or somesuch.
It would be very cool if one could write an app using {NODE|Ruby|Python|Whatever} and have the infrastructure around it notice when things spike and do some magic under the hood to spin up new containers in geographically distributed data centers and scale up a simple persistence tier.
That way you could move forward with a SIMPLE application instance and not freak out that you'll disappoint new users if there's a spike in demand. You know, sort of like what AWS Lambda was supposed to be.
Hmm... I think I might have come up with a plan for my next startup. Thank you for speaking your truth.
[Edit: To re-iterate, I think I'm saying it's just as wrong to think a small, simple app needs Amazon-level redundancy and immediate scalability as it is to say Amazon could run on a single machine. But... the "Slash-Dotted Website Goes Down" scenario is real and there should be SOMETHING the industry could do that's easier on people than to force them into a custom AWS ECS solution across multiple continents.]