4 ms·
The Author generalized "fewer features lead to less downtime" to "simple systems have less downtime". A simple system such as a hand-written web server is very
by namelosw 5y ago
The Author generalized "fewer features lead to less downtime" to "simple systems have less downtime".
A simple system such as a hand-written web server is very likely to crash. It's very likely cannot serve many users if we don't make it serve requests concurrently. What's worse, one tiny exception in one request would bring the whole system down. It stops serving any request to any user.
A relatively complex system with a self-recovery mechanism added goes a long way compared to the former. The Erlang implementation is much more complex than "an Erlang without processes". Kubernetes is complex, and it definitely gives us less downtime than simple scripts we have written before we use Kubernetes.
The real world is chaotic. If a system needs to strive for less downtime, it needs to have some features that mimic biological creatures, instead of being idealistic simple.
- citrin_ru 5y ago> A simple system such as a hand-written web server is very likely to crash. > Kubernetes is complex, and it definitely gives us less downtime than simple scripts we have written before we use Kubernetes There is a point in between 100LoC hand-written web server and K8s cluster. E. g. you need to serve static files and load is small to moderate (say <=1Gbps) you can do this in two ways: 1. Create a K8s cluster where HTTP traffic will be dynamically proxied to a container running on some set of nodes reading files from GlusterFS cluster. 2. Install nginx on a pair of physical servers (with disk configuration depending on the load: from HDD mirror to SSD RAID 10) and something like CARP for HA IPs shared between them. 2nd option is much simple and in most cases will be more reliable: in theory K8s option can have higher availability but it requires much more effort to not screw up something and much harder to troubleshoot when something goes wrong.
- ocdtrekkie 5y agoMy single Intel NUC in my basement on residential cable serves cloud services at higher reliability than Office 365. Sure, it doesn't do it for millions of people, but it's drastically less failure-prone, despite the lack of resilient design. What boggles the mind is people are often sold the cloud even though their org isn't serving millions of users, and could just as easily operate as a box in a closet.
- Zababa 5y ago> What boggles the mind is people are often sold the cloud even though their org isn't serving millions of users, and could just as easily operate as a box in a closet. Capex vs opex may play a part here. Also, companies in general seems to have transitioned to using services in general. 20/30 years ago companies had cleaners in them. Now everyone uses a cleaning service.
- ocdtrekkie 5y agoI have read about a dozen and a half articles about capex vs. opex, and it still makes absolutely no sense to me why companies prefer paying over double for opex what they'd pay for equivalent capex over the same lifecycle. Either corporate accounting is some mystical art that makes money appear where there isn't if certain practices are followed, or there's some collective mass delusion that opex is just better? I don't know, it's a concept that truly baffles me.
- citrin_ru 5y agoFor a startup it makes perfect sense to avoid high CAPEX: it is not worth to invest into own infrastructure which will have positive ROI in 3 years, if you are not sure that you startup will still be alive in 3 years. Why big established companies prefer high OPEX to lower CAPEX is less clear.
- ocdtrekkie 5y agoIndeed, I fully understand why a startup goes for the cloud: Either it scales fast enough that the dynamic scaling of cloud is key, or it fails and assets become pointless anyways. But even then, once a startup hits a certain level of stability, it makes sense to invest in your own infrastructure to minimize expense.