Hacker News Reader

First things first, web-based doesn't imply cloud-based. You can have a web-based service that's hosted on your servers and only services your intranet. This way you get most of the advantages of the web (no software to install and maintain, and easy access to the resources by your users), and still maintain control over your stack. There is very little reason to build desktop software anymore.

>For a document that the visitor cannot afford to lose, or for anything in which privacy, security or personal control are issues, a Web-based document is obviously a mistake

I don't see the obviousness of this. In fact, if it's a document that you cannot afford to lose, a cloud service makes much more sense than something stored locally (even with backup procedures). There are cloud services that handle sensitive data (such as patient records and images) today, successfully. Yes, there may be cases in which it makes sense to have data reside on your servers, as opposed to on some cloud-provider's, but those are edge cases now. We recently went through something like this at work, instead of hosting and maintaining our own Sharepoint servers, we went with a cloud-based CRM. It makes too much sense. Our source code, which is by far the most valuable piece of our business, is hosted on kiln. We do have backup strategies in cases kiln servers get hit by an asteroid, but we have no qualms about fogcreek maintaining our codebase.

>Why do you think the big players in cloud-based and Web-based storage and applications are having such a hard time getting people to adopt them?

That is absolutely false. In fact, the opposite is true. The trend has been to offload almost everything to the cloud. The big cloud-storage guys all had phenomenal growth.

>The data loss was apparently small relative to the total data stored, but anyone who runs a web site can immediately understand how terrifying a prospect any data loss is."

And how are you immune to this when YOU are responsible for managing your backup strategy and maintain your servers. Do you know how many horror stories there are of data loss that occurred because of things like bad RAID setup. Backup, replication, server maintenance is hard, expensive and time consuming, and most of the time it has no relevance to the underlying business. If you're in the business of making plastic widgets, you want to focus on making plastic widgets, and leave server maintenance to those whose entire business is server maintenance.

> First things first, web-based doesn't imply cloud-based.

True, but there are few applications that reside in a browser that don't use cloud-based storage for the results. One may safely refer to Web-based and cloud-based technologies in a single breath.

>> Why do you think the big players in cloud-based and Web-based storage and applications are having such a hard time getting people to adopt them?

> That is absolutely false.

No, it's true, and you need to do impartial research before making this sort of claim. The big players are having a hard time getting people to adopt cloud-based and Web-based technologies, and I already gave the reasons.

http://www.infoworld.com/d/cloud-computing/its-cloud-resista...

A quote: "Accenture and the LSE surveyed more than 1,035 business and IT executives and conducted more than 35 interviews with cloud providers, system integrators, and cloud service users. The key finding: There's a gap between business and IT. Businesspeople see the excitement and business benefits of cloud computing, so they're pushing for it. However, IT people see cloud computing as causing issues with security and lock-in, so they're pushing back."

> And how are you immune to this when YOU are responsible for managing your backup strategy and maintain your servers.

This is a non-argument fort an obvious reason -- if infrastructure data loss is an issue, Web-based data loss is a bigger issue, because in the latter case, users won't necessarily know where the data are located, and the number of possible failure modes is higher.

> Do you know how many horror stories there are of data loss that occurred because of things like bad RAID setup.

I can't believe you even posted this argument. How does an unreliable cloud RAID array constitute an improvement over an unreliable infrastructure RAID array?

I haven't even mentioned the legal issues, where law enforcement has a much easier time subpoenaing evidence from the cloud, compared to legally acquiring from your local network.

http://www.forbes.com/2010/04/12/cloud-computing-enterprise-...

A quote: "Enterprises are moving their assets to the cloud to capture its many business benefits, including ease of deployment and reducing, if not eliminating, the need for IT infrastructure. However, cloud computing offers an array of pitfalls for the unwary. The unique legal risks and considerations presented by the cloud are especially important and often overlooked by nonlawyers."

The article goes on to list five very serious and often overlooked legal pitfalls of cloud computing.

>One may safely refer to Web-based and cloud-based technologies in a single breath.

It may be one of those things that needs to be qualified. Pretty much every Fortune 1000 enterprise runs some kind of a web-based intranet, which may or may not be accessible outside the VPN, with various services, from email, to document management, to ... anything.

>if infrastructure data loss is an issue, Web-based data loss is a bigger issue

HOW?! First, there is nothing preventing you from having your own backups. Second, even if you completely trust the cloud provider (and who says you should?), I claim that it is still safer than managing your own data for most business, especially if your business cannot afford a top-notch IT support staff (or any staff). If you're GE, you can invest in server-farms, if you're Plastic Widget Inc. you're better off with a reputable cloud vendor.

