[jayd16]

If you need to keep track its probably too late. What makes them services is that they should be able to be deployed without a bunch of orchestration of other services. You can solve this by having backwards compatible apis.

That said, to know what changes would actually break things you'd ideally have a suite of tests.

[giantg2]

"If you need to keep track its probably too late. What makes them services is that they should be able to be deployed without a bunch of orchestration of other services."

If only you could tell my bosses/architects that. They won't listen to me.

Edit: why downvote?

[kjeetgill]

Quick counterpoint:

Just because you should be able to release without orchestration doesn't mean you shouldn't be able to watch and track things.

You shouldn't have frequent breaking changes but you should still have the tools to manage when you do.

[giantg2]

I'm not sure what your counterpoint is in reference to. I didn't see anything about tracking or recovery from breaking changes.

[lowbloodsugar]

>If only you could tell my bosses/architects that. They won't listen to me.

Then leave and go somewhere where they will. I wasted too much of my life trying to "change things from within", but I finally learned the lesson. If you have no authority but are held accountable, then GTFO.

[edoceo]

I'm not a downvoter but maybe its cause "they wont listen"

my theory is your presentation is not compelling. Was your CBA clear? What risk/reward metrics did you highlight?

[giantg2]

I'm a midlevel dev at a large company. I don't even have access to make a presentation to the true stakeholders. I can only make suggestions to my lead/boss and have them move it up the chain. On a side note, I've tried moving up th chain when I felt appropriate, but apparently a SQL injection vulnerability with full schema level privileges that was not being prioritized for remediation was not important enough to waste my department head's time.

Sometimes they take my suggestion, sometimes they are already working on it behind the scenes, and sometimes they go nowhere. In this case, they are already measuring most of the metrics like cycle times and mean time to recovery, etc. They already stated that they want microservices and have been building them out. The problem is that they implement it wrong and have no interest in re-architecting. Many of the apps are rewrites of legacy apps. Instead of evaluating the underlying business process, they just want us to build it the same in the new tech but use "microservices". The problem is that some of the business process was designed around the restrictions of the old technology or old industry norma. We should be evaluating the business process before building the technical system, otherwise we will continue to bake in these old constraints and not fully leverage the capabilities of new technology.

Edit: looks like I made someone angry since this is downvoted too.

[ethbr0]

Meta comments tend to get downvoted. Try editing the complaints out?

[giantg2]

Oh, I see.

[jupp0r]

Time for a job change? Lots of red flags.

[giantg2]

I've thought about it. I have no local options and my wife won't move. My remote options are very limited based on the stacks/languages that I have experience in.

[brianwawok]

So you have few options. Work on more? Pick up another stack. Do some weekend consulting in a new framework. Better yourself. By being stuck in the only 1 job you could possibly work for, you are just delaying the mess that happens when they close down / get bought / you get fired. The best part of programming is you can teach yourself almost anything, especially if you have previous experience to build on.

[acoard]

>What makes them services is that they should be able to be deployed without a bunch of orchestration of other services.

True, but you absolutely should still be versioning/tagging your releases for each service. It's not to provide sophisticated orchestration; but just to know each of your releases and be able to roll back to them.

Also I'll point out that some loose coupling between services is unavoidable even in the best case scenario. Sometimes breaking changes happen, or new features need to be taken advantage of. This necessitates some level of (perhaps ad-hoc) "orchestration." If you add a new feature to a microservice and rely on it elsewhere, there's an implicit dependency to that version (or later) of the microservice now.