7 ms·
Pretty accurate. Everything I've seen that doesn't scale only doesn't because it was written by idiots who read lots of blog posts about scalability. I'm still
by wrldos 4y ago
Pretty accurate. Everything I've seen that doesn't scale only doesn't because it was written by idiots who read lots of blog posts about scalability.
I'm still convinced we could run our entire software platform off 5 EC2 instances and an S3 bucket. But the last 10 years of technical mismanagement turned this into a microservices shit show. Splunk gets more traffic than our clients do.
- hkt 4y agoSimilar situation where I've arrived recently: a big public sector org where the biggest expense each month is cloudwatch.
- durnygbur 4y agoTry to say "no" or even "but" to the logging and monitoring request ticket... do you like having monthly income or not?
- smitty1e 4y agoBut we loves us some info porn.
- wrldos 4y agoData lake after 2 years = data cesspit.
- durnygbur 4y agoSoon consultant will be selling wastedata treatment systems.
- wrldos 4y agoThat's a brilliant idea. /dev/null as a service. Charge per byte.
- MikeDelta 4y ago> Charge per byte of unzipped data
- iso1631 4y agoI'd couldn't afford my backups then!
- wrldos 4y agoI guarantee we will not be upselling AWS egress fees to you though so think of the cost savings on recovery!
- exikyut 4y agohttps://devnull-as-a-service.com/ https://devnull-as-a-service.com/ - https://news.ycombinator.com/item?id=6637480 https://news.ycombinator.com/item?id=6637480 (2013) :v
- jbverschoor 4y agoOr just 1 or 2 physical machines?
- wrldos 4y agoWell we still need to handle AWS losing a region and hardware replacement. Does happen quite regularly.
- imwillofficial 4y agoBut do you? Do you really need those 5 nines? If my bank can go down every week for patching, you probably can too.
- wrldos 4y agoOur customers can't operate at all if our systems are down, so yes we do.
- mechanical_bear 4y agoI’m sure your customers can go down for a minute every other week.
- pixl97 4y agoIt doesn't matter if they can or cannot. This is what happens when you think like an engineer and not like a salesperson. What matters if they will pay someone else for that reliability they don't need.
- itsmeste 4y agoThe last 5 years I found myself developing for companies having a bunch of nonsense "microservices" with totally ridiculous separation, which added more to their problems than solving them. The common denominator of those companies is they all had no significant traffic, had their initial codebase developed by (unmanaged) amateurs, and were later managed by people inexperienced in software. Due to the heavy resistance in all cases, I eventually became tired of proposing simpler solutions and the endless discussions around it, and accepted premature microservice architectures to be part of my infinite source of income.
- rippercushions 4y agoMy favorite microservices pattern is having lots of separate little services, so you get that sweet overhead and complicated debugging, with a shared database, so you can still enjoy systemwide single points of failure and obscure side effects on data.
- itsmeste 4y agoHave those microservices use different patterns (language, framework, infra, etc), and outnumber your devs by a magnitude so everybody gets a piece of that sweet context switching, multiple times a day.
- dopidopHN 4y agoLast job I had to ask to confirm the number: 124 services. And it does not work very well. My team was hired to contains and replace it. We ended up with 3 service. Exact same API is provided. It does not matter : nobody is using it anyway !
- wrldos 4y agoAh I am gorging myself financially on exactly that form of sweet misery.
- majormajor 4y agoI was complaining recently to a manager at another company about a half-assed "microservice breakout" project in a previous job where some teams moved from one big service + one big DB to many big services + single DB and introduced fun new DB connection + perf issues... and was dismayed to learn that this other manager didn't even think "a bunch of services all talking to the same giant DB" seemed like best practices.
- mypastself 4y agoAdd to that an existing monolith that’s only been partly migrated to microservices and brother, you’ve got a stew going.
- Scubabear68 4y ago
- neilv 4y agoOne time, I had to put together an architecture diagram for a big investor presentation (diagram of an unusual bespoke many-servers system). Basically, get boxes on the diagram for each aspect the exec might want to talk about or answer questions about. So that they'd have something to point to, and investors would have some level of understanding, as well as confidence that we thought of and were doing something about each thing. (This is a bit different than the diagrams we were using to discuss and build it internally.) So I mention to a colleague that I "just know", if a room of tech investors see the Web facet of this (even though that's the easiest technical part of the system), and this one part is all going through only one server (which is all it would ever need), someone is gonna be concerned that we might not know what we're doing about scalability, and I bet the exec doesn't want to get derailed debating that with them. Colleague advised we go full "System Design Interview!", so I spewed all the unnecessary vapid things we could do, that some semi-technical person might be tuned to look for. Trying to modify the spew to be sensible enough (if encumbering overkill) that, if investors happened to have a hardcore veteran techie vetting (like one of the people who built AWS or Google from nuts and bolts), that they wouldn't become enraged with disgust, and kill me where I stand. The investor meeting seemed to go well. In a different (real, internal) diagram, for networking architecture, I also broke out out some logical functions into distinct physical servers (some fixed, some variable) in an information/control flow compartment. Then I added a comment on the diagram, something about that these might be combined into a single server for efficiency, for smaller deployments, like customer on-prem. And, I didn't add, if our own data center suddenly needed to host a hugely-popular service for others, and we suddenly had enough hardware for that, the software would be ready (but we'd still only need one server in that one spot that a System Design Interview book-prepped person would think needed a load balancer and workers).