Showing results for 
Search instead for 
Did you mean: 
Create Post

Cloud Native Operational Solutions - Configuration Management

Level 9

One of the biggest draws of the public cloud includes services like managed Kubernetes or server-less functions. Managed services like these enable IT organizations to consume higher-level services, which allow the IT organization to focus their efforts on opportunities to create business value from technology.

Configuration management tools like Chef, Puppet, and Ansible are central to modern cloud deployments. These tools enable an automated and consistent configuration of instances. This allows administrators to utilize cloud-native practices like immutable infrastructure, in which instances or servers are treated as low-value objects that can be easily recreated, as opposed to long-living servers that are carefully maintained.

Each of the popular configuration management tools utilize a server/agent construct in which the agent or node is managed by the configuration management server and pulls its configuration from the server. This introduces long living infrastructure in the form of the configuration management servers that must be maintained. Creating automation cookbooks or modules is challenging enough without having to provision and maintain the infrastructure required to facilitate the automation.

The benefits of managed configuration management are:

  1. Quickly test new versions - One of the challenges with configuration management tools is keeping up with the release cycle of the software. Utilizing a managed solution enables IT teams to quickly spin up a configuration management server and rapidly test new features with little hassle.
  2. Simplify upgrades - Once a new version of the configuration management tool has been tested and deemed production ready then the process of upgrading the server infrastructure begins. This requires a considerable amount of time and effort from the engineer. With a fully managed solution all of that time and effort is given back to the engineers.
  3. Enable isolated automation development environments - The ability to provision a production like environment along with the configuration management platform gives automation engineers an isolated environment to test their automation changes with a greater assurance that it won't break a shared environment.
  4. Scalable - Building the configuration management infrastructure that scales properly as the environment reaches thousands and tens of thousands of nodes is incredibly complex and makes things like upgrades that much more painful. The ability to utilize a single solution for ten nodes or ten thousand nodes is incredibly valuable.

Managed Deployment

The following solutions are managed deployments. This means the configuration management software company has added a deployment solution to the respective cloud provider's marketplace to allow the infrastructure to be provisioned with the click of a button.

Chef Automate

The Chef Automate platform is a configuration management platform created by Chef Software that provides an end-to-end solution for automation engineers to develop, test, and deploy their cookbooks. AWS and Azure offer a marketplace offering of a Chef Automate that can be deployed and ready to use within minutes.

Puppet Enterprise

Puppet Enterprise is a configuration management platform created by Puppet that provides a standard set configuration management functionality. Both AWS and Azure offer a marketplace deployment option.

Fully Managed

The following solutions are fully managed configuration management solutions such that the cloud provider manages your configuration management platform on your behalf and allows engineers to focus on automation cookbooks or modules.

AWS OpsWorks

AWS OpsWorks is a fully managed solution that completely abstracts the server infrastructure related to configuration management. This allows organizations to take full advantage of configuration management tools like Chef and Puppet without the administrative overhead of managing a server.

Azure Automation

Azure automation utilizes PowerShell DSC (Desired State Configuration) for managed configuration management, this fits perfectly in-line with Microsoft's vision for PowerShell to manage all things.

Ultimately the value proposition for configuration management tools is in the consistent automated configuration of the instances and not in managing the infrastructure to support the configuration management tools. Future posts will delve into other core operational aspects that are critical to cloud environments but in and of themselves don't provide much value.


It's new, it's cool, you've gotta get it!

Let me know when it's secure (physically and logically), and then prove it to my satisfaction.

Let me know when it's reliable and highly available, and when using it in the cloud is as fast to the end user as is using locally hosted apps on servers in our data centers, and I'm interested.

Until then, I'm content to wait by the sidelines and watch others succeed or be burned by unexpected / unproven access issues and security flaws.

I like it, but in someone else's yard, not my own.  So far . . .

Level 20

These tools are finally starting to mature.  I agree with containers argument.  It's nice to have services that are completely isolated from each other.  We do a lot of what you're talking about on our own cloud but are only testing workloads for AWS or Azure for possible future integration due to the security requirements we fall under.

Level 9

There is definitely a lot of hype around how great public cloud is and much like any new technology or consumption model it will have it's weaknesses that are often glossed over while the hype machine is churning along. I recently had a conversation about cloud/SaaS providers and how much should one care about their architecture from an availability and security perspective. I totally agree that those things are very much overlooked by most moving workloads to public cloud providers.

Level 9

Service maturity is definitely a big issue given the speed at which new services from AWS or Azure are being released. I think many people just think that the cloud providers are creating some magic but honestly its typically just an open source product that has been automated and presented via a UI. This means they are inheriting the flaws and pain points of the underlying products they are using.

Level 13

I agree with the security aspects that you raise. The company I originally worked for liked to lag a few months or releases behind the latest technology. Their attitude to the cutting edge was that the closer you were to it the more likely you were to end up bleeding. They preferred to wait a little while and let others find and fix the bugs and security issues that come with early deployments. Speed of implementation needs to be tempered with proper testing to avoid the pitfalls.


Nice article, thanks for sharing

Level 20

True most of the software underlying AWS is open source.

Not deploying the latest patches/fixes/updates/upgrades is a philosophy many people have adopted, due to having been burned by patches that have caused new problems while trying to correct old problems.  I can certainly sympathize with that that philosophy, and I use it myself in certain cases.

However, when it comes to securing a known vulnerability, to closing a security hole, I'm on board with correcting it soonest, and dealing with the fallout of potential problems the patch may bring.  It seems more likely that the problem (security hole / vulnerability) is worse than the cure.  But I've known the opposite to be true on occasion, where the first edition patch has caused so many problems that it brought a product or system to a halt.

Hopefully that will be increasingly rare, and that everyone can install security patches and upgrades with confidence.  But there are far too many stories on the Internet of a fix for a problem caused new issues.  And not everyone has a test environment that properly mirrors their production environment in which to install new patches and confirm they don't cause new issues.  It's a tough issue, and telling someone to simply trust that the vendor knows best, and that the vendor has done the job correctly, is a difficult challenge when the customer may have been burned by prior updates.

For something like Solarwinds, I'm happy to install updates and patches three or four months after their release--as long as the updates aren't for significant security vulnerabilities, and as long as my current SW environment isn't having major problems.  If either of those caveats are present, I'm updating the product the day I learn about the hot fix for the issue.

Level 13

Good article.  More tools to manage cloud.

Level 9

Thanks for the feedback.

Level 9

Thanks. It's definitely helpful and almost necessary to have some good tools to manage the cloud given that most deployments are actually hybrid deployments and it typically means twice the work for the same people.

Level 16

I live 7 miles from this guy and I can't get high speed internet at my home


Level 21

We have used Chef to do Azure deployments and it works great.