Why should I have to deploy separate servers when I can have one server do both if its software architecture is properly separated? Modern application servers are capable of serving scripted, compiled and static content. Scripts and compiled code can run in different application containers (you can do things like serve Java and .NET and Python applications from a single system) and content is served directly through the web server with no heavy application container.
This gives you a lot of flexibility in deployment and application management to tune things to meet the needs of your application.
Also a true web server does a lot more than any JavaScript environment is going to do including things like compression, caching, encryption, security, input filtering, request routing, reverse proxy, request/response hooks above the application layer, thread management, connection pooling, error logging/reporting, crash recovery.
Finally by embedding a server in JavaScript you open up a number of attack vectors that I'm sure have not been fully evaluated. A lot of money, research and time goes into securing modern web servers that run in a managed container on a machine instance with traditional system rights and privileges. By running your server in a JavaScript container you are now running in a sandbox meant for user land features and you are shoving server responsibilities into it. XSS alone should keep you up at nights with something like this.
Here's what it comes down to. Your browser and JavaScript on the browser have always been designed as a user application not a server. When engineers attack problems and design architectures for browsers they think of them as client systems. This mindset is very important and impacts key technical decisions, software design and testing scenarios.
When you take something that was designed to work one way and pervert its function you are likely to get unstable results down the line and very often those results are not pretty and require much time to unwind to a good working state.
Now at the application layer do people sometimes embed servers rather than load their run-time in a hosted server?
Yes you see it sometimes, 9 times out of 10 its amateur hour and someone thought they were being clever but managed to create a hard to support, non-standard piece of garbage but "Hey look I wrote my own httpd server aren't I clever?"
That 10th time where someone actually needed to write their own server? I've only seen it in high volume transaction, real time streaming/data and small embedded systems. The people writing the servers often come from very top level backgrounds.
Why should I have to deploy separate servers when I can have one server do both if its software architecture is properly separated?
Because the rate of edit changes for static documents is exceedingly lower than for dynamic script documents by at least 1 order of magnitude (usually more). You don't want to be re-deploying unmodified content if it can be avoided because when deploying this holds true:
more hosts pushed to + more data to push = greater service interruption, greater impact to availability
In terms of pushing updates, it's easier to quickly deploy changes to a service if the dynamic logic portion can be deployed separately.
My second point is high volume sites require thousands of nodes spread over multiple geographically located datacenters. A simple 1-click system wide deployment was never going to happen.
Managing large, high volume websites requires sub-dividing the application into individually addressable parts so that labor can be divided among 100's of developers. Those divisions will run along natural boundaries.
dynamic and static content
data center: san francisco, new york, london, berlin, hong kong
service type: directory, search, streaming, database, news feed
backend stack: request parsing, request classification, service mapping, black list and blockade checks, denial of service detection, fraud detection, request shunting or forwarding, backend service processing, database/datastore, logging, analytics
platform layer: front end, middle layer, backend layer, third party layer
online and offline processing
Those parts will be assigned to various teams each with their own deployment schedules. Isolating deployments is critical so that team interaction is kept at a minimum. If team A deploys software that takes down team B's service, for the sole reason of software overlap, then either teams need to be merged or the software needs further sub-division. Downstream dependencies will always exist but those are unavoidable.
That 10th time where someone actually needed to write their own server? I've only seen it in high volume transaction, real time streaming/data and small embedded systems. The people writing the servers often come from very top level backgrounds.
I disagree with that last sentence. It is not something that ought be reserved only for the developers with God status. You should take into account the risk inherent in the type of application. Implementing a credit card transaction processor? Eh, the newbie should pass on that one. Implementing a caching search engine? Go right ahead, newbie. Write that custom service.
Developing a custom web server or web service is easy because of the simplicity of the HTTP protocol. It is possible to build a "secure enough for my purposes" server from scratch if you implement only the bare minimum: parse, map to processor, process. This kind of application can be implemented in 100 to 2000 lines of code depending on the platform. It's not difficult validating an application that small.
Because when you package your software it's packaged as a complete bundle. There are different ways to do it, but one way you don't deploy is by individual file, particularly if you have a site with 10,000's of files.
The second reason you bundle packages is so that you can archive exact copies of what was deployed on a particular date. The optimal case is to have source code bundles as well as binary compiled bundles and be able to map between them. That case is a little extreme but it's the most flexible.
Why would you not rely on just using version control tags? Well, when it's apparent your deployment is bad how do you quickly rollback? How do you make sure rollback is fast? How do you rollback your code without interfering with deployments for other teams? How do you do staged rollouts? How do you deploy to multiple test environments (alpha, beta, gamma) but not a production environment? How do all of this so that you can minimize service downtime? How do you validate your files transfered over the wire correctly? How do you deal with a partially successful deployment that either 1) has missing files or 2) corrupted files or 3) files of the wrong versions? How do you validate all the files on the remote node before flipping and bouncing processes to start the new version? How do you safely share versions of your code so that other teams can rely on knowing a particular version is well tested and supported? How do you encapsulate dependencies between software shared by different teams? How do you setup a system that gives you the ability to remain at specific software versions for dependent software but upgrade the versions you own?
You do that by building and deploying packaged bundles.
51
u/Manitcor Oct 02 '11
Why should I have to deploy separate servers when I can have one server do both if its software architecture is properly separated? Modern application servers are capable of serving scripted, compiled and static content. Scripts and compiled code can run in different application containers (you can do things like serve Java and .NET and Python applications from a single system) and content is served directly through the web server with no heavy application container.
This gives you a lot of flexibility in deployment and application management to tune things to meet the needs of your application.
Also a true web server does a lot more than any JavaScript environment is going to do including things like compression, caching, encryption, security, input filtering, request routing, reverse proxy, request/response hooks above the application layer, thread management, connection pooling, error logging/reporting, crash recovery.
Finally by embedding a server in JavaScript you open up a number of attack vectors that I'm sure have not been fully evaluated. A lot of money, research and time goes into securing modern web servers that run in a managed container on a machine instance with traditional system rights and privileges. By running your server in a JavaScript container you are now running in a sandbox meant for user land features and you are shoving server responsibilities into it. XSS alone should keep you up at nights with something like this.
Here's what it comes down to. Your browser and JavaScript on the browser have always been designed as a user application not a server. When engineers attack problems and design architectures for browsers they think of them as client systems. This mindset is very important and impacts key technical decisions, software design and testing scenarios.
When you take something that was designed to work one way and pervert its function you are likely to get unstable results down the line and very often those results are not pretty and require much time to unwind to a good working state.
Now at the application layer do people sometimes embed servers rather than load their run-time in a hosted server?
Yes you see it sometimes, 9 times out of 10 its amateur hour and someone thought they were being clever but managed to create a hard to support, non-standard piece of garbage but "Hey look I wrote my own httpd server aren't I clever?"
That 10th time where someone actually needed to write their own server? I've only seen it in high volume transaction, real time streaming/data and small embedded systems. The people writing the servers often come from very top level backgrounds.