If you are thinking about going down the microservice path, then do yourself a favour and read Building Microservices (O'Reilly) [1]. It is a little wordy but lays it down pretty well. I'm not affiliated with them, but do heavily research this space, and the larger ecosystem. I found it pretty well rounded.
I'm not sure this articles 10 question list really covers the scope of what microservice means. For reference, I'm not talking about ~5 microservices here (as that might be trivial), but am thinking in the scope of ~50-100+. In that you should have a pretty good reason to adopt them re: your team size and scale of operations. You can see an increased rate of deployed changes, performance boosts, and freedom to choose languages that fit the problem, but it comes with additional operational complexity. In that, you will pay an upfront tax for using microservices. So, you really need to think about asking yourself these types of questions (and the ones in the article).
- How and where should you break things into microservices (if monolith)?
- Who should own the microservice? What does this mean in terms of coding, testing, deploying, ops issues, etc?
- You will need team buy in. A switch could mean months of work. The upside is massive but you cannot push this on them.
- How do you deal with things at the datastore level (can/should two microservice access the same table space)?
- How are you going to deploy microservice via CI/CD pipeline into your production env?
- How do microservices communicate (RPC, API, etc)?
- What type of metrics do you build into your microservice?
- How can you trace requests when they hit multiple microservices?
- You'll need to beef up your operations tools to manage these microservices too. What does that look like?
These are pretty fundamental things you need to think about and the book does a pretty decent job at explaining it.
I'll second that, can't recommended the book enough. It will tell you exactly why and when you should go down the microservice rabbit hole (at this point). I'm saying at this point because there are still many angles to this (actually by paradigm) and lots of tooling surrounding it which are not quite there yet (including most prominently docker & co).
Don't fall for the admittedly great modern devops/open-source marketing.
I've been doing both application development as well as good-old systems administration (xen, jails, openvz) for many years and believe me this stuff is still very resource intensive even with the help of other similarly experienced peers readily available. We are literally talking google-level infrastructure architecture, which of course is both bad (setup time) and good (much more flexible and often "simpler" to grasp when the whole flow is established).
While I'm still not at the product stage with my two microservice projects started in August and September (both explicit microservice customer requests, mind you) a friend of mine meanwhile has single-handedly been building two monoliths over the last couple of months. He's been leveraging the still undeniable king-of-web-app-productivity-combo of rails/heroku and is about to move on to his next project while his customers are down the "let's polish some more" beta publishing-angst.
Microservices are fun and they are an important development in our field for many use-cases but be an engineer and pick the right tool for the right job, already - educate your boss, peers or customers about the importance of seeing things more objectively!
Also, don't succumb to the macho "You must be this tall to use microservices. OK, challenge accepted!" like I have to admit to have fallen for myself (I readily obliged to going forward with the tasks at hand) - the cards are largely stacked against you, most certainly when you are alone or not well connected!
Distributed systems are hard, and building a microservice SOA that is functional is damn hard.
I feel like a lot of people are on the hype wagon of Docker and Microservices right now, they arnt building products, but instead bike shedding with technology decisions which are often not fit for their application. A lot of the people reference to Netflix, Amazon etc, who are companies who had real issues, real traffic, and real products and a real reason why they evolved into a microservice SOA.
Other people reference half finished non production implementations, or people like Hailo who took 2 years to build a technically impressive MicroSOA, replacing their PHP/Java stack, whilst their product stagnated and business declined.
I'd like to plug an open-source project that I've been working on here - https://artillery.io - as it relates to point (6) in the article. It's a load-generator, and while it's not microservice-specific per se, it's a lightweight tool that's quite easy to use and it lends itself well to being used frequently, which is great if you want to start doing load-testing early on during development (which is something I've started doing and had good results with). It has HTTP and WebSocket support out of the box, with AMQP coming in the next release (which is often employed as microservice glue).
I think of microservices as an implementation of SOA. Guess that is not that helpful, but it's almost like a battle tested guide on what the best way of implementing SOA is via trial and error. If you look at how startups are using microservices today, you will find almost a blueprint or common theme coming out. Use an API, embedded metrics in the microservice, how to do monitoring, tracing, use CI/CD, app+dependancy packaging, operations tools, etc.
FWIW, it seems early SOA placed a lot of emphasis on the bus and the middleware[1], with the problem being solved having more to do with enterprise governance[2], not one of software architecture. It seems to me, true scotsman and all, that modern micro services architecture has emerged from a first-order attempt to solve actual problems around both scaling vertically and collaborating on large systems in large organisations.
2: "OMG how do we keep track of all the stuff running on all the servers? Multiple versions, multiple languages, multiple OSs? This sounds really scary, no, leaving it to the nerds is not an option, think of the BUS COUNT!" (caricature).
We use NServiceBus, and Microservices for a lot of stuff and its really helped development. It handles retries(for network unreliability), transactions, and monitoring for us. Generally most of the issues of distributed systems.
Thanks for the info, very much appreciated. My job is basically to import best practices from good tech companies into an ancient silo'ed giant dev shop. Any idea where I should start for finding best practices with microservices?
I've read the Oreilly book, but I'm not seeing any significant difference from how we run things. Is this eXP vs. Agile all over again, or do I need this?
If you are not hitting one of the -- 1) slow rate of deployed changes, 2) app performance is sluggish, or 3) freedom to choose language<->problem issues, 4) poor resource utilization across a fleet of boxes, then I don't see the rush to change anything. In that one of these issues would need to justify the investment to make the switch. Normally people are looking for a solution to one of these really broken/festering issues and they see microservices as a solution. For example, maybe your code deploys are super slow due to developer contention and a competitor is going to kill you -- maybe it's worth a look. Or, maybe you are blowing 100k / month on cloud servers, that if only you could get better utilization, you could save all that money. You get the idea.
Here are some pretty good war stories told by people in the trenches. Highly suggest watching these talks by TellApart [1] & Wunderlist [2]. Both talk about the pain points of why they moved to microservices. FYI - Youtube 2x speed is your friend ;)
In my opinion they are the same thing, unfortunately the term SOA has gotten a bit poisoned.
SOA mostly refers to "Enterprise SOA" now and Enterprise SOA has skewed many of the decoupled principles of SOA.
For example Enterprise SOA heavily focuses on middleware, of course all these middlewares are vender specific and create vender lock-in. Microservices mostly focus on just HTTP for their middleware.
Another example of Enterprise SOA is using SOAP and most people configure their SOAP services to have very rigid contracts. So if you update your SOAP service schema to add a field, even if none of your consumers need that field they all need to update their consuming schemas which is very tightly coupled. Microservices should focus on consumer-driven contracts for services.
Language evolves and I would say a lot of people now consider SOA to mean heavy middleware and SOAP with strong contracts creating the new term "microservices" help to differentiate.
We've spent a lot of time with a lot of different companies learning about microservices and SOA. There are a ton of definitions, but the one that we've settled on and is simple is that it's an architecture that supports distributed development of distributed systems. That's what's new (I wrote a blog post on this: https://datawire.io/what-are-microservices-a-practical-defin...).
> On the other hand, verifying the quality of a whole application that is composed of many microservices can represent a significant amount of testing complexity: instead of running a single command to test the code running in one process, a large number of integrated dependent components must be running first, verified as healthy, and stay running throughout the tests.
This was very likely already the case for the monolith as well. It likely depended on databases, caches, queues, etc. The solution is the same in both cases: an orchestration solution (such as https://docs.docker.com/compose/).
Maybe. But, setting up the monolith locally is documented in one README, and you've probably already set it up. And, depending on how big your org is, the monolith probably has a lot fewer different databases and caches and queues than all your various microservices built by different teams with different preferences over the years.
Obviously there are solutions to this problem, like you pointed out. But ease of integration testing - both manual and automated - is one thing you often give up when you go down the microservices path.
Refactoring occurs in similar ways: with strong interfaces between each of your microservices, you can change the implementation of your individual microservices (e.g., keep the payment processing microservice interface the same, but change the internals). Or you can also change which microservices get invoked (e.g., switch from v1 to v2 of a given microservice).
Yeah, but you do prevent refactorization across service boundaries. I feel as if you should really think twice before cementing your architecture like that.
Can you give me an example of why you can't refactor across service boundaries? In my mind, refactoring a service interface is the same as refactoring the interface (API) of an object. It's real work (tm) but definitely do-able.
I would imagine it's more a question of risk. If you're changing an interface inside your application boundaries, you can figure out pretty easily where the changed API is called and what you've got to do to fix it. If it's something on the edge of your microservice that is public, so who knows what unknown bits of code are open to breakage if you change your API, that's harder to track down and fix.
I don't know a ton about actually implementing this sort of thing, but from the outside looking in, this seems to be a common reason for API versioning.
I'm not sure this articles 10 question list really covers the scope of what microservice means. For reference, I'm not talking about ~5 microservices here (as that might be trivial), but am thinking in the scope of ~50-100+. In that you should have a pretty good reason to adopt them re: your team size and scale of operations. You can see an increased rate of deployed changes, performance boosts, and freedom to choose languages that fit the problem, but it comes with additional operational complexity. In that, you will pay an upfront tax for using microservices. So, you really need to think about asking yourself these types of questions (and the ones in the article).
- How and where should you break things into microservices (if monolith)?
- Who should own the microservice? What does this mean in terms of coding, testing, deploying, ops issues, etc?
- You will need team buy in. A switch could mean months of work. The upside is massive but you cannot push this on them.
- How do you deal with things at the datastore level (can/should two microservice access the same table space)?
- How are you going to deploy microservice via CI/CD pipeline into your production env?
- How do microservices communicate (RPC, API, etc)?
- What type of metrics do you build into your microservice?
- How can you trace requests when they hit multiple microservices?
- You'll need to beef up your operations tools to manage these microservices too. What does that look like?
These are pretty fundamental things you need to think about and the book does a pretty decent job at explaining it.
[1] http://shop.oreilly.com/product/0636920033158.do