Upthere, a cloud storage service, wants to make file syncing a thing of the past
theverge.com
theverge.com
I'm also interested to see if they have a way for you to run your own Upthere server instead of using their service. I'm not eager to have to trust yet another third party with my private data, and if I can't host it myself somehow I'll probably avoid using the service.
You can "skip" the cache consistency problems by "just" always treating "the cloud" (which is internally probably a distributed cache) as the authority, but now you have an unreliable distributed system from a user's point of view since the thing you are skipping is how to handle real-world network weather. You can't eliminate problems by pretending they don't exist.
You also can't skip this problem with "the cloud." I am SO damn sick of "the cloud" being talked about as magic beans. If you're building a global distributed drive, then you are doing a distributed cache -- SYNCING -- in the cloud between cloud nodes. If you can do it there, why not do it on the end-user device too and let me cache my data? If you are using someone else's boxed cloud service to do this, then you are letting them build a distributed system and operate it for you in the cloud and if you ever have problems with it you better hope they have good support/SLA... and you're also doing something trivially duplicated. If that's what you're doing why don't I just use s3fs?
I sincerely hope there's more to it than this. I can trivially do this now with sshfs or Expandrive if I want a pretty GUI, and it's only tolerable with cloud storage that's physically very close to me (about <500mi).
Now we've reduced the problem to consistency on the metadata structure which aggregates objects for the user. There are "well known" ways to do this for traditional trees. Other well known options include doing an all search based approach (i.e. always talk to a server for metadata, perhaps with local result caching), and so on.
If they're doing (a) then it's just another Dropbox but with less tolerance for disconnected operation. If they're doing (b) they're just reselling and maybe with a nice client. That's not doomed as a business of course but it's not all that technically interesting.
If there's a (c) it's not in this article.
Their public comments are that they are running their own servers and not reselling other storage.
Personal opinion: no one can do (c) because of (a). That is, any possible (c) must tackle the fundamental hardness in the distributed systems problem, and this is what we agree (a) is doing. Using immutable objects as in S3 just shifts the problem elsewhere, while it reduces it, it doesn't solve it.
So let me guess:
They're doing a distributed metadata store where the cloud is the tie-breaker combined with flexible caching of immutable content-addressable (identified with SHA512 or similar) objects.
In that case it sounds like cloud-hosted-only ipfs plus a nice client to access it from a host.
Cold? Warm? :)
Personally, what I'd like to see is mainstream software bundled with https://ipfs.io/ technology. If content could be served via a DHT plus all the extra things IPFS offers, we'll be a lot closer to a world where content doesn't get lost. At that point I'd gladly pay a company to store my personal files (by simply giving them a list of hashes which resolve to my computer so they can download them), and trust that it's safe because they were encrypted on my end and the company is just ensuring that the content can be redownloaded should my computer explode.
On a sidenote, IPFS would also solve a lot of problems with public data, where everything can be reliably synced (and even updated with IPNS) for people with no persistent access to the Internet (and people on space stations or the Moon or Mars, should we ever put bases on them).
And then pictures, video, music, etc come along and wreck everything.
Maybe there are better machines to rage against than a hippie OS.
Also, I wonder if they've done the math on how much data you can actually cram into the airwaves. You can't instamagically move more data through a finite spectrum at rush hour on a Wednesday.
We badly need standardized home servers that can run 24/7 and managing storage and processing tasks for our mobile device. It would solve sooo much of the problems derived from unreliability of mobile devices.
Something that the regular users have an incentive to buy, because the primary advertised features are something they need or really want, and that then also offers a wide variety of additional services, such as mail, VoIP, coalescing proxy for your mobile devices to save their battery, storage, etc...
Copying files into your personal cloud while offline should still work. Deleting/renaming/moving files from the cached directory tree should still work offline. Opening cached files should still work offline.
They better be low power - I pay ~34c/kWH for at my house. I recently looked into building a NAS for storage + OwnCloud and I can buy an awful lot of BackBlaze + AWS for the same price.
If, but it is a big if, I have understand correctly it is a simple cloud service but it doesn't save your file in your hard drive, but directly and only on the cloud...
"Upthere says it plans to offer an API in hopes that developers will make it the default storage solution for their own apps"
So... how is that in any way different to using the AWS API to upload stuff to S3? Being a "storage solution provider" (and reselling other companies' cloud offerings at that) has some razor thin margins and a whole lot of competition. I don't understand what makes these guys different.
Nice logo though.
The ground-up approach includes the entire stack.
Hardware to software. The company has designed
its own servers down to the bend of the metal
and the motherboards used.
The founder spent 22 years working for St. Steven, and yet he didn't learn one of the most important lessons:
“People think focus means saying yes to the thing you've got to focus on. But that's not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I'm actually as proud of the things we haven't done as the things I have done. Innovation is saying no to 1,000 things.”
It's hard not to think of this: http://mashable.com/2012/10/17/color-shuts-down/#
High-concept stuff doesn't seem to fair well, the small and growing always seems to do a lot better. That said good luck to them.
I'm on what is effectively 8/1 and I'm starting to struggle with the size of Windows Updates (8->8.1 failed multiple times resulting in a repeated 2GB download), XBox One games (20-40GB), streaming and RDP/Citrix/VPN for working from home.
> I'm not even begging for the common engineering sense anymore
OneDrive! It doesn't even implement any kind of LAN Sync - you'd think MS would have bolted on some of the newer SMB stuff like HomeGroup (which is discovery+SMB over IPv6 AFAICT)
>For practical reasons and the love of God, stop with the requirement of being constantly on-line to use a goddamn app.
Ubisoft managed to lock the whole of Australia out of one if its recent betas with this mentality.
Cloud storage will still be important in this new single-device computing model, but only as a means for archival and backup. Sync won't come into play anymore because you only have the cloud and a single device to manage, and changes will tend to only propagate in a single direction from the device to the cloud.
Yet you were the "senior vice president of software engineering for Apple." You were in a better position than almost anyone else to "do what you envisioned." What stopped you? If you could not do it at Apple, why will you be able to do it at a startup?
The ability to start a startup is a new bargaining chip for high value corporate employees. Why build an innovative feature at your company -- and give them all the money -- when you could just leave and do it yourself, and keep all the money?
There is a moral hazard for corporate employees that poses a large risk to corporate innovation. If an employee at a company stumbles upon an innovative opportunity, it can be economically sensible to for the employee to avoid implementing it, in preparation for a future startup that will attract easy VC money.
The best solution to this is probably just for big companies to grant more and more stock to employees to keep incentives aligned.
So no, not a huge risk, and higher percentage chance of success than anyone else starting the same company.
So I don't think you can generalize on that point. And as far as this goes:
> That guarantees at least enough investment to hire a team the size of what you had at Apple.
There's also no way this is a guarantee. Sure, it'll be easier to get money than an 18 year-old walking in off the street will, but again, you can't compare the steady job, steady paycheck, "let's build a feature internally" with "let's go start a startup".
I will definitely agree that having the experience of a vp of engineering is better than not having it, but that's a far cry from saying that quitting your highly paid job as a VP of engineering for the biggest company in the world to start one of many cloud storage companies is "not a huge risk".