5 ms·

New View of Microservices

95 points by nikolenkoanton 11y ago

hartror 11y ago
> The most critical thing is being able to use any services locally or remotely without knowing the difference or changing the code. I thought we all agreed CORBA style location transparency was a bad idea? https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture#Problems_and_criticism https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...
- charlieflowers 11y ago
  That was my 1st reaction too ... but hold on. If you design the 2 components to be non-chatty and have robust error handling, then it can be safe to make it location transparent. In other words, the problem in the past was, we designed it as if it would be used locally, then we naively made it remote. But now, we're talking about designing it for remote use, but then using it locally. Interesting.
  - ddoscampaign 11y ago
    Top-down configuration (as opposed to discovery like UDDI) via something like zookeeper or dns solves this problem. And APIs shouldn't do WSDL either, the code and docs should document the API. It's possible to add so many over-engineered layers of YAGNI flexibility that almost no one can understand what the heck is going on or how to hack on it, e.g., Eclipse plugins. Keep it really simple, until it breaks too often.
    - lsm 11y ago
      Really good suggestion for the API doc. I admit that writing documentation is much harder than code;)
  - iofj 11y ago
    It still has all the other disadvantages of remote services, like consistency problems (everybody always assumes that RPC calls are as reliable as 2 phase commit, and they're not), more and more complex code that's harder to change, less flexibility on all fronts except for the one, ... Things like distribution are a tradeoff, an optimization : you should never split a monolithic application into 2 communicating parts until you have good reason to do so. A monolithic system executing a given function is pretty much guaranteed to be simpler than a distributed system doing the same function. A small amount of microservices is easier on the guy doing ops work for the system, because they can be individually replaced, upgraded or changed (IF the developers put in the constant amounts of efforts needed to make that possible. Every release should be able to deal with past versions of everything it talks to). These guys are also usually the ones doing load balancing and the like, so bonus points for being able to spread them over the network. Of course, numbers of microservices always grow, and grow, and grow some more. Soon it's not easier anymore on the ops guy, and becomes a constant drag on progress for everyone.
    - lsm 11y ago
      I agree, the consistency problems should be handled inside each individual services and the layer before all the services should be as simple as normal balancer.
    - gbog 11y ago
      > A monolithic system executing a given function is pretty much guaranteed to be simpler than a distributed system doing the same function. And what about a monolithic system executing thousands of different functions? If your app is a simple todo list, sure, go monolithic (but you should still delegate storage to some other tool). If it is much more complex than a todo list, then it is very likely that you have many packages containing many modules developped and maintained by many programmers. And if one glitch on one side of the monolith affects a remote module and functionalities depending on it, or even breaks down the whole monolith, then you should go microservices. Or split your code base. Or do whatever is needed so the thing can still move forwards, if slowly, without breaking apart at each little step.
      - 11y ago
  - lsm 11y ago
    Yes, you got the idea. We focus on providing developer the "ability to switch or mix between microservice and monolithic styles" so people get flexibility they need for different circumstances (e.g. development vs deployment vs testing).
  - roel_v 11y ago
    People could (and did) design robust CORBA and (D)COM objects, but the overhead was too high in some (many?) cases. Overhead in development time, but also run time. If I can pass a const pointer to a bunch of data (if I know the consumer will live in the same memory space), then that's way faster (in development and run speed) than having to marshal that data into a common byte-order and alignment etc., most likely requiring copying, keeping track of who changed what when, ... Now that I have my old fogey hat on anyway, I might as well state the 'old wine in new bags' feeling I get with articles like this. Encapsulation and separation of concerns is good you say? But inconvenient because there is overhead? So infrastructure to manage dependencies and deployment of sets of loosely coupled components is useful? Whodathoughtthat!
    - hinkley 11y ago
      It's tough. Pass by reference became de rigeur for high performance systems when we agreed that the message passing overhead represented the plurality of computation time. But pass by reference is shared state, and as we started trying to build systems with threading and for multiple cores the ugly truth about memory coherence on modern processors came out. It was pretty bad. Java and later C had to come up with some pretty odd looking compromises to get safety without throwing away all of the speed advantages.
- hliyan 11y ago
  I don't think the failure of one (or even two) implementations invalidates the concept itself. I see nothing fundamentally wrong with the idea of location transparency (where it matters)
- hinkley 11y ago
  And then we agreed that location transparency was bad in RMI, and then again in EJB. It's regular as the tides. In a couple years you'll hear everyone talking about how stupid the Cloud is and everyone will be buying their own servers. Then we'll decide that peer-peer is the way and the light. Didn't Vonnegut have a line about how it affects you to see the same mistakes repeat over and over?
  - JoeAltmaier 11y ago
    Its more about bandwidth vs capacity vs dollars. The optimum changes as the technologies change.
    - hinkley 11y ago
      Touché. Every time we hit a new balance in the inequalities we have to re-evaluate all our answers. I guess what bugs me is not the mind changing (I do that all the time myself). It's that those without a history lesson behave as if this is a bloody revolution, and they have to pick sides. And the people who think switching solutions will magically fix all of our problems.
hurrycoward 11y ago
Non-distributed Microservices? http://fmontesi.blogspot.com/2015/06/non-distributed-microservices.html http://fmontesi.blogspot.com/2015/06/non-distributed-microse...
ddoscampaign 11y ago
Hopefully, they'll do rpc adapters for zmq and rabbitmq.
- lsm 11y ago
  There's a naive zmq RPC adapter here: https://github.com/lsm/micromono/blob/master/lib/rpc/zmq.js https://github.com/lsm/micromono/blob/master/lib/rpc/zmq.js Very buggy especially when clients disconnect/reconnect. But, it's good starting point if you are interested.
_Marak_ 11y ago
I've found the best design for creating microservices is to limit the service to one exported method ( the service handler ) and one URL path. http://hook.io http://hook.io uses this approach see: http://echo.hook.io/source http://echo.hook.io/source https://github.com/bigcompany/hook.io https://github.com/bigcompany/hook.io
muhmi 11y ago
Have a look at Erlang and OTP framework which makes it really easy to compose your application of smaller applications. At least for learning. Communication between nodes is transparent on the language level, its all message passing between processes. There is a approachable language with great tooling on top of the Erlang VM [1] and a great web framework [2]. [1] http://elixir-lang.org http://elixir-lang.org [2] http://www.phoenixframework.org http://www.phoenixframework.org
- muhmi 11y ago
  http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-microservices/ http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-...
  - logicchains 11y ago
    Question: on a scale of Go to Haskell, how long on average does it take for devs only familiar with a couple of imperative languages (e.g. two of Python, C, Java or Ruby) to learn Elixir to the point that they can be productive with it?
    - ardemchenkov 11y ago
      Sorry, I'm not a person to whom this question was addressed. But in our company we had 3 developers coming from PHP and Python world. They learned basics in 1-2 days and started to commit in production repository. Then in 1-3 weeks they learned it much deeper. But in our case it was easier because we already had high traffic and there were a lot of production examples to learn.
      - nailer 11y ago
        Do they ever have to use an Erlang lib and find the documentation harder because they're Elixir programmers? I love the Elixir syntax but worry it'd be like Scala: a better way for people who already know Java, rather than a way to use BEAM / OTP etc for people used to modern languages.
Kiro 11y ago
OT but can someone give me an example of some microservices in a normal application? I'm really stuck in the mindset of doing everything as a monolith and have a hard time imagining how I could split things up in microservices.
- jschulenklopper 11y ago
  Really depends on your domain, but reading up on "bounded contexts" and "domain-driven design" will help you in determining which microservices might be named and designed in your area. For example in online retail, seperate microservices for Customers, Products (catalog), Product reviews and Orders might be a feasible distribution of responsibility, functionality and data. Note that there's always a catch in going from a monolithic application to one with a more distributed nature. Distribution of data requires data synchronization and results in integration challenges, because of the unreliability and higher latency of networks. Lastly, Martin Fowler c.s. wrote some nice articles on microservices: http://martinfowler.com/tags/microservices.html http://martinfowler.com/tags/microservices.html. That will help as well.
- brightball 11y ago
  Not to self promote, but I provided some examples in a blog post for Codeship a month ago. https://blog.codeship.com/exploring-microservices-architecture-on-heroku/ https://blog.codeship.com/exploring-microservices-architectu...
  - durzagott 11y ago
    Great blog post, thanks for sharing.
- lobster_johnson 11y ago
  Consider a vanilla CMS: Public site where random visitors can view, with an admin part where groups of privileged users can log into and create/edit articles. In a microservice world, I would (and have) split this like so: * Front end: Perhaps a basic Node.js or Rails app. It's UI only; all data handling is done through APIs to the backends. * Admin: Completely separate app. Same here, UI only. * Post backend. This is a data store for articles. It has APIs for creating, updating, deleting articles. It also has a permission system that connects users to the groups that they are part of. This could be a separate microservice, but it's natural to keep it close to the data (also for performance reasons, since every post lookup needs to check if the calling user is allowed to see it). * Login backend. This has a user database and can do things like accept logins via other services such as Google and Twitter, via OAuth. * Miscellaneus support services. For example, say you want to support upload images: Make it a microservice that calls into ImageMagick and stores stuff in S3. Or let's say you want to support importing WordPress exports (WXR archives). Make it a service that parses and uploads asynchronously to the post backend. I have built this as a monolith, and as a microservice system. The microservice platform is much more flexible and clean. It also allows us to reuse every part for other apps — and this is in my mind the number one benefit that microservices gives you. We've had several new projects completely unrelated to what we've built before, and we have simply reused the microservices we had already created, only swapping out the new front end. Making reusable microservices is an interesting challenge, since core concepts (things like users and data objects) need to be generalized, and mechanisms built in so that you can make specific features that don't burden the microservices with too many conflicting concerns. For example, let's say that your CMS's public site wants users to be able to "like" individual articles. Instead of building this into the article store, create a microservice which abstracts the concept of "liking". Or let's say you want users to sign up for a newsletter version of the site that sends them a digest every week; again, don't build it in, but make a microservice that abstracts this into "subscriptions", with a registry of emails and what users are subscribing to, and so on. To generate well-formatted emails, simply let the front end provide an API for rendering templates, which this "subscription" microservice can invoke to do the actual rendering. Generalizing it this way makes it easy to then create new types of subscriptions, such as SMS messaging. Another important point is that every microservice has to be multitenant; a single microservice can host multiple unrelated datasets, and they need to be partitioned in a way that allows the APIs to not comingle the data by accident. It's not rocket science, but it takes some planning and practice to make the APIs feel natural.
nbevans 11y ago
Nobody said micro services are meant "distributed" in the first place.
ac360 11y ago
Nice work, have my github star! People interested in this should also check out JAWS: The Server-Less Framework Powered By AWS Lambda. JAWS V1 is coming out in a few weeks and it is insanely awesome. https://github.com/jaws-stack/JAWS https://github.com/jaws-stack/JAWS
mands 11y ago
Great work - looks really cool, esp for ppl using the Node stack. Really excited by the progress in the space, with products like this, JAWS (https://github.com/jaws-stack/JAWS https://github.com/jaws-stack/JAWS), hook.io and more. At StackHut (www.stackhut.com) we're working on something similar, a micro-services based system that's provides a scalable, typed, JSON interface into JS/Python classes wrapped up in containers. Can't wait to see where this microservices-based path ends up...

> The most critical thing is being able to use any services locally or remotely without knowing the difference or changing the code. I thought we all agreed CORBA style location transparency was a bad idea? https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture#Problems_and_criticism https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...

charlieflowers 11y ago
That was my 1st reaction too ... but hold on. If you design the 2 components to be non-chatty and have robust error handling, then it can be safe to make it location transparent. In other words, the problem in the past was, we designed it as if it would be used locally, then we naively made it remote. But now, we're talking about designing it for remote use, but then using it locally. Interesting.
- ddoscampaign 11y ago
  Top-down configuration (as opposed to discovery like UDDI) via something like zookeeper or dns solves this problem. And APIs shouldn't do WSDL either, the code and docs should document the API. It's possible to add so many over-engineered layers of YAGNI flexibility that almost no one can understand what the heck is going on or how to hack on it, e.g., Eclipse plugins. Keep it really simple, until it breaks too often.
  - lsm 11y ago
    Really good suggestion for the API doc. I admit that writing documentation is much harder than code;)
- iofj 11y ago
  It still has all the other disadvantages of remote services, like consistency problems (everybody always assumes that RPC calls are as reliable as 2 phase commit, and they're not), more and more complex code that's harder to change, less flexibility on all fronts except for the one, ... Things like distribution are a tradeoff, an optimization : you should never split a monolithic application into 2 communicating parts until you have good reason to do so. A monolithic system executing a given function is pretty much guaranteed to be simpler than a distributed system doing the same function. A small amount of microservices is easier on the guy doing ops work for the system, because they can be individually replaced, upgraded or changed (IF the developers put in the constant amounts of efforts needed to make that possible. Every release should be able to deal with past versions of everything it talks to). These guys are also usually the ones doing load balancing and the like, so bonus points for being able to spread them over the network. Of course, numbers of microservices always grow, and grow, and grow some more. Soon it's not easier anymore on the ops guy, and becomes a constant drag on progress for everyone.
  - lsm 11y ago
    I agree, the consistency problems should be handled inside each individual services and the layer before all the services should be as simple as normal balancer.
  - gbog 11y ago
    > A monolithic system executing a given function is pretty much guaranteed to be simpler than a distributed system doing the same function. And what about a monolithic system executing thousands of different functions? If your app is a simple todo list, sure, go monolithic (but you should still delegate storage to some other tool). If it is much more complex than a todo list, then it is very likely that you have many packages containing many modules developped and maintained by many programmers. And if one glitch on one side of the monolith affects a remote module and functionalities depending on it, or even breaks down the whole monolith, then you should go microservices. Or split your code base. Or do whatever is needed so the thing can still move forwards, if slowly, without breaking apart at each little step.
    - 11y ago
- lsm 11y ago
  Yes, you got the idea. We focus on providing developer the "ability to switch or mix between microservice and monolithic styles" so people get flexibility they need for different circumstances (e.g. development vs deployment vs testing).
- roel_v 11y ago
  People could (and did) design robust CORBA and (D)COM objects, but the overhead was too high in some (many?) cases. Overhead in development time, but also run time. If I can pass a const pointer to a bunch of data (if I know the consumer will live in the same memory space), then that's way faster (in development and run speed) than having to marshal that data into a common byte-order and alignment etc., most likely requiring copying, keeping track of who changed what when, ... Now that I have my old fogey hat on anyway, I might as well state the 'old wine in new bags' feeling I get with articles like this. Encapsulation and separation of concerns is good you say? But inconvenient because there is overhead? So infrastructure to manage dependencies and deployment of sets of loosely coupled components is useful? Whodathoughtthat!
  - hinkley 11y ago
    It's tough. Pass by reference became de rigeur for high performance systems when we agreed that the message passing overhead represented the plurality of computation time. But pass by reference is shared state, and as we started trying to build systems with threading and for multiple cores the ugly truth about memory coherence on modern processors came out. It was pretty bad. Java and later C had to come up with some pretty odd looking compromises to get safety without throwing away all of the speed advantages.
hliyan 11y ago
I don't think the failure of one (or even two) implementations invalidates the concept itself. I see nothing fundamentally wrong with the idea of location transparency (where it matters)
hinkley 11y ago
And then we agreed that location transparency was bad in RMI, and then again in EJB. It's regular as the tides. In a couple years you'll hear everyone talking about how stupid the Cloud is and everyone will be buying their own servers. Then we'll decide that peer-peer is the way and the light. Didn't Vonnegut have a line about how it affects you to see the same mistakes repeat over and over?
- JoeAltmaier 11y ago
  Its more about bandwidth vs capacity vs dollars. The optimum changes as the technologies change.
  - hinkley 11y ago
    Touché. Every time we hit a new balance in the inequalities we have to re-evaluate all our answers. I guess what bugs me is not the mind changing (I do that all the time myself). It's that those without a history lesson behave as if this is a bloody revolution, and they have to pick sides. And the people who think switching solutions will magically fix all of our problems.

hurrycoward 11y ago

Non-distributed Microservices? http://fmontesi.blogspot.com/2015/06/non-distributed-microservices.html http://fmontesi.blogspot.com/2015/06/non-distributed-microse...

ddoscampaign 11y ago

Hopefully, they'll do rpc adapters for zmq and rabbitmq.

lsm 11y ago
There's a naive zmq RPC adapter here: https://github.com/lsm/micromono/blob/master/lib/rpc/zmq.js https://github.com/lsm/micromono/blob/master/lib/rpc/zmq.js Very buggy especially when clients disconnect/reconnect. But, it's good starting point if you are interested.

_Marak_ 11y ago

I've found the best design for creating microservices is to limit the service to one exported method ( the service handler ) and one URL path. http://hook.io http://hook.io uses this approach see: http://echo.hook.io/source http://echo.hook.io/source https://github.com/bigcompany/hook.io https://github.com/bigcompany/hook.io

muhmi 11y ago

Have a look at Erlang and OTP framework which makes it really easy to compose your application of smaller applications. At least for learning. Communication between nodes is transparent on the language level, its all message passing between processes. There is a approachable language with great tooling on top of the Erlang VM [1] and a great web framework [2]. [1] http://elixir-lang.org http://elixir-lang.org [2] http://www.phoenixframework.org http://www.phoenixframework.org

muhmi 11y ago
http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-microservices/ http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-...
- logicchains 11y ago
  Question: on a scale of Go to Haskell, how long on average does it take for devs only familiar with a couple of imperative languages (e.g. two of Python, C, Java or Ruby) to learn Elixir to the point that they can be productive with it?
  - ardemchenkov 11y ago
    Sorry, I'm not a person to whom this question was addressed. But in our company we had 3 developers coming from PHP and Python world. They learned basics in 1-2 days and started to commit in production repository. Then in 1-3 weeks they learned it much deeper. But in our case it was easier because we already had high traffic and there were a lot of production examples to learn.
    - nailer 11y ago
      Do they ever have to use an Erlang lib and find the documentation harder because they're Elixir programmers? I love the Elixir syntax but worry it'd be like Scala: a better way for people who already know Java, rather than a way to use BEAM / OTP etc for people used to modern languages.

Kiro 11y ago

OT but can someone give me an example of some microservices in a normal application? I'm really stuck in the mindset of doing everything as a monolith and have a hard time imagining how I could split things up in microservices.

jschulenklopper 11y ago
Really depends on your domain, but reading up on "bounded contexts" and "domain-driven design" will help you in determining which microservices might be named and designed in your area. For example in online retail, seperate microservices for Customers, Products (catalog), Product reviews and Orders might be a feasible distribution of responsibility, functionality and data. Note that there's always a catch in going from a monolithic application to one with a more distributed nature. Distribution of data requires data synchronization and results in integration challenges, because of the unreliability and higher latency of networks. Lastly, Martin Fowler c.s. wrote some nice articles on microservices: http://martinfowler.com/tags/microservices.html http://martinfowler.com/tags/microservices.html. That will help as well.
brightball 11y ago
Not to self promote, but I provided some examples in a blog post for Codeship a month ago. https://blog.codeship.com/exploring-microservices-architecture-on-heroku/ https://blog.codeship.com/exploring-microservices-architectu...
- durzagott 11y ago
  Great blog post, thanks for sharing.
lobster_johnson 11y ago
Consider a vanilla CMS: Public site where random visitors can view, with an admin part where groups of privileged users can log into and create/edit articles. In a microservice world, I would (and have) split this like so: * Front end: Perhaps a basic Node.js or Rails app. It's UI only; all data handling is done through APIs to the backends. * Admin: Completely separate app. Same here, UI only. * Post backend. This is a data store for articles. It has APIs for creating, updating, deleting articles. It also has a permission system that connects users to the groups that they are part of. This could be a separate microservice, but it's natural to keep it close to the data (also for performance reasons, since every post lookup needs to check if the calling user is allowed to see it). * Login backend. This has a user database and can do things like accept logins via other services such as Google and Twitter, via OAuth. * Miscellaneus support services. For example, say you want to support upload images: Make it a microservice that calls into ImageMagick and stores stuff in S3. Or let's say you want to support importing WordPress exports (WXR archives). Make it a service that parses and uploads asynchronously to the post backend. I have built this as a monolith, and as a microservice system. The microservice platform is much more flexible and clean. It also allows us to reuse every part for other apps — and this is in my mind the number one benefit that microservices gives you. We've had several new projects completely unrelated to what we've built before, and we have simply reused the microservices we had already created, only swapping out the new front end. Making reusable microservices is an interesting challenge, since core concepts (things like users and data objects) need to be generalized, and mechanisms built in so that you can make specific features that don't burden the microservices with too many conflicting concerns. For example, let's say that your CMS's public site wants users to be able to "like" individual articles. Instead of building this into the article store, create a microservice which abstracts the concept of "liking". Or let's say you want users to sign up for a newsletter version of the site that sends them a digest every week; again, don't build it in, but make a microservice that abstracts this into "subscriptions", with a registry of emails and what users are subscribing to, and so on. To generate well-formatted emails, simply let the front end provide an API for rendering templates, which this "subscription" microservice can invoke to do the actual rendering. Generalizing it this way makes it easy to then create new types of subscriptions, such as SMS messaging. Another important point is that every microservice has to be multitenant; a single microservice can host multiple unrelated datasets, and they need to be partitioned in a way that allows the APIs to not comingle the data by accident. It's not rocket science, but it takes some planning and practice to make the APIs feel natural.

nbevans 11y ago

Nobody said micro services are meant "distributed" in the first place.

ac360 11y ago

Nice work, have my github star! People interested in this should also check out JAWS: The Server-Less Framework Powered By AWS Lambda. JAWS V1 is coming out in a few weeks and it is insanely awesome. https://github.com/jaws-stack/JAWS https://github.com/jaws-stack/JAWS

mands 11y ago

Great work - looks really cool, esp for ppl using the Node stack. Really excited by the progress in the space, with products like this, JAWS (https://github.com/jaws-stack/JAWS https://github.com/jaws-stack/JAWS), hook.io and more. At StackHut (www.stackhut.com) we're working on something similar, a micro-services based system that's provides a scalable, typed, JSON interface into JS/Python classes wrapped up in containers. Can't wait to see where this microservices-based path ends up...