Simple Systems Have Less Downtime • Hacker News Board

Re: Simple Systems Have Less Downtime

#261

Post by ailideex » Wed, Mar 04, 2020, 3:26 PM UTC

AnIdiotOnTheNet wrote: post #258

ailideex wrote: post #237

Earlier quoted context omitted.

> compile it from source Way simpler to do on Linux than M$ Windows. > [no way to ] to directly distribute binaries without a gigantic fucking headache. I mean, flatpak, appimage, docker, etc ...

> Way simpler to do on Linux than M$ Windows. Completely unnecessary on Windows since it is an operating system, not a kludge of random source code from the internet. > I mean, flatpak, appimage, docker, etc ... Which of those is ubiquitous enough to ensure availability of what you're looking for in that format? In my experience: none of them. AppImage is easily the best, but the community seems to hate it because it…

> Way simpler to do on Linux than M$ Windows.

Where, pray tell, do people who write the software for this "operating system" store their source code if not somewhere that is connected to the internet? Do they use punch cards?

> Which of those is ubiquitous enough to ensure availability of what you're looking for in that format?

Have not met someone who hates AppImage. flatpak is also rather ubiquitous. I use both every day.

Re: Simple Systems Have Less Downtime

#262

Post by ailideex » Wed, Mar 04, 2020, 3:26 PM UTC

AnIdiotOnTheNet wrote: post #257

busterarm wrote: post #209

Earlier quoted context omitted.

I'm running Arch on my office workstation. I install up to date software literally every day.

Only after a third party makes an AUR for it. I'll stick to an OS where the developer can publish directly to the users without 15 different packaging formats, thanks.

Again, flatpak, appimage, docker ... you can use one of these, don't have to use 15.

Re: Simple Systems Have Less Downtime

#263

Post by AnIdiotOnTheNet » Wed, Mar 04, 2020, 4:05 PM UTC

ailideex wrote: post #262

AnIdiotOnTheNet wrote: post #257

Earlier quoted context omitted.

Only after a third party makes an AUR for it. I'll stick to an OS where the developer can publish directly to the users without 15 different packaging formats, thanks.

Again, flatpak, appimage, docker ... you can use one of these, don't have to use 15.

No, the developer can choose one of these. As a user, I have to deal with all of them because I cannot choose how the developer distributes it and there is no standard. If I could choose, I'd use AppImage for everything (since it is the only one that is portable) but I can't do that.

Re: Simple Systems Have Less Downtime

#264

Post by AnIdiotOnTheNet » Wed, Mar 04, 2020, 4:07 PM UTC

ailideex wrote: post #261

AnIdiotOnTheNet wrote: post #258

Earlier quoted context omitted.

> Way simpler to do on Linux than M$ Windows. Completely unnecessary on Windows since it is an operating system, not a kludge of random source code from the internet. > I mean, flatpak, appimage, docker, etc ... Which of those is ubiquitous enough to ensure availability of what you're looking for in that format? In my experience: none of them. AppImage is easily the best, but the community seems to hate it because it…

> Way simpler to do on Linux than M$ Windows. Where, pray tell, do people who write the software for this "operating system" store their source code if not somewhere that is connected to the internet? Do they use punch cards? > Which of those is ubiquitous enough to ensure availability of what you're looking for in that format? Have not met someone who hates AppImage. flatpak is also rather ubiquitous. I use both eve…

> Have not met someone who hates AppImage

Talk to Drew DeVault, to name one.

Re: Simple Systems Have Less Downtime

#265

Post by rsync » Wed, Mar 04, 2020, 4:09 PM UTC

carterehsmith wrote: post #245

rsync wrote: post #143

I gave a talk on this subject at CU last year and have, one way or another, spent my entire professional life thinking about this topic. I agree wholeheartedly that simple systems have less downtime. I would like to add a line from the talk that I give: Simple systems fail in boring ways. Complex systems fail in fascinating, unexpected ways. rsync.net storage arrays typically have multi-hundred day uptimes. But acros…

"simple systems have less downtime" That is not much of an insight. It is as insightful as saying "water is kinda wet.". Well... sure it is. What we need to deal with, is not "make a simplest system". Rather, we need to deal with: "build a system that does A, B, C, ... and so on". Now, if you can do all of the above and make it simple... awesome. But if you cannot do all of the above, but the system is simple.... tha…

"Rather, we need to deal with: "build a system that does A, B, C, ... and so on". Now, if you can do all of the above and make it simple... awesome."

I agree with this. It is a good point.

Some systems and protocols have very difficult requirements to meet and different constituencies driving those requirements - it's not always possible to implement simple and elegant solutions.

Re: Simple Systems Have Less Downtime

#266

Post by sebringj » Wed, Mar 04, 2020, 4:17 PM UTC

