The way we've been going on, you may assume that a pull server is a mandatory part of the DSC infrastructure. It isn't. A pull server is useful when - and only when - you plan to create updated configuration MOFs from time to time, especially if that's frequently, and you want nodes to grab them automagically and implement them.
We tend to assume that this is the "best" way because we use Group Policy that way. But for server workloads in particular, you may decide you don't even want a pull server at all. For example, DSC currently doesn't support anything like maintenance windows or scheduled downtime, so constantly pulling and implementing configurations might be disruptive in your environment.
Instead, you could choose simply to push new configurations whenever you want. And this isn't necessarily a manual procedure, either - keep in mind, DSC is a platform, not a solution that includes ready-made tools. We're aware of at least one organization that has constructed its own (sadly proprietary) "push server." That server is configured with maintenance window information and a database of configurations. When a configuration changes, the server waits until a window is open, and then pushes the new configuration to the node. It has a lot of error handling and alerting so that if a push attempt fails, everyone's informed.
The point of this short chapter is to emphasize that DSC is what you need it to be, provided you're willing (A) to be creative, and (B) to implement your own solutions on top of DSC, as needed.