DEV Community

Discussion on: Small-scale microservices in the wild (1): Anachronistic monoliths

bizzibody profile image
Ian bradbury • Edited on

I don't have any problems at the moment. It was just a comment from previous experiences.

But to add more detail....

Lets say you have a service, S1, that is provided by a division of the business D1 and used by divisions D1 and D2.

Now suppose that D2 needs a new api end point that provides an alternate format of data, or some other change to the service S1.

Suddenly D2 need to get D1 on side and persuade them to make the change they need.

D1's budgets and priorities are unlikely to be aligned to D2.

This can be the biggest problem.

Thread Thread
kr428 profile image
Kristian R. Author

Ok, this is pretty much what I thought. The only reason we didn't completely get lost within this is a mere matter of (lack of) size. Asides that, it shows rather well in my opinion that introducing changes such as DevOps, microservice architecture and the like will never really work out if they are limited to the technical staff and leave out management teams and team objectives. This seems a way more complex and difficult task to do well...

Thread Thread
bizzibody profile image
Ian bradbury


There are 2 groups of people that are a must to achieving an SOA.

a] An active and respected Technical Architecture Group
b] Clear governance bodies that oversee the Services and applications

If you have both of these groups (and the technical knowhow) then SOA can be achieved in a controlled and planned manner*.

  • Even then it is bloody difficult
Thread Thread
kr428 profile image
Kristian R. Author

Yes, that seems a valid approach that could work. Or, another approach somewhere in between DevOps and "Agile":

  • Make all these teams responsible (technically, economically) for the service they offer.

  • Give them some "manager", something like a Scrum Product Owner maybe, to do the coordination of which changes need to be implemented both in responding to "customer" request (with "customers" mostly being other teams) and in responding to issues found in operating the service.

  • Make sure these structures are known well internally so people know who they have to talk to in order to get what they need.

That's the road we're at the moment trying to take, unsure how well it will work. So far we have at least seen this "not fail" with companies around, though of course it has more than just a few pitfalls. At the moment, I am still watching and observing people who try to do right this, especially having the question of technical governance in mind as I still do think this is an approach that only works for a very specific kind of application environments - or companies. Not even talking about cultural changes in a company when trying to establish something like that after having been in operation for a couple of years... ;)