dhbradshaw wrote: post #194

sebringj wrote: post #134

In terms of the little guy having a saas, this is true for me...my saas basically is relying on s3 for both file storage and a json file per account to list out users allowed in the system. The only time it goes down is when s3 goes down or the occasional container restart.

I'd be interested in hearing more details here. Are you saying that you use s3 as your only data store?

Yes...think of it as layers... or manifests that point to another set of manifests global (list of users) -> accounts (have lists of users in them and role), content -> list of json files. I use a combination of json logic or simply listing out keys in a specific bucket...the speed of access doesn't seem to be something that bothers anyone, it started out as an experiment of less is more and because the app is not heavy on db searching etc rather only specific to account. I use oauth2 instead of relying on my own infrastructure and let people send out invites where they would use an email only but it must support the oauth 2 providers i already have in place. Basically, doesn't go down because it relies heavily on other things working that has teams of people working on them with gigantic resources. Don't get me wrong...I'm not saying it will scale to a million users, my clientele is mainly corporate that have a good amount per account sale but if it needs scaling, at least i didn't waste time and money on it during the interim and can always db-back it or dynamo it later.

Re: Simple Systems Have Less Downtime

#267

Post by dbg31415 » Wed, Mar 04, 2020, 4:35 PM UTC

gk1 wrote: post #125

dbg31415 wrote: post #43

"[The] more simple any thing is, the less liable it is to be disordered, and the easier repaired when disordered..." - Thomas Paine, Common Sense, 1776

Perfect. Added it to the essay. Thank you!

Took a few years, but glad that Government degree finally came in useful! (=

Re: Simple Systems Have Less Downtime

#268

Post by nradov » Wed, Mar 04, 2020, 4:57 PM UTC

krab wrote: post #218

nradov wrote: post #157

Earlier quoted context omitted.

That has nothing to do with the release cycle. A large monolith can still do continuous delivery and release multiple times per day. What tends to slow down is the feature delivery cycle.

Would you care to explain your reasoning? This topic genuinely interests me. My experience is quite the opposite. To deliver a feature, you still need to integrate changes in multiple services. To do it in a monolith is IMHO easier. You have a single artifact you can test, the probability you have the right automation is higher. Also, the devs will run bigger part of the system in the development version. What I was…

There are no hard rules. In general a microservices architecture tends to enforce segmentation which makes it faster to iterate on features that only impact a single service. But coordinating larger changes across multiple services owned by separate teams can certainly be slower.

Monolith architectures often degenerate into the proverbial "big ball of mud" over time. But if the team has the discipline to maintain proper design through continuous refactoring then they can retain the ability to deliver features with short cycle times.

Re: Simple Systems Have Less Downtime

#269

Post by downerending » Wed, Mar 04, 2020, 5:18 PM UTC

thijsvandien wrote: post #249

downerending wrote: post #177

As a sub-case of this, almost every HA (high availability) system I've ever seen has been less reliable than the original system was (without HA). It sounds like a good idea, but the extra complexity kills it. One non-software system was a rather expensive UPS/generator. It was meant to trip on a power loss and provide X minutes of stable power. In reality, it was incredibly sensitive to minute power fluctuations and…

At least for the relatively small businesses that I deal with, I basically always recommend to save the effort that would go into building a 'highly available' system, and instead spend it on a scenario for keeping the business running when tech fails—which it will to some extent at some point, no matter what. I suppose that line of thinking would do wonders for much larger businesses as well. When a system becomes t…

Indeed. It shocks me when I see boo-coo bucks being spent on all sorts of bells and whistles, and then ask about their backup strategy. Oh, all of our drives are RAID...

Re: Simple Systems Have Less Downtime

#270

Post by vaingloriole » Wed, Mar 04, 2020, 6:25 PM UTC

ignoramous wrote: post #130

nickbauman wrote: post #114

Earlier quoted context omitted.

They chose Erlang. A language built for communication and managing wire protocols at scale. Which describes WhatsApp itself. That was probably the biggest impact single decision for WhatsApp technically.

I am not sure if WhatsApp engs chose ejabberd because it was written in Erlang or because ejabberd was the defacto implementation of XMPP. They stumbled upon and fixed bugs in BEAM/OTP at their scale [0][1][2]. They also ran FreeBSD (for its superior networking?) on bare-metal hosts running customised system-images [3] and employed networking experts at some point. [0] https://www.youtube-nocookie.com/embed/c12cYAUTX…

'customized systems (kernel)..FreeBSD..bare metal': Which is what most of us still do if we care about performance for a single application. Running openmp fortran code for both host/accelerator on oversubscribed vmware or vanilla kvm/qemu for a good laugh and a lot of pain. Simple systems approaches are best even when what you are doing is complicated.