> Businesspeople see the excitement and business benefits of cloud computing, so they're pushing for it. However, IT people see cloud computing as causing issues with security and lock-in, so they're pushing back.

God-bless SysAdmins, but they do have a tendency to be anti-anything that comes in on their turf. They are almost never the decision makers. Having said that, you do realize that cloud services went from nothing (a few years ago) to a huge multi-hundred-billion dollar industry in the span of a few years, and growing. Clearly, SOMEBODY sees values.

> The unique legal risks and considerations presented by the cloud are especially important and often overlooked by nonlawyers.

Yes, there are "unique legal risks and considerations". What's your point? There are risks to cloud services, but there are incredible benefits as well. One always weighs risk and reward accordingly. The rewards is why the industry is growing. Here's an example of a 'unique legal consideration', Canadian hospitals cannot use cloud providers hosted on Amazon or anywhere in the US to host patient data because of things like the Patriot Act, so what do they do? They can go with a regional cloud provider that makes a guarantee that their data will not leave the province. I've seen that happen.

>> if infrastructure data loss is an issue, Web-based data loss is a bigger issue

> HOW?!

Because there are more factors involved. A local storage device has some number of failure modes, and probability of failure: A. The cloud had additional failure modes and vulnerabilities: B. The outcome is A + B. The failure modes are additive.

>A local storage device has some number of failure modes, and probability of failure: A. The cloud had additional failure modes and vulnerabilities: B. The outcome is A + B.

That's funny =)

So would you inherently trust a native GTK+ app containing some client-server functionality over a JS/HTML/CSS app running locally on an offline Chromebook?

You (and the originator of this comment thread) seem to be conflating the client-server model with the platform an application is developed for. "Being a web app" and "relying upon some server" are two entirely disjoint things.

Sim City wasnt written in web technology and needed to be online, its possible to write applications using web technology that dont need to be online.

Those arguments have nothing to do with each other, 'the web' doesnt equal 'store everything in cloud based servers'

My point was that forcing SimCity's fans to adopt a cloud-based version of the game was a big mistake, and everyone involved accepts this now.

> Sim City wasnt written in web technology and needed to be online

The present version of SimCity requires players to log on. The game will not work without a Web connection. This has created a huge outcry from fans of the game.

> its possible to write applications using web technology that dont need to be online.

If we define "online" as "connected to a network", then yes, Web-based applications require one to be online. And most Web-based applications require an Internet connection.

> Those arguments have nothing to do with each other ...

Cloud-based storage and Web-based applications have nothing to do with each other? Most Web-based applications store their results in the cloud. If you adopt Web-based applications, you're also adopting cloud-based storage at least temporarily.

>My point was that forcing SimCity's fans to adopt a cloud-based version of the game was a big mistake, and everyone involved accepts this now.

The BIG problem with SimCity wasn't that it had online features (those are great), but that it did not let you play offline for any good reason, which annoyed the heck out of people. And how does that example prove anything? A mediocre game (single or multiplayer, online or offline) gets released every other week.

>Cloud-based storage and Web-based applications have nothing to do with each other?

They don't. You can have a web-based app, that is hosted locally, or you can have an installed app, that cannot function without a cloud-service (e.g. almost every mobile app).

>Most Web-based applications store their results in the cloud.

I mentioned this in another post, but almost every business, big or small runs some of kind of a intranet, where they control the entire stack. The reality is that we're moving away from that setup as well. So no, web-based and cloud-based aren't the same thing.

> The BIG problem with SimCity wasn't that it had online features (those are great), but that it did not let you play offline for any good reason, which annoyed the heck out of people. And how does that example prove anything?

It proves exactly what I intended -- that, contrary to an earlier point, Web-based technologies aren't being embraced enthusiastically, that there are circumstances in which they're not the right approach.

>> Cloud-based storage and Web-based applications have nothing to do with each other?

> They don't.

When you post a refutation, it's customary to offer some evidence for your position. You don't -- your reply wanders off to a different topic.

> So no, web-based and cloud-based aren't the same thing.

First, I never said that. Second, Web-based and cloud-based technologies are integral to each other. The majority of Web-based applications store their data in the cloud.

> It proves exactly what I intended -- that, contrary to an earlier point, Web-based technologies aren't being embraced enthusiastically, that there are circumstances in which they're not the right approach.

The outrage about SimCity was largely based on the fact that a single player game fundamentally should not need to connect to a server (SimCity has some interactions between neighboring cities, but they're not key to the game and critics think they should be optional), but a collaborative document editor is inherently "multiplayer" - though being web based might make it harder (but not impossible) to keep a stale copy of the document while offline, the vast majority of uses for such an editor expect everyone to be online and synchronizing changes.

There are circumstances where web-based is not the right approach, but this is probably not one of them.

>> So no, web-based and cloud-based aren't the same thing. >First, I never said that

> If you adopt Web-based applications, you're also adopting cloud-based storage at least temporarily.

Some web based applications use cloud storage, some dont, they arent completely independent of each other and utterly not 'integral'

it doesnt need to be proved past http://diveintohtml5.info/storage.html

> If we define "online" as "connected to a network", then yes, Web-based applications require one to be online. And most Web-based applications require an Internet connection.

Again you are confusing history with truth, web application do not require you do be online to work

http://diveintohtml5.info/offline.html

> ... web application do not require you do be online to work ...

What?, If "online" means connected to a network, then yes, Web-based applications require you to be online, and the majority of those require you to be connected to the internet, both to access the application and to store and retrieve data.

no they do not, I linked to a very basic overview of some of the technologies used to have web applications work offline (the storage one is also relevant). There is a relatively huge ecosystem that isnt touched upon in that article, offline web apps are very much a thing.

I have been using a mobile phone whose OS(UI/App layer) was written entirely in web technologies, it most certainly doesnt turn into a brick when I dont have a data connection.

It is fine to not know these things, but its not a very good idea to be publically dismissing technologies you obviously arent very familiar with, and when people point out that you are wrong you should probably do some research before defending it.

This seems like a very misaimed rant, for this particular piece of tech.

It's a collaborative text editor. What point is there to using it offline? All the disadvantages you state are already inherent in the concept of "collaborative text editor", whether or not it's web-based.

> It's a collaborative text editor. What point is there to using it offline?

You're using your premise as your argument.

> All the disadvantages you state are already inherent in the concept of "collaborative text editor", whether or not it's web-based.

Not at all. A locally hosted application can collaborate by sharing only its data, not the application itself, with all data stored locally after the work session ends. I'm only making the point that your premise is mistaken, not that a collaborative editor isn't an obvious application for Web technologies, all legitimate objections aside.

The good news is that a collaborative editor might itself be Web-based, and its documents might reside in the cloud for obvious practical reasons. That's also the bad news, due to problems already listed.

I'm not sure if you've been keeping up with what "web-based" means, but given HTML5 cache manifests and storage APIs (localStorage, IndexedDB, etc.), web applications are perfectly capable of "sharing only its data, not the application itself, with all data stored locally after the work session ends."

You can basically think of a web application, these days, as a native app that just happens to "update" to the newest server-provided version whenever you start it up, if you're online at the time.

Data loss is a risk you have to manage no matter where your data live, whether on your desktop, in your own data center, or in the cloud.

> Data loss is a risk you have to manage no matter where your data live, whether on your desktop, in your own data center, or in the cloud.

That cannot be used to argue that cloud-based storage is just like local storage. It isn't -- cloud-based storage has some serious legal and practical problems that local storage doesn't have.

You're overstating the legal and regulatory risks. I work in health-care, which is probably one of the most regulated industries there is, and regulatory issues are not really a barrier to cloud services.

> You're overstating the legal and regulatory risks.

Okay, fair enough -- I will let this IT lawyer "overstate" them for me:

http://www.forbes.com/2010/04/12/cloud-computing-enterprise-...

> I work in health-care, which is probably one of the most regulated industries there is, and regulatory issues are not really a barrier to cloud services.

I recommend that you suspend judgment until someone wants to subpoena a case file, or internal memos and documents, for a high-profile malpractice lawsuit. It's much easier from the cloud than from an intranet or a file cabinet.

Most online medical records are encrypted for obvious reasons. But if a lawful subpoena comes down, the owner of the files is required to unencrypt and provide the requested materials, the existence of which is obvious from their online presence, even when encrypted. For local storage, a medical institution can say the files don't exist or are inaccessible. This option doesn't exist for online records.

The good news is that cloud storage speeds everything up and provides a measure of the degree to which patient data exists. That's also the bad news.

> For local storage, a medical institution can say the files don't exist or are inaccessible. This option doesn't exist for online records.

I'm not sure if that's a good example of why local is better than online, since by stating to the courts that something doesn't exist (when in actuality it does)is lying to the courts...I'm no lawyer, but I'd imagine that doing so is punishable. I think the benefits of online medical files far outweigh the offline component for many reasons.

>But if a lawful subpoena comes down, the owner of the files is required to unencrypt and provide the requested materials, the existence of which is obvious from their online presence, even when encrypted. For local storage, a medical institution can say the files don't exist or are inaccessible. This option doesn't exist for online records.

Ok, now I know you're trolling.