Oh, only nine months having an entire customer base entirely forgotten. This does not good support make.
DO has a history of doing this; see Allow Custom Images [0], with over a year of no comment, and Give option to use the Droplet's own bootloader [1], with 14 months of no comments; not even a "we're working on this". The latter shows DO's utter lack of technical competence; if they cannot even properly prepare a system image [2] or actually use their virtualization platform, what the hell can they do? Apparently, only marketing.
That's a great point and we totally missed our roadmap in 2013, by about 9-12 months. This is something that Zach Holman at Github addresses in why Github doesn't really communicate about their roadmap:
In our case it was because we were basing all of our roadmap on how we operated in 2012 when we were a much smaller company, think 5 people, servicing a much smaller customer base, say 500 customers.
It was early 2013 that our growth really started and we tried to remain optimistic about our ability to launch features. This turned out to be completely unrealistic. We had to scale our customer support department which at that time was basically myself and Etel who is our community director from 0 full-time people to 17 today. Our engineering team was all cofounders which we have since scaled to 10, and we had no SRE team which we've since also built out and recently hired Mark Imbriaco from Github as our VP of Ops.
Our tremendous growth was very exciting but it stressed every single area of the business. We had to raise two rounds in 2013. Though we closed our Series A in 2014 we actually began that process in early November of 2013.
As the customer base grew and began we also started to encounter more scale issues which began to shift our engineering focus away from feature and product development to bug fixes, refactoring, and re-engineering.
We would have wished that we could move faster and pay down technical debt so that we could move into developing features sooner but given our tremendous growth last year of scaling from 500-1,000 customers at the start of the year to close to 100,000 by the end of the year it simply wasn't possible.
Along the way we completely broke a few promises about when we would release new updates and features. Now we are finally at the point that we feel confident that we are able to develop and roll out new features and we have begun doing so.
We've certainly learned some valuable lessons along the way such as being very careful about the public promises that we make. It's hard to say at the moment, but I don't think that we will follow Github's model of being secretive with our roadmap, but we will certainly be more cautious with our estimates given how we have seen so many different factors play into our ability to release features.
I think any startup that has scaled has gone through similar problems and so it's a story which I'm sure has been repeated many times in history. We could have done a better job of staying ahead of these changes and more pro-actively communicating that we would be falling behind our product roadmap as a result and that's a personal failure on my end as I lead product in the organization.
Much like a startup evolves, matures, and changes overtime, I too have had to go through a similar process of learning and re-learning my role both as a cofounder and also as a product lead.
It's been very dynamic and interesting and certainly has been a tremendous growing experience and I've finally been catching up with the rest of my work now that we've settled so many different problem areas in just scaling a company and a business.
One of the first things was to get back on top of UserVoice and begin to provide more updates and visibility into the things that we've been working on and what's coming up. For other items we are still in the process of hashing out the details and providing better estimates so in those cases we are holding off before we make another public statement so that we can ensure we set the correct expectations.
Believe me that there is nothing more troubling to us as a company than letting down our customers, it is never our intention, and it is never out of ill-will, often times it happens out of being too optimistic. Like any trait there is a negative and positive aspect to it. As a cofounder you need that boundless optimism because there will be hard times. We had hard times when we spent 18 months with zero to little traction, and I'm sure we'll need that optimism in the future as well when we hit hard times or when the landscape shifts. During these periods it is essential. However, like anything else in life there is a balance. And, as essential as this optimism is to a startup it can also lead to issues such as these. In cases like that its a matter of being open and honest and saying yes we messed up, here is why, and here is how we are thinking about this problem in the future.
Hopefully that sheds some clarity on this area, especially since I was the one who was personally responsible for this in our company.
Apparently they've had a "Custom Image" beta in the admin UI for over two years [0]. There's also a CoreOS image request [1] that's been sitting around for almost a year. They just entered beta, and there's not really a good way to use them on DO without abusing Fedora, apparently.
This sort of thing is a big problem with IPv6 adoption. There's a lot of churn in internet software, server software, and hosting providers, and often many of the new guys delay IPv6 support in favor of other features. That makes it very possible for IPv6 adoption to stall or even reverse depending on the success of different hosting providers and software. Imagine a worst case scenario of a next generation web server which becomes hugely popular but which doesn't support IPv6. Fortunately that's an unlikely scenario, but unfortunately it can't be entirely ruled out. IPv6 is still a "nice to have" feature, and has been since it's introduction, that's always been it's major weakness.
I run an Arch droplet and this is the first I've heard of this. Certainly makes me want to take my business elsewhere. Suddenly they don't have any bleeding edge distros.
Linode just seems to care more about their customers.
Grandfathered users are our early adopter customers.
When we do large rollouts we usually release new features to them first in a limited public beta test so we can collect feedback. They have been extremely helpful in helping us to find and resolve bugs before we move a feature to general release.
I saw that and wondered what it meant... hopefully they aren't going to try and charge customers for IPv6 addresses. Most hosts give those out for free.
Any details on exactly what you get with Digital Ocean IPv6? The page doesn't really go into much detail - and the implementation can make or break things.
Is this a single static IPv6 address with a /64 (or /56 or /48) subnet routed to it? Or is it something else?
We are rolling out IPv6 initially with a single IP address to see how the network side of things handles that since we have already a large deployment of IPv4 and then evaluate from there.
Received this email earlier, though I don't have any droplets running in their Singapore center. Wish I could test this out, but I usually keep my servers in the US.
Can somebody who has a "grandfathered" account shed light on what makes an account "grandfathered" in this sense, and also what size allocations they're giving out?
(I'm aware what grandfathering is in a general sense, but unless they mean "we're releasing IPv6 as a beta to all users who were users before we made this announcement", it doesn't seem to fit here. And that would be strange)
Answered below, grandfathered users are our early adopters and we release features to them in a limited public beta test first to collect feedback before a general release.
There is no correlation to size allocation, it's just that they are first to be able to assign IPv6 to droplets in the Singapore region.
Singapore is running on a new backend code base which supports this we are working on a migration pathway for the rest of the cloud so it is in the works. But as I mentioned in another area of this thread regarding product roadmap announcements we are working on being more realistic with our timelines so that we do not upset our customers. Just wanted to share that we are working on this issue and making progress, really depends on the migration and how that goes to see when we can get this rolled out.
General IPv6 question...is this a case where there is a benefit in being on of the early adopters? i.e. are there specific "good" addresses. Kinda like money.com is better than asoef.com.
It seems to me bit crazy that a hosting provider launched in 2011 did not have full IPv6 support on day 0, especially when the provider in question was not some shoe-string garage operation.
Not really, the issue of deployment hasn't been lack of hardware support but lack of knowledge on the part of architects and engineers. A greenfield site has enough issues getting up and running without doubling the IP stack as well.
What's really surprising is the lack of mature service provider's who are not performing incremental roll outs.
I'm in Colorado, and I am getting a solid 10 Mbps down, 1.5 Mbps up (the up is actually what I pay for from Comcast, so it may be faster still). Not bad.
I am actually interested in IPv6 - will you release 1 IP per Droplet? Do they cost similar to IPv4 for hosting company, they are cheaper or are they free?
I'd also like to know that, especially as there are lots and lots of hosters out there who don't grasp IPv6 and are already breaking it before it has really taken off by creating pointless bureaucratic overhead and thus incentive to create bad network setups that will hurt us all.
As for the cost for the hosting company: No, one major reason for IPv6 is that it has a huge address space with 128 instead of v4's 32 bit addresses, so they are a lot cheaper - as it should be, there is no point in artifically making addresses scarce. RIPE members, for example, are billed for an IPv6 /32 (about 4 billion /64 subnets) like for an IPv4 /21 (2048 addresses).
In short: You should generally avoid any hosting company that allocates anything smaller than a /56, they probably haven't understood the internet.
[+] [-] Hello71|12 years ago|reply
https://digitalocean.uservoice.com/forums/136585-digitalocea...
Oh, only nine months having an entire customer base entirely forgotten. This does not good support make.
DO has a history of doing this; see Allow Custom Images [0], with over a year of no comment, and Give option to use the Droplet's own bootloader [1], with 14 months of no comments; not even a "we're working on this". The latter shows DO's utter lack of technical competence; if they cannot even properly prepare a system image [2] or actually use their virtualization platform, what the hell can they do? Apparently, only marketing.
[0] https://digitalocean.uservoice.com/forums/136585-digitalocea...
[1] https://digitalocean.uservoice.com/forums/136585-digitalocea...
[2] https://missingm.co/2013/07/identical-droplets-in-the-digita...
[+] [-] raiyu|12 years ago|reply
https://github.com/holman/feedback/issues/534
In our case it was because we were basing all of our roadmap on how we operated in 2012 when we were a much smaller company, think 5 people, servicing a much smaller customer base, say 500 customers.
It was early 2013 that our growth really started and we tried to remain optimistic about our ability to launch features. This turned out to be completely unrealistic. We had to scale our customer support department which at that time was basically myself and Etel who is our community director from 0 full-time people to 17 today. Our engineering team was all cofounders which we have since scaled to 10, and we had no SRE team which we've since also built out and recently hired Mark Imbriaco from Github as our VP of Ops.
Our tremendous growth was very exciting but it stressed every single area of the business. We had to raise two rounds in 2013. Though we closed our Series A in 2014 we actually began that process in early November of 2013.
As the customer base grew and began we also started to encounter more scale issues which began to shift our engineering focus away from feature and product development to bug fixes, refactoring, and re-engineering.
We would have wished that we could move faster and pay down technical debt so that we could move into developing features sooner but given our tremendous growth last year of scaling from 500-1,000 customers at the start of the year to close to 100,000 by the end of the year it simply wasn't possible.
Along the way we completely broke a few promises about when we would release new updates and features. Now we are finally at the point that we feel confident that we are able to develop and roll out new features and we have begun doing so.
We've certainly learned some valuable lessons along the way such as being very careful about the public promises that we make. It's hard to say at the moment, but I don't think that we will follow Github's model of being secretive with our roadmap, but we will certainly be more cautious with our estimates given how we have seen so many different factors play into our ability to release features.
I think any startup that has scaled has gone through similar problems and so it's a story which I'm sure has been repeated many times in history. We could have done a better job of staying ahead of these changes and more pro-actively communicating that we would be falling behind our product roadmap as a result and that's a personal failure on my end as I lead product in the organization.
Much like a startup evolves, matures, and changes overtime, I too have had to go through a similar process of learning and re-learning my role both as a cofounder and also as a product lead.
It's been very dynamic and interesting and certainly has been a tremendous growing experience and I've finally been catching up with the rest of my work now that we've settled so many different problem areas in just scaling a company and a business.
One of the first things was to get back on top of UserVoice and begin to provide more updates and visibility into the things that we've been working on and what's coming up. For other items we are still in the process of hashing out the details and providing better estimates so in those cases we are holding off before we make another public statement so that we can ensure we set the correct expectations.
Believe me that there is nothing more troubling to us as a company than letting down our customers, it is never our intention, and it is never out of ill-will, often times it happens out of being too optimistic. Like any trait there is a negative and positive aspect to it. As a cofounder you need that boundless optimism because there will be hard times. We had hard times when we spent 18 months with zero to little traction, and I'm sure we'll need that optimism in the future as well when we hit hard times or when the landscape shifts. During these periods it is essential. However, like anything else in life there is a balance. And, as essential as this optimism is to a startup it can also lead to issues such as these. In cases like that its a matter of being open and honest and saying yes we messed up, here is why, and here is how we are thinking about this problem in the future.
Hopefully that sheds some clarity on this area, especially since I was the one who was personally responsible for this in our company.
Thanks, Moisey Cofounder DigitalOcean
[+] [-] davidcelis|12 years ago|reply
[0] http://digitalocean.uservoice.com/forums/136585-digitalocean... [1] https://twitter.com/digitalocean/status/176338623053045760
[+] [-] nwh|12 years ago|reply
[+] [-] InclinedPlane|12 years ago|reply
[+] [-] Sir_Cmpwn|12 years ago|reply
[+] [-] agildehaus|12 years ago|reply
Linode just seems to care more about their customers.
[+] [-] dfc|12 years ago|reply
[+] [-] raiyu|12 years ago|reply
When we do large rollouts we usually release new features to them first in a limited public beta test so we can collect feedback. They have been extremely helpful in helping us to find and resolve bugs before we move a feature to general release.
Thanks, Moisey Cofounder DigitalOcean
[+] [-] 2bluesc|12 years ago|reply
[+] [-] SudoAlex|12 years ago|reply
Is this a single static IPv6 address with a /64 (or /56 or /48) subnet routed to it? Or is it something else?
[+] [-] raiyu|12 years ago|reply
Thanks, Moisey Cofounder DigitalOcean
[+] [-] davidcelis|12 years ago|reply
[+] [-] akerl_|12 years ago|reply
(I'm aware what grandfathering is in a general sense, but unless they mean "we're releasing IPv6 as a beta to all users who were users before we made this announcement", it doesn't seem to fit here. And that would be strange)
[+] [-] raiyu|12 years ago|reply
There is no correlation to size allocation, it's just that they are first to be able to assign IPv6 to droplets in the Singapore region.
Thanks, Moisey Cofounder DigitalOcean
[+] [-] ptnapoleon|12 years ago|reply
[+] [-] asb|12 years ago|reply
[+] [-] raiyu|12 years ago|reply
Thanks, Moisey Cofounder DigitalOcean
[+] [-] atmosx|12 years ago|reply
[+] [-] dvanduzer|12 years ago|reply
[+] [-] Havoc|12 years ago|reply
[+] [-] justincormack|12 years ago|reply
[+] [-] Hello71|12 years ago|reply
[+] [-] zokier|12 years ago|reply
[+] [-] nextweek2|12 years ago|reply
What's really surprising is the lack of mature service provider's who are not performing incremental roll outs.
[+] [-] 2bluesc|12 years ago|reply
Of course you need to be on IPv6 to reach that page :)
[+] [-] X-Istence|12 years ago|reply
[+] [-] lucb1e|12 years ago|reply
Edit: Nevermind, their v4 goes at 100KB/s.
[+] [-] justincormack|12 years ago|reply
[+] [-] funkyy|12 years ago|reply
[+] [-] zAy0LfpBZLC8mAC|12 years ago|reply
As for the cost for the hosting company: No, one major reason for IPv6 is that it has a huge address space with 128 instead of v4's 32 bit addresses, so they are a lot cheaper - as it should be, there is no point in artifically making addresses scarce. RIPE members, for example, are billed for an IPv6 /32 (about 4 billion /64 subnets) like for an IPv4 /21 (2048 addresses).
In short: You should generally avoid any hosting company that allocates anything smaller than a /56, they probably haven't understood the internet.
[+] [-] booruguru|12 years ago|reply
[+] [-] booruguru|12 years ago|reply
[+] [-] cma|12 years ago|reply