I guess if the micro service is using a bunch of shared code from a Laravel project (maybe just interfacing with the database) or if your team is large and already using Laravel, then the first step of optimizing a service into a 'micro service' is to use Lumen. Then step two (if Lumen isn't going fast enough) is to go raw PHP as you described.
But if your service is getting that popular, memory leaks are going to be a problem, maybe moving to HipHop (or whatever it's called now) or Node or something is a better idea.
Yes! Haha I realized that when I'm working double the hours without noticing, because the challenges are finally unique enough to be interesting :)
I think you hit the nail on the head again too, since frameworks as a philosophy don't intrinsically value shared-nothing (SN) principles which is the other 'dimension' to scalable concurrency--from a devops perspective, anyway.
And while there's never complete isolation, minimizing that interdependence makes your builds that much more environment-agnostic, and easy to provision dynamically.
Honestly what I'd love to see is a kernel-up PHP environment/container that doesn't focus on runtime in isolation, but the entire TCP stack from syscntl to the webserver (h2o?) and maybe even with some experimental support to extract frequent commands to compiled modules with C headers.
But by that point you'd probably just be using Go or Haskell because that's what compiled, statically-typed languages are for ;)
Comments
I guess if the micro service is using a bunch of shared code from a Laravel project (maybe just interfacing with the database) or if your team is large and already using Laravel, then the first step of optimizing a service into a 'micro service' is to use Lumen. Then step two (if Lumen isn't going fast enough) is to go raw PHP as you described.
But if your service is getting that popular, memory leaks are going to be a problem, maybe moving to HipHop (or whatever it's called now) or Node or something is a better idea.
Sounds like you're having fun!
Yes! Haha I realized that when I'm working double the hours without noticing, because the challenges are finally unique enough to be interesting :)
I think you hit the nail on the head again too, since frameworks as a philosophy don't intrinsically value shared-nothing (SN) principles which is the other 'dimension' to scalable concurrency--from a devops perspective, anyway.
And while there's never complete isolation, minimizing that interdependence makes your builds that much more environment-agnostic, and easy to provision dynamically.
Honestly what I'd love to see is a kernel-up PHP environment/container that doesn't focus on runtime in isolation, but the entire TCP stack from syscntl to the webserver (h2o?) and maybe even with some experimental support to extract frequent commands to compiled modules with C headers.
But by that point you'd probably just be using Go or Haskell because that's what compiled, statically-typed languages are for ;)