It is often a reasonable strategy to use the same server process, because the type-of-traffic in each case is consistent with what a web-server is designed to do. If you need scalability, consider a
container-based strategy that can then be scaled-up or scaled-down (dynamically!) at any number of cloud-hosting services, such as
RackSpace. Many of these services can actually scale-up/down for you automatically and dynamically, within ranges that you have set (and paid for): if traffic increases, so do the number of containers, and vice-versa.
"Container" technology is used because it is light-weight, providing the
isolation that is required by a public-facing application in a shared environment – even up to the appearance of being "a virtual machine," if you select
that kind of container – but without the overhead of actually running a VM. The hosting-service takes care of all the "iron" for you, and they use
mainframes b-i-g iron. (They also get stuck futzing with their
networks!
"Yay!")
The database-interface and back-end interfaces (in general) that are used by a container-hosting service are a little bit more complex so that they, too, can be scaled up or down quickly.
Now, I don't consider "a mobile-facing web site" to be "a mobile
app," not at all. Neither do I think that "a web-site in drag" is a mobile-app, either.
But even ordinary web-frameworks can detect that a browser calls itself "mobile" and serve a different so-called "skin" on the content of the site in order to better suit its small display. This simply happens per-request in the choice of "templates" that are routinely used to format the content.
Web platforms can also commonly deliver content directly as YAML, JSON, or even XML, performing both "web
page" functions and "API-call" functions – although they're not designed to serve as full-on SOAP-servers.
