But if the CDN is serving your static assets, your origin webserver only has to generate them once[1] to populate the CDN. It almost doesn't matter how long this takes. And this works well enough that you don't need to bother setting up an Nginx or Apache instance at all. And furthermore, you don't have to copy your static files anywhere -- just use your framework's built-in webserver for everything!
This greatly simplifies your production deployments and in my books that's a huge win.
[1] well... that fudges it a bit, since each POP needs to make its own fetch, and the assets can theoretically drop out of the CDN's cache; so the truth is actually "a handful of times" instead of "once".
How you use a CDN is site-specific. Some people still need to serve hundreds of thousands of requests via a caching frontend layer separate from their CDN origin. It's silly to assume you will never need a fast web server, because unless you aren't serving dynamic content, you will be serving content yourself and the rate will be consistent with the number of users, among other things.
Using a CDN does not actually simplify production deployment, it complicates it. It's an extra layer of complexity, and one you don't know very much about since it isn't your gear. You need an API hook (or a web interface) to invalidate old content when you publish new content. You need a contact with whom you can figure out why a tenth of your users can't route to the CDN all of a sudden, but can route to you. You need to get all your headers right so you don't accidentally push an invalidate to all content and kill your slow-ass origin with new traffic.
Finally, as someone else mentioned, using a framework webserver for production is A Bad Idea(TM). Only one of the reasons why is poor performance. Several others are security, compatibility, cache control, access control, privilege separation, stability, high-availability, virtual hosting, and about a billion other features that webservers have been designed to handle for decades that you will need to reinvent the wheel for with your application framework, which was never intended to be a webserver.
The reason your framework has a webserver is it's the simplest way to get the dynamic content from the app server to the frontend proxy. For example, AJP is such a huge pain in the ass that most Tomcat admins I know use http to communicate between app server and frontend (and it's more compatible). But would they use Tomcat as their production server? Not if they wanted to stay sane.
I wonder if anyone actually use the framework's built-in webserver for everything! Sounds Great and i wonder what happens in practice. Anyone know of any real world usage on this?
This greatly simplifies your production deployments and in my books that's a huge win.
[1] well... that fudges it a bit, since each POP needs to make its own fetch, and the assets can theoretically drop out of the CDN's cache; so the truth is actually "a handful of times" instead of "once".