|
|
|
|
|
|
by benjaminwootton
4052 days ago
|
|
|
I wrote this article some time ago and it has generated hundreds of inbound emails asking me about the risk points associated with Microservices: http://highscalability.com/blog/2014/4/8/microservices-not-a... Building Microservices does have a real premium - you are building a complex platform which needs specialists skills and additional work to make happen. The payback of that premium comes later, in the ability to then iterate and change the system easily and quickly. The problem comes when people think they are building an application and not a platform which will support them for the next 5+ years. I try to hammer this point home to our clients who are looking at Microservice architectures. |
|
|
In my experience that "iterate and change the system easily and quickly" simply doesn't end up being true. That is the bait, but then comes the switch. Once you have a real system, heavily interdependent, the cost of changing things starts to go up greatly, and your ability to cleanly describe a working system becomes challenging. Answering simple management questions like "OK, so if we change X, what could break?"... "We should send out an email to all the teams to ask!" (ugh)
The problem is that for most significant changes to a component -- there are changes to the interface to that component. So you have 'the choice' -- (1) Maintain this interface forever or (2) Ensure all the teams transition off it by X date, via a deprecation system. Both work, and most companies seem to use a mix of both, they strive for (1) until it gets insane, then they do (2) and force everyone to upgrade to X version by Y date.. rinse and repeat.
We are currently doing the "fat binary" cookie cutter system. Our deploy is a single binary that does "all the things". There is a lot to like about this system. Easy to manage and role back. Compile time checking, including additional tools for static analysis, etc. No network overhead on making local calls. You know and can clearly describe 'the system', it isn't in some continuous flux state. Due to compiling time checking and static analysis you can maintain 'one truth' and when you upgrade a component, you can go into all the callers and update them, so you don't have to maintain that old interface. You can scale decently vertically not just horizontally, which at times is a far more efficient way to scale. Overall, it has made us able to move much faster because it gives us a lot of confidence in what we are shipping, and a sense of safety in that we can quickly go back to what we had.