Announcement

Collapse
No announcement yet.

Scaleway's EPYC Powered Cloud Is Delivering Competitive Performance & Incredible Value

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    It would be interesting to compare Scaleway's Atom-based VMs to the AWS ARM-based VMs.

    Comment


    • #12
      I gave up on scaleway middle of last year. Their offering has always felt half baked. The prices are competitive but too often when I tried to spin up an instance it wouldn't start or it would start but never fully boot (stock image), worse I had more than one instance of a VM not coming back up after a reboot and it took several relaunches to get it to work. It was a decent provider for "lab" work but I wouldn't do any production important/work with them.

      Anyone had better experiences recently?

      Comment


      • #13
        Originally posted by Michael View Post

        Unfortunately I don't have unlimited resources to compare to as many cloud providers and instances as I'd like, so for keeping things simple and to the masses, comparison was to EC2.
        Well I didn't mean compare Scaleway to Amazon and DO, I meant you should've dropped Amazon altogether, since it's a much different portfolio of services, and DO (or Vultr) would've been much more of an apples to apples comparison.

        In fact, even Scaleway's UI is a blatant knock-off of DO's UI.



        DO have 12 datacenters and more than 1 million customers so saying they're not "for the masses" is quite a stretch, too.

        Comment


        • #14
          Originally posted by atomsymbol

          The programmer cannot freely choose the HTTP/HTTPS port (default is 80/443). The process of IP address resolution doesn't include the port number. A non-standard HTTP/HTTPS server port would mean that the browsing user has to specify it which affects user-friendliness.

          In other cases, I agree with you.
          Reverse proxy, you can map multiple domains(or subdomains) to different internal ports(eg, a server on port 3000, and another at 9000, but the ports aren't directly exposed and must go through the reverse proxy on ports 80/443).

          Comment


          • #15
            Originally posted by anarki2 View Post
            DO have 12 datacenters and more than 1 million customers so saying they're not "for the masses" is quite a stretch, too.
            Agreed with DO and Vultr being rather well known names for VPS outside of the big name providers. They're good for value/perf iirc, but not EPYC which I thought was the point of the provider comparison for the most part?

            Comment


            • #16
              Originally posted by atomsymbol

              The programmer cannot freely choose the HTTP/HTTPS port (default is 80/443). The process of IP address resolution doesn't include the port number. A non-standard HTTP/HTTPS server port would mean that the browsing user has to specify it which affects user-friendliness.

              In other cases, I agree with you.
              How you'd typically do it is have some kind of proxy listening on port 80 or 443. It would be configured to proxy requests to the correct port. So for example, you might configure it like:

              /login => 10000
              /user => 10001
              /product => 10002
              /booking => 10003


              You'd then run these services on the above ports, and access them via the SAME IP. nginx, apache, haproxy ... these can all do this. Read up on it.

              Comment


              • #17
                Originally posted by atomsymbol

                Thank you for your suggestion, but it does not suit my needs.
                No worries Just out of curiosity - what are your needs that clash with this approach?

                Comment


                • #18
                  Originally posted by atomsymbol

                  I have a small HTTP/HTTPS web server implemented in Go that dispatches URLs to different code/data paths depending on request's IP address and depending on URL's path. I am not forwarding requests to different executables (via Linux sockets or pipes), and if that need might arise in the future I believe it won't be hard to implement in Go. nginx or apache would unnecessarily increase the complexity of the server without improving its function.
                  Ah! Well if you've hard-coded the IP address thing into your design, then yeah, not much else will fit.

                  Comment


                  • #19
                    Originally posted by atomsymbol

                    IP addresses is are parameters.
                    Sure, but you've locked in the requirement that there be a 1:1 relationship between 'services' and IP addresses, right? As a couple of us have noted, the standard approach is to map different URL paths to different ports, thereby only requiring 1 IP address. As you've discovered, having multiple IPs can cost you ...

                    Comment


                    • #20
                      I've been using scaleway for more than 1 year, and i'm impressed, price, performance, quality, everything is there

                      And Unlimited bandwidth !!!!!! what else do you need ?

                      Comment

                      Working...
                      X