ThatConference 2016 – Microservices Minus the Hype: How to Build and Why
For my first session on Microservices, Mark Heckler (@mkheck) was delivering the presentation. I’ve never directly built or worked with microservices but I believe my future projects will involve microservices in one form or another – and preferably sooner rather than later. I felt compelled to visit this topic as I’ve always thought of microservices as SOA but much smaller in size and larger in quantity, but I definitely needed more information.
Mark brought up the Play-doh principle which I wasn’t aware of but I believe it’s accuracy in my own experiences:
“It’s always easier to combine small, self-contained code or data than it is to decouple code or to parse data”
This play-doh principle, while seemingly silly is remarkably true in my experience. I don’t think it’s a pillar of microservices, but the sentiment is definitely evident within the microservice architecture and design. Another favorite quote from this topic was pretty simple: “Monoliths never stay small”. Gah, he’s right.
There was some nice comparisons pros/cons format between SOA and microservices which definitely helped me build a better picture in my mind. One of my key takeaways was his gains and losses analysis:
Gains
- Scalability
- Efficiency
- Effectiveness
- Velocity
- Optimization
- Interoperability
- Availability
- Independence
- Cost savings
- Increased revenue
- Less complexity*
- Control
Losses
- Greater Complexity (at macro level)
- Better architects needed
- Single data repos for organization
- Change.. seriously
- Greater complexity – it bears repeating
I’ve highlighted two as I didn’t even think about the architects needed to design everything. For many monolithic applications, I thought the architecture was just as complicated but breaking things down further into microservices would in fact make things more complex, which Mark clearly emphasized (twice).
As for the single data repos for the organization, I’ve been so entrenched in a single data repo model and microservices clearly break that model. Is it good or bad? Clearly, it depends. The benefits seem to outweigh the negatives, but unless you have tools in place to help piece together everything, it sounds like more work to me – which is fine. But the loss of a single repo means more work to tie everything together and is another aspect of the complexity that Mark highlighted.
It was a very interesting and helpful presentation. Mark made a lot of interesting points of the positives and the negatives which so few people are willing to discuss regardless of whatever technique, tech stack or tool. So far, Mark has not put up the slides on his site, but I’ve sent him a tweet asking if he would be willing to do so.
