5 ms·

> ...communicating with lightweight mechanisms, often an HTTP resource API HTTP is great and all but it's not lightweight. I'm curious what happens when each i

> ...communicating with lightweight mechanisms, often an HTTP resource API HTTP is great and all but it's not lightweight. I'm curious what happens when each incoming HTTP request from a client cascades into 5-10 HTTP requests inside your "Microservices" ecosystem. Does that scale? Granted, these may all take place on the same box but that still seems wasteful. Then there's the challenges of making sure each piece of the architecture is working correctly - and if it isn't, are you safely handling the error/routing to a known working node, etc? Sounds quite difficult to cope with in practice.

ritchiea 13y ago
Seems to me if you start writing your app with a service oriented architecture in mind then you have the flexibility to make your calls to services either in memory function calls or HTTP requests/RPCs. One example case: you write a monolithic Rails app that is structured around services but all services are in memory service objects. In production you find that your search service is both doing far more work than your other services & getting queried more often. So you refactor your application so that a call to the search service is no longer an in memory function call but instead an RPC to a group of servers that only handle the search service and have been rewritten in Java/Go/C++ to be blazing fast. Since you wrote your app with services in mind, you probably don't change the API at all, it just becomes a wrapper for an RPC rather than a class in your monolithic app. This way you don't automatically bulk up on unnecessary, expensive HTTP requests but you maintain the flexibility of optimizing modules of your app for performance.
- jermo 13y ago
  This reminds me a lot of the way Twitter and Netflix migrated from large monolithic applications to microservices. At Twitter they used Finagle for service discovery and RPC calls. The complication arising from splitting into microservices is that tracing and profiling calls become more difficult. So you have to start using new tools like Zipkin. [1] http://qconlondon.com/dl/qcon-london-2014/slides/BrianDegenhardt_RealTimeSystemsAtTwitter.pdf http://qconlondon.com/dl/qcon-london-2014/slides/BrianDegenh... [2] http://qconlondon.com/dl/qcon-london-2014/slides/AdrianCockcroft_MigratingToMicroservices.pdf http://qconlondon.com/dl/qcon-london-2014/slides/AdrianCockc...
- kainosnoema 13y ago
  This is amazingly great advice. Don't go pre-"optimizing" by adding a bunch of needless network calls—you'll only end up with more instability if done naively. DO start from the beginning with clear interfaces and boundaries between concerns in your codebase. Design for services from day one. If you don't have discipline not to tightly couple objects together, split into multiple codebases (gems, modules, whatever) tested in isolation that can be deployed together until it's time to pull them apart. A well designed class interface can be turned into an HTTP (or socket) API easily enough. By the time you need to, you'll probably have the resources to monitor, scale and maintain the additional service properly.
feralmoan 13y ago
AOP type architectures work fairly naturally with out of band queues etc. (0MQ, RabbitMQ or Redis pub/sub off top of my head) so its never really difficult to parallelize those requests out to workers who can largely operate independently. HTTP isn't a silver bullet and for the most part its how public API's are defined - however within your own infrastructure there's a bunch of other transport options, protobuffers, thrift, msgpack or whatever. But yes building some kind of hypervisor or FSM to manage error conditions across a cluster and particularly across datacenters can get out of hand very quickly

ritchiea 13y ago

Seems to me if you start writing your app with a service oriented architecture in mind then you have the flexibility to make your calls to services either in memory function calls or HTTP requests/RPCs. One example case: you write a monolithic Rails app that is structured around services but all services are in memory service objects. In production you find that your search service is both doing far more work than your other services & getting queried more often. So you refactor your application so that a call to the search service is no longer an in memory function call but instead an RPC to a group of servers that only handle the search service and have been rewritten in Java/Go/C++ to be blazing fast. Since you wrote your app with services in mind, you probably don't change the API at all, it just becomes a wrapper for an RPC rather than a class in your monolithic app. This way you don't automatically bulk up on unnecessary, expensive HTTP requests but you maintain the flexibility of optimizing modules of your app for performance.

jermo 13y ago
This reminds me a lot of the way Twitter and Netflix migrated from large monolithic applications to microservices. At Twitter they used Finagle for service discovery and RPC calls. The complication arising from splitting into microservices is that tracing and profiling calls become more difficult. So you have to start using new tools like Zipkin. [1] http://qconlondon.com/dl/qcon-london-2014/slides/BrianDegenhardt_RealTimeSystemsAtTwitter.pdf http://qconlondon.com/dl/qcon-london-2014/slides/BrianDegenh... [2] http://qconlondon.com/dl/qcon-london-2014/slides/AdrianCockcroft_MigratingToMicroservices.pdf http://qconlondon.com/dl/qcon-london-2014/slides/AdrianCockc...
kainosnoema 13y ago
This is amazingly great advice. Don't go pre-"optimizing" by adding a bunch of needless network calls—you'll only end up with more instability if done naively. DO start from the beginning with clear interfaces and boundaries between concerns in your codebase. Design for services from day one. If you don't have discipline not to tightly couple objects together, split into multiple codebases (gems, modules, whatever) tested in isolation that can be deployed together until it's time to pull them apart. A well designed class interface can be turned into an HTTP (or socket) API easily enough. By the time you need to, you'll probably have the resources to monitor, scale and maintain the additional service properly.

feralmoan 13y ago

AOP type architectures work fairly naturally with out of band queues etc. (0MQ, RabbitMQ or Redis pub/sub off top of my head) so its never really difficult to parallelize those requests out to workers who can largely operate independently. HTTP isn't a silver bullet and for the most part its how public API's are defined - however within your own infrastructure there's a bunch of other transport options, protobuffers, thrift, msgpack or whatever. But yes building some kind of hypervisor or FSM to manage error conditions across a cluster and particularly across datacenters can get out of hand very quickly