4 ms·

Scaleway can "disrupt" the industry as much as they want. As long as they don't have a solid product it's useless for production usage (backups, weird storage s

by nik736 9y ago

Scaleway can "disrupt" the industry as much as they want. As long as they don't have a solid product it's useless for production usage (backups, weird storage system, unpredictable network, etc.) They should just offer cheap Xeon D VMs and not this ARM stuff. The CPU is way too slow and the ratio is completely off, 2 of these ARM cores for 2 GB RAM? Even a shared Xeon or Xeon D core offers better performance than those ARM CPUs.

jameskegel 9y ago
Scaleway customer here. I read a review on HN a while back that got me to buy into their service. While on the surface, it seems like a great value, there are inconsistencies I cannot reconcile that have kept me on DigitalOcean and GCP since. For example, there's quite a bit of funny business going on in all of their stock kernels, so much so that you can't even run things like Docker or Minikube. If you try and install your own kernel mods, you'll find that an uphill battle as well.
- drdaeman 9y ago
  I run a C1 instance with Docker, and there weren't any immediate issues with stock kernels for me (I think I've switched between at least 4-5 during the year). Except when a systemd upgrade broke things and I had to reconnect the drive, but that wasn't Docker-related. However, I haven't had anything fancy there. (Docker multiarch support - or better say lack of one - is still a complete mess though. But that's also not a Scaleway issue.) There are tricks to running your own kernel there (via kexec), for Arch it's neatly packaged here: https://github.com/stuffo/scaleway-archkernel https://github.com/stuffo/scaleway-archkernel (but new servers don't have Arch as an option) Still, it's all terribly inconvenient. Possibly fun to mess with once, DIY/learning-style... but if you just want a server that works (and works in a way you want things to be, not how vendor had set it up) it could be sort of unpleasant.
  - jameskegel 9y ago
    It's very unpleasant considering half of their github scripts, including the one you listed, in my experience just flat out don't run how they were intended anymore.
- ch0wn 9y ago
  I've never had issues running docker on their instances. Was that on ARM or x86? I've only used the latter so far.
- user5994461 9y ago
  Mandatory read: https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/ https://thehftguy.com/2016/11/01/docker-in-production-an-his... https://thehftguy.com/2017/02/23/docker-in-production-an-update/ https://thehftguy.com/2017/02/23/docker-in-production-an-upd... If you have issue with Kernels and Docker. It's not just you and it's not entirely the fault of the provider. ;)
  - ryukafalz 9y ago
    He has some good points, but... >All CI pipelines in the world which rely on docker setup/update or a system setup/update are broken. It is impossible to run a system update or upgrade on an existing system. It’s impossible to create a new system and install docker on it. If the loss of package repos counts as a critical outage for you, you should be running your own package mirrors. Especially if you're not paying for commercial support and don't have anyone to escalate issues to.
    - user5994461 9y ago
      The package repo is not lost. It is online and serving packages with corrupted signatures. That's a crypto error interpretable as an active MITM attack on the repo, which causes a apt-get and subcommands to terminate abruptly with a critical error. Last but not least, the repository is mirrored and cached, the mirrors simply reproduced the corrupted source repo :D It is not a mere case of offline repository, though I can understand the confusion ;)
      - ryukafalz 9y ago
        I'm well aware of how traditional "dumb" mirrors work (e.g. ftpsync), and those would indeed just mirror the packages with their incorrect signatures. But for an internal network, surely you'd want something more like aptly[0] so you can roll back to a working version? [0] https://www.aptly.info/doc/overview/ https://www.aptly.info/doc/overview/
        user5994461 9y ago
- pstadler 9y ago
  I'm running a fully functional Kubernetes cluster on VC1S servers (x86) using this guide[1]. In case you're stuck compiling Kernel modules or running Docker, check out how it's done in the provisioner[2] that comes with the guide. [1] https://github.com/hobby-kube/guide https://github.com/hobby-kube/guide [2] https://github.com/hobby-kube/provisioning https://github.com/hobby-kube/provisioning Disclaimer: I'm the author of this project
zzzcpan 9y ago
I use C1 in production since the beginning along with a bunch of others. Their network is ok, no worse and no better than anyone else's, their weird storage is actually quite nice, nobody else offers anything similar in terms of space and performance in that price range, and I don't understand the point about backups, never used a backup feature of any hosting provider in fifteen years, it's kind of a vendor lock-in feature. And these new ARM CPUs could satisfy performance needs of like 99% of projects.
- nik736 9y ago
  That's just not true. - Network ist worse than the competition for sure, just benchmark it and you will see it. And if you benchmark it over a certain time period you will see that it's very unpredictable. If you only need 5mbit all the time, sure it's the same as anyone elses. The good thing is that you don't pay for traffic, but I would rather have a stable system/network. Also, the AMS network has a bad carrier mix which is why they route a lot of the traffic through Paris, which adds latency because their network is bad. - The storage system is a joke. Max 150 GB per volume, it's very slow depending where your VM lands. If you only look at the price, sure it's quite good, but that doesn't make it production ready. - How is an additional automated backup system vendor lock in? It's quite nice to restore backups with a click, how is that a bad thing? You can still do your own backups, but at least the option would be great. - No, the ARM CPUs don't statisfy 99% of projects. Because most web projects need single thread performance and that's exactly where ARM CPUs are garbage.
  - kureikain 9y ago
    I can confirm this. That's my experience as well. I run an uptime monitoring tools[1] and the node run on Scaleway is the most unreliable one due to network issues. It happens randomly once in 2 weeks when the instance experience 3-5minutes of disconnecting from internet completely. They are also very slow when you stopping instance. Mine take hours to just stopping instance. --- [1] noty.im
  - eropple 9y ago
    > most web projects need single thread performance What makes you say that? Near as I can tell, most web projects need I/O more than anything else. You're waiting on one end or another of a socket, a disk device, or a memory bus way more than you're doing anything chewy. (I agree with you that Scaleway isn't serious, however.)
reacweb 9y ago
scaleway customer since 09/2017. It is true that CPU is slow: apt-get update/upgrade is about 10 times slower than on my desktop. SSD disk is not very fast. There are network slowdown sometimes, but it is generally a lot faster than my home access. I use it for hosting of a couple of personal sites. My apache site is faster than a cheap entry level shared hosting. My node.js site is blazingly fast (most data is cached in memory and disk access are mostly async). I use it also as a proxy to work around enterprise internet filter (bluecoat filter blocks archive.org). With a bluetooth keyboard, a ssh client and tmux, my phone can be used to maintain my servers from anywhere. It is really dirt cheap compared to the service it gives.
- pjc50 9y ago
  > scaleway customer since 09/2017 Traveller from the future!
  - reacweb 9y ago
    typo: 09/2015
- mtgx 9y ago
  Worth pointing out that these are new ARM processors, potentially 3x faster than the (very) old ARM processors it was using before. I still think they should've gone with Qualcomm's Centriq 2400 [1] platform, though, which I think will be significantly ahead in performance and perf/W than either Cavium or APM's processors. I guess they went for that sweet price/performance value, but I think in ARM's case, it's worth going with the best there is, if nothing else to not continue the "too slow" stigma that ARM gets in servers, which can only hurt any ARM-based vendor. In my view, it would be better to offer similar or better performance than Xeon D (or other Xeons, depending on number of cores) for 20% less than offer half the performance for 50-60% less. [1] https://www.qualcomm.com/news/onq/2016/12/07/meet-qualcomm-centriq-2400-worlds-first-10-nanometer-server-processor https://www.qualcomm.com/news/onq/2016/12/07/meet-qualcomm-c...
polymeris 9y ago
> They should just offer cheap Xeon D VMs They do, they call them "Workload Intensive", and they start at 25 euros for 6 cores and 8^H [edit: 15] gigs of RAM. https://www.scaleway.com/pricing/ https://www.scaleway.com/pricing/ That said, I have no idea how they perform in practice.

by nik736 9y ago

jameskegel 9y ago

Scaleway customer here. I read a review on HN a while back that got me to buy into their service. While on the surface, it seems like a great value, there are inconsistencies I cannot reconcile that have kept me on DigitalOcean and GCP since. For example, there's quite a bit of funny business going on in all of their stock kernels, so much so that you can't even run things like Docker or Minikube. If you try and install your own kernel mods, you'll find that an uphill battle as well.

drdaeman 9y ago
I run a C1 instance with Docker, and there weren't any immediate issues with stock kernels for me (I think I've switched between at least 4-5 during the year). Except when a systemd upgrade broke things and I had to reconnect the drive, but that wasn't Docker-related. However, I haven't had anything fancy there. (Docker multiarch support - or better say lack of one - is still a complete mess though. But that's also not a Scaleway issue.) There are tricks to running your own kernel there (via kexec), for Arch it's neatly packaged here: https://github.com/stuffo/scaleway-archkernel https://github.com/stuffo/scaleway-archkernel (but new servers don't have Arch as an option) Still, it's all terribly inconvenient. Possibly fun to mess with once, DIY/learning-style... but if you just want a server that works (and works in a way you want things to be, not how vendor had set it up) it could be sort of unpleasant.
- jameskegel 9y ago
  It's very unpleasant considering half of their github scripts, including the one you listed, in my experience just flat out don't run how they were intended anymore.
ch0wn 9y ago
I've never had issues running docker on their instances. Was that on ARM or x86? I've only used the latter so far.
user5994461 9y ago
Mandatory read: https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/ https://thehftguy.com/2016/11/01/docker-in-production-an-his... https://thehftguy.com/2017/02/23/docker-in-production-an-update/ https://thehftguy.com/2017/02/23/docker-in-production-an-upd... If you have issue with Kernels and Docker. It's not just you and it's not entirely the fault of the provider. ;)
- ryukafalz 9y ago
  He has some good points, but... >All CI pipelines in the world which rely on docker setup/update or a system setup/update are broken. It is impossible to run a system update or upgrade on an existing system. It’s impossible to create a new system and install docker on it. If the loss of package repos counts as a critical outage for you, you should be running your own package mirrors. Especially if you're not paying for commercial support and don't have anyone to escalate issues to.
  - user5994461 9y ago
    The package repo is not lost. It is online and serving packages with corrupted signatures. That's a crypto error interpretable as an active MITM attack on the repo, which causes a apt-get and subcommands to terminate abruptly with a critical error. Last but not least, the repository is mirrored and cached, the mirrors simply reproduced the corrupted source repo :D It is not a mere case of offline repository, though I can understand the confusion ;)
    - ryukafalz 9y ago
      I'm well aware of how traditional "dumb" mirrors work (e.g. ftpsync), and those would indeed just mirror the packages with their incorrect signatures. But for an internal network, surely you'd want something more like aptly[0] so you can roll back to a working version? [0] https://www.aptly.info/doc/overview/ https://www.aptly.info/doc/overview/
      - user5994461 9y ago
pstadler 9y ago
I'm running a fully functional Kubernetes cluster on VC1S servers (x86) using this guide[1]. In case you're stuck compiling Kernel modules or running Docker, check out how it's done in the provisioner[2] that comes with the guide. [1] https://github.com/hobby-kube/guide https://github.com/hobby-kube/guide [2] https://github.com/hobby-kube/provisioning https://github.com/hobby-kube/provisioning Disclaimer: I'm the author of this project

zzzcpan 9y ago

I use C1 in production since the beginning along with a bunch of others. Their network is ok, no worse and no better than anyone else's, their weird storage is actually quite nice, nobody else offers anything similar in terms of space and performance in that price range, and I don't understand the point about backups, never used a backup feature of any hosting provider in fifteen years, it's kind of a vendor lock-in feature. And these new ARM CPUs could satisfy performance needs of like 99% of projects.

nik736 9y ago
That's just not true. - Network ist worse than the competition for sure, just benchmark it and you will see it. And if you benchmark it over a certain time period you will see that it's very unpredictable. If you only need 5mbit all the time, sure it's the same as anyone elses. The good thing is that you don't pay for traffic, but I would rather have a stable system/network. Also, the AMS network has a bad carrier mix which is why they route a lot of the traffic through Paris, which adds latency because their network is bad. - The storage system is a joke. Max 150 GB per volume, it's very slow depending where your VM lands. If you only look at the price, sure it's quite good, but that doesn't make it production ready. - How is an additional automated backup system vendor lock in? It's quite nice to restore backups with a click, how is that a bad thing? You can still do your own backups, but at least the option would be great. - No, the ARM CPUs don't statisfy 99% of projects. Because most web projects need single thread performance and that's exactly where ARM CPUs are garbage.
- kureikain 9y ago
  I can confirm this. That's my experience as well. I run an uptime monitoring tools[1] and the node run on Scaleway is the most unreliable one due to network issues. It happens randomly once in 2 weeks when the instance experience 3-5minutes of disconnecting from internet completely. They are also very slow when you stopping instance. Mine take hours to just stopping instance. --- [1] noty.im
- eropple 9y ago
  > most web projects need single thread performance What makes you say that? Near as I can tell, most web projects need I/O more than anything else. You're waiting on one end or another of a socket, a disk device, or a memory bus way more than you're doing anything chewy. (I agree with you that Scaleway isn't serious, however.)

reacweb 9y ago

scaleway customer since 09/2017. It is true that CPU is slow: apt-get update/upgrade is about 10 times slower than on my desktop. SSD disk is not very fast. There are network slowdown sometimes, but it is generally a lot faster than my home access. I use it for hosting of a couple of personal sites. My apache site is faster than a cheap entry level shared hosting. My node.js site is blazingly fast (most data is cached in memory and disk access are mostly async). I use it also as a proxy to work around enterprise internet filter (bluecoat filter blocks archive.org). With a bluetooth keyboard, a ssh client and tmux, my phone can be used to maintain my servers from anywhere. It is really dirt cheap compared to the service it gives.

pjc50 9y ago
> scaleway customer since 09/2017 Traveller from the future!
- reacweb 9y ago
  typo: 09/2015
mtgx 9y ago
Worth pointing out that these are new ARM processors, potentially 3x faster than the (very) old ARM processors it was using before. I still think they should've gone with Qualcomm's Centriq 2400 [1] platform, though, which I think will be significantly ahead in performance and perf/W than either Cavium or APM's processors. I guess they went for that sweet price/performance value, but I think in ARM's case, it's worth going with the best there is, if nothing else to not continue the "too slow" stigma that ARM gets in servers, which can only hurt any ARM-based vendor. In my view, it would be better to offer similar or better performance than Xeon D (or other Xeons, depending on number of cores) for 20% less than offer half the performance for 50-60% less. [1] https://www.qualcomm.com/news/onq/2016/12/07/meet-qualcomm-centriq-2400-worlds-first-10-nanometer-server-processor https://www.qualcomm.com/news/onq/2016/12/07/meet-qualcomm-c...

polymeris 9y ago

> They should just offer cheap Xeon D VMs They do, they call them "Workload Intensive", and they start at 25 euros for 6 cores and 8^H [edit: 15] gigs of RAM. https://www.scaleway.com/pricing/ https://www.scaleway.com/pricing/ That said, I have no idea how they perform in practice.