7 ms·

Microservices - 72 resources

105 points by calineczka 12y ago

notastartup 12y ago
This is essentially what I ended up doing. I used to talk about an architecture where each component would be a standalone REST api and that together all these components would talk to each other to other standalone components with it's own REST api. I'm really glad that there's a word for this, I bet in a few years we will see this become the new buzzword and see it in job requirements. I really like the microservices architecture because it just feels efficient.
hewitt 12y ago
Breaking down an application into micro services allows me to keep a clearer picture of the entire application and how it should work. Not to mention the advantage of evolving the services individually without affecting the entire system. I've started a little library in Python for writing small services. It leverages nanomsg. link: https://github.com/walkr/nanoservice https://github.com/walkr/nanoservice
- hartror 12y ago
  Why have you chosen not to use HTTP and all the ease of use and interoperability advantages it confers?
  - hewitt 12y ago
    Performance and simplicity would be two factors. Plus I think nanomsg doesn't play well with HTTP. And I'm saying this because I remember ZeroMQ didn't play well with HTTP also. nanomsg is a rewrite of ZeroMQ, so I might be wrong here.
valevk 12y ago
What is actually the difference between a "microservice" architecture, and a component based architecture?
- ownagefool 12y ago
  You can install a component and never upgrade it. You might fall behind on security concerns and be running different code from your counterparts but you can do that if you like. If you consume some service, you're going to have to keep your app up-to-date should the service chage, go away, or fail. Therefore one could argue that services are easier to manage centrally at the expense of some overhead and less flexibility.
  - mhluongo 12y ago
    That doesn't sound like a primary difference between the two? You can certainly leave up an old service.
    - vidarh 12y ago
      Yes, but that is not up to the consumer of the service (or not under the direct control of the consumer, in any case; assuming for the sake of argument that the consumer of the service is distinct from the producer)
- mhluongo 12y ago
  This might help http://petritsch.co.at/download/SOA_vs_component_based.pdf http://petritsch.co.at/download/SOA_vs_component_based.pdf It seems like a distinction is between organization-wide, discoverable services (SOA -> microservices) and reusable components that may or may not communicate via a remote protocol. EDIT - From reading more about component-based, another difference is that services are less tightly coupled. They often run on different machines & OS's, and are also often written in different languages. In the case of microservices, a common theme in these resources is that each microservice is owned by the part of the organization that created it, which is pretty interesting.
DenisM 12y ago
I was expecting a list of 72 micro services, instead there are 72 articles on the subject. Feels like it's the opposite of "curated list" - a list everything.
stevepike 12y ago
What do people recommend for learning about SOA / microservices? I liked Patterns of Enterprise Application Architecture and Enterprise integration patterns, but didn't have a great experience with the SOA design with Rails book - it felt much to focused on very basic details (e.g., here is how you consume JSON).
- auxbuss 12y ago
  The best advice I can think of is to build one. There really aren't any general rules. Everyone's needs (and languages/platforms/tools) and experiences are going to be different, which is great to learn from, but isn't going to present you with prescriptive advice. However, since microservices are, by definition, small, building something basic is not complex or time-consuming. I'd suggest tackling something fundamental, such as user login and restricting service actions based on, say, a user's role. This is all well-established stuff in web-based apps via sessions, etc., but presents a number of issues when using microservices. For example, you'll probably want some sort of token (for the user) and a way to manage it. Going through those steps will get your brain ticking over about any number of problems and will provide you with much learning. Since you are using Rails, I'd suggest creating a User service (one rails app) and a Blah service (another rails app) that requires authorisation to access some actions. Building that, and thinking through the issues, and building solutions, will give you a lot of feel for building microservices. Rails (specifically v4 in API-mode, which avoids a lot of MVC stuff) is actually quite cool for microservices, where you can leverage its filters and gems to provide cross service functionality -- like the token handling I alluded to above. (As an aside: if you do do the above, you'll probably find that you need some sort of "system/root" user access to some services. The "obvious" solution is to create such a user with super powers (that only the system can use). However, think through the implications of this -- massive potential security hole -- and other ways in which you can provide the required services. Actually, thinking about it, that might be a prescriptive rule: never create a super/root user -- that's not to say that a user can't have, say, an admin role.)
  - stevepike 12y ago
    Thanks! I agree that just building something is a great way to get familiar with this stuff. I'm not looking for someone to say "this is how you build SOA" (which is probably why I found the rails book lacking) but rather "here is some complex challenge which I solved in this way, and here are the things we would have done differently in a re-write". Getting started with microservices is easy - there's probably more code to write in the deployment / testing / monitoring / logging plumbing than there is in your entire first service - but I'm sure there are subtle patterns that others have found that'd be good to know.
