So you are stumbling into what I consider a larger topic on the scope of what CM handles. I can assure you, that there are going to be as many opinions on this as people, but I’ll do my best to outline things from my perspective, which are my own my own yadda yadda yadda…
While I’ve not heard the term “inside vs outside configuration”, I’m going to assume it’s explicitly referring to the scope of CM, and what you intend to (or even can) manage with it.
Here’s the TLDR version: The scope of what I’ll call “traditional CM” (ala Chef/Puppet) is going to be directly related to the maturity and scale of your DevOps model, or more specifically: where you are in your “cattle vs pets” journey (which is not exactly the same but really tightly coupled).
Ready to get fun?
Right now you have pets. Lots and lots of pet servers that need configurations, patching, tweaking, etc. I’ll assume almost exclusively as you’re looking at CI with great interest.
As you start to declare configurations and standardize servers, you are going to start down the path of shifting from pets to cattle: things that are never taken care of, but rather replaced. It will start simple with web servers, app servers, but legacy systems and most databases servers will sit firmly in the realm of pets … even if you do manage large aspects of them with CM.
At this phase in the journey your CM usage will be massive … touching nearly everything. Yes: Puppet and Chef can deploy the entire server soup to nuts, but it will take hooks to other tools (remember I mentioned Foreman? That has an AWS/Azure provision-er so it can create servers for you then kick off the Chef/Puppet run). THings will be good and you’re going to do very well with it.
To be honest … within the MS ecosystem this is about as far as most get … but our Linux brethren have already evolved passed this. Lets talk scenario:
see what’s going to start happening is things like Azure ARM and AWS Cloud Formation start a shift in thinking: remember images? You may have heard Snover say the “golden image is dead” … but “long live the image”. See, spinning up a server then pushing a recipee/puppet manifest/dsc mof still means your servers will take minutes to be ready. 15+. This sounds decent now … but eventually you’re going to start falling in love the idea of pre-baked images again. Machines that boot in 10 seconds ready to go. This will be especially good for all that “auto scale out” you hear about. As you continue down this “go faster” path you’ll be gin to realise: you dont need CM after the box is deployed … they’re cattle after all. You just need the images perfect then you provide a huge list for people to use.
Suddenly chef and puppet retract. All they are doing is helping you build images and commit them to AWS/VMware where ever, oh and still handling that really complex stuff that can’t really live as an image very well (yet, you’ll get better and the toolsd will get better … and it will happen).
Then you hit your next realization: if all im doing is building images … why do I need DSC or any kind of declarative language at all? That thing that sounds awesome now becomes … overhead. I dont want to train people in a new language … just let them make a stupid PowerShell/bash script and build the image. It only has to build once … then the image is stored. Suddenly that invaluable CM tool that started you on this journey is a hindrance… except for those big massive oracle/mysql databases … still insanely valuable there.
As you continue to mature that container thing will happen. See at some point (if it hasn’t started already) your devs will want to build their app and test it locally then ship that finished thing. It’s way easier that way … but CM is going to fall flat and hard to handle this. You’re going to start looking into Azure Service Fabric, or Kubernetes clusters, or HashiCorp tools to start helping you out. And as you start to understand the role of schedulers and service discovery you’re going to realize something huge: that stuff helps with the legacy apps, too.
By the end of your journey you will likely still have some Puppet/Chef but in a way you’ll be right back where you started: very little of it covering very little (basically it manages only the lowest layer of your now hugely abstracted cloud). So it’s use is like a bell curve.
So why is this relevant to your question of “inside outside configuration”? Because in my never humble opinion: the difference answers you get are due to the where said person is in their own DevOps delivery model journey.
It sounds like you like the Chef product: move on it. Just because I’m predicting a fade in/fade out doesn’t mean it’s not a path worth taking. It starts some wonderful things in motion.