File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Agile and Other Processes and the fly likes Release It!: How much Design and Deploy Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Release It!: How much Design and Deploy" Watch "Release It!: How much Design and Deploy" New topic
Author

Release It!: How much Design and Deploy

Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi Michael,

Welcome to JavaRanch .

Originally posted at Release It!: Design and Deploy Production-Ready Software:
Other books on design and architecture only tell you how to meet functional requirements. They help your software pass Quality Assurance. But painful experience has shown that "feature complete" is not even close to "production ready."


I can only underline the last statement in above quote. While both aspects of Design and Deployment are most often handled in separate books you seem to concentrate on glueing them together in one book.

Personally I have some weakness in the Deployment part or better said in the release stuff. However I think creating a good Design is much tougher to achieve than a process of release management. Simply because to my opinion Design is an art while the release management is a (also tough) one-time discipline.

How do you weight both apsects of Design and Deployment in your book? Is it fifty-fifty or do you pay more attention on one over the other?

Regards,
Darya


SCJP, SCJD, SCWCD, SCBCD
Michael Nygard
author
Ranch Hand

Joined: Jan 03, 2007
Posts: 40
Darya,

I would say that most of the book focuses on design and architecture. Deployment gets its own section, in the chapter on Adaptation.

However: the foundation of my book is the notion that we build software that must run in the real world. Deployment is _always_ a concern. So, the section on stability patterns, for example, discusses the problems you can run into with version-locking (where you have to upgrade both endpoints of an integration simultaneously).

Cheers,
-Mike


Michael T. Nygard<br /><a href="http://www.michaelnygard.com/" target="_blank" rel="nofollow">http://www.michaelnygard.com/</a><br /> <br />Release It! Design and Deploy Production Ready Software<br /><a href="http://pragmaticprogrammer.com/titles/mnee/index.html" target="_blank" rel="nofollow">http://pragmaticprogrammer.com/titles/mnee/index.html</a>
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Originally posted by Michael Nygard:
... the section on stability patterns, for example, discusses the problems you can run into with version-locking (where you have to upgrade both endpoints of an integration simultaneously).


Is the stability pattern a new pattern or just a name for your discussion? What role do design patterns in general play in your book?

Regards,
Darya
[ February 15, 2007: Message edited by: Darya Akbari ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Darya, don't know about the book, but keep in mind that not all patterns are *design* patterns. There are also process patterns, configuration management patterns, you name it. The whole pattern movement actually started with patterns for house architecture!


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Michael Nygard
author
Ranch Hand

Joined: Jan 03, 2007
Posts: 40
Originally posted by Darya Akbari:

Is the stability pattern a new pattern or just a name for your discussion? What role do design patterns in general play in your book?


Darya,

I use "stability pattern" to describe design and architecture patterns that enhance stability by addressing entire classes of problems. The stability patterns allow your application to recover from failures that could otherwise propagate everywhere.

For example, there's a common type of failure that I call a "Cascading Failure". This is when a failure in one layer or subsystem causes problems in callers of that layer. For example, imagine the search servers in a retail site go belly-up (which search engines do with distressing frequency). If the application servers that make search queries are written naively, then threads calling out to search servers will hang. Once all the request-handling threads in the application servers hang, the application servers are essentially dead and your site is down. That's a Cascading Failure. (BTW: I refer to these as "stability anti-patterns".)

To counter Cascading Failures, I apply a stability pattern I call Circuit Breaker. Circuit Breaker protects the application servers from failures in the search servers. It prevents problems from "jumping the gap" between one layer and another.

You can apply a Circuit Breaker to any integration point that involves synchronous calls. That's why I call it a stability pattern.

Cheers,
-Mike
Dion Stewart
Greenhorn

Joined: Feb 15, 2007
Posts: 3
Mike,

Would you say your design patterns are more like infrastructure design patterns as compared to GoF domain model design patterns?

Dion
Michael Nygard
author
Ranch Hand

Joined: Jan 03, 2007
Posts: 40
Dion,

I'm not sure I would say that, but it may be because I have a different definition of "infrastructure" than you are using.

To me, infrastructure refers to the physical layer of power and environmental controls, along with hardware for machines, and network devices.

I think of the stability patterns as software architecture patterns aimed at improving reliability and availability of applications. So, they are about the things you can build in the application layer to deal with the fallible nature of real-world systems.

Cheers,
-Mike
Hanumanth Kanthi
Ranch Hand

Joined: May 27, 2004
Posts: 74
So Mike, the way you are describing.... it seems your "stability patterns" are input to "infrastructure patterns"....agree?

Cheers
H. Kanthi
Michael Nygard
author
Ranch Hand

Joined: Jan 03, 2007
Posts: 40
Hanumanth,

I suppose you could view it that way.

I would also say that these stability patterns should inform design decisions inward--that is, toward the structure of code inside your application--and outward--toward your interface and protocol design between applications.

For example, I mentioned the Circuit Breaker pattern earlier. This pattern works best when it is supported by code inside the calling application that knows it sometimes will not get a result from a call out to another system. In other words, sometimes a call with a Boolean result can actually give back TRUE, FALSE, or "no answer".

Circuit Breaker works even better when the protocol you define between the applications lets the serving application cry uncle. If you are calling my web service, for example, then I should have a way to say, "stop calling so much" or perhaps, "I can't answer that request within my defined SLA."

So, while the stability patterns can affect your choice and topology of infrastructure, I would say that they have more effect on the design and architecture of your applications.

Cheers,
-Mike
Hanumanth Kanthi
Ranch Hand

Joined: May 27, 2004
Posts: 74
Agree - Well said....

Thanks,
H. Kanthi
Dion Stewart
Greenhorn

Joined: Feb 15, 2007
Posts: 3
If you are calling my web service, for example, then I should have a way to say, "stop calling so much" or perhaps, "I can't answer that request within my defined SLA."


Mike, that's an interesting concept. So, do you approach architecture with the idea that your various components should have SLA's? I could see that being useful.

Dion
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Dion Stewart:

as compared to GoF domain model design patterns?


Dion, what makes you think that the GoF patterns are *domain* model design patterns? I've never heard of that before.
Michael Nygard
author
Ranch Hand

Joined: Jan 03, 2007
Posts: 40
Originally posted by Dion Stewart:
...do you approach architecture with the idea that your various components should have SLA's?


Dion,

That is how I approach it. Sometimes that an explicit requirement, as in the case of a service-oriented architecture. Sometimes it's more of a notional service level. If you think about that 4 second threshold for a lost user on a page response, you can break it down into the maximum allowable response time from each system or subsystem.

I often use retailers as an example, because they're familiar to everyone, either as an implementer or a customer.

Using a retailer as an example, if we set 4 seconds as the maximum response time for a product search, we might break that down to the time we would allow for the search servers to respond, the time we expect the application servers to spend looking up additional details from the database, the time it takes the inventory system to say what the products' availability is, the time it takes to send the page response, the time it takes to serve each of the thumbnails, stylesheets, javascript files, etc.

Suppose that market research discovers that you can increase your conversion rate by being faster. (You can.) You can work with the time budget and the component-level SLAs to decide what will have the greatest impact on overall response time. Of course, you'd also have to balance that against the cost of implementation and operations of whatever alternatives you're looking at.

If your system is a service provider, on the other hand, you might want to provide an SLA for a variety of reasons. First, so you can truly say whether or not your system can handle more load. [*See below about capacity.] Second, so you can refuse more incoming requests when you're operating outside your SLA. Third, so you can use data to refute the "your system is slow" criticisms that plague any back-end service provider.

[* I define capacity as the maximum number of concurrent transactions your system can process within its SLAs. The usual definition is a lot fuzzier; it goes something like, "the most concurrent users the site can handle before it crashes". The trouble is that you'll start losing users long before the site crashes. At the point where response times are measured in double- or triple-digits, whether or not the server crashed is moot.

This means that without an SLA, you can't actually define your capacity. It would be something like "10,000,000 TPS reports at a time, but each one will take twelve hours."]

Sorry, Dion. Long winded answer to a concise question...

Cheers,
-Mike
Dion Stewart
Greenhorn

Joined: Feb 15, 2007
Posts: 3
Dion, what makes you think that the GoF patterns are *domain* model design patterns? I've never heard of that before.


Ilja,

I made that comment in the context of trying to get Mike to describe the differences between the patterns in his book and existing design patterns.

Of course you're right in that there's nothing in the GoF patterns that limits them specifically to domain modeling. However, I find myself applying the GoF patterns most frequently during domain modeling and to a lesser extent when coding rich GUIs (even though a lot of the patterns had their origin in GUI coding). When I'm coding Application Layers, Services, Infrastructure Layers etc. I don't use them nearly as much.

It was probably a bad characterization though.

Dion
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Release It!: How much Design and Deploy