Re: [tlug] hosting in Japan

[Curt Sampson <cjs@example.com>]

Well, Josh already gave a good reply to this, but I've got a few
further comments.

On 2017-02-13 03:55 +0000 (Mon), Jason Frisch wrote:

> We see many instances where customers move to us (and our non-big 4
> competitors), because AWS was just the “easy” choice when they get
> started, but once they need real performance and stability, and
> cost-performance, AWS doesn’t tick any boxes so they search for
> alternatives. I expect Google is the same, but never done a
> cost-performance comparison.

In a word, "no," and you do yourself a disservice by expressing things
this way. 

While you are certainly correct that cost-performance varies, and my
personal experience with Tsukaeru was that it offered better
cost-performance than AWS did for what I was trying to do, it's
really, really important to understand exactly what one is trying to
do to determine if the performance is there at all.

For example, there are requests that can't be handled by a CDN, such
as updating individual information about a user. If you're trying to
scale to global levels at high reliability with this sort of thing you
need a load balancer (or, actually, a set of load balancers) on an
anycast[1] address which is handled by multiple data centers on
different contenents. Google's Cloud Load Balancing[2] does just this:
do you do the same? (Do you even offer the ability to have servers in
data centers outside of Asia?)

(For an example of the kind of problems you can run into when you're a
global-scale site and running on a single load balancer, have a look
at Netlify's DDOS experience last August.[3] Would you be capable of
dealing with that sort of thing better than Rackspace?)

Another area where it looks like you're not playing with the "big boys"
is in disk I/O operations per second (IOPS). "IOPS free" isn't particularly
comforting, since nobody can give you unlimited IOPS. If I need to spec.
a cluster that I know can handle continuous 50,000 IOPS across its storage
that's easy enough to do with GCP or AWS; your pages don't even offer that
sort of information.

Don't take this as Tsukaeru not being a good service; in fact, I'm
pretty sure that for some kinds of applications it's going to be
better than GCP or AWS. But trying to claim that you're better than
Google or Amazon even for large-scale (hundreds of thousands of
requests per second) applications is just going to give people the
impression that you don't really know what you're doing, at least when
your web site doesn't support that. (If you do have multiple data
centers around the world and load balancers with anycast addresses
that balance across all of these, my apologies, and you may want to
update your web site to make it clear that this is the kind of service
you offer. And, if like Google, you actually build your own switches
and other networking hardware, even more props to you, though you
really should be telling people about this.)

[1]: https://tools.ietf.org/html/rfc4786
[2]: https://cloud.google.com/load-balancing/
[3]: https://www.netlify.com/blog/2016/08/23/august-22nd-ddos-learning-review/

cjs
-- 
Curt Sampson         <cjs@example.com>         +81 90 7737 2974

To iterate is human, to recurse divine.
    - L Peter Deutsch