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.<p>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
Are people typically building their microservices infrastructure on top of a SQL database, or other datastores?<p>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.<p>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.
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).
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.
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.<p>I've started a little library in Python for writing small services. It leverages nanomsg. link: <a href="https://github.com/walkr/nanoservice" rel="nofollow">https://github.com/walkr/nanoservice</a>
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.
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.<p>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.<p>I really like the microservices architecture because it just feels efficient.