Random running-a-server comments, and in no particular order,....
Systems that are servers are always available, and generally don't and won't be shut down or rebooted save for maintenance or upgrades or similar. While it's possible to shut them down, it's not typical.
If you do want to shut OS X Server down and then restart it as required later, you'll either need to get the so-called Magic Packet — wake on LAN — working from some other box on your own LAN (the packet doesn't work across a VPN or remote link — or you'll need something like a network-connected power switch. Some way to wake the server remotely.
Once you start using your own server with (for instance) your own DNS server, you'll want your server operating continuously, as DNS translations would otherwise fail.
OS X Server needs local DNS services running for at least itself or various services will get weird and unstable, and you cannot (successfully) reference ISP DNS servers or other off-LAN DNS servers. As you start using authentication and network encryption services on your local network, those are dependent on proper local DNS — it's the local IP address to host name DNS translation that the ISP and off-LAN DNS servers can't answer, and that question is used with various security-related network operations. This is the so-called reverse DNS translation; address to name.
You'll want a static IP from your ISP or you'll need dynamic DNS for the remote connection.
If you decide you want to host your own mail server, you'll need static IP from your ISP or you'll have to relay all your mail via some other mail server — other mail servers on the network increasingly depend on DNS to spot spam engines, and a server on a dynamic IP address is indistinguishable from a spam engine. Hence static IP or an (authorized) relay mail server.
Connecting into your system via VPN will be preferred path for remote access, as the gremlins will find and poke at any ports open and port-forwarded through your firewall.
Servers are attack targets, so — if you're going to start running something like a web content management system, or if you might have a weak password around — you might want to investigate placing your server in a DMZ. This if you have other and potentially less secure systems on your LAN. A web server breach can be a hassle to clean up, and there are presently at least three DDoSs underway (NTP, DNS and SNMP) that can suck down your network bandwidth, if your server happens to be configured to be vulnerable to these or some other DDoS that somebody finds and starts exploiting. Put another way, don't forward all ports to your server through your network firewall; restrict that inbound remote access to either VPN-only, or to specific ports absolutely required.
To extend and elaborate on what Linc Davis has written, Server.app is just the front end GUI interface for managing it, and Server.app can be run locally or can connect and manage a server remotely. Server.app can come or go as needed, and the underlying services on the target server will continue in the same state — started or stopped — as they were last set to by Server.app or by the command line.
Cloud services including Dropbox and SpiderOak are available and deal with remote storage as an alternative to learning about servers and IP networking and the rest, though it's possible to go well past something like AFP or SMB/CIFS file services on your server and load and run additional "cloud" software such as OwnCloud — that's more advanced to set up and configure and manage, but more features. Managing a server is more effort — and if that's not part of your goals and expectations here — using hosted services — now called "cloud services" can be a good trade-off for various situations.