Scaleway C2 and ARM64 instances will reach end-of-life in December 2020
scaleway.com
scaleway.com
The ARM64 offering is based on ThunderX servers from Gigabyte / Cavium. These servers were plagued by kernel panics from the first kernels provided by Cavium and firmware bugs that had never been fully resolved before the servers went into production. They were also plagued by consumer-grade 1TB SSDs that were constantly crapping the bed and losing customer data (unlike the other 1.92TB enterprise SSDs installed, which were robust).
Offer C1 is also based on custom hardware [2] and faces the same situation as offer C2. If you are an existing C1 customer, I would take a backup and consider alternatives.
I don't find it very surprising that they announced the withdrawal of these offers, you can check their GitHub repositories to see years of neglect to these products: operating system images rarely updated [3], and major usability issues have never been solved [4].
(Throwaway account to protect sources)
[1] https://blog.scaleway.com/2016/c2-insanely-affordable-x64-se...
[2] https://blog.scaleway.com/2015/from-online-labs-to-scaleway/
> Dear customer, > As of December 1 st, 2020, our C2 and ARM64 Instances will reach their end-of-life. The physical servers hosting them are indeed randomly affected by several stability issues, which prevent us from fully guaranteeing the overall quality of service. Rest assured, however, that we are committed to guiding you in your migration and provide you with the best matching resources for improved stability, performance and reliability.
> Starting from April 14th, 2020, it is no longer possible to create new C2 and ARM64 Instances. In addition, their support will end on July 1st, 2020. As a result, our technical assistance will no longer address issues related to those instances. A price increase is also to be expected on July 1st, 2020. Lastly, C2 and ARM64 Instances will be completely deprovisioned as of December 1st, 2020. > > As a reminder, C2 and ARM64 instances include: C2S, C2M, C2L ARM64-2G, ARM64-4G, ARM64-8G, ARM64-16G, ARM64-32G, ARM64-64G, ARM64-128G
> You will find below our recommandations to migrate to both our Virtual Instances or our Bare Metal cloud servers.
> [...]
They don't explain it further; but I used several ARM64 instances and they mostly worked. The main issue I had is that they sometimes took hours to stop, which meant they were stuck in a state where you couldn't access the data or free any resource related to the instance.
That was a killer idea. Get dedicated hardware, with all the security and performance consistency it implies, for even cheaper than a VM instance.
And when it was introduced, it was really a game changer. And it worked really well.
Unfortunately, Docker images were and still are mostly for x86_64, and that didn't make adoption easy in spite of their efforts to help improve the situation.
The hardware eventually didn't prove to be as reliable as expected, so moving to more traditional hardware was a safe route to go.
Sad, but the instance types they have remain very compelling. The DEV1-S instance is only $2.99, with unmetered bandwidth.
I just moved two ARM64 instances to a DEV1-S. Same price, and even though that instance type has only 2 virtual cores instead of 4, it is actually much snappier ARM64 instances. Plus, I can scale up if necessary, while that wasn't really an option with ARM64 CPUs.
https://blog.scaleway.com/2017/scaleway-disruptive-armv8-clo...
The C1 was introduced in 2013.
And now Scaleway's Arm experiment is over?
Cavium ThunderX; Now under Marvell, has a newer ThunderX2 and an upcoming X3 [1]. Since they explicitly mentioned ARM64 it seems they are giving up the ARM64 Server business as a whole.
I was surprised when they launch C1 / ARM Offering so early in 2013, and would have expected the experiment to end in a few years time, but to discontinue ARM64 after AWS announced they are going All in, seems something. ( Sigh, my limited lexicon. Cant find the right word. )
[1] https://www.servethehome.com/marvell-thunderx3-arm-server-cp...
> As of December 1 st, 2020, our C2 and ARM64 Instances will reach their end-of-life. The physical servers hosting them are indeed randomly affected by several stability issues, which prevent us from fully guaranteeing the overall quality of service
Using non-x86 (or even just non-Intel) is also an investment, as you are less dependent on a duopoly.
The latter is tricky. You’re creating redundancy, which is good. But that redundancy is mighty expensive, as you have to either accept a lower quality of service in both, or invest in more specialized labor for both platforms.
Analogy: One of the ways that Southwest managed to keep costs down was to use one type of plane. While its peers used a mixed group of Airbus and Boeing aircraft tailored to the route, Southwest only used the 737. This allowed it to save huge amounts of money on maintenance and pilot training, as tons of parts and crew were easily moved around. And then the 737 MAX8 clusterfuck happened, and Southwest is stuck spending more fuel than its Airbus A321-neo flying competitors are.
It has been publicly said before by many, though I'm not sure we ever released any data publicly on this, so I'll keep this at the anecdata level
I don't know for sure if this was the issue that caused them to stop, but I expect if there was this and other issues that were hard to solve or kept cropping up, they perhaps just decided it was trouble than it was worth.
https://github.com/scaleway/image-ubuntu/issues/87#issuecomm...
Scaleway gave zero notice of the removal of the ability to start ARM64 instances. That means if you had a CI pipeline or automated system which started those instances, it just broke on you. Hope your clients don't mind random downtime!
You're going to have to port all your code to x64 or another cloud provider to restore service. That could take weeks. Weeks of downtime!
Don't touch Scaleway, ever, especially if you want an SLA.
But really the answer is "enough people for Amazon to invest heavily in manufacturing custom CPUs"
Scaleway just decided that you're not shipping any code today, you're retooling your configuration.
I don't think it's that bad, but it's not something a platform you trust to run anything valuable on would ever do.
The images run on the machines might be binaries licensed from vendors which are ARM. Have fun calling every vendor and saying "Yeah, I know you completed your contract with us 4 years ago, but would you mind recompiling the whole project as x64?".
Scheduled maintenance on their network, notified 1 week in advance. "No action required", they said. My IPv6-only VPS stopped to be reachable from outside and I could not get the web console. I opened a ticket and after some ineffective suggestions (trying to switch the machine on and off or go into recovery mode) as I was sure there was a problem in their new network, I found a workaround by myself: buying a floating IPv4 address, attaching it to the machine and using Cloudflare for IPv6. Today, after 16 days since the high priority ticket has been created, I got a reply with a solution: create a new instance, one month of refund.
Tip: there are many good alternatives to be considered even if you are looking for <= 5 $ VPS that have way less shortcomings and many times the cheapest VPS on Scaleway is above 10 $/month because of prolonged shortages. I would consider it only for hobby projects which require a lot of network traffic (VPS network is not capped).
Their ARM64 instances were actually disabled for new users, and required submitting an IT-ticket to be enabled. I thought it was strange at the time, but now with the EOL notice I guess it makes sense.
I think most providers would find a way to pull the plug on that kind of usage.
I deleted my Scaleway account last year after migrating all of my resources over to DO and other providers. I was sick of having to deal with randomly losing access to my servers in intervals of less than half a year.
Now that they're nuking C2 and ARM64 because of stability issues, from a pure price for performance perspective it would make sense for me to return to using their services.. but after my experience battling those issues with their support, it's unlikely.
I tried moving my services to them, during sign up they asked for a scan of my ID and before I could even send it, I got banned "irreversibly" and without a explicitly said reason.
I ended up using Linode instead.
To this day, I still wonder that the hell triggered their systems so bad to ban me before even finishing signing up.
- Hetzner EPYC Rome: 600/1900 - Scaleway EPYC Zen (DEV): 526/1844
Not much difference for a generation bump. But still, good value!
Other offers:
- Scaleway EPYC Zen (GP): 826/2887 - Hetzner Xeon Skylake: 673/2325
For support, they have a Slack channel: if you go in there and speak directly to the engineer who looks after things, you generally get a pretty decent level of service. Of course that's a totally different prospect than Google support, but the pricing is totally different too.
I happily host my side projects with them without too many issues. There was a recent outage on their block storage product, and the channels of communication were open and transparent in slack -- which is more than I can say for AWS.
I'm now up to 5 small dev servers and running hundreds of thousands of tasks per month across docker, serverless, and linux VMs.
+1 happy customer here.
Looks like you're fine.
Same here. My impression is that C1 is so dead that nobody in the company remembered to announce discontinuation :( Seriously, check the kernel maintenance if you don't understand what I mean.
None I can think of.
I ended up with an ARM instance, which was just fine for me. Since my monitoring application[1] was golang based it was a quick cross-compile to get a binary I could deploy to the host. The host itself ran Debian , and all the packages I'd expect were easily available.
TLDR: Cheap and easy to deploy to.