Living in the Cloud

Engineers that design and describe networks -- that is, how computers and other devices connect to each other, may draw a block diagram that shows all these devices and how they are connected. Within the area under direct organizational control; the computers, printers, networking devices, and interconnects are generally specified and drawn. You can see the big picture and how everything connects.

But areas of a network outside of an organization's control, such as the internet, are often drawn as a puffy cloud. That cloud signifies a segment of the connection that "just works" and knowing the details of that segment aren't always necessary or relevant.

The cloud, from that perspective, is simply a utility to be tapped, not too unlike how the public water supply works. You turn a faucet handle and water comes out. You, personally, aren't particularly interested in how that water got to your faucet.

Let's take that idea further. In the old days of the internet, in order to use email, a company had to set up and maintain an onsite email server. All incoming and outgoing email passed through that company-owned server.

Today, pretty much only large corporations run their own email servers. Small and medium sized businesses use email servers, such as Microsoft Exchange or Google Workspace, that are located in large data centers. These customers usually don't know or care about how that data center is run, so long as its secure and reliable -- that it "just works".

This makes email one of the earliest cloud applications. Since the very nature of email is communicating with other people, then locating that system on a cloud server makes some sense.

This discussion centers around business computer use. Although the facts discussed could apply to personal-use cloud services as well.

Evolution

The evolution of cloud infrastructure has been remarkably fast. Prior the the mid-aughts there really wasn't much to it. Businesses pretty much owned and operated their own infrastructure.

Early Cloud - 2006-2010

AWS (Amazon Web Services) launches S3 and EC2. This is the starting gun. Early adopters include new startup companies, test environments, and experimenters. Established companies aren't attracted just yet. On-premises is still king.

Cloud Becomes Credible - 2010-2014

AWS matures considerably; Azure (Microsoft) and Google Cloud make their marks. Virtualization, having been an on-prem feature for a while now, is helping to make that same virtualization -- but in the cloud -- more palatable.

SaaS offerings (more on that below) such as Salesforce, Office 365, and Google Workspace, quietly normalize businesses to trust "someone else's servers".

CapEx avoidance becomes a selling point.

Inflection Point - 2014-2019

For new business applications undergoing development, the cloud becomes the default model. On-prem options are either secondary or non-existent. Migrations away from on-prem (lift and shift) to cloud-provided equivalents are picking up.

Momentum and direction are clear. Enterprise users are coming onboard, cloud provider revenue starts taking off, cloud-first is here.

COVID Kick - 2020-2022

Work from home nukes most remaining resistance. Companies are having to quickly accommodate an at-home workforce. Early adaptations were simply adding remote capability to existing on-prem solutions but cloud-based providers quickly moved in.

Current State - 2022-Today

The cloud providers have pretty much won since the tech billionaires are calling the shots. On-prem solutions are still possible and often preferred for general-purpose business management tools. But depending on what specialized applications your business requires, some cloud involvement may be inevitable.

Cloud Service Providers (CSP)

These are companies that provide "Software as a Service", often abbreviated in the I.T. world as "SaaS".

What's that, you ask?

SaaS is software that is centrally hosted and accessed over the internet, typically through a web browser rather than installed locally. Unlike most traditional software, SaaS operates on a subscription basis, providing software makers with more predictable revenue while also enabling continuous updates and scalability.

While the subscription model is a strong business driver, SaaS also emerged due to advancements that made cloud-based software delivery more practical and efficient for some use-cases. e.g. Today's speedy fiber internet and high-powered data centers made SaaS products more feasible.

The Darker Side

The "cloud" isn't the panacea that most cloud pundits might imply, especially those that offer cloud services, funnily enough. Cloud services have their downsides that must be considered.

Following is a cloud-antagonistic discussion. I’m deliberately not presenting "both sides" because the cloud providers are perfectly capable of representing themselves and don’t need my help to trumpet their services. But like any company, they aren't too keen to point out their disadvantages. That's the reason for this article.

Disadvantages such as...

More Costly

Cloud Service Providers (CSPs) are all subscription-based. You'll pay monthly or yearly fees, generally per user or based on how much of the cloud service you make use of, depending on the service. These fees can be pretty high, sometimes far exceeding the cost of essentially similar functionality as a local implementation, assuming a local solution is even available. Increasingly they aren't.

Leaving a CSP

Another aspect of cost is entanglement. If you become dissatisfied with your cloud-service provider for whatever reason (cost escalation, feature/need misalignment, performance decline, up-time issues, CSP change of strategy, etc.) then leaving could be an arduous affair.

