Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go + Services = One Goliath Project

engineering.khanacademy.org

Post reply on HN
Print view View original

331–340 of 449 posts

Re: Go + Services = One Goliath Project

#331

Post by andy_ppp »

pm90 wrote: post #287
bhntr3 wrote: post #281

> If we moved from Python to a language that is an order of magnitude faster, we can both improve how responsive our site is and decrease our server costs dramatically. I see people say things like this a lot but my experience is that while other languages are 10x or more faster than python in some benchmarks it's very rare that computation time dominates server latency or that servers are running at 60%+ cpu across…

* It’s not just that Go is faster to run but also faster to iterate on. If python can be neither, its offering little benefit. * they moved from a monolith to a microservices architecture; concern that any of the services in the request path could add latency just because of the overall runtime speed is slow is a legitimate one. * their primary deployment method is Google App Engine where you are billed by CPU used.…

Go is faster to iterate on is absolutely false. Where do you get this idea from?

Re: Go + Services = One Goliath Project

#332

Post by RandyRanderson »

olingern wrote: post #267
RandyRanderson wrote: post #258

Why do they call them "micro services" and not distributed systems? Oh right, it's because distributed systems are obviously really hard to create correctly and no sane person would ever agree to pay for that. Nice: re-branding. I can't wait for the, maybe "consolidated computing" manifesto (aka turning micro services back into monoliths).

Why are you getting hung up on nomenclature? The point of the article is clear. If you feel that using 'microservices' is too trite or "buzzword-y" then that's about you and not the article.

I guess you're agreeing with me sarcastically? Very funny.

Re: Go + Services = One Goliath Project

#333

Post by andy_ppp »

Sevii wrote: post #269
RandyRanderson wrote: post #258

Why do they call them "micro services" and not distributed systems? Oh right, it's because distributed systems are obviously really hard to create correctly and no sane person would ever agree to pay for that. Nice: re-branding. I can't wait for the, maybe "consolidated computing" manifesto (aka turning micro services back into monoliths).

People are willing to pay for it when you have 50+ engineers trying to push code through one deployment pipeline. There's an inflection point somewhere at which the cost of sharing deployments is no longer worth it.

I actually think this is where good software design and bounded contexts come in. You can perfectly well run a monolith with hundreds of developers if each of the sections is very well contained. There is no need to add network partitions everywhere to enforce this!

Re: Go + Services = One Goliath Project

#334

Post by RandyRanderson »

Sevii wrote: post #269
RandyRanderson wrote: post #258

Why do they call them "micro services" and not distributed systems? Oh right, it's because distributed systems are obviously really hard to create correctly and no sane person would ever agree to pay for that. Nice: re-branding. I can't wait for the, maybe "consolidated computing" manifesto (aka turning micro services back into monoliths).

People are willing to pay for it when you have 50+ engineers trying to push code through one deployment pipeline. There's an inflection point somewhere at which the cost of sharing deployments is no longer worth it.

I'm trying to imagine that ( real or imagined) benefit outweighting solving distributed transactions.

Re: Go + Services = One Goliath Project

#335

Post by SamReidHughes »

coldtea wrote: post #227
Thaxll wrote: post #178

Earlier quoted context omitted.

See for yourself: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

See what? This is an unofficial benchmark game - and based on implementations people bothered to provide. Not some scientific test, and nothing that guarantees these are the best implementations. And even if they were they're not representative of server/long running program behavior (where JIT quality and especially GC implementation) matters. Even so, the page linked starts with "Back in April 2010, Russ Cox charit…

That is for the purpose of "measuring the quality of the generated code when both compilers are presented with what amounts to the same program." But Go also allows pointers to fields and array elements and by design reduces pointer indirections and allocations in general, which those comparisons don't capture.

Re: Go + Services = One Goliath Project

#336

Post by nablaoperator »

speedplane wrote: post #309
golergka wrote: post #307

Earlier quoted context omitted.

