Choosing Infrastructure as Code Tools: Questions to Ask

Choosing infrastructure as code tools comes down to four answers: where your cloud runs, who writes and keeps the files, how you hold the record of what you built, and what your approval and data rules require. Test two shortlisted options on one real environment, and let the result settle the choice.

Infrastructure as code puts the description of your servers, networks and storage into files, which a tool then applies. Where infrastructure work sits in DevOps shows how that fits the wider practice. The page suits an engineering lead, an IT manager or a delivery owner. It assumes you have settled on the use case for automated infrastructure setup and now need a tool. If you are still asking whether to start at all, read the problems of setting up environments by hand. Here we cover how to choose an infrastructure as code tool by the questions to ask. We name no products, and the question list is a Signisys working view that ranks nothing.

Which Layer Does the Tool Have to Manage?

Name the layer before you compare any supplier. Different jobs sit at different layers, and one team may need more than one layer.

Ask yourselves:

• Do we create cloud resources such as networks, databases and storage?
• Does our team configure servers after they exist?
• Do we build machine images that new servers start from?

Then ask which of the three you do today, and which you will do next year. Will the tool you pick for today’s layer still fit the next one? Ask each supplier which of your layers it covers and where it hands over to something else. Write the hand-over points down, because someone must own each one.

One Cloud or Several: Where Will the Estate Run?

The number of clouds you use, and may use, is the first thing to settle before you compare suppliers. Official cloud provider guidance on choosing a tool says the right choice depends on your business requirements and operating model, including whether you run on one cloud or several. That is why this question comes early.

If you run one cloud today:

• Is a second cloud likely within your plan period?
• Who decides that, and when would they tell the team?

If you run several:

• Does the team want one way of working across all of them, or one way per cloud?
• Who owns the gaps between the ways of working?

A merger, a customer demand or a data-location rule can add a cloud sooner than the plan says. For firms in India and the GCC, a second region or a second provider can follow a customer contract rather than an engineering choice. Ask the engineering head who would hear first.

In the trial, ask each supplier to show one change applied in every cloud you use. A slide proves little. Ask for a working change.

Choosing Infrastructure as Code Tools for Your Team’s Skills

The people who will write and keep the files matter when you choose. Ask who writes the files and who reads them, and which languages the team already reads.

Put these to the team:

• What does a new engineer pick up in week one?
• Who maintains the files when the author leaves?
• Who reviews each change before it applies?

Then look at how your team is organised. In an operations-led team, ask which way of writing suits the people who will keep it running. In a developer-led team, ask the same of the developers, and ask who covers the operations side. These questions go to your own people, and their answers tell you about fit better than a supplier’s description does.

A tool that suits the author may suit the person who inherits the work less well. Skills also change. Ask whether you plan to hire, train or contract the work, and whether the shortlisted option matches that plan.

Choosing Infrastructure as Code Tools: State and Approval

For each item below, ask for a live demonstration in the trial as well as a written answer.

For state, ask:

• Where does that record live, and who can read or change it?
• Who backs it up, and how?
• How does it lock, so that two people do not change the same thing at once?

How to set state up belongs to the order of work once you have chosen a tool. Here we ask only what the supplier can show.

Review comes next. Can you preview a change, and can a second person read that preview before anything applies?

Then approval:

• Can the team name an approver and a backup?
• Does the tool record the approval decision, with a name and a time?
• Does the approver see the preview before deciding?

If you already have a setup in files and want to score it, read a pass-or-fail review of a setup you already have. The two jobs differ: this page helps you pick, and that review checks what you have built.

India and GCC Fit When Choosing Infrastructure as Code Tools

Where the supplier’s service runs, and who answers the phone, matter to buyers in India and the Gulf. Send these four groups of questions to each supplier in writing and file the replies with your shortlist.

Data location:

• In which region do the supplier’s service and any state storage run?
• Does the supplier let your firm choose the region?

Rules:

• Which data-residency duties or sector obligations apply to the firm?
• Who inside the firm confirms the reply?

Support hours:

• Do the supplier’s support hours cover your working days, given that the weekend can differ between India and GCC countries?
• Who picks up when a release runs into the evening in Pune or Riyadh?

Assurance:

• Will the supplier hand over an independent security audit report?
• Which parts of the service does that report cover, and which does it skip?

Have your security lead read the report. Then ask whether you can check what it says as well as read a statement.

Decision Rules by Team Size

The people involved change as a team grows. For choosing infrastructure as code tools, this table gives a question for a supplier and a decision for your own people. It sets no figure or threshold. Bring it to the supplier meeting.

Read across a row rather than down a column. A team of five that grows to fifty has moved to a different row, and the questions change with it. Ask at what point your firm needs a shared owner of the files, and decide that before the purchase.

A Short Trial on One or Two Real Environments

Test before you commit. Choose one or two real environments that differ in shape, and push the same change through each option on your shortlist.

Agree the measures before the trial starts. They are time to first change, the number of questions the reviewer asks, how a rollback goes, and how long onboarding takes. The targets are yours to set. No benchmark is offered here, and another firm’s figure says little about your estate.

Cost and year two come as questions only:

• What does the supplier count, and what happens to the total when the team grows twofold?
• Who handles upgrades?
• What is the exit route if you change tool?

Record who decided and why, with the options, the measures, the supplier’s replies and the date. A year on, that note explains the choice to whoever asks.

Signisys can walk your team through these questions and help shape the trial. The work comes through our infrastructure automation for mid-size teams solution and support from a DevOps delivery team. We agree scope on the call.

Choosing Infrastructure as Code Tools FAQ: Short Answers