<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=676831495802534&amp;ev=PageView&amp;noscript=1">

Achieving Environment  Equivalence for Software Agents

In an ideal world, environments would all be identical. All servers would run the same OS, have the same networking configuration, store their data in the same way and so on. In that situation, there would be perfect equivalence between environments.


But this is not a perfect world (it’s also not as boring as one in which everything looks the same), and perfect environment equivalence is never going to happen. Even when ITOps teams try hard to maintain homogeneity across their infrastructure, environment variability always creeps in in one way or another.


But that doesn’t mean ITOps is helpless in the face of this environment variability. There are solutions. In this post, I take a look at this issue, then explain how the challenge can be overcome using container-based software agents in order to optimize the management of servers across variable environments.

The Importance of Equivalence

To start, let’s go over why environment equivalence matters. If your environments are variable and you don’t address that variability in an effective way, you run into serious problems. For instance, maintaining equivalence between development and production environments ensures that what stands up in development stands up in production. It also simplifies the task of working across heterogeneous environments.


Seemingly minor environmental differences can cause code that worked in development or staging to fail in production. That’s why equivalence between development and production environments is one of many goals in Adam Wiggins’ Twelve-Factor App manifestoAccording to Wiggins, a 12-factor app achieves equivalence not just by running the same services but by closing the tools, time and personnel gaps:


The Time Gap: a developer may work on code that takes days, weeks, or even months, to go into production.


The Personnel Gap: Developers write code, and Ops engineers deploy it.


The Tools Gap: Developers may be using a stack like Nginx, SQLite, and OS X, while the production deploy uses Apache, MySQL, and Linux.


For all of these reasons, equivalence between development and production environments is essential.


And that’s just an example, remember. There is much to say as well about the importance of maintaining equivalence between different types of production environments. If you have many different types of servers in your infrastructure, each configured in a different way, managing them efficiently is impossible if there is no environment equivalence. It’s also difficult to deploy apps on them reliably, since you have to test and administer the apps for many different types of environments.

The Traditional Solution


Enterprises have traditionally reacted to the lack of environment equivalence by trying to fight against it. They place themselves in a constant battle against variability by recurringly seeking to take environments that are not identical and make them more similar.


That’s why you see people installing X11 on Windows, for instance, or installing PowerShell on Linux systems. These are examples of some of the rather messy things that ITOps teams do to try to make dissimilar environments more similar in an effort to simplify management. When they can’t do that, they develop wrappers to try to make different environments mutually compatible from an administrative standpoint. And when even that fails, they resort to distinct workflows tailored to each environment.


These approaches might work in the sense that they provide some level of environment equivalence. But none of them are efficient. Resources are wasted trying to impose equivalence on environments that are just never going to be identical. Wrappers add overhead and usually do not work perfectly. Maintaining multiple workflows for different environments is a huge drain on admins’ time and expertise.


Plus, the equivalence you get from an approach like the ones outlined above will be limited. To go back to one of the previous examples, X11 on Windows is just never going to behave exactly the same as it does on environments to which it is truly native. As a result, equivalence will be imperfect.

 

The Better Solution: Container-Based Software Agents

So far, I’ve explained why environment equivalence is vital, yet is achieved by many organizations in an inefficient, imperfect way.


There’s a better approach. It involves using containerized software agents, like the ones provided by Intigua, to help manage dissimilar servers. Using container-based agents, you can streamline management and achieve environment equivalence even if the underlying servers remain different from one another.


Containerized software agents provide several advantages that promote environment equivalence. First, they interface with server management tools for you. That means that no matter how many different types of environments you are working with, the software agents provide a single, centralized way to manage them. The dirty, inefficient work of configuring the servers is automatically handled by the agents.


Second, because they run inside containers, containerized agents are themselves environment-agnostic. That adds another layer of equivalence to your software stack. Traditionally, if you used software agents to assist in configuration management for multiple types of environments, you would have to tailor the agents themselves to each particular environments. In contrast, containerized agents deliver a consistent environment for the agents.


Last but not least, containerized agents help you to scale. In the past, scalability was constrained by lack of environment equivalence because it is hard to add more servers to your infrastructure if each server requires a special configuration or management workflow. But when you have container-based agents to automate configuration, you can add new servers to the mix at will with virtually no increase in the management burden on your team.


Conclusion: Software Agents and Efficient Equivalence

As I explained above, there are different ways to go about achieving environment equivalence. Most of them are inefficient and will lead only to an imperfect level of equivalence, at best.


On the other hand, containerized software agents, such as the ones you can have using the Intigua Agent Manager, let you achieve equivalence without sacrificing efficiency. On the contrary, they can make your heterogeneous infrastructure even more efficient than it would be otherwise, since they allow flexibility across the servers you run without reducing efficiency.


Want to try Intigua? You can download it for free or play with a live demo.