In this article Jimmy Nilsson describes an architectural style that he has observed slowly growing in popularity over the last few years, a style that he calls Chunk Cloud Computing.
Read: Chunk Cloud Computing
Nilsson summarizes the style like this:
Before: Focus on layering
Now: More focus on partitioningBefore: Focus on loose coupling
Now: A balance (include high cohesion)Before: Huge teams
Now: Extremely small teamsBefore: Integration database
Now: Application databases
Nilsson’s article is a review of this decade’s trends in software architecture, the lessons learned and a conclusion on the current status.
Community comments
Various DBs can be used
by Lee Wayne,
Re: Various DBs can be used
by Mark Taylor,
Re: Various DBs can be used
by Sándor Nacsa,
Re: Various DBs can be used
by Gregg Wonderly,
Nice article
by Toby Jee,
Follow up article with examples
by Toby Jee,
SOA done right
by Peer Reynders,
Aspects of Integration
by Patrick Logan,
Interfaces and Mobile Code Rule the World
by Gregg Wonderly,
Re: Interfaces and Mobile Code Rule the World
by Christopher Churchill,
Various DBs can be used
by Lee Wayne,
Your message is awaiting moderation. Thank you for participating in the discussion.
Great article, Jimmy!
Just one cent about DB partition, I think different types/brands/configurations of DBs can be used for different partitions, e.g., CouchDB for UI preference persistence, single server MySQL for admin log tracking, large DB2 farm for mission-critical app ...
BTW: some past experience from Telecom industry FYI. Over the years, operators have built lots systems for standalone services (call, messaging, push-to-talk, ...) Nowadays operators realize they need to roll out lots new value-add-services (VAS) with existing service systems (now called Silos) constantly to stay competitive. So lots custom inter-links between the Silos are created, which in the end create kind of "spaghetti" mess. So some vendors propose the idea of Service Delivery Platform (SDP) to remove the spaghetti with a kind of ESB like layer, on top of which you can build new apps smoothly. Simply put, SDP is like SOA for Telecom.
True experience from working with a large operator's SDP initiative: the specs took years for engineers and consultants from both sides to work out, numerous revisions, endless discussions, reviews and debates on data model, domain model, whatever model... The initiative's title changed several time meanwhile, since the requirements evolved overtime with different executives involved ... Finally the consultant phase is complete, and a new contract is signed for the prototype phase (no idea when's the actual implementation).
So I guess it is always a dilemma in the end for large complex system: too hard to draft an overall design satisfying all parties, needless to say implementing it; On the other hand, partitions (silos) are easier to design and build individually, but eventually hard to integrate together to support changing biz logic requirements.
Anyway, I think your approach is better -- at least we can get some working silos instead of piles of specs few can fully understand :)
Wayne
Nice article
by Toby Jee,
Your message is awaiting moderation. Thank you for participating in the discussion.
Nice article, good to read. Thanks Jimmy.
Follow up article with examples
by Toby Jee,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi Jimmy,
Ever thought about perhaps a follow up article with examples?
SOA done right
by Peer Reynders,
Your message is awaiting moderation. Thank you for participating in the discussion.
"So, I think of the partitions I’ve discussed above as 'SOA done right'"
Replace the UIs in your partitions with service interfaces/contracts and you have yourself some (exceptionally) "high autonomy" services (according to Thomas Erl).
www.soaprinciples.com/service_autonomy.asp
www.soapatterns.org/composition_autonomy.asp
Aspects of Integration
by Patrick Logan,
Your message is awaiting moderation. Thank you for participating in the discussion.
There are several important aspects to integration. Perhaps foremost are the "pure data" issues that will help or hinder integration. Those are mostly independent of using a single integration DB, or integrating multiple DBs via conforming dimensions, or through other kinds of service or resource approaches.
There may be forces for then using more than one approach, each aided by good data integration.
Re: Various DBs can be used
by Mark Taylor,
Your message is awaiting moderation. Thank you for participating in the discussion.
"100 developers in a single team, that’s just scary and the risk of failure is enormous. Even if you add 20 more!"
Is this the best line in the entire article? I think so!
:D
Interfaces and Mobile Code Rule the World
by Gregg Wonderly,
Your message is awaiting moderation. Thank you for participating in the discussion.
"The argumentation is actually similar, although maybe not as strong, when it comes to the UI as with the integration database vs. application database. Instead of creating one UI on top of several services, why not let each service have its own UI and then integrate the different UIs with a UI container framework instead?"
I like this thought because it speaks of something that I find to be very powerful. The Jini ServiceUI mechanism defines the mechanism for registering one or more "UI" implementation with a service's registration in the Jini lookup service. These can be added by third parties based on security controls on the LUS. So, you can add a UI to something that you didn't write, but which you do know the service interface definition for.
A ServiceUI is a UI, not just a GUI. Because it is mobile code, it can be downloaded and instantiated on a client that needs a particular style of implementation. If you need XML document interactions, but the service just has java objects, you can do that. If you need JDBC access but the service just has XML you can do that too.
It encourages layered integration techniques by making it part of the system design, from the start, to enable such things.
Of course the ServiceUI documentation only speaks of GUI based details, but it can be used to recast a service from one interface model, into another for any "user" whether that's a chunk of code or a person etc.
Re: Interfaces and Mobile Code Rule the World
by Christopher Churchill,
Your message is awaiting moderation. Thank you for participating in the discussion.
Mofo does not know what he is speaking about. This will be a deployment nightmare.
Re: Various DBs can be used
by Sándor Nacsa,
Your message is awaiting moderation. Thank you for participating in the discussion.
These words are the best to express our inability to deal with the complexities in large enterprise custom solution space. Nobody was able so far to provide a SOA-only programming paradigm which could have been the solution to this silo problem. It would have even beeen impossible to achieve the acceptance of such a one and the history is the best proof of that. ALGOL 60 was an absolutely forward looking programming paradigm nevertheless COBOL was the dominant one in the enterprise application space for not less than three decades.
Re: Various DBs can be used
by Gregg Wonderly,
Your message is awaiting moderation. Thank you for participating in the discussion.
There never was the kind of commercial support for algol 60, in the era it would have been most useful, like there was for cobol when it was needed. Cobols readability and support for reporting was what businesses needed. Algo 60 never had anything close to that.
In programming language development, we constantly have the problem that most languages are developed by individuals with bias and understanding of a very small minority of what the world uses computing power to do.
Languages like the C-language succeed because of simplicity, not because of complexity and large libraries. However, that also means that they create an environment for long lived applications, because you hardly ever can find another language with all the things you wrote, ready for you to just do some simple structured programming to recreate your application.
What cloud computing needs to do is decide on a machine standard and leave it at that. I personally would prefer that the machine be the Java virtual machine, because that would allow dynamic binding and portability and competition in machine performance that would help Java continue to improve with a purpose to serve the users.
If the machine was something like VMWare supported OSes or something else virtual, like that, than we'll continue to struggle with the need for all these crap data interchange mechanisms that completely overwhelm software development.
One machine is good. The wrong machine is bad.