Article: Chunk Cloud Computing
- Share
-
- |
Read later
My Reading List
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.
Various DBs can be used
by
Lee Wayne
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
Follow up article with examples
by
Toby Jee
Ever thought about perhaps a follow up article with examples?
SOA done right
by
Peer Reynders
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
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
Is this the best line in the entire article? I think so!
:D
Interfaces and Mobile Code Rule the World
by
Gregg Wonderly
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
Re: Various DBs can be used
by
Sándor Nacsa
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 :)
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
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.
Educational Content
Clojure in the Field
Stuart Halloway May 23, 2013
Tuning the Size of Your Thread Pool
Kirk Pepperdine May 23, 2013
Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think