Just like gym memberships, where signing-up is a cinch, but leaving almost requires an act of congress, so too can a CSP make leaving painful. They do this by making it difficult to export your data (numerous ways they can do that) and charging steep exit fees.

Loss of data autonomy

Your company data will be stored in a data center somewhere, possibly in another country. It takes a lot of faith to entrust your data to some cloud provider. How good are their internal and external access controls and security? If in another country, what are that country's privacy laws?

Dependency on internet

By definition, cloud solutions require internet access to work. Granted, we all have internet pretty much all the time, so this isn't a biggie. But if your internet access is down for some reason, then whatever you do that's hosted on a cloud service will not work. If that need is critical, and it probably is, then you'd want a secondary internet provider as a fail-over. That costs money.

Performance penalty

Performance can suffer for several reasons, most of which are outside your control.

CSPs can be "over subscribed" (too many customers sharing too few resources), meaning that performance can suffer. This translates to slower web page loads, slower data-fetches on the service, and other ways that it's not snappy and responsive. The CSPs primary imperative is profits. Adding more resources to reduce over-subscription, or conversely, not accepting as many tenants, runs counter to that imperative.

They'll generally try not to over-subscribe their servers too badly. After all, they don't want a bunch of customers tying up their support lines complaining. But you can be sure they'll operate right at the edge, sometimes spilling over.

Another source of slowdown is that modern web interfaces are far more complex than older, lightweight interfaces. Modern web apps rely on heavy JavaScript frameworks and dynamic, client-side rendering, which increases load times. I'm sure you've noticed how some websites are more sluggish while others feel snappy.

Case in point: I have symmetric gigabit fiber with 1ms latency and a hardwired, high-end workstation -- by any measure, a performance-oriented set up. I'm an I.T. guy, after all. Yet, UPS and FedEx, two websites I use frequently, are slower than molasses in January. Page loads take several seconds each. Verizon Wireless, my former mobile provider, was even worse. That site was nearly unusable, it was that bad. That's because these web pages are laden with code and assets that took forever to serve and render. This is what many web UIs are like today.

By contrast, locally executed compiled code -- like that in a native, non-web-served product -- is much faster because it runs directly on local hardware without the overhead of browser rendering and internet latency, and is immune from the effects of an over-subscribed CSP.

Poor internet performance specs (from your ISP) can also hurt your cloud-based experience. In most markets, businesses pay considerably more for internet access than do residential customers. A traffic-heavy cloud service could require you to upgrade to faster internet which could be costly.

And getting more download speed isn't necessarily the answer, either. Cloud-services can make heavy use of upload. Most non-fiber ISPs limit upload speeds to a tiny fraction of the download speed -- as little as 5%. Getting high upload speeds could require a costly "dedicated" symmetric service with your ISP.

With on-premises systems (file server, CRM, database, whatever), your access speeds are far higher, running at bidirectional LAN speeds, which is usually 1 gigabit. Local latency is also lower, resulting in quicker I/O from your server.

Subcontracted players

Your CSP likely doesn't even own the infrastructure they are renting out to you. Except for the largest players, most CSPs of specific, niche products, like that HR system you might be using, are themselves renting space from the big guys, like Amazon Web Services, Microsoft Azure, and Oracle Cloud, to name a few. These big players are called Hyperscale Cloud Providers. They provide wholesale cloud services to smaller players who, in turn, bolt on their services and rent them out to you.

Additionally, different components of the full technology stack needed to make your CSP's product work are likely owned and operated by even more companies you've probably never heard of. Segmentation is a big thing in the cloud services ecosphere. Every segmented actor is another potential point of failure.

This isn't necessarily always a bad thing but it is cause for pause and ponder. It illustrates how incredibly complex the world of cloud computing can be. Each of these numerous companies have their own strategies and roadmaps for the future which can affect your cloud product going forward.

Mergers, acquisitions, buyouts, strategic change, etc. are a constant feature of this industry. No five year period will resemble the preceding five years. This industry roiling will certainly affect you at some point.

Data integrity

One (of many) mistakes uninformed users make is assuming they don't need to backup their cloud-based data. "Hey, my files are in a big data center. Certainly they perform backups."

Um, not necessarily. To be sure, big CSPs do some backing up. But those backups are for the providers redundancy in case the server or storage array containing your data fails. They can spin up another virtual server and reconnect to your data, sometimes without you even noticing.

But those backups don't usually protect against faults that originate outside of the data center. e.g. You accidentally deleted an entire folder, deleted a calendar, deleted a user's email account, or an encrypting virus invaded your instance on the cloud server. Are you protected against that? Good chance you aren't unless you subscribe to a separate backup system that, itself, will also be cloud-based.

