[INTPenis]

I'm helping a company get out of legacy hell right now. And instead of saying we need microservices, let's start with just a service oriented architecture. That would be a huge step forward.

Most companies should be perfectly fine with a service oriented architecture. When you need microservices, you have made it. That's a sign of a very high level of activity from your users, it's a sign that your product has been successful.

Don't celebrate before you have cause to do so. Keep it simple, stupid.

[dragonwriter]

> And instead of saying we need microservices, let's start with just a service oriented architecture.

I think the main reason microservices were called “microservices” and not “service-oriented architecture” is that they were an attempt to revive the original SOA concept when “service-oriented architecture” as a name was still tainted by association to a perceived association with XML and the WS-* series of standard (and, ironically, often systems that supported some subset of those standards for interaction despite not really applying the concepts of the architectural style.)

[shoo]

Service oriented architecture seems like a pretty good idea.

I've seen a few regrettable things at one job where they'd ended up shipping a microservice-y design but without much thought about service interfaces. One small example: team A owns a service that runs as an overnight job making customer specific recommendations that get written to a database, and then team B owns a service that surfaces these recommendations as a customer-facing app feature and directly reads from that database. It probably ended up that way as team A had the data scientists and team B had the app backend engineers for that feature and they had to ship something and no architect or senior engineer put their foot down about interfaces.

That'd be pretty reasonable design if team A and team B were the same team, so they could regard the database as internal with no way to access it without going through a service with a well defined interface. Failing that, it's hard to evolve the schema of the data model in the DB without a well defined interface you can use to decouple implementation changes from consumers and where the consuming team B have their own list of quarterly priorities.

Microservices & alternatives aren't really properties of the technical system in isolation, they also depend on the org chart & which teams owns what parts of the overall system.

SOA: pretty good, microservices: probably not a great idea, microservices without SOA: avoid.

For anyone unfamiliar with SOA, there's a great sub-rant in Steve Yegge's 2011 google platforms rant [1][2] focusing on Amazon's switch to service oriented architecture.

[1] https://courses.cs.washington.edu/courses/cse452/23wi/papers... [2] corresponding HN thread from 2011 https://news.ycombinator.com/item?id=3101876

[ReclusiveCoder]

That's the right approach. This is what the article suggests:

>> For most systems, well-structured modular monoliths (for most common applications, including startups) or SOA (enterprises) deliver comparable scalability and resilience as microservices, without the distributed complexity tax. Alternatively, you may also consider well-sized services (macroservices, or what Gartner proposed as miniservices) instead of tons of microservices.

[zbentley]

What characteristics define "legacy hell"?

I'm curious, and the specific list of problems and pain points (if--big if!--everyone there agrees what they are) can help more clearly guide the decisions as to what the next architecture should look like--SoA, monolithic, and so on.

[INTPenis]

Try 20+ year of git history. (yes they migrated to git from svn).

The biggest obstacle is changing people's mindsets from legacy programming to modern DevOps workflow. Making them believe it's worth the effort.

[zbentley]

Say more? That sounds like an old codebase, and poor programming practices. What about the codebase and your struggles with it suggests that a rearchitecture is in order? What about it suggests that microservices might be the right solution?

I apologize if that sounds critical; it's not meant to be. Microservices/SoA are often the best available solution given human and technical constraints--I'm not skeptical, just curious.

[INTPenis]

I never said microservices were a solution, I said a service-oriented architecture is a giant leap forwards for a legacy platform.

This whole thread is about how microservices are often abused when they're not necessary, and to clarify my point, I completely agree with that.