

Matrix of Services - espinchi
http://www.continuousagile.com/unblock/ea_matrix.html

======
cjbprime
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](https://plus.google.com/+RipRowan/posts/eVeouesvaVX)

~~~
asinglenet
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.

~~~
dragonwriter
> 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.

------
drtse4
"Matrix of Services, which I will call MAXOS, is the secret weapon that
Silicon Valley is using to disrupt and destroy competitors."

I think i will stop here, thanks.

~~~
AVTizzles
Not so secret?

~~~
drtse4
Yep, and too many useless hyperboles in one sentence.

------
platz
latency - how do you build a platform with high performance if every customer
request has a network of n services to traverse for every operation?

~~~
jfoutz
what's your budget? Is 30ms fast enough to put a widget in a shopping cart?
Let's just assert 15ms from your server to the customer, you've got 15ms to
play with. Given this
[https://gist.github.com/jboner/2841832](https://gist.github.com/jboner/2841832)
let's assume you get around 5ms for each service, say a couple big disk reads
and some filtering.

So if n=3, it doesn't seem to bad. How much can you do in parallel? Stuff like
search, it seems like you could partition quite a bit hit a bunch of services
(10?)in the first 5ms, then spend the remaining 10ms sorting results, just
send your best effort.

I'm (of course) assuming a customer request means there's a customer sitting
there waiting and 30ms is good enough. Won't work for a game. Won't work for
HFT.

I guess you'd use the standard stuff, many layers of caching, efficient
implementation of the specific services, good algorithms. Heck, you could play
a game with docker and run the whole infrastructure on 1 big machine, i think
those local sockets would be a lot quicker that the 500,000 ns of a datacenter
read.

I mean, if an l2 cache miss is a disaster for you, clearly this won't do
anything for you. But how fast is fast enough? do you need to hit that target
every single time(real time)? Can you be late 1 in a million requests?

Are you sort of dismissing the idea out of hand or are you (aside from the
silly title) really thinking through the consequences of implementing an
application this way?

~~~
platz
not dismissing - 30ms would be stellar. Although I think that sets the bar
very high. Careful engineering can get it that low, but my experience is that
some platforms aren't that fast, especially if you're not building a
greenfield set of services from the ground up.

------
Fuzzwah
I only skimmed the article but it made me think about Valve Software's cabal
based development.

[http://www.gamasutra.com/view/feature/131815/the_cabal_valve...](http://www.gamasutra.com/view/feature/131815/the_cabal_valves_design_process_.php)

