SCNET · Enterprise IT · Ankara, Türkiye

Sanal Çekirdek

Cloud is an operating model, not a location.

Cloud architecture is not running the same virtual machine somewhere else. Sanal Çekirdek treats network, identity, data placement, cost visibility and the operating model as one design.

Workloads moved before the architecture exists run more expensively and more fragilely in cloud. The gain comes from changing how you operate, not from the move itself.

Target architecture and placement

A target environment is decided per workload: some are rehosted, some are refactored, some stay where they are. The decision follows how the application holds state, its data class and how tightly it is integrated.

  • Stateful components are handled separately
  • Staying put is also a decision, not a default
  • Tiers of one application may live in different environments
  • The reasoning goes into the architecture record

Network, identity and boundaries

In a hybrid architecture, connectivity and identity are built before applications. Without an addressing plan, private connectivity, DNS resolution and a central identity source, every migrated workload stands on a workaround that is hard to remove later.

  • Addressing conflicts are resolved before any migration
  • One identity source, least-privilege authorization
  • Cross-environment traffic is explicitly permitted
  • Management plane access runs on a separate path

Cost visibility and FinOps

Cloud cost is controlled by a management discipline, not by an invoice. Tagging standards, cost ownership and budget alerts are set up on day one; otherwise the source of spend is investigated at month end.

  • Tagging is enforced before resources can be created
  • Every line of spend has an owner
  • Reservation and commitment calls are made on measurement
  • Idle resources are flagged automatically

Operating model and automation

Infrastructure built by hand breaks by hand. Resources are defined as code, changes pass review, and environments are produced from the same definition. That buys reversibility as much as speed.

  • Resource definitions live under version control
  • Environment differences come from parameters, not forks
  • Every change leaves a review record
  • Rollback means applying the previous definition

How we work

  1. Inventory workloads and how they hold state
  2. Decide the target environment per workload
  3. Build the network, identity and cost foundation
  4. Migrate in waves
  5. Put the operating model and automation into service

How success is measured

  • Every workload has a written target and rationale
  • The share of untagged resources approaches zero
  • Idle resources are shut down in the period they are flagged
  • Environments can be reproduced from one definition

Frequently asked questions

Should everything move to cloud?

No. Some workloads should stay where they are; the call is made per workload against criteria. An all-cloud decision can be as unjustified as a no-cloud one.

Doesn't multicloud add complexity?

It does. That is why multicloud should be the consequence of a requirement — regulation, vendor risk or a specific service — rather than a goal. Without that reason, a single provider is cheaper and sturdier.

Does cost actually go down?

Usually not if the architecture moves unchanged. The gain comes from elasticity, from being able to switch things off, and from lower operational load. We put the expected effect in numbers up front.

Share your inventory and we will draw the target architecture together — one decision per workload, each with its reasoning.

Request a target architecture review