This is a great post for validating management concerns about pulling in sexy new technologies for the hell of it. Every place I've worked I've been unable to convince management to use e.g. Rails (5 years ago) or node.js (recently). Even though I love these technologies and wish I'd had more time in full-time employment to learn and play with them, I understand and appreciate the risks implicit with adopting a shiny new technology in your company's IT dev/production environments.
It's also a great post illuminating how in hindsight some things can be really obvious (that building a high capacity web service dependent on a single-threaded server will give you problems down the road), but at the time it's not always easy seeing the woods for the trees.
For me though, the big takeaway was that one line summary: "You’re comparing a lower level server to a full stack web framework." Node.js has a pretty nice library/module ecosystem now, but for a complete full-stack solution with maximum productivity I would venture that there is nothing out there that compares to Rails currently.
> This is a great post for validating management concerns about pulling in sexy new technologies for the hell of it.
But their old technology is requiring towers with 36GB of RAM. It seems like more of a choice between the devil you know vs the devil you don't. Obviously there needs to be a cost-benefit analysis even if it's imperfect. Otherwise you'll get stuck in a local maxima and before you know it you're paying $10 per million cycles of a mainframe running batch COBOL jobs maintained by old men who are dying faster than you can replace them.
This is a great post for validating management concerns about pulling in sexy new technologies for the hell of it.
At the end of the day, the Rails stuff got the job done. LinkedIn stayed up and was able to grow and add mobile features during that time. The current solution, the node.js stack, is even newer than Rails. So no, I don't think this validates management desires to stay with old technology.
It's also a great post illuminating how in hindsight some things can be really obvious (that building a high capacity web service dependent on a single-threaded server will give you problems down the road), but at the time it's not always easy seeing the woods for the trees.
Um, the new solution is single-threaded too. Threading and concurrency are not the same things.
It's also a great post illuminating how in hindsight some things can be really obvious (that building a high capacity web service dependent on a single-threaded server will give you problems down the road), but at the time it's not always easy seeing the woods for the trees.
For me though, the big takeaway was that one line summary: "You’re comparing a lower level server to a full stack web framework." Node.js has a pretty nice library/module ecosystem now, but for a complete full-stack solution with maximum productivity I would venture that there is nothing out there that compares to Rails currently.