automation with purpose…

Every engineer, architect, system administrator and project manager all has to make decisions on automation. Albeit, those decisions will be from different perspectives, but we all have to figure out what makes sense. The main reason I’m writing this blog, is that I have been seeing a lot chatter recently about posteriori (dynamic) configurations and grumblings about performance and I know doing more a priori will improve performance.

When does it make sense to do configurations a priori vice posteriori? Obviously it depends on what you’re trying to do. Some things to consider are,

  • Does the configuration(s) need to be dynamic?

When configuring the environment is there anything that needs to be dynamic? For services that have dynamic configurations, how much of the service configuration is actually dynamic vice static? In other words, if I have a dynamic configuration, but only 2 commands out of 50 need to be done dynamically, I may consider setting up static configurations for 48 commands and only doing 2 commands dynamically. There are diminishing returns for this type of approach so if the example was the other way around, then you could have 48 dynamic configurations and 2 static configurations. In this case depending on the scale will dictate whether to spend time doing both static and dynamic configurations; huge number of machines will make dynamic and static approach more reasonable, because even a tenths of a second for each server start up time gets expensive when the number gets high.

  • How many machines will this affect?

Regardless someone will have to design and create the architecture of the environment, but if there are only a few machines spending time creating a dynamic environment can inhibit productivity and will not be worth while.

  • What are the resource requirements for spinning up the environment?

When you’re creating your test machine how long does it take to configure the environment; this will be approximately how much time it will take each environment to dynamically be created.

  • Does this need to be repeatable?

What is life expediency of the machine and/or services? If the life expediency isn’t long then why spend the additional effort making the entire process automated?

The basic take away is always try to do things a priori and when you can’t, only do the configurations that need to happen dynamically, dynamically. Trying to do everything dynamically will be expensive implementing a repeatable solution and computationally expensive. If you aim to leverage automation with a priori configurations I guarantee that you will improve performance and lower costs.


Author: jasonmarley

I have been with Red Hat since 2010 and love it! My day to day is consulting on RHEL/JBoss/OpenShift, but I work on open source projects in my free time. The best part about my job are my awesome colleagues and our community.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s