DEV Community: Manny Frank

Cloud-Native vs Cloud-Agnostic Isn't a Technology Debate

Manny Frank — Tue, 16 Jun 2026 12:24:41 +0000

One of the most common architecture discussions today is whether teams should build cloud-native or cloud-agnostic systems.

The conversation is often framed as a technical decision, but the reality is usually more nuanced.

The Cloud-Native Argument

Cloud-native architectures allow teams to move quickly.

Managed databases, serverless platforms, and vendor-specific services can significantly reduce operational complexity and accelerate delivery.

For startups and teams searching for product-market fit, this speed can be a competitive advantage.

The Cloud-Agnostic Argument

As products scale, priorities change.

Organizations may need portability across providers, stronger negotiating leverage, regulatory flexibility, or resilience against vendor-specific limitations.

At that stage, cloud-agnostic architectures become more attractive.

The Real Question

Instead of asking:

"Which approach is better?"

Ask:

"Which approach best supports our current business stage?"

The answer for an early-stage startup may be completely different from the answer for a mature enterprise.

Further reading:
https://geekyants.com/blog/cloud-native-and-cloud-agnostic-are-not-ideologies-they-are-business-stage-decisions

What has your experience been?

Most Financial Institutions Are Solving Fraud the Right Way but Building Infrastructure the Wrong Way

Manny Frank — Tue, 16 Jun 2026 05:27:53 +0000

Fraud is getting smarter.

Every year, financial institutions invest billions into fraud detection systems, risk management tools, compliance processes, and security teams. Yet fraud losses continue to rise as attackers increasingly leverage automation and AI.

The industry's response has been predictable: invest more heavily in AI-driven fraud prevention.

And honestly, that's the right move.

What surprises me is that many organizations embrace AI for fraud detection while simultaneously making infrastructure decisions that slow down their ability to deploy and improve those systems.

In my opinion, the future belongs to financial institutions that are aggressively cloud-native.

Not cloud-agnostic.

Not multi-cloud by default.

Cloud-native.

AI Is Becoming the New Fraud Analyst

Traditional rule-based fraud systems struggle because fraud patterns evolve faster than manual rules can be updated.

Modern AI systems can:

Detect anomalies in real time
Analyze behavioral patterns across millions of transactions
Reduce false positives
Improve risk scoring accuracy
Adapt to emerging fraud techniques

This shift is already visible across the financial industry.

Organizations such as JPMorgan Chase, Capital One, PayPal, Stripe, and Mastercard continue investing heavily in machine learning and AI-powered risk management systems because manual approaches simply cannot keep pace with modern threats.

The result is not just reduced fraud losses.

It's lower operational costs.

Every false positive reviewed manually creates additional workload. Every missed fraudulent transaction creates direct financial damage.

AI addresses both problems simultaneously.

A recent article from GeekyAnts highlighted how AI-driven fraud prevention helps organizations reduce financial losses while improving operational efficiency. The broader trend across the industry suggests this is becoming less of a competitive advantage and more of a baseline requirement.

The Infrastructure Contradiction Nobody Talks About

Here's where I think many organizations get it wrong.

While investing in AI-powered fraud detection, they're also building infrastructure strategies around maximum cloud portability.

The intention sounds reasonable.

Avoid vendor lock-in.

Maintain flexibility.

Preserve future options.

But these goals often come at a cost.

Additional abstraction layers.

More operational complexity.

Longer deployment cycles.

Slower innovation.

Ironically, the same institutions trying to accelerate fraud detection through AI frequently slow themselves down through infrastructure decisions.

Why Cloud-Native Gives AI Teams an Advantage

AI workloads thrive on cloud-native capabilities.

Managed data platforms.

Real-time event streaming.

Serverless processing.

Elastic compute resources.

Integrated machine learning services.

These capabilities dramatically reduce the time required to move from experimentation to production.

Companies such as Netflix, Amazon, Uber, and Spotify have demonstrated the value of leveraging cloud platforms aggressively instead of treating every provider feature as something that must eventually be abstracted away.

The same lesson applies to financial services.

If a managed cloud service helps a fraud detection model reach production six months earlier, the business value often outweighs theoretical migration concerns years down the road.

The Industry Overestimates Vendor Lock-In

This may be unpopular among architects.

But I think the industry dramatically overestimates the dangers of cloud dependence while underestimating the cost of delayed execution.

Most organizations will never migrate entire platforms between cloud providers.

Most organizations will, however, suffer from slow delivery cycles.

Those are not equivalent risks.

The obsession with cloud agnosticism often creates complexity long before it creates value.

A recent GeekyAnts article made an important observation: cloud-native and cloud-agnostic approaches are not ideologies. They are business-stage decisions.

I agree with that principle.

Where I differ slightly is that I believe the majority of growth-stage companies should lean toward cloud-native architectures far more aggressively than they currently do.

What Leading Organizations Understand

