Cloud Platforms: Public, Private and Hybrid

The decision is made per workload, not per organization. On its own, "we are moving to the cloud" is an intention rather than a decision.

Three properties are examined. Demand variability: if your load swings several-fold through the day or the season, the elasticity of public cloud pays off directly; on a flat load you are paying a premium for elasticity you do not use. Data sensitivity: where the data may sit, by country and by facility, is often regulated, and where it is, the choice starts there and cost comes second. Latency tolerance: an application tightly coupled to an on-premises system pays network latency on every call once it moves.

In practice most organizations end up hybrid, but there is a wide gap between a deliberate hybrid and "we moved half and the rest stayed". In the first, every workload's location has a reason and that reason is written down.

Generally yes, and knowing that up front makes the decision easier.

Costs rise in three places. Egress charges: providers make data cheap to bring in and expensive to take out; if data flows constantly between two clouds this line item adds up. Two sets of expertise: each provider has its own identity model, network architecture and service names, and the team has to know both in depth. Two operating stacks: monitoring, backup, cost reporting and security policy all get built twice.

Against that, multi-cloud has two legitimate reasons: reducing vendor lock-in, particularly for negotiating position, and a regulator requiring a second provider.

The wrong reason is expecting it to be cheaper. We measure the real cost of your current spread and show it; the decision follows that number.

Almost always the same three causes, and all three are measurable.

Resources never switched off. An environment spun up for a test is left running when the work ends. What finds these is tagging discipline: if every resource carries an owner, an environment and an expiry, the ownerless and expired ones surface in a report.

Oversizing. Instance size is usually chosen for the worst case and never revisited. Measure actual usage and you find machines running at 10% CPU.

Forgotten disks and snapshots. Deleting a virtual machine does not delete its disk. Snapshots accumulate. Individually small on the bill, collectively large.

The first step is inventory and tagging. Cutting without knowing what something is carries risk: nobody can safely switch off a resource whose owner is unknown. Once inventory is in place, a meaningful drop usually shows in the first three months.

We do the analysis and the tracking; the purchasing decision stays with you.

A reservation means committing to a given capacity for one or three years in exchange for a substantial discount. The savings are large, but the commitment cannot be undone: a miscalculated reservation means paying for unused capacity for three years.

The analysis therefore rests on usage history: which workload genuinely runs continuously, which is seasonal, which is being retired next year. Only the first group is proposed for commitment.

Tracking is part of the work too: commitment end dates are monitored. A reservation that quietly expires means the bill jumping unexpectedly within a month, and that does happen where nobody is watching.

Yes, and a takeover always begins with an inventory.

The first question is "which accounts exist", and in most organizations the answer is longer than expected: accounts opened for a project and then forgotten, subscriptions someone opened on a personal card, environments inherited from an acquisition.

The second is "who holds permissions". Departed employees with live access, shared administrator accounts and keys that never expire all surface here.

The third is "what does each resource serve". Operational handover does not happen before this is established: nobody can safely switch off a resource whose owner is unknown, and a resource that cannot be switched off stays on the bill forever.

Once the inventory exists, handover is phased: monitoring and reporting first, then routine operations, and change authority last.

No, and be wary of a provider who says otherwise.

Some workloads do not pay back the cost of moving. Flat, predictable, resource-hungry workloads (large databases, continuously running compute jobs) often run more cheaply on your own hardware. Fully depreciated hardware costs little beyond power and maintenance, while the same capacity in the cloud is charged at full price every month.

Second case: applications tightly coupled to an on-premises system. Put the application in the cloud with the database still on-premises and every query crosses the network.

Third: legacy applications that will not change. Moving them to the cloud does not modernize them; it just runs them on someone else's hardware.

The better question is: where does each workload belong?

The choice starts there and every other decision follows from it.

First, we pin down exactly what the requirement means, because "the data stays in Türkiye" is not enough on its own. Production data, or backups too? Do log and telemetry data count? Does an engineer seeing the data on screen during support count as a transfer?

Once those are answered the options narrow: a public cloud provider with an in-country region, an in-country private cloud, or a combination.

The configuration itself is then locked: the region restriction is defined as policy, so resources cannot be created in the wrong region. Without that lock, a correctly built environment can be broken six months later by one resource someone created in a hurry.

Part of it is, and not knowing which part is the source of the most common security gap.

Providers describe this as the shared responsibility model. The provider is responsible for physical security, the hypervisor and the infrastructure layer. You are responsible for the operating system, the application, identity and access management, network configuration, and the data itself.

In practice the large majority of breaches happen not in the provider's layer but in the customer's: a storage bucket left public, a role granted far too many permissions, an unpatched server, a key committed to source control.

So being in the cloud does not make you secure. The cloud provides the tools you need, but it will not close a door you left open.

There is planned downtime; the aim is to have no unplanned downtime.

It depends on the method. With continuous replication the data synchronizes in the background for weeks and the final cutover takes minutes, usually within a weekend window. With a one-off copy the outage depends on data volume and can run to hours.

The length depends more on dependencies than on data: what the application will connect to once moved, when DNS changes, what the rollback plan is. Where these are not written down in advance, a "two-hour window" stretches past midnight.

Every migration has a rollback point: if verification is not complete by a set time, you return to the old environment. The threshold for that decision is written in advance, not argued over on migration night.