Malware, breach, and exfiltration

Any business, or private individual for that matter, can be infected with malware. That basic truth is just a sad fact of computing life today. But the attack surface* varies greatly. CSPs have a different, and in some ways larger, attack surface compared to a similar local (non-cloud) implementation.

* The attack surface is all the various ways that a system is vulnerable to attack.

The primary enabling reason is exposure to the internet. By necessity, CSPs must expose certain access methods to the internet in order for their customers (companies and people like you) to access them. Depending on how the cloud provider was breached, the damage may spread laterally to some or all of that provider's tenant customers which could include you.

This is why many bad actors are now targeting CSPs. The potential payoff for a successful infiltration is far higher.

Furthermore, many attack campaigns against cloud infrastructure are automated. Bots (automated processes) are constantly banging away 24/7/365 at publicly-facing APIs, logins, or website vulnerabilities, looking for a toe hold.

Advantage local

This isn't to say that small companies that keep everything in-house (no cloud services) are perfectly safe -- I'm certainly not asserting that. But there is generally less focus on closed, in-house systems by bad actors because they are not as exposed to the internet thus reducing their attack surface. Attacking these systems may rely more on social engineering -- tricking an employee into giving up sensitive credentials or installing malware.

For a small company using local-only solutions, there is somewhat less risk because it's more work for bad actors for what is likely a lower payout. Not no risk. Just less risk.

Flying under the radar

One of the factors in helping to assess risk of breach is your company's visibility. If you're a small, private company, with a dozen or so employees, serving only your city, and not a large regional or national firm, then it's less likely that a bad actor would target you specifically.

The term for this sort of "protection" via lack of knowledge or awareness is security through obscurity. It's not intended by itself to inform proactive security measures. But it can be a useful input when developing a threat profile. If a bad actor half a world away doesn't know you exist, they aren't going to target you specifically. Opportunistic attack, however, is still possible and needs appropriate preventative measures.

If you're using a CSP, this is where your relative invisibility (security through obscurity) might not provide any protection. Whereas your company might be "too small" to be noticed and targeted for attack, your CSP almost certainly isn't. Your use of that CSP means inheriting their threat profile. Your CSP likely has many thousands of other tenants in addition to you.

In such an attack, it's like being caught with many others in a large building that got bombed, rather than a bomb meant specifically for you. Or if you prefer a less violent metaphor, it's like being caught up in a long line fishing net instead of on an anglers hook.

So now what?

Given the discussion above, what sort of things should stay local and off the cloud? One answer is things that aren't collaborative in nature outside your business especially if there's a local solution.

Things like...

Server or Workstation Backups

Data backups should be local. They are much faster, less prone to a data breach, and less costly. If you want a cloud solution as a secondary backup, a belt and suspenders approach, that's fine (depending on internet performance and quantity of data). But the primary backup system should always be local.

QuickBooks

QuickBooks Online (QBO) has its up-sides but, boy howdy, does it have its downsides as well. Most of my clients that are heavy QB users have found that QuickBooks desktop (QBD) is faster and more feature rich. And it doesn't rely on the internet. It's cheaper, too, since you can go several years between updates.

But, alas, this ship is leaving port, never to return. Intuit is pressing hard toward moving customers to their hosted solution, QBO. Supposedly Enterprise edition users can keep using desktop software -- for now, anyway.

Company Data

All the files your company uses such as Word, Excel, PDFs, etc. should be local. They are safer in your possession (assuming you follow other best practices like backing up) than on a cloud-server somewhere and are accessible even without internet access. Same thing applies to databases that may contain customer data.

"Local" doesn't mean you can't access data from afar. But these access methods aren't exposed to the internet in the same way which can make them less vulnerable.

Closing comments

Using CSPs might seem convenient because it relieves you from needing to maintain as much local infrastructure or needing an I.T. geek. There's some truth to that.

But that comes at a cost: First of all, it literally costs more. It reduces your control over your applications, data, and cost containment because it binds you more intimately to third parties (the makers of your applications) whose interests probably don't align with yours, in ways that local infrastructure does not.

Another way to think of it. Businesses got along pretty well before CSPs came along. If there wasn't money to be made the CSPs would not exist. That money has to come from somewhere.

None of this is to say that you should never use a cloud service. Just don't believe everything you read spouted by cloud service evangelists or salespeople.

As more complex cloud-hosted products are being offered at the "retail level" (directly to end-users) without benefit of professional, knowledgeable advice, the more mistakes are made by folks who don't understand the tech involved and the consequences of actions taken.

This is where having an I.T. pro that you can call is a good idea.