The best technology organizations don't treat architecture as a philosophical debate.

They treat it as a business decision.

**Amazon optimized for scale.

Netflix optimized for streaming reliability.

Stripe optimized for developer velocity.

Capital One optimized for cloud transformation.
**
Modern engineering firms such as **GeekyAnts, Thoughtworks, and Accenture **increasingly advocate aligning technology choices with business objectives rather than blindly following architectural trends.

The organizations gaining the most value from AI fraud prevention are often the same organizations willing to embrace cloud-native platforms to accelerate delivery.

That's not a coincidence.

My Take

AI-driven fraud prevention is quickly becoming mandatory in financial services.

The real differentiator won't be whether companies adopt AI.

Most eventually will.

The differentiator will be how quickly they can deploy, improve, and scale those systems.

That's why I believe cloud-native architectures are the smarter default for most financial institutions undergoing digital transformation.

Fraud evolves too quickly for organizations to spend years optimizing for hypothetical infrastructure scenarios.

In the race between portability and execution, execution wins far more often than the industry wants to admit.

And in financial services, slower execution can be just as expensive as fraud itself.

Your Code Is Costing You More Than You Think

Manny Frank — Tue, 19 May 2026 07:30:35 +0000

Fast shipping is exciting. But fast shipping combined with constant hotfixes, release anxiety, fragile deployments, and recurring bugs eventually becomes expensive.

A recent YouTube video called “Your Code is Costing You. Here’s How to Fix It” highlights a problem many engineering teams quietly struggle with: poor code quality slowly turns into a business problem, not just a technical one.

And honestly, most teams do not notice it early enough.

The Problem Usually Starts Small

In the beginning, technical debt feels manageable.

A rushed feature here. A skipped test there. A temporary workaround that somehow becomes permanent six months later.

Nothing breaks immediately, so the team keeps moving.

Then suddenly:

Releases become stressful
QA cycles take longer
Developers avoid touching certain modules
Production bugs keep returning
Deployments feel risky
Simple changes require too much effort

At that point, the issue is no longer “just code quality.” The engineering foundation itself starts slowing the product down.

Clean Code Alone Is Not Enough

A lot of developers associate code quality with formatting, linting, or naming conventions

Those things help, but mature engineering goes much deeper.

Real code quality includes:

Architecture that scales cleanly
Reliable testing practices
Secure APIs and infrastructure
Faster deployment pipelines
Maintainable systems
Predictable releases
Reduced operational risk

A codebase can look clean while still being difficult to scale or maintain.

That is why teams focusing only on surface-level cleanup often fail to solve the actual problem.

Technical Debt Quietly Compounds

Technical debt behaves a lot like interest.

The longer it stays unresolved, the more expensive future development becomes.

A feature that once took two days suddenly takes two weeks because developers now need extra testing, manual validation, and debugging before every release.

This creates a dangerous cycle where teams spend more time maintaining old systems than building new improvements.

The worst part is that technical debt rarely feels urgent until it starts affecting roadmap velocity.

By then, recovery becomes significantly harder.

Security Is Part Of Code Quality

One thing the video gets right is connecting code quality with security readiness.

Modern applications are expected to be secure by default. That includes:

API integrity
Authentication flows
OWASP compliance
Infrastructure hardening
Dependency management
Safe deployment practices

Security gaps often come from rushed engineering decisions, outdated systems, or inconsistent architecture standards.

This becomes even more important for SaaS platforms, fintech products, AI applications, and enterprise software where trust matters as much as functionality.

A product that scales without proper security eventually becomes a liability.

Better Testing Changes How Teams Ship

Testing is usually treated as a bottleneck until teams experience what strong test coverage actually does.

Good testing reduces fear.

Developers can refactor confidently. Releases become predictable. Bugs are caught earlier. Rollbacks happen less often.

The same applies to deployment speed

If deployments take too long or require manual coordination, teams naturally release less frequently. That slows feedback loops and delays product improvements.

Engineering maturity is not only about writing better code. It is about creating systems that allow teams to move faster without increasing risk.

Legacy Systems And AI Products Share Similar Problems

Interestingly, this issue affects both old and modern stacks.

Legacy systems often carry years of accumulated patches, undocumented logic, and fragile dependencies.

AI products introduce different complexity. They rely heavily on APIs, integrations, model pipelines, and infrastructure consistency. Even impressive AI features can fail in production if the engineering foundation underneath is unstable.

In both cases, scaling becomes difficult when engineering discipline is missing.

Final Thoughts

Most engineering problems do not appear overnight.

They build slowly through rushed releases, weak testing, inconsistent architecture, and unresolved technical debt.

Eventually, teams reach a point where every deployment feels risky and every new feature takes longer than expected.

That is why code quality should not be treated as a cosmetic improvement. It directly impacts delivery speed, security, maintainability, and long-term product growth.

Good engineering is not about perfection.

It is about building systems that developers can confidently maintain, scale, secure, and ship.