I know microservices have passed the excitement phase of the hype cycle, but they're not useless. One of the most enjoyable systems I've worked on was a microservice architecture.
That said, I'm going make some wild inferences about what you were getting at in ordet to say that I agree that a microservice architecture is probably a solution in search of a problem in most cases. And, even in the cases where it is a good option, I can see all sorts of ways to mess up the implementation. The article is right; the trickiest things to get right about microservices are actually organizational issues, not technical ones. My hot take is that dev teams who are considering adopting microservices should take a serious look at how much ability they have to influence the org chart and inter-team and inter-departmental communication. If management is strictly something that happens to them, I would not give them stellar odds of achieving sustainable success with microservices. Perhaps some other form of SOA, but not actual microservices.
I wouldn't underrate the technical issues. To really make it work, you've gotta get the tooling right, so you're not writing and maintaining plumbing (logging, tracing, runtime config, networking, deployment, API layer, repository, etc etc) for every single microservice, all in their little bespoke ways. I once decommissioned a microservice after noting that the LoC of all its plumbing and config outweighed the actual logic 5:1. Pushing that plumbing to the background, so it can be managed as a cross-cutting concern, isn't so easy.
> Hearing some places just have one giant database where all teams can add and remove columns is... Kind of scary to me.
Are you talking about Bank of America? My impression from the interview was that it is not a free for all but rather all teams are equal but some teams are more "equal" than others (compliance). I still don't get why they need write/execute access. I would be OK with other teams having read access to my database.
There was a discussion the other day about using views as an external interface to a "service" so basically we maintain rest, gRPC, or whatever but if other teams just need read only access to our data, we can expose a view to them
Assuming people will need reports that cut across team/microservice boundaries, all that data has to end up in one common place, possibly a data warehouse. At which point, other teams can still add and remove columns and break your reports.
Well, a data warehouse is one thing. I have heard of them just having a single live database that everyone hits. For all uses.
Edit: in contrast, I don't want anything about a user, except their id in a table for most features. Hearing of free for all's on data makes me question how they protect payment or just general private data.
That said, I'm going make some wild inferences about what you were getting at in ordet to say that I agree that a microservice architecture is probably a solution in search of a problem in most cases. And, even in the cases where it is a good option, I can see all sorts of ways to mess up the implementation. The article is right; the trickiest things to get right about microservices are actually organizational issues, not technical ones. My hot take is that dev teams who are considering adopting microservices should take a serious look at how much ability they have to influence the org chart and inter-team and inter-departmental communication. If management is strictly something that happens to them, I would not give them stellar odds of achieving sustainable success with microservices. Perhaps some other form of SOA, but not actual microservices.