Addyall 12y ago
Why do we need a new term for this? Isn't this just Unix philosophy applied to SaaS? No need to learn about "micro services" when you can learn about Unix/Linux and why it's built the way it is, then apply that knowledge to your SaaS product.
- cordite 12y ago
  Reminds me about when the web finally realized that grids and ratios, common principles that print-related specialists have known and used for decades. At least that case kept the same names, I think.
- hibikir 12y ago
  There are a couple of differences. First, a key part of the Unix philosophy is the pipes. Programs do not really communicate without them. The closes thing I have seen in a microservice architecture is some magical bus, which is not easy to implement well, thanks to the fun of distributed systems: We don't spent time wondering if grep is going to get the data twice, or not at all, do we? A second difference is that, in the unix world, we fully accept the concept of glue. Along with the reusable tools of the world, we have all the code that we know is not going to be reusable, that lets us do the task at hand. Depending on how hard it is, we might use something from bash to Perl. In a microservice architecture, such glue, if created, would be the actual logic of your application! So the moment you start adding glue, then the attention will quickly go to the glue, like the C gets pretty big in MVC. Now, personally I am no believer in microservices as the panacea. The big advantage of the unix world is the reusable components. In a typical business application, the one we tend to get paid to do, how much code is actually stable enough, and reusable enough, that we really believe that its interface will last us a long time? In my experience, it's very little. Where I have seen microservice-like architectures pull their weight is in actor systems, as a way to handle massive parallelism. But, just like many NoSQL implementations, they are solving a problem that many people would love to have, and very few people actually do. So we see startups building architectures in semi-exotic languages to handle hundreds of thousands of connections a second, when their actual volume of work could be handled with a boring Java app pointing to a Postgres database.
- christiansmith 12y ago
al2o3cr 12y ago
This article would be way better if each resource was in a separate blog post. :) #snark
InfiniteRand 12y ago
One issue I have with this and similar architectures is that it often sticks an HTTP stack where it is not needed. The HTTP request/response paradigm does add a useful process management architecture, but it seems like you could implement that without the HTTP component, although then you would also need to figure out the inter-operability side of things if you wanted that flexibility to plugin into stuff. Which may lead you to wanting a protocol for making things easier. Okay, I guess I do understand why the HTTP stack is wanted, but with HTTP/2 around the corner, it might be time to think about whether it makes sense to create a more primitive version of HTTP focused on non-networked or locally-networked applications
- lobster_johnson 12y ago
  HTTP is great because it lets you use the same API in the browser. Given the right services, you can build your front end UI entirely based on your service APIs, no other back end needed. If services used ZeroMQ or Thrift or similar, a browser front end would require an adapter layer. If you have 10+ services, that's a lot of redundant code. Plus: You're leveraging a lot of great infrastructure. With HTTP APIs you can just curl into your APIs. Or load balance and proxy them with HAProxy, Nginx, Varnish etc.
