If speed is your biggest concern, it is likely that you will build a system that has a lot of services which each have a shallow stack. Each service would not go very deep into the service stack before hitting the data it was looking for. PHP, for example, almost always works this way. Maybe the data would be in a cache, as suggested by other commenters here. You have more places to put caches if you think about your system as multiple services.
If you are making a big system, you probably would not want to try to put all of the components in one monolithic place. I argued that this makes testing and release more complicated (and slower). But, I suspect it also affects runtime speed by making the stack deeper. You would be doing more switching to get your requests to the right components.
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.
That is really great to hear, it would be awesome to really read some real stuff besides analogies. By real stuff I mean situations, so all people can learn from them.
Author here - I can make an observation about old people because I myself am 49 years old. I'm not making a value judgement about older people. That would be ageism. I'm observing that the attendees "agile" events tend to be older than most programmers, and even most IT staff. That's just demographics. Why is that? That affects a lot of things.
I can make an observation about old people because I myself am 49 years old
That doesn't make any logical sense. All that suggests is that you have n=1 experience with people over the age of forty.
As for observing that agile events in your neck of the woods are full of older people, there are many, many possible explanations for this and your blog post advances one without providing evidence that it is anything other than confirmation bias.
One thing I would do before making a statement like that is attend some other methodology events and check out the ages. If you go to a CMM conference, how old are the people? How about a PMP Institute gathering?
You may find that older people are more interested in methodologies while younger people are more interested in technologies. You might not, but your essay does nothing to establish that your explanation carries more weight than my conjecture.
And if my conjecture is correct, your point really should be that "Excessive interest in methodologies has the smell of death." That might be true!
I am not saying you're wrong, only that your essay is not persuasive on this one point.
I don't make a conjecture about the reason that agile events skew to an older crowd because I really, really don't know why it is true. I do know that it changes the whole perception of the effort. So, I have to be careful when I use the word "agile". It's got a demographic implication that isn't positive, isn't "us" for many younger people. You can argue about the wisdom of my saying it this way, but the word has a real demographic and emotional association. This article is a chance to express my doubts about the word "agile". It's done. I'll be more positive from here on out.
CMM and PMP are basically anti-agile. They are useful, but useful for projects that just shouldn't be agile. The fact that agile events attract a similar demographic isn't a positive, in my opinion.
It's got a demographic implication that isn't positive, isn't "us" for many younger people
Compared to what, exactly? What development management practices do have an "us" demographic for younger people? One possibility is that you will reply and name one or more named practices with a "young" demographic, and I will accept your point.
The other possibility is that there really isn't a development management practice that has a "young" demographic, that young developers just aren't into spending a lot of time thinking about practices.
If the second case is true, I really believe it undermines your point. If young developers don't really align towards any particular named repeatable practice, Agile is no better and no worse than anything else on account of the age of the people interested in it enough to attend events. It isn't worth "hating" agile for its lack of traction any more than hating PERT charts or Theory of Constraints.
My hunch is one of the main reasons people who attend Agile events tend to be on the mature side is because they've have families so they can't (and don't want to) spend their weekends at beer-fuelled hackathons and have seen that the root of software project success & failure is in the processes rather than the tools.
That kind of stuff is pretty boring for the younger generations who are still caught up in the idea that shiny technologies and gargantuan coding sessions can save the world and make them all billionares.
You are either a hypocrite or cannot remember your own writing. "The smell of death" permeates agile gatherings, because the attendees are largely over 50. That's not a statement of fact. It might have been a factual statement, had you written that the attendees were animated, rotting corpses.
If you want to see a lot of young people then go to a 48-hour hack-a-thon. That's a development methodology where you'll find fewer 40-50 year old devs.
You find mostly older devs at meetups about process and methodology not because it's and old and boring subject. Rather, because they're the ones who are concerned about process and methodology and are more likely to be at a management level.
As I explain above the oldies are there because their 401ks tanked and they had to get back into the workforce somehow without programming skills. Hence, the Agile Coaches in the AARP set
No, Assembla is not proud of having such a low selling price. We have seen that as a problem since the beginning. The original sin is not the current low selling price. The original sin was offering the "private" product for free during a time when it wasn't a serious business for us. We took an enormous amount of abuse when we discontinued this product, and to soften the blow, we worked to keep prices low. We did this even though it's clear that a customer who makes a decision based on a $2 price point isn't going to make much of a contribution to the company. It's now clear that our gesture wasn't fully appreciated, and it's dragging down the pricepoint for our serious customers - startups, corporate product developers, outsourcers, agencies, and consulting companies that need professsional management features.
I have to disagree with the guy that says the service doesn't have value over $20. Even on the face of it, he would replace it with a server costing $50/month, plus install and admin time costing at least that. So, he's already at $100. He's probably only using the subversion repository, which he could easily install on his own. However, if you are serious about getting the most from your team, you would be using the alerts, code browser, the ticketing system, which would cost you substantially more if you bought it from Atlassian or Fogbugz, and be well worth it. If you have a consulting operation, as many Assembla customers do, you will use the time tracking and reporting. In other words, if you manage your team professionally, you will get a lot of value out of this software. And, certainly we will work on charging appropriately.
If you are making a big system, you probably would not want to try to put all of the components in one monolithic place. I argued that this makes testing and release more complicated (and slower). But, I suspect it also affects runtime speed by making the stack deeper. You would be doing more switching to get your requests to the right components.