You can also avoid using separate process for each client (NodeJS).

> You can also avoid using separate process for each client (NodeJS). Yes, NodeJS solves one problem by having low process overhead, but it also fails to take advantage of parallelism in modern processors. Ideally, I'd like to see a system with both.

You can always use the 'cluster' module or worker threads.

Re: Go + Services = One Goliath Project

#337

Post by pm90 »

andy_ppp wrote: post #331
pm90 wrote: post #287

Earlier quoted context omitted.

* It’s not just that Go is faster to run but also faster to iterate on. If python can be neither, its offering little benefit. * they moved from a monolith to a microservices architecture; concern that any of the services in the request path could add latency just because of the overall runtime speed is slow is a legitimate one. * their primary deployment method is Google App Engine where you are billed by CPU used.…

Go is faster to iterate on is absolutely false. Where do you get this idea from?

I can easily ask the vice versa of such a bland question. Answer that first if you want a real answer instead of trying to flame.

Re: Go + Services = One Goliath Project

#338

Post by RandyRanderson »

thethimble wrote: post #264
RandyRanderson wrote: post #258

Why do they call them "micro services" and not distributed systems? Oh right, it's because distributed systems are obviously really hard to create correctly and no sane person would ever agree to pay for that. Nice: re-branding. I can't wait for the, maybe "consolidated computing" manifesto (aka turning micro services back into monoliths).

What if the services you are writing are independent in that they solve separate business problems, are built by separate teams, have little to no data coupling (e.g. Only basic auth), have different scalability profiles, etc? Separate services are really effective for these cases. Neither micro services nor monoliths are silver bullets. Instead it's possible for each approach to be the best approach in a particular…

In several decades of it experience , I've not known or heard of a nontrivial system like the one you describe in the first part of your message.

In the latter part, that must be a disingenuous dichotomy. You don't really believe that just because an avenue exists we should include it in an evaluation?

Re: Go + Services = One Goliath Project

#339

Post by sethammons »

I've been in a similar boat. We've been splitting up or converting large Python 2.6/2.7 applications into Go services (and doing the same to large Perl applications) for a long time now.

Go has consistently been 10-20x performant (allowing for dramatically reduced hardware needs), easier to maintain, and more productive to produce code in than our previous Python (Twisted) and Perl (AnyEvent).

Hopefully KhanAcademy has solid telemetry data in both legacy and new code so they can quantify benefits. They will also have a learning curve for managing multiple micro services vs monoliths. Accessing shared data will be a problem they will likely have to solve. We've opted for each service controlling its own data - no reaching into another service's data behind its back. Everything through APIs. This gives the microservice the ability to alter its datastore as it needs to and not be blocked by other teams' need to update how they access the data.

Debugging a distributed solution is much harder than a single service. Distributed tracing, consistent structured logging with log aggregators that let you do fancy searches (like Splunk), and application telemetry and metrics will be even more important than before.

Re: Go + Services = One Goliath Project

#340

Post by lesserknowndan »

baddox wrote: post #278
lesserknowndan wrote: post #214

Earlier quoted context omitted.

I tentatively disagree with both of you. I've sometimes wondered whether code would be universally clearer if all you could do in a loop is have a one-liner or call another function/method (mainly when looking at my own code within loops and thinking WTF!!!). Would probably cause issues when teaching programming though. It would be interesting to have a compiler switch that enforced this...

What comes to mind immediately is that you would lose the ability to `break` unless you had another convention like returning a specific value to indicate you want to break.

If you are limited to one statement you could still do something along the lines of the following (no particular language):

  foreach ( $item in $list )
  {
    if ( 1 == some_function( $item ) )
    {
      continue;
    }
    else
    if ( 2 == some_function( $item ) )
    {
      break;
    }
    else
    {
      another_function( $item );
    }
  }
But I would immediately concede that it is starting to miss the entire point of why it was enforced in the first place...
Post reply on HN