- persei8 12y ago
  Request/Reply pattern makes a poor choice for communication between services - it increases coupling. It doesn't matter much if it comes with HTTP or any other flavour. Again, Jeppe nails it in very detailed post: http://www.tigerteam.dk/2014/microservices-its-not-only-the-size-that-matters-its-also-how-you-use-them-part-3/ http://www.tigerteam.dk/2014/microservices-its-not-only-the-...
  - PeterGriffin 12y ago
    The post talks about synchronous communication increasing temporal coupling. There's nothing in sending a request and getting a response that's increasing coupling in a traditional sense, and often there's no much of an alternative anyway, if you want donuts, you'll have to request donuts, and then receive donuts. While I dislike shoving HTTP everywhere for many reasons (reminds me of XML abuse), HTTP is not synchronous, nor asynchronous. It's a protocol sent over a socket. Synchronicity is not the domain of HTTP at all. It's up to the application how it does it. Additionally, the response can always be a blank acknowledgement of the received request. There are very few cases where you just want to go forward blindly without even receiving an ACK about your request at some level (or alternatively, an error), because sometimes things fail.
bgentry 12y ago
Are people typically building their microservices infrastructure on top of a SQL database, or other datastores? I'd be concerned not just about the overhead of managing lots of different (though simple) services, but also the fact that you give up a lot of convenient & useful features that you could get for free with a monolithic application, such as transactions. You either have to avoid needing transactions between microservices, or deal with the complexity of coordinating distributed transactions. That seems like an awfully big hurdle to overcome for a new application, especially if you're a startup that needs to focus on delivering customer value as quickly as possible.
- persei8 12y ago
  Transactions spanning several microservices violate their autonomy - one service should not lock resources of another. Jeppe Cramon explains it pretty well in http://www.tigerteam.dk/2014/micro-services-its-not-only-the-size-that-matters-its-also-how-you-use-them-part-2/ http://www.tigerteam.dk/2014/micro-services-its-not-only-the...
  - PeterGriffin 12y ago
    That's often not practical. Say you're a shop front. If you have a goods purchase service and a goods delivery service, you want to reserve the good (limited quantity) and reserve a time slot for transport (limited number of deliveries a day) before you charge the customer, and make the "commit". And if you'd merge two separate companies into one uber-service, you've just created more problems than you've solved.
    - deleted 12y ago
      [deleted]
    - superuser2 12y ago
      Atomic transactions are one of several strategies for handling this problem, and not always the right answer. Starbucks is a good analogy (http://www.eaipatterns.com/ramblings/18_starbucks.html http://www.eaipatterns.com/ramblings/18_starbucks.html). If Starbucks were transactional, you would have to stand there at with the money on the counter and wait until your drink was finished, then exchange at the exact same time. Even the mental image is ridiculous. In practice, it makes much more sense to allow the system to enter certain inconsistent states and then remediate them. Out of an ingredient? Refund the money. Can't pay? Pull the drink out of the queue, or just write it off. This can involve some cost, but less cost than than the throughput you'd lose by enforcing consistency. For your specific example of a goods delivery service, most take-out restaurants fly in the face of these claims: you can pay the driver in cash when they arrive. They are willing to accept the risk that you made your order fraudulently, won't pay, etc. because it's still better for them to have your business. If you reserved a time-slot or inventory for someone whose credit card is declined, so what? Just un-reserve it. It's not hard to UPDATE a row in a database. The system was in an inconsistent state for 10 seconds. Big whoop. (You might have turned down a legitimate customer, but only if they were consuming the last resource, and if demand is that high, another customer will buy the item.) Notice that Ticketmater and most airlines will hold your seats (i.e. leave the system in an inconsistent state) for up to 15 minutes while you enter your card details. Hell, Ticketmaster can easily reverse a transaction at any point up until the moment your ticket is scanned at the door. So could an airline, and they often do. The classic example of account balances isn't necessarily the case either - banks can INSERT records of individual transactions. Since addition is commutative, race conditions are irrelevant. Balances are then calculated nightly offline by playing back the transaction records. I guess that's a form of locking, but even if it weren't, the balance isn't the source of truth - the transactions are, and the balance can be recomputed. Banks also don't hide the complexities of transaction processing. Your "current balance" is different from your "available balance" and your most recent transactions show as pending anyway. You don't need transactions as often as you think you do.

105 points by calineczka 12y ago

This is essentially what I ended up doing. I used to talk about an architecture where each component would be a standalone REST api and that together all these components would talk to each other to other standalone components with it's own REST api. I'm really glad that there's a word for this, I bet in a few years we will see this become the new buzzword and see it in job requirements. I really like the microservices architecture because it just feels efficient.

hewitt 12y ago

Breaking down an application into micro services allows me to keep a clearer picture of the entire application and how it should work. Not to mention the advantage of evolving the services individually without affecting the entire system. I've started a little library in Python for writing small services. It leverages nanomsg. link: https://github.com/walkr/nanoservice https://github.com/walkr/nanoservice

hartror 12y ago
Why have you chosen not to use HTTP and all the ease of use and interoperability advantages it confers?
- hewitt 12y ago
  Performance and simplicity would be two factors. Plus I think nanomsg doesn't play well with HTTP. And I'm saying this because I remember ZeroMQ didn't play well with HTTP also. nanomsg is a rewrite of ZeroMQ, so I might be wrong here.

valevk 12y ago

What is actually the difference between a "microservice" architecture, and a component based architecture?

ownagefool 12y ago
You can install a component and never upgrade it. You might fall behind on security concerns and be running different code from your counterparts but you can do that if you like. If you consume some service, you're going to have to keep your app up-to-date should the service chage, go away, or fail. Therefore one could argue that services are easier to manage centrally at the expense of some overhead and less flexibility.
- mhluongo 12y ago
  That doesn't sound like a primary difference between the two? You can certainly leave up an old service.
  - vidarh 12y ago
    Yes, but that is not up to the consumer of the service (or not under the direct control of the consumer, in any case; assuming for the sake of argument that the consumer of the service is distinct from the producer)
mhluongo 12y ago
This might help http://petritsch.co.at/download/SOA_vs_component_based.pdf http://petritsch.co.at/download/SOA_vs_component_based.pdf It seems like a distinction is between organization-wide, discoverable services (SOA -> microservices) and reusable components that may or may not communicate via a remote protocol. EDIT - From reading more about component-based, another difference is that services are less tightly coupled. They often run on different machines & OS's, and are also often written in different languages. In the case of microservices, a common theme in these resources is that each microservice is owned by the part of the organization that created it, which is pretty interesting.

DenisM 12y ago

I was expecting a list of 72 micro services, instead there are 72 articles on the subject. Feels like it's the opposite of "curated list" - a list everything.

stevepike 12y ago

What do people recommend for learning about SOA / microservices? I liked Patterns of Enterprise Application Architecture and Enterprise integration patterns, but didn't have a great experience with the SOA design with Rails book - it felt much to focused on very basic details (e.g., here is how you consume JSON).

auxbuss 12y ago
The best advice I can think of is to build one. There really aren't any general rules. Everyone's needs (and languages/platforms/tools) and experiences are going to be different, which is great to learn from, but isn't going to present you with prescriptive advice. However, since microservices are, by definition, small, building something basic is not complex or time-consuming. I'd suggest tackling something fundamental, such as user login and restricting service actions based on, say, a user's role. This is all well-established stuff in web-based apps via sessions, etc., but presents a number of issues when using microservices. For example, you'll probably want some sort of token (for the user) and a way to manage it. Going through those steps will get your brain ticking over about any number of problems and will provide you with much learning. Since you are using Rails, I'd suggest creating a User service (one rails app) and a Blah service (another rails app) that requires authorisation to access some actions. Building that, and thinking through the issues, and building solutions, will give you a lot of feel for building microservices. Rails (specifically v4 in API-mode, which avoids a lot of MVC stuff) is actually quite cool for microservices, where you can leverage its filters and gems to provide cross service functionality -- like the token handling I alluded to above. (As an aside: if you do do the above, you'll probably find that you need some sort of "system/root" user access to some services. The "obvious" solution is to create such a user with super powers (that only the system can use). However, think through the implications of this -- massive potential security hole -- and other ways in which you can provide the required services. Actually, thinking about it, that might be a prescriptive rule: never create a super/root user -- that's not to say that a user can't have, say, an admin role.)
- stevepike 12y ago
  Thanks! I agree that just building something is a great way to get familiar with this stuff. I'm not looking for someone to say "this is how you build SOA" (which is probably why I found the rails book lacking) but rather "here is some complex challenge which I solved in this way, and here are the things we would have done differently in a re-write". Getting started with microservices is easy - there's probably more code to write in the deployment / testing / monitoring / logging plumbing than there is in your entire first service - but I'm sure there are subtle patterns that others have found that'd be good to know.

