Yes. I saw the last days of a VMS cluster (actual VAX not Alpha) system being ported to windows/vb/com/asp. The speed difference was actually incredible. It ended up on a mediocre single Xeon 500MHz P3.
At the end of the day, the windows based system was just as reliable as far as nines went and tens of times faster.
This was only just recently replaced with asp.net I understand. They got nearly 20 years out of each rewrite.
You're confusing hardware speed with the software/IPC measurement - the fastest VAX machine ever made ran at 100Mhz (or maybe 120), with 10Mbit ethernet and SCSI-2 I/O paths (1MB/s on a disk or so).
If you found a 486/100 and compared raw compute speed, the vax would likely have won for most cases, because it has 4x the registers.
I'm not actually sure about the clustering IPC performance, but you are essentially comparing hardware about 3-4 generations apart and blaming the software for the issues.. if you were comparing with 500MHz Alphas, etc, then you might have a point..
It's perfectly reasonable to put your credentials and configuration into a VCS if any secrets are in ansible vault or something similar.
I reckon they either stuffed it all in as plain text or someone got hold of their source code and found a stupid hole in it and just read the database file off the front end somewhere. It's not unusual for the unclued to stick a database dump on a front facing web server with a "secret url" and just pull that down with curl or something.
It's really never reasonable. Even if your VCS is already secure, inserting credentials means bringing it up to spec with actual credential storage policy, even if that means inconvenience to the developers - and if it's not inconvenient, your policy is probably too lax in the first place. There should be a total separation of concern between your code and user credentials.
Ansible vault, separate repository to the code and you're fine. You're up shit creek if you lose your code too unless you're 100% perfect so there is no distinction in policy.
Hell if you're using vault you might as well chuck the config in with the code. The vault key distribution is what needs to be controlled.
There is a real difference in company impact between leaking your code and your credentials. If your code and credential policies are the same, your company has a serious problem of priorities, since it's either not protecting credentials enough, or it's slowing down developers too much.
I'd argue it's cheaper scaling out the monolith or introducing isolated functional silos and scaling them out than even bothering migrating everything to microservices. Also you certainly can't port a complex monolith to microservices; you have to start again. We're quite happily able to shift 15,000 requests/sec from over 2000 http endpoints with a monolith and our kit is at ~20% capacity. Need more? Slice up a silo some more.
Key aspect when you design the monolith is not building a spaghetti monster. If X doesn't need to talk to Y, put a wall there (package level)
> Also you certainly can't port a complex monolith to microservices
Upvoted you, but I disagree with a little. "Microservices" tend to pathological cases, but you 100% can segment a monolithic apps into services. Each module in your application has an interface. Behind that interface, replace it with network calls that fulfill the interface's contracts. (If your monolith doesn't have sections that encapsulate work--well...kinda did it to yourself, but that IME is rare.)
You can, hence my comment about silos. The interface is rarely well defined enough to be able to abstract it over a network boundary from experience. One of the things I see in a lot of monoliths is leaky abstractions and they are really difficult to reign in.
We tend to go for throwing related web front and and API endpoints into the same ball of mud silo and back end that directly with the storage and cache services. We scale those silos up and partition across tenants too. I think a couple of the silos are around the 1 million LoC size now as well.
Fair enough. In places where I've had to deal with that, I was in the code review seat ahead of time and was generally able to go "no no no, let's not do that"--but I can see how stuff can decay.
> Behind that interface, replace it with network calls that fulfill the interface's contracts
Just like that?!
You can encapsulate work fine, without making microservices at all easy to retrofit. There's a big difference between calling a function that does something and returns a result, and calling a function that does nothing until you've gone back to the main loop to handle network input.
(You can confront many of these issues by implementing your services as threads from day 1. Decoupling request and response is a major issue, and this will force you to do that straight away. The other issues associated with moving from single process to multiple processes are fairly minor by comparison.)
> There's a big difference between calling a function that does something and returns a result, and calling a function that does nothing until you've gone back to the main loop to handle network input.
the difference is latency, so of course you put extreme low-latency operations inside the same service.
That. Most folks understand services as separate codebases, running as separate deployments. My take is that they are logical entities to a degree where their physical implementation is irrelevant to their clients.
About 50% of the companies I consulted for between 2004-2013 had no issue tracker. Most emailed and/or emailed spreadsheets around.
What's even more shocking is about 25% of them didn't even use a VCS, most relying on some poor guy to sit there with a diff tool and merge everyone's shit into something cohesive. One company used a wooden spoon as an ownership lock.
A few weeks ago, someone had a thread up asking what people did to help them get past impostor syndrome, and I had a stab at writing up an answer that revolved around "realise that if you read hacker news, you're probably inside a quality bubble. Look at how bad some people who are employed in software are at their jobs and get some perspective".
I ended up deleting the comment without posting it because I didn't have any good examples that I felt I could talk about in detail.
This is a great one though. To everyone on hacker news, if you ever feel inadequate about not writing as many unit tests as you know you should (or whatever is bugging you), remember that time Staofbur found a whole company of people so clueless they used a wooden spoon instead of version control.
Yeah you should probably write more unit tests, but overall, the fact that you even know enough to feel worried about that makes you the cream of the software industry. There's a whole pail of rather thin milk below you.
Hey, the spoon worked well, until I bought another one and left it in the office :) They had SVN running for everyone a week after and a month later they were running feature branches.
Just last week, I witnessed a meeting where a QA guy said he doesn't want to update any jira ticket as it should be the business analyst who updates tickets?
More strangely, not everyone can open a pull request. I can understand not everyone being able to merge but not being able to request a merge? Is say your team was better than what I witnessed even when they didn't have version control.
> "until I bought another one and left it in the office"
Ooh! You mean 'whoever has the spoon has the lock', type thing? I genuinely presumed you meant, 'don't mess up this code with conflicts or you'll get a smack of the wooden spoon' :D
Yes it was a "hardware lock" i.e. the holder of the spoon was allowed to diff their copy with the master on a file share and update that. The spoon was used as a casual weapon to beat idiots as well in jest ;)
A lot of the companies, software was a function of the business, not the business itself. There was no motivation for the staff to do anything other than minimal effort or even research what their job was about. There was no pride, no ingenuity or creativity. Inevitably this descended into chaos and then I got hired to unfuck the places. Some places you couldn't fix because they were too cheap, too lazy and didn't want to make a change because they were in denial that the poo was actually already over the fan blades.
It was depressing and if I'm honest it made me physically ill and I folded the company and got a permanent job with a company that wielded the clue stick.
Indeed. Apparently some of the human race loves suffering!
To be honest, even though we were just pulling TortoiseSVN into most of the companies, some people just couldn't figure it out even after being bought books, reading the manual AND sitting in training sessions for hours where we hand-held them through every day use cases.
They could, because it also points out the UK had the "fastest reduction in deaths amenable to health care in the past decade" i.e. the most improvement in that category.
If you take a look at the raw data, you can see the basis of comparison (four major diseases: heart attack, stroke, breast cancer, colon cancer, + overall mortality data). The biggest outlier for the UK is clearly the cancer survival rate, where it is more than two standard deviations worse than average and this has been known for some time. The underlying reasons are complex, partly social, mostly ones of late diagnosis, partly due to failure to implement good screening programmes; reports on the topic vary in their tendency to blame patients for presenting late or for comorbidity factors, but here's one of the more measured, from 2011: https://www.kingsfund.org.uk/sites/files/kf/How-to-improve-c...
Most tellingly, with breast cancer, a 2008 report suggested that if you remove all the women who die within a year of diagnosis (whose cancers were likely to have been diagnosed at a very advanced stage), then UK survival rates fall into line with the European average. In other words, the UK has a problem with late diagnosis.
Note that the UK also has a better cancer registry. Germany only captures 1% of the population, the UK captures 80%. Unsure whether the OP report has attempted to detect any resulting skew in the statistics.
Bottom line: if the UK improves the five-year cancer survival rate to OECD standards - and note that the data in this report is from 2015 - then it will flip its position in those rankings and totally cement the #1 position overall.
Back in about 1999, I was working for a big corporate and one of our Oracle admins lost her shit and had a meltdown, think it was around 8i era. She just got up and walked out shouting "fuck this fucking shit, I quit". This was on a freshly delivered HP N-Class HPUX box and they just couldn't get it to run after a month of going back and forth between HP and Oracle.
I bumped into her last year at Ansible Fest London and she was still angry about it 17 years later!
And that's what Oracle does to your soul :)
Edit: that N class and Oracle NEVER got deployed in the end. It just sat there unused, licenses weren't renewed, it got sheepishly powered down after a few months to save electricity and it got chucked in a skip after 5 years. About £200k of expenditure down the pan.
Yeah a big chunk of that was consultancy, support, Oracle licenses. TCO was going to be around £500k for 5 years.
The whole platform got replaced with SQL Server on a clone PC server in the end which cost less than £10k. No fan of Microsoft but there was no competition. And the tooling was far better!
When I get issues were vendors point fingers at each other I three way call them, tell them what's up, hit mute, go get a coffee, and let them figure it out.
Oof. You should bill them for your time. I sent HP or Dell (can't recall) an invoice for $800 in my early 20s for my time wasted on a support call where a "support tech" had asked me to reinstall Windows as a way to fix a disk that failed in a RAID array. OS was AIX.
Another bit of advice I can give from dealing with a few particularly shitty vendors is that if you can't actually download a copy from their web site or extract one from their sales team and see it in action yourself, they have something to hide.
This is usually cost escalators, a really poor deployment and management story, an upsold incomplete product or just a wall of lies.
Also refuse to buy a license until you trial it on your own kit.
