Forem: Ali-Funk

Lets say my Manager wants Multi-Cloud (AWS + GCP) in 6 months here’s how I would respond and why

Ali-Funk — Thu, 02 Apr 2026 21:33:26 +0000

A contact on LinkedIn asked a question that every cloud architect eventually hears:

“Your manager says "We need to be Multi Cloud, AWS plus GCP. In 6 months."
You’re currently 100 % in AWS. Do you push back, agree, or propose a middle path? The reason behind the request matters more than the request itself.”

Here is exactly how I answered and why.

The Hidden Costs of the Multi-Cloud Trend

Transitioning to a Multi Cloud architecture is often sold as a strategic victory. When management sets a six month deadline to integrate GCP into an existing 100 % AWS environment, the first job of any engineer is to evaluate operational reality rather than marketing hype. Drawing on eight years of professional experience as a Solutions Architect, I consider this one of the most dangerous directives an engineering team can receive.

Questioning the Directive First

The very first step is always to clarify the objective. Is the company facing strict regulatory compliance that genuinely requires two clouds? Or is management simply afraid of "vendor lock in"? If the reasoning is
fear based rather than business-driven, the resulting architecture will be flawed from day one.

The one non negotiable exception is Mergers and Acquisitions. If your company just acquired an organization running natively on GCP, integrating that environment is a hard business mandate, not a trend.

Evaluating the True Costs

Data Egress

Cloud providers want your data to stay inside their ecosystem. Moving even moderate volumes of data between AWS and GCP triggers significant egress fees. The hyperscalers let data in for free but charge heavily to move it out. The network architecture required to bridge the two environments adds complexity and cost that is rarely budgeted.

Team Capacity

Forcing a single team to master both AWS and GCP is an engineering
anti pattern. The alternative , hiring a completely new team or launching extensive retraining programs , this cannot be done securely or effectively in just six months.

Architectural Coupling

The danger level of a six month timeline depends entirely on your compute layer.
If your AWS environment relies heavily on proprietary managed services like Lambda and DynamoDB, a GCP integration is an operational nightmare.

However, if your architecture is already heavily containerized using EKS and stateless microservices, dropping those workloads into Google Kubernetes Engine is significantly less complex.

Pipeline Fragmentation

Managing infrastructure state across two hyperscalers requires immense discipline. The cognitive load of preventing configuration drift while deploying to two different environments is almost never factored into management timelines. Securing two separate Identity and Access Management perimeters at the same time doubles the risk of a breach.

Here is a minimal Terraform example that illustrates the immediate fragmentation:

# AWS provider
provider "aws" {
region = "eu-west-1"
}

# GCP provider already doubling the cognitive load
provider "google" {
  project = "my-gcp-project"
  region  = "europe-west1"
}

# Two separate remote backends become mandatory
terraform {
backend "s3" { }      # AWS state
# GCP state needs its own backend GCS
}

A single terraform apply now touches two completely different ecosystems. State drift detection, IAM policies, and security scanning all become twice as complex.

When (and only when) Multi Cloud actually makes sense
In rare cases Multi Cloud is the right call: strict data-residency regulations that force workloads into specific GCP regions, a highly specialized service (such as BigQuery for massive analytics that has no cost-effective AWS equivalent), or a true disaster recovery strategy that demands geographic and provider diversity.

When those conditions are met, the safe middle path is not a big bang six month migration. Start with a narrow, non-critical "proof of concept" workload in GCP (e.g., a new analytics pipeline), keep the core platform in AWS, abstract common patterns with Terraform modules, and enforce strict cost and security gates before any production traffic moves.

Conclusion

Multi Cloud is not inherently bad, but rushing into it for the wrong reasons is expensive, risky, and almost always avoidable. The reason behind the request matters more than the request itself. Ask why first. Then protect the team and the architecture with data, not dogma.
Sources

AWS Data Transfer Out Pricing (to Internet / other clouds):

https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer

Martin Fowler

“Don’t get locked up into avoiding lock-in” (Multi Cloud discussion):

https://martinfowler.com/articles/oss-lockin.html

HashiCorp
Workspace Best Practices for HCP Terraform (Multi Cloud state management):
https://developer.hashicorp.com/terraform/cloud-docs/workspaces/best-practices

I highly recommend for you all to see theses views on comments in your code. Great perspective!