Addyall 12y ago

Why do we need a new term for this? Isn't this just Unix philosophy applied to SaaS? No need to learn about "micro services" when you can learn about Unix/Linux and why it's built the way it is, then apply that knowledge to your SaaS product.

cordite 12y ago
Reminds me about when the web finally realized that grids and ratios, common principles that print-related specialists have known and used for decades. At least that case kept the same names, I think.
hibikir 12y ago
There are a couple of differences. First, a key part of the Unix philosophy is the pipes. Programs do not really communicate without them. The closes thing I have seen in a microservice architecture is some magical bus, which is not easy to implement well, thanks to the fun of distributed systems: We don't spent time wondering if grep is going to get the data twice, or not at all, do we? A second difference is that, in the unix world, we fully accept the concept of glue. Along with the reusable tools of the world, we have all the code that we know is not going to be reusable, that lets us do the task at hand. Depending on how hard it is, we might use something from bash to Perl. In a microservice architecture, such glue, if created, would be the actual logic of your application! So the moment you start adding glue, then the attention will quickly go to the glue, like the C gets pretty big in MVC. Now, personally I am no believer in microservices as the panacea. The big advantage of the unix world is the reusable components. In a typical business application, the one we tend to get paid to do, how much code is actually stable enough, and reusable enough, that we really believe that its interface will last us a long time? In my experience, it's very little. Where I have seen microservice-like architectures pull their weight is in actor systems, as a way to handle massive parallelism. But, just like many NoSQL implementations, they are solving a problem that many people would love to have, and very few people actually do. So we see startups building architectures in semi-exotic languages to handle hundreds of thousands of connections a second, when their actual volume of work could be handled with a boring Java app pointing to a Postgres database.
christiansmith 12y ago

