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

This is just describing Service-oriented Architecture (SOA) -- for a better read, see Steve Yegge's Google Platforms Rant: https://plus.google.com/+RipRowan/posts/eVeouesvaVX



Yes, MAXOS is a variant of SOA. And, service architectures seem to have won the test of time. However, the modern version of service architecture has a very different management philosophy from the SOA of the last decade. The old SOA was to put components in place with a top down design. The new version is designed to evolve with lightweight and bendable protocols, peer-to-peer interactions, and continuous integration.

The old version of SOA focused on defining the protocols and API's that services would use to communicate, from the top down. There was a lot of effort put into standardized object definitions and CORBA and EJB, and standardized protocols like SOAP. The resulting services were put into directories and locked down. That's what made SOA so annoying and cumbersome. It was a lot of work just to set up the plumbing, and then you can't change it to do what you want.

I call the new version "service architecture" because "service oriented architecture" has such stifling connotations. This version uses a variety of protocols which are faster, lighter, and sometimes more specialized. It can include the old RPC protocols, new platform-specific RPC, connection pools, message queues, HTTP-REST, and plain old HTTP. It's not so important to define the protocols up front, because the whole system is always being tested as a unit. Reliability is being created by continuous integration, not by up front engineering and standards. There is little effort to package things into similar code objects. Services from many different languages and platforms co-exist. That's the whole idea.

That said, I believe that services packaging may converge into something portable like Docker containers. As my friend Aaron O'Mullen of Codebox said, a Web service is the new executable.


> The old version of SOA focused on defining the protocols and API's that services would use to communicate, from the top down. There was a lot of effort put into standardized object definitions and CORBA and EJB, and standardized protocols like SOAP.

I think that CORBA and EJB are sort of the institutionalization of the SOA concept, in much the way that rigid, top-down practices like Scrum are part of the institutionalization of Agile.

I don't think original SOA was any more heavyweight, top-down than original Agile; I think people tend to naturally gravitate toward centralized, top-down ways of doing things, producing a natural cycle of "back to basics", followed by centralizing, top-down approaches trying to impose more definition and manageability on the "new" approaches. (And are aided in this by tool vendors, who want people to buy exclusively into their tools rather than have heterogenous environments, for clear commercial reasons.)

There's also new techniques that develop in parallel to the cycle and stop the cycle from strictly being reinventing the wheel, usually, but the basic pattern is largely cyclical.

> Services from many different languages and platforms co-exist. That's the whole idea.

That was a widely touted feature of old SOA, and of earlier (but by now somewhat old) reactions to the way old SOA went as heavily platform dependent services became common in it.


> I call the new version "service architecture" because "service oriented architecture" has such stifling connotations.

That's why the term 'microservices' is being pushed. It would be better to just agree on 1 new term instead of several new terms.




Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: