Cloud Architecture in New Zealand

Ask what the simple version looks like

This is the most useful question you can put to an architect, and the answer tells you almost everything about them.

For most New Zealand businesses — a few thousand users, a few hundred transactions an hour, one country — the simple version is genuinely enough: a couple of well-run application servers, a managed database, a load balancer, and somewhere to put files. It will serve you for years, it costs a fraction of the alternatives, and one person can understand all of it.

Microservices, Kubernetes, event-driven designs and multi-region deployments each solve real problems. They are the problems of organisations with many teams needing to deploy independently, or with load and availability requirements most businesses never approach.

Ask directly: what would the simplest design be, and what does yours add over it? A good architect answers with a specific requirement of yours. A weaker one answers with a property of the technology.

Design for the team you have

An architecture is not only a design, it is an operating commitment. Someone has to run this on a Tuesday when it breaks.

So ask: how many people does this need to operate, with what skills, and do we have them?

A design requiring a platform team you do not employ is the wrong design however elegant it is. Two developers and an outsourced support arrangement can run a straightforward architecture well; they cannot run a distributed system with a service mesh, and they should not be asked to.

This is the most common way good architecture becomes a bad outcome in the New Zealand market, where teams are small.

Get the cost model, with assumptions

A design without a monthly running cost is half a design.

Ask for a figure at your real expected load, the assumptions behind it, and what it becomes at three times that. Check it includes the lines people forget: non-production environments, data transfer, backups and their retention, managed service minimums, and the support plan.

Then ask which parts of the bill scale with usage and which are fixed. A design with a high fixed floor is expensive while you are small, which is exactly when it hurts.

Separate what is expensive to change

Not all decisions are equally reversible, and good architecture spends its attention accordingly.

Expensive to change later — think hard now:

• The data model, and how tenancy or customer separation works.
• How identity and permissions are handled.
• Whether audit history is captured from the start.
• The boundaries between major components.

Cheap to change when the need arrives:

• How big the compute is.
• Whether there is caching.
• How many instances there are.
• Which region it runs in, mostly.

Building the second list for a scale you do not have is the standard expensive mistake. Thinking carefully about the first list is nearly always worth it.

Insist on decision records

Diagrams show what was built. They do not say why, and in two years the question will always be why.

Ask for architecture decision records: a page per significant decision saying what was decided, what the alternatives were, why they were rejected, and what would cause a revisit. Half a page each.

This is what stops the next developer quietly undoing a deliberate choice, and it is what makes an architecture reviewable rather than a matter of trust.

Ask what fails, and what happens then

A design document that only describes the happy path is incomplete. Work through, explicitly:

• The database becomes unavailable. What does the user see?
• An integration you depend on is slow. Does everything queue behind it?
• A deployment goes wrong. How do you get back?
• An availability zone fails. Does the system continue, and did you decide that deliberately?
• Someone deletes something important. How long to restore, and has that been tested?

The last one is worth pressing. Plenty of designs specify backups; far fewer have ever had a restore performed.

Know what binds you

Ask which parts of the design would be difficult to move to another provider, not because you plan to leave, but because the answer shows how tightly the design commits you.

Virtual machines, containers and standard databases move without much drama. Deep use of proprietary managed services is genuinely convenient and genuinely harder to unpick. That is a reasonable trade — but it should be made deliberately, and somebody in your business should have heard it out loud.

A second opinion is cheap

If you have a large proposal and the price surprised you, an independent review costs a fraction of the build. It either confirms the design, which is worth knowing, or finds simplifications that pay for it several times over.

Use someone who will not be bidding for the work, and give them the same brief the original firm received rather than the proposal alone.

Comparing five quotes

Read for:

• Who described the simplest option and justified going beyond it?
• Who asked how many people you have to operate this?
• Who provided a cost model with assumptions?
• Who offered decision records rather than only diagrams?
• Who named the three decisions they were least confident about?

Describe what the system does, how many users and transactions you genuinely expect, who will run it, and any requirement about data location or availability. Architects worth hiring will try to make the design smaller before they make it bigger.