4 ms·

ESB is dead, long live ESB. I think i’m getting old... was telling coworkers that their fancy micro services existed 15 years ago in the form of EJB and servic

ESB is dead, long live ESB. I think i’m getting old... was telling coworkers that their fancy micro services existed 15 years ago in the form of EJB and service bus was a thing. And look, here it goes again

SomeHacker44 7y ago
Or 25 years ago building things on Tibco Rendezvous...
hestefisk 7y ago
Except you had to use CORBA or JMS to invoke them, which was pretty frustrating and expensive computationally.
- segmondy 7y ago
  Was it? Do you think REST/gRPC will be exciting in the 90's? I think it was timing. Hardware and network were super slow back then.
  - awinder 7y ago
    Agreed completely, programming patterns are just like anything else, timing is everything. I thought that ESB pattern was cool in the early 00s, today that pattern has touched off and evolved a robust ecosystem. It’s totally fair to rebrand it as a descendent of ESB, it’s fair to point out the lineage, but ecosystem evolution + pattern refinement is a distinct thing to get excited about.
- devonkim 7y ago
  CORBA and the object mapping model (similar to the issues of ORMs) is what led to the dreaded ClassCastException problems that required every service to re-deploy at once which was completely broken and indicative of the architects being engineers that hardly ever touched day to day production. The transition off of syncing object representation in a monolith and God Service Schema / Registry was necessary but by that point we had moved on to SOAP and screwed that part up once again by needing to re-deploy JARs yet again constantly and out of sync and also being unable to separately deploy and route components off which led to either more ditch digging via OSGI or by going to REST APIs... or if you didn’t get here you used earlier incarnations of object and message serializations with protocol buffers. Only with these painful lessons have we as an industry learned how to actually decouple our services’ business boundaries well enough to call them decoupled, scalable services.
  - LaserToy 7y ago
    Did we learn the lesson? Protobufs are getting traction, and some rising star companies started using them for data related purposes. The problem they are facing - change in the protobuf is not automatically reflected in you data schema (not like with avro), you have to recompile and redeploy pieces of your stack + orchestrate deployment so data is not lost in processing. It can be solved easily with avro, but “we want to use protos, Bla Bla Bla”
    - paulddraper 7y ago
      Protobufs are relatively good with backwards compatibility, no?
      - devonkim 7y ago
        Thrift, ProtoBufs, and Avro solve the messaging compatibility layer problem at least (optional fields in a schema are all you need 99%+ of the time) and so far nothing out there has managed to solve any data schema incompatibility problem automatically because that’s pretty much intractable, but providing tools that make finding problems earlier certainly helps with the reality of SOA in its various incarnations.

SomeHacker44 7y ago

Or 25 years ago building things on Tibco Rendezvous...

hestefisk 7y ago

Except you had to use CORBA or JMS to invoke them, which was pretty frustrating and expensive computationally.

segmondy 7y ago
Was it? Do you think REST/gRPC will be exciting in the 90's? I think it was timing. Hardware and network were super slow back then.
- awinder 7y ago
  Agreed completely, programming patterns are just like anything else, timing is everything. I thought that ESB pattern was cool in the early 00s, today that pattern has touched off and evolved a robust ecosystem. It’s totally fair to rebrand it as a descendent of ESB, it’s fair to point out the lineage, but ecosystem evolution + pattern refinement is a distinct thing to get excited about.
devonkim 7y ago
CORBA and the object mapping model (similar to the issues of ORMs) is what led to the dreaded ClassCastException problems that required every service to re-deploy at once which was completely broken and indicative of the architects being engineers that hardly ever touched day to day production. The transition off of syncing object representation in a monolith and God Service Schema / Registry was necessary but by that point we had moved on to SOAP and screwed that part up once again by needing to re-deploy JARs yet again constantly and out of sync and also being unable to separately deploy and route components off which led to either more ditch digging via OSGI or by going to REST APIs... or if you didn’t get here you used earlier incarnations of object and message serializations with protocol buffers. Only with these painful lessons have we as an industry learned how to actually decouple our services’ business boundaries well enough to call them decoupled, scalable services.
- LaserToy 7y ago
  Did we learn the lesson? Protobufs are getting traction, and some rising star companies started using them for data related purposes. The problem they are facing - change in the protobuf is not automatically reflected in you data schema (not like with avro), you have to recompile and redeploy pieces of your stack + orchestrate deployment so data is not lost in processing. It can be solved easily with avro, but “we want to use protos, Bla Bla Bla”
  - paulddraper 7y ago
    Protobufs are relatively good with backwards compatibility, no?
    - devonkim 7y ago
      Thrift, ProtoBufs, and Avro solve the messaging compatibility layer problem at least (optional fields in a schema are all you need 99%+ of the time) and so far nothing out there has managed to solve any data schema incompatibility problem automatically because that’s pretty much intractable, but providing tools that make finding problems earlier certainly helps with the reality of SOA in its various incarnations.