3 ms·

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-depl

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.

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.