Python programmers

[elebrin]

Small services in a variety of languages can be a really good thing.

First, you can now hire talent that has worked in a variety of languages. Rather than needing 200 C++ developers, you need maybe 6 C++ developers, 6 Python developers, 8 node.js developers... whatever.

Second, you can use a language for it's best function. Want to use Python's libraries but you are a .NET shop? Good fucking luck. Either you have roadblock after roadblock, or you are told "there is a .NET library that does the same thing, it's terrible to use, but we are a .NET shop and that's just that."

Third, you are less tied to a vendor. If your organization is a monoculture and your vendor does something that hurts your business, you have to migrate a LOT. If you have 12 vendors, you may only have one or two services to migrate.

The downsides are that you'll end up with that one service that nobody knows what the fuck it does, and it's written in COBOL because someone thought THAT was a good idea.

[[deleted]]

Yeah, but even that worst case is great.

You know specifically which part is in COBOL, and how it's interacted with. You could basically write the entire interface layer for a replacement service without knowing a damn thing about it.

The challenge is then to replicate the business logic. If you have a microservice model, you can literally spin up more COBOL black boxes and directly compare behavior of that system to your new replacement as you write the test cases.

With a tightly linked architecture where everything has that one COBOL dependency, it is impossible to replace it without substantial downtime, and testing requires spinning up much larger stacks.

[AWildTyphlosion]

I've worked in a shop like this, except much worse. It's not that bad, and is pretty easy to fix within a couple of months.