Reply to post: Re: I'd be interested...

Microservices guru warns devs that trendy architecture shouldn't be the default for every app, but 'a last resort'

SVV Silver badge

Re: I'd be interested...

This sums up some of my problems with the current microservices hype. At the moment it is focused on quick development, quick deployment and other flavours of aqile-infused quickness. Little or no attention is paid to the two real-life problems of this approach. Number one is the primary importance of interfaces. Designing these carefully, with an emphasis on large-grained objects rather than small grained individual parameters has always been one of the key benefits of OO languages (eg you pass an Address object, rather than individual address fields, so that when you need to add stuff to an address format you don't need to change all the interfacing code, just the address class.). Service based systems take you back to the days of functional programming where functionality change meant interface change too - and changes to all the calls to that function too.

The second is dependency management. Start seperating code out into completely isolated services, and sooner or later you are going to hit the problem where version x of one service is dependent on version y of another. This needs a way to be defined strictly if you want to avoid descending into unmanageable chaos, otherwise you're reliant on "run the tests and hope for the best".

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

SUBSCRIBE TO OUR WEEKLY TECH NEWSLETTER

Biting the hand that feeds IT © 1998–2020