Cloud Architecture & Optimisation

Make the architecture fit the organisation.

Moving something to the cloud is relatively easy.

Designing an environment that remains secure, resilient, understandable and affordable as the organisation changes is considerably harder.

Fern ICT helps organisations design, review and improve cloud and hybrid architectures, with the emphasis on making sound technical decisions rather than simply adopting a particular platform or cloud pattern.

The right answer may involve more cloud.

It may involve less.

It may even be deciding that a particular workload should not move to the cloud at all.

Do you actually need to move everything to the cloud?

Cloud adoption is often treated as an inevitable direction of travel.

It doesn’t have to be.

Some workloads benefit considerably from cloud infrastructure. Others may be better suited to existing infrastructure, private environments or a hybrid architecture.

The important question is not whether something can be moved to the cloud. It is whether moving it creates enough operational, technical or commercial value to justify the change.

We can help assess questions such as:

Does this workload actually benefit from being in the cloud?
What would migration achieve?
What dependencies would migration introduce?
What would be lost by retaining existing infrastructure?
Are there regulatory, security or data-residency considerations?
Would a hybrid architecture provide a better balance?
Is the proposed migration solving a genuine problem?

A cloud migration is a means to an objective, not an objective in itself.

Review the architecture you already have

You don’t necessarily need to start again.

Cloud environments evolve incrementally. A workload is added here, a managed service adopted there, an integration introduced somewhere else. Over time, an architecture can become difficult to understand and increasingly expensive to change.

An independent review can identify:

unnecessary complexity;
architectural dependencies;
resilience weaknesses;
security concerns;
performance constraints;
inappropriate technology choices;
opportunities for consolidation; and
sources of avoidable cost.

We can review existing AWS, GCP, Microsoft Azure and hybrid cloud architectures, as well as environments incorporating on-premises infrastructure and other providers.

The objective is not to produce documentation for its own sake.

It is to understand whether the architecture is still doing what the organisation needs it to do.

Is your cloud architecture costing more than it should?

Cloud cost is an architectural issue as much as a financial one.

An environment can be expensive because of poor configuration, but it can also be expensive because the underlying architecture creates unnecessary consumption.

Examples might include:

services that are unnecessarily duplicated;
data being moved repeatedly between environments;
storage architectures that have evolved without review;
workloads that are poorly matched to their infrastructure;
excessive dependence on managed services;
architectures that require more operational infrastructure than necessary; or
resilience arrangements whose cost is disproportionate to the risk they address.

Cost optimisation should therefore not simply mean finding cheaper instances or turning things off.

The more useful question is:

What architectural decisions are driving the cost, and are those decisions still justified?

Sometimes reducing cost means changing the architecture rather than tuning the configuration.

How resilient is your cloud architecture?

Cloud availability does not automatically make a system resilient.

Resilience needs to be designed into the architecture, taking account of the failures that could realistically occur and the consequences if they do.

Depending on the environment, this might involve considering:

failure of individual services or components;
loss of connectivity;
availability-zone or regional failures;
dependency on a single cloud provider;
loss or compromise of credentials;
data corruption or deletion;
failure of external dependencies;
operational dependencies; and
the ability to continue operating when parts of the system are unavailable.

A resilient architecture is not necessarily one with the greatest amount of redundancy.

The appropriate level of resilience depends on the consequences of failure and the organisation’s ability and willingness to pay for reducing that risk.

The objective is to understand what happens when something goes wrong and make sure the architecture provides an appropriate response.

Balancing cost, performance, security and resilience

Cloud architecture involves trade-offs.

Increasing resilience can increase cost. Improving performance can increase infrastructure requirements. Additional security controls can introduce operational complexity. Reducing cost in one area can create dependencies or risks somewhere else.

There is rarely a configuration that maximises everything simultaneously.

We help organisations understand those trade-offs rather than optimising one dimension in isolation.

A useful architecture should balance:

cost — what the organisation is prepared to spend;
performance — what users and workloads actually require;
security — what information and operations need to be protected;
resilience — what failures the organisation needs to tolerate; and
operability — how difficult the resulting environment is to understand, manage and change.

The objective is not maximum performance, maximum resilience or minimum cost.

It is an architecture whose characteristics are proportionate to the value and risk of what it supports.

One cloud or several?

Using multiple cloud providers can appear to offer greater resilience and flexibility.

Sometimes it does.

But multi-cloud also introduces additional identity systems, interfaces, skills, operational processes, monitoring, security controls and data movement. The resulting architecture may be considerably harder to operate.

The important question is therefore not:

“Should we use multiple clouds?”

It is:

“What problem would multiple clouds solve, and is the resulting complexity justified?”

Multi-cloud can make sense where there is a genuine requirement for provider independence, regulatory separation, workload diversity or resilience against provider-specific failure.

It can also become an expensive abstraction layer that provides little practical benefit.

We assess the trade-off rather than assuming either single-cloud or multi-cloud is inherently superior.

Keeping complexity under control

Cloud platforms provide enormous flexibility.

They also make it remarkably easy to create complicated environments.

Services accumulate. Integrations multiply. Responsibilities become unclear. Data moves between systems. Identity and access models become difficult to reason about. Costs become harder to explain.

At some point, the architecture itself becomes part of the problem.

Good architecture should make the system easier to understand, not harder.

We look for opportunities to simplify designs, make dependencies explicit and ensure that technical choices remain proportionate to the problems they are solving.

Sometimes the best optimisation is removing something.

What does a cloud architecture review involve?

The scope depends on the questions that need answering.

A review might consider:

application and platform architecture;
AWS, Azure or other cloud services;
hybrid and on-premises integration;
data flows and storage;
networking and connectivity;
identity and access;
security boundaries and trust relationships;
resilience and recovery;
scalability and performance;
operational processes;
service and supplier dependencies; and
cloud expenditure and its architectural drivers.

The review can be focused on a particular workload or service, or consider the wider architecture.

The emphasis is on the decisions that matter rather than applying a generic checklist.

Independent advice

Fern ICT is independent of cloud providers, software vendors and implementation partners.

That means we can consider:

public cloud;
private infrastructure;
hybrid architectures;
single-cloud approaches; and
multi-cloud architectures

without starting from a predetermined answer.

The important question is not:

“Which cloud should we use?”

It is:

“What architecture makes sense for what we are trying to achieve?”

When cloud architecture advice makes sense

Independent cloud architecture advice can be particularly useful:

before committing to a significant cloud migration;
when an existing AWS or Azure environment is becoming expensive or difficult to manage;
when cloud expenditure is increasing without an obvious corresponding benefit;
when reviewing a proposed cloud architecture;
when assessing whether a multi-cloud strategy is justified;
when resilience or security requirements have changed;
when an existing architecture has accumulated significant complexity;
before a major application modernisation; or
when senior management needs an independent technical assessment of a cloud strategy.

You don’t need to know exactly what is wrong before starting a review.

Sometimes the most useful question is simply:

“Is this architecture still the right one?”

Start with the architecture

If you’re considering a cloud migration, reviewing an existing AWS or Azure environment, questioning cloud costs, or trying to understand whether your architecture is resilient enough, an independent conversation can be useful before committing to a particular approach.

We can start with the problem, the constraints and what you already know.

Then work out what the architecture needs to do.

No predetermined cloud strategy. Just experienced technical judgement.

Start a conversation →