When Sam Newman's book (280 pages) on microservices was released in the first month of january 2015, I was already reading a preview edition for some weeks. Having the book as paper version next to my desk, let's me open it once in a while to find a good example for a concept or a piece of software for my microservices day work.
The book is not about indepth knowledge about every part of hosting lots of little connected systems, but gives such an awesome overview about all parts, that I can encourage everybody maintaining or creating systems and libraries to read this book!
He also talks about somehow non-technical things like "Conways Law" and reminds that nomatter how much you automate all the things (and you really should!), it is important to reason about how people working with this system and developing this system do interact with this, hence they are humans!
I am enforcing semantic versioning for years, but it was an interesting read how versioning works in Newman's head for microservices. I also recommend reading the book Continous Delivery on this matter, because those two combined make a very good fit when you think about how to version and version control your distributed system.
One good quote for microservice adaptors, if you don't know the domain, yet, but start from scratch:
"Greenfield development is also quite challening, [...] consider starting monolithic first and break things out when you are stable."
Another quite important topics for me are testing, monitoring and alerting. With continous delivery from git's master to the test system and running semantic monitoring to ensure everything works, did work for me in past years well. I can see how immutable servers and releases make this much more predictable. The destinction between Unit-Tests, Service-Tests and End-to-End-Tests is very reasonable and helped me to figure out, which pieces of tests are written by our QA and which one is written by our developers. Additionally it helped us to reason about when a test needs to be run: on build, when building dependent services or once in a while.
"Change is inevitable. Embrace it."
Since I am working with a big team on such microservice structured project right now, these are the important parts, which make our daily work predictable and easy:
- Automate all the things (necessary for development and QA): builds, checkstyle, ci setup, deploy to testsystem
- Use github's/gitlab's PR/MR mechanism to enforce continous code review
- QA gets a new version as soon as something was merged in master
- Have and maintain a CHANGLOG.MD for ever service and library
- Versioning should work automatic (see my maven versioning post)
- Releasing a new version to production or stage is just a matter of saying, which version should go live and does not involve any new builds
- Have a dashboard with build status
- You will notice if you need a new microservice while building another one. No need to optimize prematurely.
- You will notice if you need to merge a microservice (back) into another one. No need to worry if splitting up was to early or to late.
I'll close with another quote of the book: "Change is inviteable. Embrace it."
If you haven't bought this book, yet: do it!
