I'm going to say something that's probably going to annoy a few people in the technology industry.
I hate the cloud.
There. I said it.
Now, before somebody starts explaining virtualization, distributed computing, or the benefits of hyperscale infrastructure to me, let me save us both some time.
I understand the technology.
That's not the problem.
My problem is what we've done with it.
Somewhere along the way, we took technologies that have existed in various forms for decades, wrapped them in a convenient marketing term, and started selling them as though we'd discovered the technological equivalent of the Holy Grail.
Need more computing power? Move it to the cloud.
Need better security? Move it to the cloud.
Need disaster recovery? Move it to the cloud.
Need business continuity? Apparently, the cloud solves that too.
And if you listen to enough sales presentations, you'd think the answer to every infrastructure problem humanity has ever encountered is simply to move everything into somebody else's data center.
Give me a break.
The Cloud Isn't Magic
Let's establish something right away.
Behind every cloud service are physical servers, storage systems, networking equipment, power systems, cooling infrastructure, software, and people responsible for keeping everything running.
Those things don't disappear because someone puts a cloud-shaped icon on a PowerPoint slide.
And neither do the engineering problems.
Hardware still fails. Networks still experience outages. Software still has vulnerabilities. People still make mistakes.
And poorly designed systems still collapse when the wrong combination of circumstances occurs.
The underlying technologies can be extraordinarily useful. But usefulness doesn't make them universally appropriate.
And convenience doesn't eliminate the responsibility to engineer a solution correctly.
One Size Does Not Fit All
Years ago, around 2018, I had a conversation with a friend who was familiar with the CDC's BioSense public-health surveillance platform.
We discussed some of the challenges associated with running workloads on AWS, particularly when standardized resource configurations didn't necessarily align with an application's changing requirements.
As I recall, one concern was that obtaining additional capacity in one area could sometimes mean paying for resources that weren't needed elsewhere.
Now, this was a conversation about a particular workload at a particular point in time. AWS has evolved considerably since then, and I'm certainly not suggesting that every service has those limitations today.
But the underlying lesson hasn't changed.
Just because an infrastructure model works well for millions of customers doesn't mean it's automatically the right fit for every customer.
Standardized offerings can be efficient and economical. They can also impose tradeoffs that don't align with a particular workload.
Sometimes those tradeoffs are acceptable.
Sometimes they aren't.
And when they aren't, the customer shouldn't be pressured into believing the problem is somehow theirs for having requirements that don't fit the provider's preferred model.
Engineering should come before the sales pitch.
High Availability Is a House of Cards
Here's something that drives me absolutely crazy.
People throw around terms like high availability, redundancy, resilience, and disaster recovery as though they're interchangeable.
They're not.
High availability is a house of cards.
And before somebody misunderstands that statement, I'm not saying high availability is inherently unreliable.
I'm saying that achieving it requires meticulous planning, engineering, and a thorough understanding of how the entire system behaves.
You can have redundant power supplies, redundant switches, redundant storage, and multiple geographic locations.
Congratulations.
Now tell me what happens when those components share a common dependency.
What happens when your management plane becomes unavailable?
What happens when a software defect propagates across supposedly independent systems?
What happens when your redundant copies faithfully replicate corrupted or compromised data?
And what happens when your organization discovers that having its applications available somewhere else doesn't mean its employees can actually perform their jobs?
Redundancy is not the same thing as survivability.
A system doesn't become highly available simply because the vendor's brochure says it is.
Stop Pretending All Infrastructure Is Interchangeable
Another one of my pet peeves is the idea that practically everything should be virtualized simply because we can virtualize it.
Let me be clear.
I'm not opposed to virtualization.
There are excellent reasons to virtualize workloads, management systems, and many network functions.
Atlas itself plans to use virtualized components where they're appropriate.
But there's a difference between using virtualization intelligently and assuming a software implementation running on general-purpose hardware is automatically equivalent to purpose-built equipment.
Take high-performance data center networking.
Companies like Cisco have invested enormous engineering resources into specialized switching hardware, forwarding silicon, buffers, and fabric architectures.
That engineering exists for a reason.
Now, can a software-based switching solution meet the requirements of certain workloads?
Of course it can.
But that doesn't mean its performance characteristics, isolation properties, operational dependencies, or failure behavior are identical to those of purpose-built switching hardware.
And it certainly doesn't mean we should assume equivalence without examining and testing those differences.
For ordinary workloads, the tradeoffs may be perfectly acceptable.
For environments where failure could interrupt emergency communications, hospital operations, or other essential services, the standard of engineering evidence needs to be considerably higher.
You don't get to replace engineering with enthusiasm.
Borderless Disaster Recovery Meets Zero Trust
Here's another example.
We've spent years promoting concepts like borderless disaster recovery.
The idea is attractive.
Your organization shouldn't necessarily be dependent on one building, one city, or one geographic region to recover its operations.
Fair enough.
But at the same time, the cybersecurity industry has been promoting Zero Trust.
And for good reason.
Zero Trust recognizes that access to systems and information must be explicitly authorized, appropriately limited, and continuously evaluated.
Now ask yourself something.
What happens when an organization begins moving workloads and data across multiple locations, providers, administrative domains, and jurisdictions?
Do its security controls automatically follow?
Do its identity and authorization policies remain consistent?
Do its segmentation boundaries behave exactly as intended?
Who controls recovery?
Who verifies the integrity of the recovered systems?
And who makes the final decision that those systems are safe to reconnect?
Borderless disaster recovery and Zero Trust are not inherently incompatible.
But making them work together requires careful engineering.
You cannot simply assume that because a workload can move, its security boundaries and operational authority will move with it correctly.
And this brings me to the part of this entire conversation that bothers me most.
The People Who Need These Technologies Most
The organizations that could benefit most from sophisticated infrastructure, cybersecurity, and continuity solutions are often the organizations least equipped to evaluate them.
Small and medium-sized businesses.
Rural hospitals.
Municipal governments.
Nonprofits.
Humanitarian organizations.
Critical infrastructure operators.
These organizations may not have teams of specialized engineers capable of dissecting every technical claim in a sales presentation.
That's often why they're hiring a managed solutions provider in the first place.
And what do we sometimes tell them?
Don't worry. It's managed.
It's redundant.
It's secure.
It's in the cloud.
Then, when something goes wrong, suddenly we're talking about shared responsibility, configuration requirements, exclusions, limitations, and contractual language that the customer may never have fully understood.
Now, don't misunderstand me.
Customers have responsibilities too.
They need to communicate their requirements, participate in planning, understand their business risks, and make informed decisions.
But if you're selling engineering expertise, you have an obligation to exercise that expertise.
You cannot sell someone the promise of professional management and then act surprised when they expect you to manage the professional responsibilities that come with it.
That's particularly important when the customer is responsible for healthcare, emergency response, critical infrastructure, or humanitarian operations.
Because in those environments, the consequences of getting it wrong can extend well beyond financial losses.
People's lives may depend on the outcome.
We've Traded Security for the Perception of Survivability
I think one of the most dangerous developments in our industry is the false sense of security we've created.
Organizations purchase geographic redundancy and believe they've purchased business continuity.
They purchase backup services and believe they've purchased disaster recovery.
They purchase cybersecurity products and believe they've purchased security.
And they purchase high-availability infrastructure and believe they've purchased survivability.
Those things are related.
They are not the same.
A backup isn't particularly useful if you cannot restore it within the time your organization needs.
Geographic redundancy isn't sufficient if all your locations depend on the same compromised identity infrastructure.
And a recovery environment isn't much of a solution if your people, processes, communications, and operational dependencies cannot function when you need them.
The problem isn't that these technologies have no value.
They can have tremendous value.
The problem is believing that purchasing the technology automatically delivers the operational outcome.
It doesn't.
You have to engineer it.
You have to test it.
And you have to be willing to confront the results when those tests reveal something you don't want to hear.
Whatever Happened to Corporate Responsibility?
In 1982, Johnson & Johnson faced a crisis after seven people died from cyanide-contaminated Tylenol capsules.
The company's response became one of the most frequently studied examples of corporate responsibility.
It recalled products, prioritized consumer safety, and changed its packaging practices.
That response involved enormous financial consequences.
But it also demonstrated something I believe we've lost sight of in parts of the technology industry.
Doing the right thing shouldn't require someone from a regulatory agency to stand over your shoulder.
Regulation matters.
Contracts matter.
Compliance matters.
But corporate responsibility should mean more than doing the minimum necessary to avoid legal consequences.
If your organization is selling a solution that people depend on, you have a professional obligation to understand whether that solution is appropriate for their requirements.
And if you discover a serious problem, you have an obligation to address it.
That doesn't mean every vendor must make identical decisions in every situation.
It means corporate culture should reflect a genuine commitment to the people and organizations the company serves.
You can regulate compliance.
You cannot regulate integrity into a corporate culture.
The Standard I'm Setting for Atlas
Atlas Global Technologies is still in its prelaunch development stage.
We're designing a continuity-focused infrastructure platform, not claiming to have already demonstrated a fully operational global network.
And I want to be very clear about something.
The standards I'm discussing here must apply to Atlas just as much as they apply to every other technology provider.
Our planned approach starts with understanding the customer's actual business requirements through a business impact analysis conducted by the customer or an independent party.
From there, we intend to work with customers to define measurable operational outcomes and develop continuity testing around those requirements.
Not just what the infrastructure is supposed to do.
What the organization actually needs to keep doing when something goes wrong.
And if our engineering team believes a proposed solution cannot safely meet its intended requirements, I want those engineers to have the authority to temporarily freeze the solution or contract pending executive review.
I don't care how much the contract is worth.
Certain engineering and life-safety requirements must remain non-negotiable.
That review should involve both the engineers responsible for the solution and independent technical and risk oversight.
And the CEO shouldn't be able to declare an unsafe architecture safe simply because the organization wants the revenue.
We also intend to establish contractual procedures for addressing unsafe practices discovered after deployment, including remediation periods, accelerated action where serious life-safety concerns exist, appropriate disclosure provisions, and controlled transitions when continued service is no longer acceptable.
Those procedures will require careful legal and operational design.
But the underlying principle is straightforward.
It doesn't mean anything to build a profitable, successful company if we achieve that success by knowingly putting customers' businesses or people's lives at unacceptable risk.
Period.
So Why Do I Hate the Cloud?
Because I hate what the term has come to represent in too many conversations.
I hate the assumption that one delivery model solves every problem.
I hate the tendency to confuse convenience with engineering.
I hate the idea that redundancy automatically means continuity, or that availability automatically means survivability.
And I especially hate the false confidence that can develop when organizations trust solutions they haven't been given the knowledge or evidence to evaluate properly.
But I don't hate the underlying technology.
Far from it.
Years ago, I wrote an article called Social Justice and Corporate Responsibility in the Digital Age: A Story of Transformation.
In it, I discussed how the internet and emerging technologies could help address some of humanity's greatest challenges.
I believed that then.
I believe it today.
The possibilities are extraordinary.
But with those possibilities comes responsibility.
Customers need to demand proof that the solutions they're purchasing can deliver the outcomes they require.
Executives need to stop treating cybersecurity and business continuity as boxes they can check by signing a contract.
And vendors need to remember that their professional obligations don't end when the customer signs on the dotted line.
Because at the end of the day, I believe there's one principle every technology company should remember.
If you build it and they come, you have an obligation to make them safer and more resilient than they were before.
Period.