Интерфейс это фактически регламент взаимодействия.
Класс который реализует интерфейс обязан реализовывать все его методы.
В интерфейсе вы описываете лишь сигнатуры методов, то есть вы указываете что класс наследник должен уметь делать, но как он будет это делать, тот решает сам.
Таким образом вы уверенны, что если класс реализует тот или иной интерфейс, все объекты данного класса имеют определенный набор методов.
ООП - мир абстракций :) Впустите его в себя :) Интерфейсы это еше одна абстракция позволяющая отделить описание от реалзиации.

"Придумать класс с правильным именем" - так вы не сможете заставить "наследников" реализовывать функционал.

Интерфейсы располагаются на уровень выше классов, если можно так выразиться. Они неявно "объединяют" классы схожие по каким то общим признаком, и которые обязаны (по логике вашего приложения) реализовывать те или иные методы.

interface Instruments {
    final static String key = "До мажор";
    public void play();
}
class Drum implements Instruments {
    public void play() {
        System.out.println("бум бац бац бум бац бац");
    }
}
class Guitar implements Instruments {
    public void play() {
        System.out.println("до ми соль до ре до");
    }
}

p.s: программисты дополнят и поправят.

С "оркестрейшеном" у puppet все плохо.
Был puppet-kick, но его выпилили, теперь есть mcollective, который позволит вам дернуть агента на всех нодах и применить конфигурацию. Но имхо это из пушки по воробьям.
Мы по прежнему по старинке, через pssh дергаем на нужной группе нод 'puppet agent -t'.
Применить конфиг на отдельном сервере, из коробки я думаю врядли получится. Нужно придумать что то свое :).
Ну или конечно же, Вы всегда можете нагородить

if $::fqdn in $testing_nginx_servers {
    $config = new_config
  else {
    $config = stable_config
  }
  ::nginx::vhost { 'server.com' :
    template      => $config
    server_name   => "${::fqdn} ${title}",
    document_root => '/var/www/server.com',
    ssl_keys      => 'server.com'
  }

А где нить в site.pp объявить

$testing_nginx_servers = [ 'web-1.server.com', 'web-2.server.com' ]

В конце концов вы можете раскатывать конфиг, но не релоадить nginx :).

На тему ansible vs puppet. Субъективно, ansible, массовый раннер скриптов :). К тому же на состояние полугодовалой давности довольно тормозной.

Puppet подразумевает, что накатка изменений, не влияет критично на Ваше окружение, и может происходить в фоне. Тоесть для ряда пакетов Вы написали 'ensure => latest', и не паритесь, обновляется оно сам по себе когда нада +\- 30 минут и всё. Внесли изменения в конфигу, проверили на одном серваке, и уверенны что через полчаса это будет везде. Сейчас скажу глупость, но о "схеме" его работы можно сказать что он "согласован в конечном счете", и этот "конечный счет" определяется получасовым таймаутом обновления (как в DNS :) )

Может быть уже неактуально, но вот здесь человек сравнивал ansible \ salt в качестве альтернатив для переезда.

Если привлекает YAML в puppet есть hiera, для экспорта ресурсов с нод, есть puppetdb (к примеру что бы при добавлении backend серверов, их адреса попали в необходимый upstream у nginx, без прямого прописывания их в конфиге).

Если напрягает что нету всяких "циклов", то это решается во первых при помощи define, или в свежем синтаксисе есть each / slise / reduce / filter, который позволяет удобно работать с со всякими списками параметров, плюс очень много чего полезного реализовано в stdlib.

Puppet декларативен, и если вы не хотите мирится с отсутствием возможностей перезаписать переменную / параметры ресурса / класса, то Вам будет сложно с ним, иначе не вижу ничего плохого в этом выборе.