The C2 bare metal offer is based on the Atom C2000 series, which has the AVR54 errata. They are based on in-house custom hardware [1] and are no longer manufactured. The switching fabric used in this offering only supports stateless firewalls, creating a huge issue of feature parity between offerings. The switch fabric is part of the hardware design, so it is impossible to replace it with something that would support dynamic firewalls.
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].
A few days ago, Scaleway sent this in a mail to all customers:
> 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.
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. )
I have a C2 with them, and find that whenever I try to reboot it from within the VPS, it kernel panics rather than reboots. This makes automated security updates requiring reboot problematic (this is a small personal server for running nextcloud, I don't care if it has a couple of minutes downtime in the early morning, but turning off and not turning back on again is more annoying.)
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.
> 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
I’ve always seen the primary utility of ARM being in devices attached to a battery. In a data center the costs of changing probably trounce whatever power savings may be available.
The former makes sense. It’s just a question of whether those power savings are enough to offset the cost of switching, both for the hosting provider and the consumer.
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.
Not double, really. Phase change cooling is surprisingly efficient, you get a lot more heat moved than you'd expect for the power consumption (hundreds of percent).
AWS is all-in because they acquired Annapurna Labs and are designing their own in-house ARM chips. I'm sure they've found a way to do that cheaper than buying from Intel or AMD. Scaleway is nowhere near the size of Amazon, nor do they own their own in-house chip design studio. Not really an apples to apples comparison.
Google, who is frequently criticised for killing projects, guarantees cloud services for at least one year from the announcement of deprecation, and typically gives much longer.
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.
I agree with you and I would like to share what just happened to me with Scaleway.
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).
Thanks for your feedback.The creation of new C2 and ARM Instances is no longer possible for customers who do not use these offers, but we have considered those who still use them. Their quota per offer has not been reduced to zero, but to the number of instances they have plus one, which lets some flexibility to prepare migration before end of life on December 1st, 2020.Regarding SLA, we work hard to satisfy you and we invite you to give a try to our General Purpose Instances: https://www.scaleway.com/en/virtual-instances/general-purpos.... They have been designed for critical production needs. Regards -AA
I guess most companies could easily just run their code on x64 without porting necessary. How many clients would have ARM64-specific code running that absolutely would not run on x64? What Scaleway did is not ideal, but I think you are blowing it out of proportion.
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?".
I've been put off from being a Scaleway customer after having been in contact with their customer support and them doing this is not really changing my opinion about them.
That's too bad, there aren't too many companies offering ARM-based VPS'es. I ended up getting a Scaleway account as late as last month, for the sole reason of using their ARM64 instances. Needed it for debugging some user-reported ARM-specific bug in one of my side projects.
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 ran an alpine/arm tor node on scaleway for a while, but I had often problems with filesystem corruption and general stability. I don’t know if it was alpine or the arm server or both, but it was not a super stable setup. Their x64 boxes are more stable.
This is definitely not an ARM-only problem, I also had the same issues for years with both ARM64 and C2.
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 can highly recommend hetzner cloud. I run all my new stuff there. Great hardware, good connectivity, good prices, and okay UI to do things in: https://www.hetzner.de/cloud
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.
Online/Scaleway is a subsidiary of Iliad, a French telecom operator. Rumor has it (and it's not far-fetched) that they actively encourage heavy upload usage from Scaleway customers to help balance out their peering and/or transit connections to negotiate better deals.
I agree! If at any point they would've asked me to lower my usage I would've gladly done so. But they never did that so kudos to them. :) Especially considering it costs me 3EU a month.
I run one on hetzner cloud that does similar traffic and it is no problem at all for them. I basically max out the bandwidth at any given moment and they never complained.
Hard to say. I have made heavy use of their C1/Arch (dedicated Arm 32-bit) for 4 years now, and medium use of their Arm64/Debian virtualized instances on and off the past 2 years, and have experienced no problems of any kind.
I agree. I was also a happy customer of C1 until they stopped to maintain the kernel. The HW has still been running well, but with no way to install your own kernel either it has become unbearable. Sad to leave them behind.
Just moved from Scaleway to Hetzner's new AMD Epyc VPSs.Will see how it turns out.The CPX11 for 4.19/month seems a bargain.Their network seem a little slow though...With scaleway i was getting consistently Gigabit D/U.Now i sometimes get below 100mbps on hetzner.
Hetzner is doing network maintenance right now, check again in a while. This is the first time in quite a while that maintenance has degraded the network performance.
I also got burned by this. However, I'm going to buck the trend and say something nice about Scaleway: I've been using their managed Kubernetes product, Kapsule, for a few months now and I have generally been happy with it. It's pretty cost-effective, it auto-provisions SSD block storage and, so far, it has been reliable. No charges for the management plane at the moment (though like GKE, that could change).
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 will tip my hat to Scaleway as well. I'm in a couple of the product betas and enjoy having access directly with the engineers via slack.
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.
How about the C1s? I've been happily paying $3/mo for a C1 instance to host my personal stuff since 2015, and don't need to upgrade. Will they remain around?
Hello, no end of life is planned for the moment for C1 Instances. Nevertheless, these instances are now almost six years old. We recommend to rather turn to the Development and General Purpose Instances to build a future-proof infrastructure. Regards -AA
> How about the C1s? I've been happily paying $3/mo for a C1 instance to host my personal stuff since
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.
I wanted an monitoring host, which would just run HTTP/SSH/PING/FTP tests against my real infrastructure. So I googled providers with decent reviews that were cheap.
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.
I guess this is what Nuvia is trying to change. They are reputed to be bringing the power-saving features of ARM to ARM servers. (https://nuviainc.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/
[3] https://github.com/scaleway/image-fedora/issues/34
[4] https://github.com/scaleway/image-ubuntu/issues/87