Ali-Funk — Tue, 31 Mar 2026 17:14:38 +0000

Tual Maxime (@filozofer)

Mar 22

I was asked to delete my comments before committing

#git #productivity #developer #ai

Comments 22

5 min read

The AI Rebound Effect and the Transition to Systems Architecture

Ali-Funk — Tue, 31 Mar 2026 07:12:26 +0000

The reaction to the recent Claude AI outage reveals a fundamental misunderstanding of how developers should interact with artificial intelligence.

Reports of developers feeling entirely unable to work without their AI assistant point to a dangerous trend of „deskilling“.

John Nosta accurately describes this as the „AI rebound effect“, where improved performance masks a rapidly declining foundational ability.

If an engineer relies so heavily on a probabilistic model that they cannot function when it goes offline, they are using the tool incorrectly.
One developer on Reddit described it as : "I wrote code like a caveman"

The future of software engineering requires us to elevate our skills, not abandon them. Instead of focusing purely on syntax generation and accepting the first output a model provides, I find that engineers should or even must transition into the role of systems architects.

By mastering agentic workflows and deterministic execution, we shift our cognitive load from writing boilerplate code to designing complex and secure infrastructure.

The AI handles the syntax, but the human must control the logic (or at least the human should be in control), the security constraints, and the integration points.

Letting your core skills regress is a choice.

The alternative is to step up, utilize spec driven development, and master the architecture that governs the AI.

Sources:

Business Insider: AI deskilling impact on worker skills and productivity
https://www.businessinsider.com/ai-deskilling-impact-on-worker-skills-productivity-2026-3
Psychology Today: The AI Rebound Effect and Cognitive Decline
https://www.psychologytoday.com/us/blog/the-digital-self/202508/ai-rebound-the-paradoxical-drop-after-the-ai-lift
Hyper AI: The Great AI Deskilling Trend https://hyper.ai/en/stories/93549dd29c8a15321052bf0d1d71a5e4

The European Commission AWS Breach and the Failure of Paper Security

Ali-Funk — Fri, 27 Mar 2026 13:33:07 +0000

The European Commission, the executive body of the European Union, is currently investigating a security breach of its Amazon Web Services infrastructure.

According to a report published today by Bleeping Computer, a threat actor gained access to at least one AWS account used to manage the Commission's cloud environment. Although the incident was detected quickly, the breach demonstrates a critical reality:
administrative checklists and compliance frameworks fail where deterministic architecture is missing. If the most heavily regulated entity in Europe can suffer an AWS breach, paper security is proven ineffective against real-world threat actors.

The Misunderstood Shared Responsibility Model

When an enterprise-level breach occurs on AWS, the failure is almost never on the side of the provider. The AWS Shared Responsibility Model is explicit. Amazon secures the facility, the compute hardware, the hypervisor, and the underlying global network. The customer is entirely responsible for securing everything in the cloud: the configuration, the data, the applications, and the identity perimeter.

AWS makes this distinction crystal clear: Amazon secures the cloud, while the customer secures what is inside the cloud. You cannot audit your way to a secure configuration. Threat actors do not read your ISO 27001 documentation. They scan for misconfigured S3 buckets, overly permissive IAM roles, exposed access keys, and configuration drift.

The moment you rely on manual changes in the AWS Management Console, you introduce human error. In a cloud environment, that single human error can scale instantly into a structural compromise.

Deterministic Security through Infrastructure as Code

The only reliable way to prevent cloud takeovers is to remove manual intervention entirely. Security must be engineered directly into the deployment pipeline using Infrastructure as Code.

By defining your entire AWS environment with Terraform, you transform abstract security policies into mathematical certainty. Every IAM policy, every private subnet, every security group rule, and every encryption setting is declared in code, version-controlled, peer-reviewed, and applied through automated pipelines.

The Terraform state file becomes the single source of truth for your infrastructure. If an engineer attempts to manually alter a configuration in the AWS console, the next Terraform run will detect the drift and revert the environment back to its secure baseline.

This mechanism directly prevents the exact type of configuration drift that attackers exploit to gain and expand their foothold.

Here is a minimal example that enforces least privilege and blocks dangerous actions attackers commonly abuse:

# Enforce least-privilege IAM with no long-lived access keys
resource "aws_iam_role" "app_role" {
  name = "ec2-app-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "ec2.amazonaws.com" }
      Action    = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_policy" "least_privilege" {
  name = "least-privilege-policy"

A single terraform apply now guarantees these boundaries cannot be weakened by console clicks or emergency fixes.

Enforcing the Identity Perimeter

Traditional network boundaries are obsolete in cloud environments. Identity is the only true perimeter left.
To prevent the unauthorized access seen in the European Commission breach, strict Identity and Access Management must be enforced at the API level. This means abandoning static, long-lived access keys in favor of temporary credentials generated through AWS IAM Identity Center or IAM Roles Anywhere. Every workload, every autonomous agent, and every service must operate under the strict principle of least privilege.
If an attacker compromises a single service, well-defined execution boundaries must prevent lateral movement into sensitive databases or escalation to higher-privilege administrative roles.

Conclusion

Compliance is a byproduct of good engineering, not the other way around. Building a resilient AWS environment requires deep operational experience and a genuine commitment to deterministic architecture.

We must stop treating security as an administrative burden and start treating it as a "core engineering discipline."

In my view "Paper policies" do not stop breaches. Code does.

Sources

Bleeping Computer Report on the European Commission AWS Breach

(March 27, 2026):

https://www.bleepingcomputer.com/news/security/european-commission-investigating-breach-after-amazon-cloud-hack/

AWS Shared Responsibility Model:

https://aws.amazon.com/shared-responsibility-model/

HashiCorp Terraform State Management:

https://developer.hashicorp.com/terraform/language/state

The End of the Demo Phase: Securing AI Infrastructure in the Enterprise

Ali-Funk — Sat, 21 Mar 2026 11:22:32 +0000

The Market Reality

We are officially moving past the demo phase of artificial intelligence. The new NVIDIA certification framework correctly categorizes AI Networking and AI Operations as distinct professional tracks. Enterprise value is no longer created by chatting with a generative model. It is created by integrating these systems into highly secure cloud environments.

The Architectural Divide

The industry is currently splitting into two definitive paths. You are either building intelligence or you are building infrastructure. While the application track focuses on probabilistic generative models, the infrastructure track demands absolute deterministic control. The application track is rapidly fragmenting into countless new tools, while the infrastructure track relies on the permanent constants of physical networks, compute clusters, and Zero Trust architecture.

The Security Mandate

You can design the most advanced multimodal system in the world. If you deploy it into a Virtual Private Cloud with broad subnet allowances and weak ingress rules, you have failed the enterprise.

While rapid iteration is valuable in R&D, production environments demand deterministic controls. Probabilistic systems guess and iterate — when they are allowed to iterate across an unsecured network, they become a critical vulnerability. A broad network configuration is a lazy engineering practice that breaks isolation and expands the blast radius.

Here’s the difference in practice (Terraform):

[FAIL] Demo era configuration
ingress {
from_port   = 443
to_port     = 443
protocol    = "tcp"
cidr_blocks = ["0.0.0.0/0"]  # This opens up to the entire world!
}
[PASS] Production era Zero Trust configuration
ingress {
description      = "HTTPS from internal networks"
from_port        = 443
to_port          = 443
protocol         = "tcp"
cidr_blocks      = ["10.0.0.0/16"]
security_groups  = [aws_security_group.app.id] # Limit access to a specific application security group
}

The Operational Execution

My operational reality is securing this foundation. Bringing eight years of operational IT experience into my current AWS Solutions Architect training, I understand that data scientists need a highly restricted environment: VPC endpoints only, no public subnets, IAM roles with least-privilege access for SageMaker or Bedrock, network ACLs combined with security groups, and private model registries.

This aligns perfectly with my direct progression toward a Master of Business Administration in IT Security and Compliance. Securing compute clusters and enforcing Zero Trust network boundaries is the only way to move intelligent systems from isolated tests into production. This requires strict Terraform execution and absolute adherence to compliance standards.

The future of enterprise scale belongs to those who build the secure boundaries.

Sources

1.NVIDIA Deep Learning Institute Certification Framework:
https://www.nvidia.com/en-us/training/certification/

2.AWS Security Best Practices for Machine Learning:
https://docs.aws.amazon.com/sagemaker/latest/dg/security.html

3.NIST Artificial Intelligence Risk Management Framework:
https://www.nist.gov/itl/ai-risk-management-framework

4.HashiCorp Terraform AWS Provider Documentation:
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/security_group

5.AWS Well Architected Framework Security Pillar:
https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html

Zero Trust Architecture for AI Runtime Execution

Ali-Funk — Tue, 17 Mar 2026 22:03:04 +0000

The introduction of the Bedrock AgentCore Runtime Shell Command elevates large language models from text generators to active system participants. This capability demands a strict zero trust architecture.

Enterprise operations require predictability. When deploying an autonomous shell, the infrastructure must enforce a zero trust baseline. Giving a probabilistic model direct interaction with an operational environment is a massive paradigm shift. We can no longer rely on prompt engineering to secure an enterprise environment. Trusting a generative model to obey natural language constraints is a structural vulnerability. Instead, we must apply strict deterministic limits.

Here is how we build the architecture for an autonomous shell:

Network Isolation
The execution environment must be entirely sealed. Place the Bedrock agent runtime in a dedicated Virtual Private Cloud with no inbound internet access. Outbound connections must be explicitly allowed to approved endpoints only.

Identity and Access Management
The role assumed by the agent must have a strict permissions boundary. It should never have the ability to alter its own permissions or create new policy versions. Limit the blast radius to the exact resources required for the task.

Immutable Logging
Every system command generated and executed by the shell must be recorded. Send these logs to an isolated storage bucket where the agent has zero write access. You need a verifiable audit trail of every automated action.

Security is not optional. We MUST build environments that dictate the rules to the AI. We MUST treat the autonomous shell exactly like an unverified external entity. Security is established by deterministic infrastructure rules, never by generative models.

Sources:

https://aws.amazon.com/about-aws/whats-new/2026/03/bedrock-agentcore-runtime-shell-command/

https://docs.aws.amazon.com/bedrock/latest/userguide/security-iam.html

https://aws.amazon.com/architecture/security-identity-compliance/

Why End-to-End Encryption Cannot Protect Infrastructure Metadata

Ali-Funk — Mon, 09 Mar 2026 20:30:31 +0000

The recent incident involving Proton and the FBI is not a technical failure of encryption. It is a harsh reminder of a fundamental architectural truth:

end-to-end encryption protects the payload, but network infrastructure inevitably generates metadata.

When enterprise architects or privacy advocates confuse encrypted storage with "absolute" anonymity, they create a massive vulnerability in their threat model, at least that´s my view.

At its core, end-to-end encryption ensures that the content of a message remains cryptographically sealed between the sender and the recipient. The service provider cannot read the payload.

However, delivering that payload requires routing. It requires session tokens, account creation timestamps, payment gateways, and recovery email addresses. This operational "exhaust" is the metadata and that metadata can be analyzed.

When legal compliance frameworks and cross-border assistance treaties are activated, authorities do not need to break the AES or RSA encryption of the message content.

What do they have to do instead to get around it ?

They simply target the metadata. A recovery email address linked to a different provider or a logged IP address from a specific session is often more than enough to establish identity.

The industry is finally beginning to recognize this vulnerability at the network layer. For example, Mullvad VPN recently integrated DAITA (Defense against AI-guided Traffic Analysis) into their infrastructure.

Because modern AI can analyze the size and timing of encrypted packets to accurately infer user activity, DAITA pads all data packets to a constant size and injects random "dummy" traffic into the tunnel.
This feature is a direct architectural response to the fact that payload encryption is no longer enough. The battleground has entirely shifted to obscuring the operational exhaust.

However, while tools like DAITA protect real-time traffic analysis from ISPs or data brokers, they do not solve the static identity problem.

After eight years in operational IT, the most common architectural flaw I observe is the assumption that a secure application automatically provides a secure environment. But the assumption is what I see as a mindset problem.

If you deploy a highly encrypted service but fail to govern the underlying identity verification mechanisms or account recovery paths, you have only shifted the vulnerability.

Trusting a third-party service provider ultimately means trusting THEIR local legal jurisdiction and their logging mechanisms. Marketing claims about safe haven data centers do not override international legal cooperation.

If your threat model requires absolute operational anonymity, relying on a _public _ SaaS provider is architecturally insufficient, regardless of how "strong" their encryption is. You must govern the ENTIRE DATA LIFECYCLE, from the physical network routing up to the application layer.

That is very expensive. That is why only the so-called "Hyperscalers" Amazon Web Services, Google Cloud and Microsoft Azure can do it.

To truly understand this vulnerability, we must visualize the network journey. The following architecture diagram maps a standard secure connection. Notice how the core payload is protected, yet the operational exhaust like DNS requests, routing IP addresses, and session logs remains fully exposed at multiple infrastructure layers.

The Visual Proof: Payload vs. Metadata Exhaust

This reality completely dismantles the illusion that small-scale operators can realistically govern the entire data lifecycle without relying on external infrastructure. It proves that true digital sovereignty is a financial issue, not just a technical one.

Everything else is just an illusion of privacy.

Sources:

Proton: FBI user identification shakes Swiss data protection
https://www.heise.de/en/news/Proton-FBI-user-identification-shakes-Swiss-data-protection-11203086.html
Proton Legal and Privacy Policy
https://proton.me/legal/privacy
Mullvad VPN: Introducing Defense against AI-guided Traffic Analysis (DAITA)
https://mullvad.net/en/blog/introducing-defense-against-ai-guided-traffic-analysis-daita
Electronic Frontier Foundation: The Problem with Metadata
https://www.eff.org/deeplinks/2013/06/why-metadata-matters

Architecting Zero Trust for Autonomous Agents

Ali-Funk — Sat, 07 Mar 2026 22:03:43 +0000

Network Segregation and Identity Boundaries

Integrating autonomous systems and agentic orchestration fundamentally changes enterprise cloud architecture. Granting software the ability to execute dynamic decisions requires "absolute"governance.

When you deploy these agents into production, you are introducing a highly capable entity inside your perimeter. Securing this new operational paradigm requires a dual approach: strict network isolation at the infrastructure layer and granular execution boundaries at the identity layer.

Deploying autonomous agents into a flat network is a critical vulnerability. If an agent is compromised or hallucinates an incorrect operational path, the blast radius must be physically contained. Utilizing AWS Transit Gateway allows us to architect strict routing domains. The agents are placed in isolated virtual private clouds that cannot communicate directly with core enterprise workloads. All traffic is forced through centralized security inspection hubs. This ensures that even if an agent attempts unauthorized lateral movement, the underlying network architecture mathematically blocks the routing.

However, network isolation is only half the architecture. The agent must also be restricted in what AWS APIs it can call. Implementing IAM Permissions Boundaries ensures that an agent cannot escalate its own privileges or modify its own guardrails. By combining strict identity policies with resource tags, we ensure the agent only interacts with explicitly approved data sets and services. This creates a hard ceiling on the maximum possible permissions the agent can assume, regardless of the role it is executing.

True architectural leverage comes from enabling advanced capabilities while limiting their risk. Sounds obvious but it isn´t.

Combining firstly "Transit Gateway routing isolation" with secondly
"IAM permissions boundaries" provides the exact governance required to *safely * integrate autonomous orchestration into modern environments.

You build the infrastructure so the software cannot break the rules.

Sounds abstract in an article but if you get this wrong in the real world the consequences are news worthy.

Here are some real world examples:

The Register: Vibe coding service Replit deleted production database
https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/

The Guardian: Amazon cloud hit by outages caused by AI tools
https://www.theguardian.com/technology/2026/feb/20/amazon-cloud-outages-ai-tools-amazon-web-services-aws

Sources:

AWS Transit Gateway Architecture
https://aws.amazon.com/transitgateway/
AWS IAM Permissions Boundaries
https://aws.amazon.com/iam/
AWS Cloud Security
https://aws.amazon.com/security/

Why Bare Metal Nostalgia is Dead and Cloud Governance is the New Sovereignty

Ali-Funk — Sun, 01 Mar 2026 23:21:38 +0000

The romantic idea of the isolated local server is dead. Let us look at the absolute reality of enterprise architecture in 2026. The cloud won the infrastructure war. Even the loudest advocates for European digital sovereignty, like the Schwarz Group with their STACKIT initiative, recently realized they had to form a massive strategic partnership with Google Cloud to actually deliver modern services. Retreating entirely to local hardware is operational suicide for any globally scaling business.

But acknowledging that the hyperscalers won does not mean we have to surrender our architecture to them.

Right now, cloud providers are using their market dominance to fund their massive artificial intelligence bubble. They are raising compute prices and forcing their enterprise customers to foot the bill. Companies that built their entire infrastructure using proprietary click operations within a single provider dashboard are now trapped in a devastating financial lock in. They are bleeding cash with absolutely zero leverage to negotiate.

The immediate reaction from traditional IT departments is panic. They want to retreat. They want to buy bare metal, rack physical servers in basements, and hire traditional system integrators to plug in cables.
But the traditional system integrator is an outdated concept ( I know because I am re-training to get official certified as one). It is a piece of paper designed to bypass human resources filters, not a strategy for building modern, resilient global architecture.
For that, at least in my view, you need to become a Cloud Architect.

True digital sovereignty in 2026 does not mean owning the physical metal. It means owning the abstraction layer.

Real power lies in infrastructure as code. If you use tools like Terraform to define your entire environment via the command line interface, you own the architectural blueprint. You utilize the hyperscaler, but the hyperscaler does not own you. Your enterprise architecture is not "held hostage" inside their proprietary menus.

This is where infrastructure as code transforms from a technical practice into a financial weapon. I call it "Architectural Leverage."

When your entire system is abstracted into code, you hold the ultimate negotiating power. If a cloud provider suddenly doubles their compute pricing to fund their algorithmic models, you do not panic. You do not beg your account manager for a discount. You simply change the provider variables in your codebase and deploy your environment somewhere else.
At least you should.
You use portability to keep the cloud providers in check and your costs low.

The industry does not need traditional network administrators anymore. It desperately needs modern cloud governance engineers. Over my eight years of professional experience, I have seen the cycles of outsourcing and the inevitable structural failures it causes. Enterprises now require professionals who can execute three core directives:

1.Design abstracted deployments

2.Aggressively audit billing cycles

3.Ensure structural flexibility to shift workloads without rebuilding
the foundation

Digital sovereignty is no longer about avoiding the cloud. It is about using strict code governance to dictate exactly where the enterprise spends its money.

Sources:

1.Basecamp The Big Cloud Exit FAQ
https://world.hey.com/dhh/the-big-cloud-exit-faq-20274010

2.Andreessen Horowitz The Cost of Cloud a Trillion Dollar Paradox
https://a16z.com/2021/05/27/cost-of-cloud-paradox/

3.CUDO Compute Why AI teams need cloud infrastructure without vendor lock ins
https://www.cudocompute.com/blog/why-ai-teams-need-cloud-infrastructure-without-vendor-lock-ins

4.Luminis Digital Sovereignty and the Public Cloud Navigating Azure in a European Context
https://www.luminis.eu/blog/digital-sovereignty-and-the-public-cloud-navigating-azure-in-a-european-ccontext/

The Trillion Dollar Smokescreen and why Replacing Engineers with Algorithms is a Structural Failure

Ali-Funk — Thu, 26 Feb 2026 23:19:16 +0000

The recent memo from Goldman Sachs detailing job cuts under the guise of an Artificial Intelligence push is not an isolated incident. It is the exact blueprint of the current tech market. We are watching executives confuse cost reduction with value creation. Over the past few years, the industry "overhired" massively. Now, Artificial Intelligence is being deployed as the ultimate corporate smokescreen to justify restructuring, leaving the actual tech workers to pay the heavy price.

Let us be absolutely clear about the financial reality. Firing your engineers to fund algorithmic initiatives does not create new business value. It merely shifts capital from internal payroll directly into the pockets of a few select cloud providers and hardware giants. The workers lose their livelihoods, while the enterprise gains exactly zero competitive advantage. Most companies do not even possess the clean data infrastructure required to utilize these models effectively. They are buying the hype, but only the "Hyperscalers" are taking home the actual profit.

From an architectural perspective, this mass replacement of human capital is a catastrophic compliance failure waiting to happen. If a bank or enterprise replaces its technical workforce with language models, it inherently destroys its human auditing layer. A language model generates syntax, but it cannot take legal responsibility. When executives cut the staff who architect, validate, and secure the output, they are trading human governance for automated liability. Over my eight years of professional experience, I have seen exactly what happens when you remove the governance layer. The entire system collapses under its own weight.

This does not happen overnight. It is a slow and painful process in which those who had the privilege to not be cut have to pick up the work of those who were let go. Over time, those people get overworked and undervalued because they have to do more with fewer people. They are purposefully overlooked until they have no choice other than to leave too, willingly this time.

Do not get me wrong. Artificial Intelligence is not inherently bad. It is a powerful tool. But it is just that: a tool.

It is not a magical solution that fixes broken enterprise architecture or replaces the need for senior oversight. We are still in the early stages of figuring out how to actually integrate these systems without compromising security and digital sovereignty.

Until we understand the operational boundaries of this tool, treating it as a direct replacement for human intellect and experience is just reckless management. Driven by exactly what you would expect: the fear of being left behind, also known as FOMO.

But who actually got left behind?

The people who gave their lives to the companies that just fired them. Some of us will remember the age of so called Artificial Intelligence as the time companies thought that firing under the disguise of AI would go unnoticed.

For those of you who read this far: I hope you see it too. Workers and humans are the ones who lost their livelihoods because a chosen few used the hype they themselves created to get even richer than they already were.

Make no mistake, we are operating inside a massive Artificial Intelligence bubble. But the tide is turning. More and more people are finally catching on to the fact that this unchecked hype has inflated a bubble completely devoid of actual business value. The future of technology belongs to those who govern the systems, not those who blindly trust the generated output. It is time we hold the industry accountable for selling a narrative that profits a few at the expense of the workers who actually built the foundation.

Sources:

Reuters Goldman Sachs eyes job cuts and hiring slowdown amid AI push
https://www.reuters.com/business/world-at-work/goldman-sachs-eyes-job-cuts-hiring-slowdown-amid-ai-push-memo-shows-2025-10-14/

Goldman Sachs Gen AI Too much spend too little benefit
https://www.goldmansachs.com/insights/top-of-mind/gen-ai-too-much-spend-too-little-benefit

Forbes AI Study 2025 Why Enterprises Struggle to Measure AI ROI
https://www.mavvrik.ai/forbes-ai-study-2025/

Gartner Predicts 30 Percent of Generative AI Projects Will Be Abandoned
https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025

Layoffs Tracker
https://layoffs.fyi/

ENISA Artificial Intelligence
https://www.enisa.europa.eu/topics/artificial-intelligence

The Illusion of Digital Sovereignty: Why Vendor Swapping is Not a Compliance Strategy

Ali-Funk — Mon, 23 Feb 2026 21:12:52 +0000

The recent announcement that the Schwarz Group is moving hundreds of thousands of employees to Google Workspace is being marketed as a "triumph of digital sovereignty".

They built an impressive European data center infrastructure with STACKIT. But migrating from one American hyperscaler to another and calling it sovereignty is essentially an official declaration of surrender.

It is a brilliant marketing campaign, but from an enterprise architecture and compliance perspective, it is a structural failure.

The Cryptographic Facade

To be clear, the technical execution of the storage layer is solid.
Schwarz Digits is utilizing External Key Management combined with Client Side Encryption.
Architecturally, holding the cryptographic keys in their own STACKIT environment while using Google purely for encrypted storage is the correct way to mitigate the US CLOUD Act for data at rest. Google only sees encrypted blobs.

However, encrypting the payload is only a fraction of the governance equation.

Architectural Blind Spot 1: The Execution Context

The fundamental flaw lies in the execution layer. The data is encrypted on the endpoint, but who delivers the application code that performs this encryption?
If users are accessing Workspace via a web browser, Google is delivering the Javascript payload.

If a United States intelligence court issues a secret subpoena, they can legally compel the vendor to serve a modified code payload to a specific target. In that scenario, the local encryption is compromised before the data ever reaches the STACKIT key management vault.
You cannot claim sovereignty if a foreign entity controls the execution environment of your software.

Architectural Blind Spot 2: The Metadata Reality

Encrypting the document content completely ignores the value of metadata. Google still processes the authentication requests, the IP addresses, the timestamps, and the collaboration networks. In state level surveillance or corporate espionage, knowing exactly who is talking to whom, and when, is often more valuable than the actual file content. The hyperscaler still owns the telemetry.

Architectural Blind Spot 3: Structural Dependency

The final point is raw operational governance. What happens when the vendor changes their terms of service, alters their pricing model, or faces extreme political pressure? The cryptographic architecture does not change the fact that the entire enterprise is completely dependent on a US software platform.

True sovereignty requires absolute control over the software itself, not just the encryption keys. Investing massive resources into European data centers just to run American software is not digital independence.

The Governance Reality

The industry needs to stop framing vendor transition projects as "sovereign architectures." True IT security and compliance dictate that you must control the boundaries of the code, the execution, and the data.
The future of enterprise architecture belongs to organizations that invest in owning their systems, not just renting new ones.

Sources:

https://t3n.de/news/echte-europaeische-alternativen-ich-sehe-schwarz-1730598/

justice.gov/dag/cloudact (Official US Department of Justice CLOUD Act mandate)

cloud.google.com/workspace/security (Google Workspace Security and Client Side Encryption architecture)

stackit.de/en/security (STACKIT Cloud Security and Compliance documentation)

edpb.europa.eu (European Data Protection Board guidelines on supplementary measures for data transfers)

nist.gov/publications (National Institute of Standards and Technology Zero Trust Architecture outlining execution context risks)

enisa.europa.eu (European Union Agency for Cybersecurity guidelines on data sovereignty and engineering)

The AI Productivity Crisis And The Architecture Of Execution

Ali-Funk — Sun, 22 Feb 2026 20:15:50 +0000

Companies are burning billions on AI, yet over 80 percent of them see zero productivity gains. Reports from Tom’s Hardware and the Economic Times confirm the reality: executives are spending 90 minutes a week typing prompts into a chatbot and wondering why operations aren't scaling.

The problem isn't the models. It’s the architecture.
The Market Bloodbath: Feb 20, 2026

If you want proof of what happens when you fix the architecture, look at the market reaction to Anthropic’s release of Claude Code Security. Unlike a chatbot, this is an executing agent. It scans codebases, traces data flows, and autonomously writes patches. It found over 500 bugs in production open-source code that human reviewers missed for years.

The market response was a vertical drop. When Wall Street realized the difference between a "text generator" and an "executing agent," billions in market cap vanished from legacy cybersecurity firms in a single session.

JFrog: -24.94%
Okta: -9.18%
CrowdStrike: -7.95%
Cloudflare: -8.05%
Zscaler: -5.47%

Verification: Pulling the Raw Data

To ensure these numbers weren't just "AI-hallucinated" or pulled from biased news snippets, I ran a raw data extraction against the Yahoo Finance API for the Feb 19–21 window.

The Python Verification Script:

import yfinance as yf
tickers = ['FROG','OKTA','CRWD','NET','ZS']
data = yf.download(tickers, start='2026-02-19', end='2026-02-21')['Close']
print(((data.iloc[-1]-data.iloc[0])/data.iloc[0]*100).round(2))

Terminal Output (Raw Source Truth):

Ticker
CRWD    -7.95
FROG   -24.94
NET     -8.05
OKTA    -9.18
ZS      -5.47
dtype: float64

A 25% drop for JFrog in 24 hours isn't a glitch this is a structural realignment of the industry.

Why Architecture Matters

I have spent eight years in IT operations. When a system fails at 03:00, a chatbot is useless.

It can’t access your DB
it can’t update your CRM
it can’t resolve a ticket

Real business value and the reason the stocks above tanked.
That´s from Autonomous Execution.

In the AWS Become A Solutions Architect program, the technical answer
is Agentic AI.
We are moving from "Systems of Record" to "Systems of Action."

The Architectural Blueprint for ROI:

The Orchestration Layer: Move beyond simple chat. Use Pre-processing to validate requests and Post-processing for final execution.

The Execution Layer: Use Amazon Bedrock Action Groups. Integrate FMs with backend services via isolated Lambda functions.

Infrastructure as a Boundary: Secure probabilistic models with deterministic infrastructure limits via IAM.

Zero Trust Principles: Treat agents as stateless, disposable units.

Which means:

Productivity only rises when AI stops generating prose and starts completing end-to-end tasks.

Sources:

https://www.tomshardware.com/tech-industry/artificial-intelligence/over-80-percent-of-companies-report-no-productivity-gains-from-ai-so-far-despite-billions-in-investment-survey-suggests-6-000-executives-also-reveal-1-3-of-leaders-use-ai-but-only-for-90-minutes-a-week

https://www.heise.de/en/news/Anthropic-launches-Claude-Code-Security-Cybersecurity-stocks-lose-value-11185215.html

https://economictimes.indiatimes.com/tech/technology/cybersecurity-stocks-hit-sharply-by-anthropic-claude-code-security/articleshow/128631892.cms