Hacker News new | past | comments | ask | show | jobs | submit login

I've had this feeling in some place that 'SOA' is a bit of a dirty word because it connotes a certain style of systems architect, or working like you do in Java or enterprise-scale PHP.

Many monolithic apps would benefit from a refactoring towards that rather than distributing a call stack across the network. The microservices can come later on if there's a need for it. If nothing else, it'll present a clearer picture of how things fit together when you start enforcing boundaries.




SOA also brings up memories of soul destroying ESB's.

I would love a resurgence of discussions about services and how to best build and govern those without always resulting in a focus on the micro versions.

How are people building a modern IT landscape consisting of different services and system?


The problem with ESBs in my opinion is one of tight coupling; all of these distributed systems that know about and depend upon each other. The solution to this is to loosen coupling whilst formalising interfaces/contracts/schemas, with a design that enables versioning and mandates graceful evolution. The modern version of ESB is an event based (note: this does not necessarily and probably does not mean event sourced) architecture built upon a distributed, append-only log that is ideally fed directly from a database transaction log.


ESB is new to me but just casting a glance on it makes me think... Kafka.

You can't avoid the centralisation unless you want infinite repetition.

The human spine is composed of multiple vertebrae and forms a consistent network with the brain and CNS and the rest of your body. The spine itself is the centralism, no matter how much you separate the bones into vertebra.

A service bus is basically putting all of your eggs into one wire. Or so it seems... it's so easy to strawman yourself to microservices.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: