Speaking as Linode user with all my eggs in their basket: I'm sad that they are falling so much behind other players like DigitalOcean. I'm looking more and more to DO these days just because of the speed they are able to deliver new features.
That being said this is a great addition! Looking forward to trying it out when it reaches my datacenter. And I'm also looking forward to see what their next big project will be.
I don't know, I'm currently using Linode and am trying to keep my stuff as platform-agnostic as possible (just give me dumb Linux boxen).
Most of the great new features proliferating on other providers seemed designed to encourage vendor lock-in. On my current project, I made one concession to my usual aversion to proprietary lock-in and went with AWS S3 for storage of user uploads (also looked at Azure's offering but my BizSpark application was denied, so meh), since there really is no equivalent. I'd thought about using Linode's beta block-storage (which would have probably been more performant), but I was afraid I would be forever fighting with managing volumes and nfs mounts (or massively overbuying capacity).
Why does block storage seem to take so long for companies to implement? DigitalOcean only implemented it in the past year, when they had hundreds of employees. It seems like it would be a priority feature, so I imagine a sizable team was working on it. Why did it take so long for digitalocean, and now Linode, to implement block storage? Are there some inherently architecture-dependenent complexities that render it a deceivingly difficult project to implement?
I'm in a similar basket with my non-work projects and to be honest, most of what Linode is missing is available if you use multiple providers.
For instance, I use OVH object storage in conjunction with an image hosting site on Linode. The latency from OVH Canada to Newark is small enough its pretty seamless and if OVH Canada goes down, I can use an EU location with higher latency. Linode fails over to their London location (assuming there is enough availability with VMs, the spin up may be automated but I run 0 webservers there 99.9% of the time).
Personally, I wouldn't pick DO because they tend to have poorly disclosed problems with their "new features" that you really only get an answer to if you contact support or dig through their documentation. For instance, DO's object store doesn't handle index files at all but everyone else's does. So if you try to switch, you almost immediately end up with "eh...srsly?" moment.
Linode and other hosts at least deploy the standard feature set when they expect money from you.
I create DigitalOcean droplets on-demand via their API and roughly 10% of the requests just fail with a generic error message, and then get into an error state with "failure to create droplet."
It's... pretty frustrating, so I'm looking for a new provider with a simple API.
I had the worst customer support experience with Digital Ocean in my whole life. Having been a Dreamhost customer for over a decade I thought DO would treat me well. I got really pissed off by how bad they handled things so I tried Linode instead. Man, how happy I am now. I don't care if DO is doing better, I care that Linode treats me with respect as a paying customer.
I wonder how difficult it would be to build an S3 like interface on top of this so you can get a coarse pay-for-what-you-use, avoid downtime, but also have a much larger capacity than the max of 10TB for one drive.
You might be able to build this on top of minio. Start with, say, 4 1GB linodes (smallest), with 8 volumes each (the max) of the smallest volume size of 10GB, and a somewhat low 1:3 parity in minio (redundancy is mostly handled by linode replication). That would be 320GB * $0.10 + 4 * $5 = $52/mo to start with. After some utilization threshold, incrementally resize all drives to grow dynamically, the parity drives would fill in while a drive is offline & resizing. The parity is also enough to resize the linodes one at a time too if you need to up their compute capacity. This system could grow up to 320 TB raw / 240TB accessible.
The last I poked around at this idea when linode block storage was introduced, this "should" work with minio, but I got the impression they didn't really consider this kind of use case.
I wish these block storage services gave you some idea of failure rate/durability and availability. Amazon publishes some rough volume loss rates but not even Google tells you what kind of durability to expect out of a persistent volume. They all say they are tri-replicated, which semi-implies highly durable storage. What about availability?
Lastly, I'd love to know if DO/Linode have custom rolled their solution or are using Ceph or something similar. Not that I don't trust them, but they aren't recruiting the same engineers as Google.
Based on their open jobs listings, DigitalOcean is using Ceph. I really hope (for everyone's sake) that Linode didn't roll their own solution.
As someone who runs ~100 Ceph clusters at multi-petabyte scale, publishing availability and durability SLAs is not an easy task, however not impossible either.
Since they just started offering it, Linode probably doesn't have accurate statistics to share, and most people can't correctly interpret very small probabilities anyway. They'd probably be better off saying something like "you should assume that each volume will fail at some point in its life".
[+] [-] erikrothoff|8 years ago|reply
That being said this is a great addition! Looking forward to trying it out when it reaches my datacenter. And I'm also looking forward to see what their next big project will be.
[+] [-] jcadam|8 years ago|reply
Most of the great new features proliferating on other providers seemed designed to encourage vendor lock-in. On my current project, I made one concession to my usual aversion to proprietary lock-in and went with AWS S3 for storage of user uploads (also looked at Azure's offering but my BizSpark application was denied, so meh), since there really is no equivalent. I'd thought about using Linode's beta block-storage (which would have probably been more performant), but I was afraid I would be forever fighting with managing volumes and nfs mounts (or massively overbuying capacity).
[+] [-] chatmasta|8 years ago|reply
[+] [-] AFNobody|8 years ago|reply
For instance, I use OVH object storage in conjunction with an image hosting site on Linode. The latency from OVH Canada to Newark is small enough its pretty seamless and if OVH Canada goes down, I can use an EU location with higher latency. Linode fails over to their London location (assuming there is enough availability with VMs, the spin up may be automated but I run 0 webservers there 99.9% of the time).
Personally, I wouldn't pick DO because they tend to have poorly disclosed problems with their "new features" that you really only get an answer to if you contact support or dig through their documentation. For instance, DO's object store doesn't handle index files at all but everyone else's does. So if you try to switch, you almost immediately end up with "eh...srsly?" moment.
Linode and other hosts at least deploy the standard feature set when they expect money from you.
[+] [-] funwithjustin|8 years ago|reply
It's... pretty frustrating, so I'm looking for a new provider with a simple API.
[+] [-] caiobegotti|8 years ago|reply
[+] [-] infogulch|8 years ago|reply
You might be able to build this on top of minio. Start with, say, 4 1GB linodes (smallest), with 8 volumes each (the max) of the smallest volume size of 10GB, and a somewhat low 1:3 parity in minio (redundancy is mostly handled by linode replication). That would be 320GB * $0.10 + 4 * $5 = $52/mo to start with. After some utilization threshold, incrementally resize all drives to grow dynamically, the parity drives would fill in while a drive is offline & resizing. The parity is also enough to resize the linodes one at a time too if you need to up their compute capacity. This system could grow up to 320 TB raw / 240TB accessible.
The last I poked around at this idea when linode block storage was introduced, this "should" work with minio, but I got the impression they didn't really consider this kind of use case.
[+] [-] jerf|8 years ago|reply
[+] [-] hemancuso|8 years ago|reply
Lastly, I'd love to know if DO/Linode have custom rolled their solution or are using Ceph or something similar. Not that I don't trust them, but they aren't recruiting the same engineers as Google.
[+] [-] antongribok|8 years ago|reply
As someone who runs ~100 Ceph clusters at multi-petabyte scale, publishing availability and durability SLAs is not an easy task, however not impossible either.
[+] [-] tkulick|8 years ago|reply
[+] [-] wmf|8 years ago|reply
[+] [-] AFNobody|8 years ago|reply
[+] [-] antongribok|8 years ago|reply
[+] [-] tkulick|8 years ago|reply