al2o3cr 12y ago

This article would be way better if each resource was in a separate blog post. :) #snark

InfiniteRand 12y ago

One issue I have with this and similar architectures is that it often sticks an HTTP stack where it is not needed. The HTTP request/response paradigm does add a useful process management architecture, but it seems like you could implement that without the HTTP component, although then you would also need to figure out the inter-operability side of things if you wanted that flexibility to plugin into stuff. Which may lead you to wanting a protocol for making things easier. Okay, I guess I do understand why the HTTP stack is wanted, but with HTTP/2 around the corner, it might be time to think about whether it makes sense to create a more primitive version of HTTP focused on non-networked or locally-networked applications

lobster_johnson 12y ago
HTTP is great because it lets you use the same API in the browser. Given the right services, you can build your front end UI entirely based on your service APIs, no other back end needed. If services used ZeroMQ or Thrift or similar, a browser front end would require an adapter layer. If you have 10+ services, that's a lot of redundant code. Plus: You're leveraging a lot of great infrastructure. With HTTP APIs you can just curl into your APIs. Or load balance and proxy them with HAProxy, Nginx, Varnish etc.
persei8 12y ago
Request/Reply pattern makes a poor choice for communication between services - it increases coupling. It doesn't matter much if it comes with HTTP or any other flavour. Again, Jeppe nails it in very detailed post: http://www.tigerteam.dk/2014/microservices-its-not-only-the-size-that-matters-its-also-how-you-use-them-part-3/ http://www.tigerteam.dk/2014/microservices-its-not-only-the-...
- PeterGriffin 12y ago
  The post talks about synchronous communication increasing temporal coupling. There's nothing in sending a request and getting a response that's increasing coupling in a traditional sense, and often there's no much of an alternative anyway, if you want donuts, you'll have to request donuts, and then receive donuts. While I dislike shoving HTTP everywhere for many reasons (reminds me of XML abuse), HTTP is not synchronous, nor asynchronous. It's a protocol sent over a socket. Synchronicity is not the domain of HTTP at all. It's up to the application how it does it. Additionally, the response can always be a blank acknowledgement of the received request. There are very few cases where you just want to go forward blindly without even receiving an ACK about your request at some level (or alternatively, an error), because sometimes things fail.

