4 ms·

I imagine the lifetime savings of having a backend in Go is dwarfed by the one-time cost of such a migration. That's why they invented Hack and HHVM in the fir

by cbhl 9y ago

I imagine the lifetime savings of having a backend in Go is dwarfed by the one-time cost of such a migration. That's why they invented Hack and HHVM in the first place -- it was a cheap-enough compromise that didn't require rewriting the whole code base.

tyingq 9y ago
I'm not even convinced there's much savings. Hhvm supports an asynchronous pattern, and their proxygen web server (no fixed number of fcgi processes), so the typical PHP bottlenecks may not be an issue for FB. Wouldn't most of the pressure be on whatever the data layer is?
closeparen 9y ago
IIRC, Facebook uses (their derivative of) PHP to collect data from a number of services in different languages over Thrift, which they developed. PHP is the presentation layer. Much of the actual logic is in C++, Java, and maybe even Go by now.
- jsmthrowaway 9y ago
  They mentioned exactly that as a talking point during a talk I saw in 2012, so I'd imagine it's even more accurate now. Thrift exists for a reason. Another fun bit from that deck was a newsfeed-related PHP function with something like over 70 arguments across a dozen lines -- basically template data to render that had organically grown over time. It earned its own slide. There was an audible gasp from the room when it was revealed in all its glory, and they talked about the work it takes to refactor stuff like that (which is extensive).
- rbranson 9y ago
  (Former Facebook employee) The VAST majority of online serving code at Facebook is written in Hack (PHP) and is part of a gigantic codebase called fbwww. Backend services that do heavy lifting (mostly search, feed ranking, ad matching, TAO, various caches, proxies, etc) are fairly light on business logic and written in C++. It isn't a microservices architecture at all: they only move stuff to C++ for latency and efficiency reasons. For instance most of the ad stack is written in Hack, but certain key pieces use C++ for better performance. I'm not aware of any Java or Go code that is part of the online serving stack.
  - geggam 9y ago
    Do you know of any place actually using microservices at scale ? ( 400 Million + users )
    - closeparen 9y ago
      Your definition of "at scale" doesn't seem to leave room for Amazon, Netflix, or Uber (all in tens to low hundreds of million monthly active users according to a cursory Google search) but... those.
      - geggam 9y ago
        Guess my perspective of scale is different. Its just an observation of having worked on systems at scale and I dont see the microservices / containers used. I am curious if anyone else has. The more I am around containers and the network complexity/issues that are created the less I am convinced it is the most optimal way and I am looking for opinions that differ from mine so I can learn
        pc86 9y ago
        Only about 3.2 million people have the internet (as of 2015). Your definition of scale is 12.5% of the entire connected world or more? This is like the guy in these threads saying $400k a year for a software engineer is "market rate" and/or "easily achievable."
        closeparen 9y ago
        In my experience, these issues are minor when your large company has an infrastructure team dedicated to the service substrate (CI, self-service incremental deploys, service discovery and routing, standard RPC layer, canonical repository of IDL files, standard messaging layer, persistent storage as a service, time series collection, dashboarding, alerting, distributed tracing, safe internal and external nginx configs, etc). Microservices are probably a bad idea (for now) if you aren't large enough for such a team. But you've constructed your question to exclude the companies that work this way, which I think any reasonable person would call "at scale."
concede_pluto 9y ago
It's not one-time; Go will always have an ongoing time cost in reading and writing tedious boilerplate to reimplement features Hack already had built in.

by cbhl 9y ago

tyingq 9y ago

I'm not even convinced there's much savings. Hhvm supports an asynchronous pattern, and their proxygen web server (no fixed number of fcgi processes), so the typical PHP bottlenecks may not be an issue for FB. Wouldn't most of the pressure be on whatever the data layer is?

closeparen 9y ago

IIRC, Facebook uses (their derivative of) PHP to collect data from a number of services in different languages over Thrift, which they developed. PHP is the presentation layer. Much of the actual logic is in C++, Java, and maybe even Go by now.

jsmthrowaway 9y ago
They mentioned exactly that as a talking point during a talk I saw in 2012, so I'd imagine it's even more accurate now. Thrift exists for a reason. Another fun bit from that deck was a newsfeed-related PHP function with something like over 70 arguments across a dozen lines -- basically template data to render that had organically grown over time. It earned its own slide. There was an audible gasp from the room when it was revealed in all its glory, and they talked about the work it takes to refactor stuff like that (which is extensive).
rbranson 9y ago
(Former Facebook employee) The VAST majority of online serving code at Facebook is written in Hack (PHP) and is part of a gigantic codebase called fbwww. Backend services that do heavy lifting (mostly search, feed ranking, ad matching, TAO, various caches, proxies, etc) are fairly light on business logic and written in C++. It isn't a microservices architecture at all: they only move stuff to C++ for latency and efficiency reasons. For instance most of the ad stack is written in Hack, but certain key pieces use C++ for better performance. I'm not aware of any Java or Go code that is part of the online serving stack.
- geggam 9y ago
  Do you know of any place actually using microservices at scale ? ( 400 Million + users )
  - closeparen 9y ago
    Your definition of "at scale" doesn't seem to leave room for Amazon, Netflix, or Uber (all in tens to low hundreds of million monthly active users according to a cursory Google search) but... those.
    - geggam 9y ago
      Guess my perspective of scale is different. Its just an observation of having worked on systems at scale and I dont see the microservices / containers used. I am curious if anyone else has. The more I am around containers and the network complexity/issues that are created the less I am convinced it is the most optimal way and I am looking for opinions that differ from mine so I can learn
      - pc86 9y ago
        Only about 3.2 million people have the internet (as of 2015). Your definition of scale is 12.5% of the entire connected world or more? This is like the guy in these threads saying $400k a year for a software engineer is "market rate" and/or "easily achievable."
      - closeparen 9y ago
        In my experience, these issues are minor when your large company has an infrastructure team dedicated to the service substrate (CI, self-service incremental deploys, service discovery and routing, standard RPC layer, canonical repository of IDL files, standard messaging layer, persistent storage as a service, time series collection, dashboarding, alerting, distributed tracing, safe internal and external nginx configs, etc). Microservices are probably a bad idea (for now) if you aren't large enough for such a team. But you've constructed your question to exclude the companies that work this way, which I think any reasonable person would call "at scale."

concede_pluto 9y ago

It's not one-time; Go will always have an ongoing time cost in reading and writing tedious boilerplate to reimplement features Hack already had built in.