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.
And these new ARM CPUs could satisfy performance needs of like 99% of projects.
- 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.
They are also very slow when you stopping instance. Mine take hours to just stopping instance.
--- [1] noty.im
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.)
But as soon as the CPU comes into play a proper single thread performance is in most cases better than multiple slow threads. And if you have the choice, why would you choose ARM cores if you can have the better single thread performance?
I ask because you appear very biased and you experience contradicts mine, you could be right though. If you are right I would want to know, because I might make mistakes if you don't correct me in an objective way.
Needing the fastest cpu, great networks and accepting backup lock-in are examples of laziness in design. Sourcing commodity materials and already having a few nodes in every role is my preferred bet. Being able to upgrade the node performance by 10 times if scaling plans fail wont hurt either..
The tiny place where I disagree is that some tasks might take unbounded CPU/GPU time and network bandwidth. Your task clearly does not and I agree your workload looks like a common workload.
When working for the Air Force Weather Wing, it seemed clear that our decision to use the super computers we used was a budgetary decision and that is what bounded the size of the data we fed into our systems. Because we generated forecasts we had tight time constraints to meet, a 72 hour forecast that takes 100 hours to make is useless.
Weather modeling and forecasting is still advancing and even the latest models are not stable simulations (small fluctuations in inputs can cause large fluctuations in output) and this makes the most nuanced data possible desirable. While most commercial systems used 25km polygons covering the earth, ours used 17km polygons when I left. This meant that we had more precise sims and could accurately model further in the future, perhaps by several days. Even faster CPUs and networking might lead to a drop to 8-11km polygons allowing even better predictions. Ideally the meteorologists want to skip the rounding to regional polygons and use the parcels or air model that local forecasters use for the entire world. Presuming Moore's law holds up and weather modeling is amenable to newer GPUs I do not see weather modeling backing away from needing the fastest hardware money can buy in the foreseeable future.
(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 (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.
https://thehftguy.com/2016/11/01/docker-in-production-an-his...
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. ;)
>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.
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 ;)
First commit done in 2014.
It's funny how people always mention workarounds that were non existent or non viable at the time of the issue. ;)
I have worked on mirrors a few times in my career. I am sadly well aware than even the best mirroring solutions are rather poor. Not gonna argue that they have flaws. Not gonna argue that we wish for better.
Nonetheless, it probably wasn't nearly as stable, and certainly wasn't as well-known then. So I'll concede that it may not have been viable at that point.
The Docker crypto fuckup was quite peculiar. The distribution pipeline can't handle that. It also broke their other repos (including ubuntu) and propagated to the mirrors.
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 [2] https://github.com/hobby-kube/provisioning
Disclaimer: I'm the author of this project
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.
Traveller from the future!
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-c...
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/ That said, I have no idea how they perform in practice.