Article: Chunk Cloud Computing

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, good to read. Thanks Jimmy.

Hi Jimmy,

Ever thought about perhaps a follow up article with examples?

"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

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.

"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

"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.

Mofo does not know what he is speaking about. This will be a deployment nightmare.

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 :)

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.