I think it's safe to invoke Betteridge's Law here.
Anyone working in this space can tell you that's still the age-old discussion: Wether it was mainframes vs. microcomputers, containers vs. VM's, microservices vs. monolithic applications. Sometimes a particular architecture was preferred, sometimes the other. And none have gone away for good, and none have taken up the market completely. Essentially, the answer depends on your requirements (And the world just isn't binary).
The only thing that's for sure is that distributed systems are here to stay – but how you call the various abstraction layers forming them up really doesn't matter. All that really changes (currently) is the size of the market, or the shares therein.
Some of you might remember that we did the 'cloud' before it was called as such, and while the terms I/P/SaaS weren't known under this moniker, it was already in use.
> I do feel that the replication/failover story needs a lot of work, but there's been some progress towards getting it in the box. Even digging into any kind of HA strategy is cumbersome to say the least (short of a 5-6 figure support contract)
Eeeh...a simple HA solution can be developed in about a week (I was able to do so on 9.3, and so far, it held it's ground). Also, now with 9.5's pg_rewind you can easily switch back and forth between nodes (http://www.postgresql.org/docs/9.5/static/app-pgrewind.html), simplifying things a great deal. Can't imagine that's 5-6 figures.
I agree that you don't get a Plug&Play-Solution out of the box, but from anecdotal evidence they often don't quite work as advertised anyway (remember 1995? And I'm sure your friendly DBA has some stories to share as well).
> (...) the "doesn't matter, I'll be dead soon" card.
This mindset is what creates a _lot_ of problems; while some decisions do not matter greatly for oneself, they do for others and/or even more so for future generations.
I think many people grasp this concept in the context of polluted oceans et al., but fail to do so when it comes to the real-world manifestations of 1984 and the like.
> They are also dirt cheap to buy ($20 - 30K) but they burn A LOT of fuel.
She does. However, given a well-maintained engine, and 10 to 12 passengers, cars are easily rivaled, and given favourable conditions, even undercut. We did the math, briefly said, the plane has a higher cruise speed, and can fly in a straight line between destination, etc. pp.
> I'd always day-dreamed about getting one but I can't imagine it's practical.
Well...I co-own one with some other crazy blokes. While a 3.5-ton dry mass can't be put into the bike rack in front of your house, it hardly affects your daily life. I.e. she's next-to-none more inconvenient than owning a small Cessna or the like.
Edit: Judging from your user name, there's a different story though. From what I've heard, the U.S./FAA doesn't really like this soviet plane, and you've got some artificial prohibitive rules on it (compared to Europe).
> Interestingly, it doesn't even trade maximum speed for being unstallable.
Depends on how you interpret it. The bi-plane design does impose quite a drag at higher speeds. There has been research into making the design faster, so far, that meant getting rid of the lower wings.
On the other hand, the designer never intended her to go fast.
For those of you located in Switzerland; you can "hitch" a ride at http://an2.ch – though you must become a club member or ride as a guest of another member (This is required by swiss law for non-commercial flights). Another possibility is to show up at airshows; where tours may be, and are given to the visitors for a modest fee.
It's quite an impressive experience, especially while starting, when the audio of the power plant's huge displacement is felt by your stomach.
When I read your responses, I can‘t shake the feeling I'm talking to some snake oil salesman in a nice suit.¹
And to be honest, GUN‘s docs sound similar. Heavy on how to use, and how awesome everything is, but as soon as one tries to understand stuff, it‘s either WIP or “team up with me/us!”. eyebrow rises
And the claim of “building up connection with academics and hiring them” falls perfectly in line with this. Why the hell can‘t you describe what you did by yourself? If it's so awesome, why don‘t you just die to explain it to everyone who asks? Or, $DEITY forbid, should the “academics” lend some credibility to GUN, even if it's with just their title? What's this HAM about?
Maybe it's just me, but all this with a rather complex naming convention (souls...) and code...
eh, I'll go with “show us teh algoz”. Or describe it.
¹) To illustrate: « I'm actively working [...]» – I'd like to see you passively working.
Usually, there are practically no downsides to it, unless there is a fundamental problem in your $ORG.
1. First of all, it will get you connected to the users which depend on your $APP/$SYS. Hard. You will get to know their struggle/woes - it's not just some ticket you can work on at your leisure.
2. If it's your stuff that causes problems, you will get your shit together and make sure that it works, code defensively, and test thoroughly - whatever necessary. After all, you don't want to deprive yourself unnecessarily of sleep – or others, after the experience.
3. If it's not your stuff that causes problems, you'll get the oppurtunity to “yell” at the people responsible for it. And they must act on it - nobody cares on the why or what, if people have to get up in the middle of the night, it costs the company¹, and everybody gets upset.
It only impacts your health if you get called up regularly, and no actions are taken to remove the root causes of it. Or you can't take any.
It's less of a technical problem, but more an organizational one, so – as it already has been said in here – you should talk to the people of the team, not HN.
As most of the times, there are about a hundred different – not all of them necessarily better – ways to achieve the goal of this project. No issue there.
Putting part of such a project to $SHAREDHOSTINGSERVICE however, that's were I'd stop.
Then again, more sensitive stuff floats around on the intertubes.
(Also, not serving it by yourself feels like stopping halfway, and not in the hackers-do-take-shortcuts-way).
Anyone working in this space can tell you that's still the age-old discussion: Wether it was mainframes vs. microcomputers, containers vs. VM's, microservices vs. monolithic applications. Sometimes a particular architecture was preferred, sometimes the other. And none have gone away for good, and none have taken up the market completely. Essentially, the answer depends on your requirements (And the world just isn't binary).
The only thing that's for sure is that distributed systems are here to stay – but how you call the various abstraction layers forming them up really doesn't matter. All that really changes (currently) is the size of the market, or the shares therein.
Some of you might remember that we did the 'cloud' before it was called as such, and while the terms I/P/SaaS weren't known under this moniker, it was already in use.