Creating a Microservice? Answer These Questions First
datawire.io
datawire.io
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!
http://martinfowler.com/bliki/MicroservicePrerequisites.html
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.
1: https://en.wikipedia.org/wiki/JBoss_Enterprise_SOA_Platform
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).
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?
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 ;)
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.
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/).
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.
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.