Microservices - 72 resources • Hacker News Board

Re: Microservices - 72 resources

#21

Post by persei8 » Sun, Jul 06, 2014, 9:01 PM UTC

PeterGriffin wrote: post #17

bgentry wrote: post #12

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…

The point of a microservice is you can build it on anything, and change what you built it on over time, without changing its interface. As for your concerns... you know how every time some good idea pops up people have to ruin it by pushing it to ridiculous extremes? Case in point, microservices. You don't have to make things so modular that you give up SQL, transactions, or anything. With experience you'll naturally…

> If the entities in one service are not in strong relationship with one another, it's a sign you can split them in two services. But if two microservices talk to each other so extensively, that the service boundary is becoming a bottleneck, it's a sign that they should be one service.

In other words it's best to break down services by Bounded Contexts.

Re: Microservices - 72 resources

#22

Post by persei8 » Sun, Jul 06, 2014, 9:28 PM UTC

bgentry wrote: post #12

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…

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...

Re: Microservices - 72 resources

#23

Post by persei8 » Sun, Jul 06, 2014, 9:47 PM UTC

InfiniteRand wrote: post #11

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…

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-...

Re: Microservices - 72 resources

#24

Post by persei8 » Sun, Jul 06, 2014, 9:51 PM UTC

justincormack wrote: post #14

bgentry wrote: post #12

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…

It seems to be that, roughly, if a service is doing joins on a datastore it might not be a microservice any more...

Service owns it's data. Other services can't access this data directly. Within service, on it's data, you can do as many "joins" as you want.

Re: Microservices - 72 resources

#25

Post by stevepike » Sun, Jul 06, 2014, 9:56 PM UTC

auxbuss wrote: post #20

stevepike wrote: post #5

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).

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 fundamen…

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.

Re: Microservices - 72 resources

#26

Post by persei8 » Sun, Jul 06, 2014, 10:02 PM UTC

bgentry wrote: post #15

justincormack wrote: post #14

Earlier quoted context omitted.

It seems to be that, roughly, if a service is doing joins on a datastore it might not be a microservice any more...

Yeah, that makes sense. It's not just joins, though. Consider the transactional nature of something like the signup process, where you want it to either succeed completely or fail completely. If you're creating objects independently in multiple microservices during signup, and one of those fails, you've then got to deal with rolling back any changes that have already completed with other services. Maybe traditional w…

amazon.com is pretty traditional web application and they've been doing SOA for ages.

Re: Microservices - 72 resources

#27

Post by persei8 » Sun, Jul 06, 2014, 10:04 PM UTC

stevepike wrote: post #5

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).

If I could recommend _just_one_ resource from that list, it would be http://www.tigerteam.dk/talks/IDDD-What-SOA-do-you-have-talk...

Re: Microservices - 72 resources

#28

Post by bgentry » Sun, Jul 06, 2014, 10:41 PM UTC

persei8 wrote: post #26

bgentry wrote: post #15

Earlier quoted context omitted.

Yeah, that makes sense. It's not just joins, though. Consider the transactional nature of something like the signup process, where you want it to either succeed completely or fail completely. If you're creating objects independently in multiple microservices during signup, and one of those fails, you've then got to deal with rolling back any changes that have already completed with other services. Maybe traditional w…

amazon.com is pretty traditional web application and they've been doing SOA for ages.

Right, but they also have their own internal Paxos service to manage distributed transactions, and they have thousands of engineers and thus can deal with the increased complexity.

As I said in my original comment:

> 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.

I'm really curious to hear if/how others are able to leverage the benefits of microservices yet avoid the perceived complexity that goes along with it.

Edit: I was reminded that Pat Helland (from Amazon) wrote a famous paper "Life Beyond Distributed Transactions" which gives some great guidelines on how to build an SOA that avoids reliance on distributed transactions: http://www-db.cs.wisc.edu/cidr/cidr2007/papers/cidr07p15.pdf

I still think this is clearly quite a bit more complex and harder to develop than i.e. a single Rails app, so I'm still very curious to hear when this approach starts making sense.

Re: Microservices - 72 resources

#29

Post by notastartup » Sun, Jul 06, 2014, 10:43 PM UTC

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.

Re: Microservices - 72 resources

#30

Post by PeterGriffin » Sun, Jul 06, 2014, 10:45 PM UTC

persei8 wrote: post #23

InfiniteRand wrote: post #11

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…

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-...

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.