There is no "one right answer" as to which enterprise platform is best. Every project has a unique set of requirements and constraints. Each team consists of some group of people with some body of skills/experience. I have found it best to avoid getting religiously attached to any architecture or platform. I ask myself and my team "how do we best solve the problem the business has and deliver a great experience to customers?" I am currently engaged on a project where despite having C#/.net and PHP on LAMP stacks already in production at a large entertainment company, we opted to use node.js for a specific use case. The proof will be in the pudding after years in production, but so far node.js, CoffeeScript, MongoDB and Redis seem to be the right tools for this set of requirements. That said, I would not attempt to use node.js to cover all the use cases you specify in the original post. There are certainly people that would argue it is suitable for that, but I would not be one of them. Last thought is do a little research and see who IS using node.js and talk to them. I did this as part of my due diligence on this project. I also talked to those adamantly against using it. You have to decide what offers the right risk/reward ratio for your specific project. You will most likely end up with different tiers of your enterprise back-end with different tools for different needs.

Sure what you say is true. There will always be work for true experts with experience. But people just entering the field need to consider how things are changing. The company I work at does not have a single server in house. We don't rent rackspace at colo. We are 100% cloud based. We consume SaaS services. We've been looking for a web ops lead and getting resumes from traditional IT people who are clueless about the new tools like Amazon EC2/S3, salesforce.com. They list off credentials about how many flavors of hardware switches they can configure. Those jobs are diminishing for sure. We can write off the anon poster as a poser. But some of the points he makes are indeed part of the reality facing IT. I've seen a number of great points in the comments here about regulations, privacy, yielding control of mission critical apps... But the solution isn't to cling to the past--its to look forward and say "how can we solve these problems in the cloud." For giant corporations maintaining server farms and in-house ops may make sense, but increasingly the services they need to remain competitive will be consumed over the cloud meaning they are suddenly thrust into the same problem space as a small startup PLUS all their existing challenges. I'm always amazed by the number of people who attack questions like our anon poser asked. It almost seems they are trying to convince themselves that their skills remain relevant. None of our micro-skills will be relevant forever. It's the macro-skills that matter. It's the problem solving skills that carry us forward. Of course the rules of the game will constantly evolve. A focus on hardware-side of IT will certainly limit your job opportunities in the future, whereas understanding how to configure and secure business workflows on the cloud will grow. So sure the poser may have been a newb, but if he's considering entering the IT workforce as a career, he's asking the right questions.

I was once in charge of some important software for one of the top 3 software companies. When we went into code freeze and I took a couple of days off my team had too much time on their hands and inserted some easter egg code. I went ballistic when I found out. It was inevitable that I would find out since I diffed the code regularly to make sure nothing had changed. Many argued that the code was "guaranteed harmless". But a seasoned pro would know better. There is no "harmless" code changes after code freeze. When QA has covered as much code as possible and verified a given build shifting even a single byte COULD cause a new problem to surface. So although I enjoy a good easter egg and I am certainly vain enough about wanting credit for the major products I've shipped, I can't condone the addition of an easter egg late in the lifecycle. If you really want an easter egg, build it early in the lifecycle so the code is validated with the "feature" in place. Of course, if you have enough time to design and test a good easter egg, then you have time enough to add another feature that the marketing department would just LOVE to have! So bottom line is easter eggs signal to me a team with misplaced priorities.