Something we hear way too often while talking to Software Architects is “When I fix this it breaks that.  When I add or move new applications, or change Windows (or Linux) application settings everything goes Kaboom.  When I make a change to database credentials and an app doesn’t get changed, or is missed or fat fingered stuff breaks. It puts me in dependency hell!”  One change of configuration data for one application should not cause so much turmoil.  This is a really frustrating place to be when working with software.

Application Dependency Hell

Many application environments have complex dependencies.  Making changes to one may affect another or many application components or services.  Not knowing what may affect the other can put an engineer in “dependency hell.”

Your important web based applications may depend on the configurations, settings and performance of multiple other apps, databases and middleware within their ecosystem. And of course those other apps, databases and middleware are subject to frequent edits and updates themselves. So it is easy to understand how even well-run IT departments can fall into fire-fighting mode when something breaks…And something will break.  To make matters worse the only way to fix a problem is to search through out-of-date documentation or pick the brains of one of the subject matter experts you have available to help.  You have no idea which of the changes you made today broke what.

“Dependency Hell kinda feels like the Eagle’s Hotel California. You can checkout any time you like, but you can never leave!”

Get out of dependency hell

With Orca you can create relationships between configurations on different nodes. So if the configuration of one node changes, it flags the other node as being “out of compliance”. For instance, your Disaster Recovery (DR) IIS configurations should probably look identical to your Production IIS configurations. Ditto with your Linux based configurations. If a sysadmin were to bypass Orca and log directly into a production server to change a configuration, they may forget to make the same change in their DR environment. But even though that sysadmin worked outside of Orca, Orca will immediately detect that a change has been made to Production but not DR. Anyone glancing at Orca’s compliance heatmap will instantly see that DR does not match Production.

To learn more about Orca’s compliance rules, controlling drift, or calendaring your changes please take a look at our articles and videos on these topics. Or better yet, request a walk-though demo where we can discuss scenarios that you matter to you in your environment.