bgentry 12y ago

Are people typically building their microservices infrastructure on top of a SQL database, or other datastores? I'd be concerned not just about the overhead of managing lots of different (though simple) services, but also the fact that you give up a lot of convenient & useful features that you could get for free with a monolithic application, such as transactions. You either have to avoid needing transactions between microservices, or deal with the complexity of coordinating distributed transactions. That seems like an awfully big hurdle to overcome for a new application, especially if you're a startup that needs to focus on delivering customer value as quickly as possible.

persei8 12y ago
Transactions spanning several microservices violate their autonomy - one service should not lock resources of another. Jeppe Cramon explains it pretty well in http://www.tigerteam.dk/2014/micro-services-its-not-only-the-size-that-matters-its-also-how-you-use-them-part-2/ http://www.tigerteam.dk/2014/micro-services-its-not-only-the...
- PeterGriffin 12y ago
  That's often not practical. Say you're a shop front. If you have a goods purchase service and a goods delivery service, you want to reserve the good (limited quantity) and reserve a time slot for transport (limited number of deliveries a day) before you charge the customer, and make the "commit". And if you'd merge two separate companies into one uber-service, you've just created more problems than you've solved.
  - deleted 12y ago
    [deleted]
  - superuser2 12y ago
    Atomic transactions are one of several strategies for handling this problem, and not always the right answer. Starbucks is a good analogy (http://www.eaipatterns.com/ramblings/18_starbucks.html http://www.eaipatterns.com/ramblings/18_starbucks.html). If Starbucks were transactional, you would have to stand there at with the money on the counter and wait until your drink was finished, then exchange at the exact same time. Even the mental image is ridiculous. In practice, it makes much more sense to allow the system to enter certain inconsistent states and then remediate them. Out of an ingredient? Refund the money. Can't pay? Pull the drink out of the queue, or just write it off. This can involve some cost, but less cost than than the throughput you'd lose by enforcing consistency. For your specific example of a goods delivery service, most take-out restaurants fly in the face of these claims: you can pay the driver in cash when they arrive. They are willing to accept the risk that you made your order fraudulently, won't pay, etc. because it's still better for them to have your business. If you reserved a time-slot or inventory for someone whose credit card is declined, so what? Just un-reserve it. It's not hard to UPDATE a row in a database. The system was in an inconsistent state for 10 seconds. Big whoop. (You might have turned down a legitimate customer, but only if they were consuming the last resource, and if demand is that high, another customer will buy the item.) Notice that Ticketmater and most airlines will hold your seats (i.e. leave the system in an inconsistent state) for up to 15 minutes while you enter your card details. Hell, Ticketmaster can easily reverse a transaction at any point up until the moment your ticket is scanned at the door. So could an airline, and they often do. The classic example of account balances isn't necessarily the case either - banks can INSERT records of individual transactions. Since addition is commutative, race conditions are irrelevant. Balances are then calculated nightly offline by playing back the transaction records. I guess that's a form of locking, but even if it weren't, the balance isn't the source of truth - the transactions are, and the balance can be recomputed. Banks also don't hide the complexities of transaction processing. Your "current balance" is different from your "available balance" and your most recent transactions show as pending anyway. You don't need transactions as often as you think you do.