Infrastructure as Code (IAC) is an approach used by some of the largest Internet companies in the world like Facebook, Netflix, Etsy and Amazon. IAC allows them to enable automation and testing of their infrastructure.
Just as software development has source code as its fundamental unit so to IAC is an approach where infrastructure is described in a form of source code. This allows for a change from the manual and custom script based approach for infrastructure automation.
The role of DevOps in this process is to create the infrastructure automation environment.
In this article we focus on how IAC and DevOps can be used automate WebSphere middleware deployments.
IAC Tools and Techniques
In IAC we source control middleware configurations with Git just like we would with regular code. We also link our middleware configurations to the applications that use middleware services in all environments – Development, Test and Production.
Any version of the state of the middleware should be able to reference the version of the applications deployed to it.
We programmatically configure and deploy to the nodes and we refactor the configuration data as we would regular source code. We can also track issues using the same bug tracking software used for regular development. Testing processes are identical to regular development in Unit, Functional and Integration tests.
There are 2 broad approaches to IAC, Imperative vs. Declarative.
Imperative (Procedural) is the “how”. It’s a historical approach which uses the “I don’t trust you, give me the actions” parameters in explicit steps.
Declarative (Functional) is “the what. “This is what I need, I can’t be bothered telling you how to get there” parameters. The how is handled by the interpreter/engine not the administrator. The sys admin describes a desired end state and the tool attempts to reach it.
It is results focused.
Here is a great example of the Imperative vs Declarative approaches:
*Image from Xkcd.com
For tools that take an IAC approach, there are also 2 methods through which changes are propagated: Push vs Pull.
*Image from Xkcd.com
Push – A centralised Server pushes changes out, typical for production (control is centralised and in the hands of the admins).
Pull – Clients contact central server for updates, typically more scalable also more appropriate for developer workspaces.
There are a number of IAC tools that form part of the DevOps toolchain. Choosing the right tool for the job is essential as some tools handle different parts of the DevOps lifecycle and not others.
Review of tools
*Table from Wikipedia – https://en.wikipedia.org/wiki/Infrastructure_as_Code
Chef, Puppet, UrbanCode and Talos are tools focussed on middleware deployment.
We will discuss these tools and their application in more detail in an upcoming blog post so stay tuned.