Traditionally, services on unix system are started and supervised directly by the init process ("init system"). That has been SysV init for most of the time, but in the last decade we got two major new systems: upstart (dead now) and the infamous systemd. Using systemd can still be a very good alternative to using docker today.
> Was it a machine stack per service?
That still sounds like a good approach to me today.
If your service is not big/expensive enough to need at least one full machine, why bother cutting your app up into such small services in the first place?
For example, for web applications, a traditional setup would have been to have a couple of dedicated servers that run the database and a larger pool of webservers that serve the (stateless) application. In front of that you could have two linux boxes doing the network load balancing and failover or a commercial load balancer "box" product.
Cloud Foundry and other opensource PaaSes. Heroku. Chef, Puppet et al. Java app servers with WARs.
Before that was a time of heroic mythology. Shell scripts, bailing wire and raw genius.
Disclosure: I work for Pivotal, we work on Cloud Foundry.
Twitter from 2013: https://www.slideshare.net/caniszczyk/twitter-opensourcestac... They had a similar in-process JVM-based approach as Netflix, but they also used Mesos as a scheduler.
Nowadays we do much the same thing, but with Docker on ECS. The glue script is gone, because Terraform.