scalability and manageability

Discussion in 'Java' started by gk, Jan 19, 2011.

  1. gk

    gk Guest

    If I increase the Tiers of the application , does scalability and
    manageability inverse proportion ?
    gk, Jan 19, 2011
    #1
    1. Advertising

  2. gk

    Lew Guest

    On 01/18/2011 11:20 PM, gk wrote:
    >
    > If I increase the Tiers of the application , does scalability and
    > manageability inverse proportion ?


    Not necessarily, but maybe.

    Tiers are there for reasons, and scalability and manageability aren't
    necessarily among them.

    Let me ask you, in hopes that you'll answer this question at least, in inverse
    proportion of what to what?

    Scalability and manageability are not related to how many tiers there are but
    how well those tiers are engineered and how they connect to one another and
    how encapsulated they are from one another.

    --
    Lew
    Ceci n'est pas une pipe.
    Lew, Jan 19, 2011
    #2
    1. Advertising

  3. gk

    gk Guest


    > Let me ask you, in hopes that you'll answer this question at least, in inverse
    > proportion of what to what?
    >


    What to What ? well ok..what I meant was if I increase the Tiers say
    1 Tier, 2 Tier , 3 Tier likewise does the manageability of the system
    decreases ?
    gk, Jan 19, 2011
    #3
  4. gk

    Lew Guest

    On 01/19/2011 02:35 AM, gk wrote:
    >
    >> Let me ask you, in hopes that you'll answer this question at least, in inverse
    >> proportion of what to what?
    >>

    >
    > What to What ? well ok..what I meant was if I increase the Tiers say
    > 1 Tier, 2 Tier , 3 Tier likewise does the manageability of the system
    > decreases ?


    That's what I thought you meant, and the question I answered.

    --
    Lew
    Ceci n'est pas une pipe.
    Lew, Jan 19, 2011
    #4
  5. gk

    Arne Vajhøj Guest

    On 18-01-2011 23:20, gk wrote:
    > If I increase the Tiers of the application , does scalability and
    > manageability inverse proportion ?


    If we use the definition:
    tiers = separation where different tier can but does not have to on
    different boxes
    layers = separation where different layers (within the same tier) has
    to run on the same box

    Then I would expect more tiers to:
    - increase scalability
    - not decrease manageability significant

    (the drawbacks of more tiers being worse performance
    and more complex software)

    Arguments:
    - unless all tiers are only vertical scalable then adding
    tiers will make some of them horizontal scalable and
    that is the key to being scalable
    - the managing should depend on the total software not how
    that software is distributed on multiple systems (this
    assumes that the work of managing OS instances is
    insignificant)

    Arne
    Arne Vajhøj, Jan 20, 2011
    #5
  6. gk

    Arne Vajhøj Guest

    On 19-01-2011 07:44, Patricia Shanahan wrote:
    > gk wrote:
    >> If I increase the Tiers of the application , does scalability and
    >> manageability inverse proportion ?

    >
    > It depends. Division into tiers may simplify an application. Division
    > into tiers is a form of modularization, the general strategy of dividing
    > a large, complicated design into smaller, simpler pieces. Done well, it
    > reduces complexity. Done badly, it makes things worse.


    I assume that you are using tiers as synonym for layers here.

    Arne
    Arne Vajhøj, Jan 20, 2011
    #6
  7. gk

    Arne Vajhøj Guest

    On 19-01-2011 20:15, Patricia Shanahan wrote:
    > Arne Vajhøj wrote:
    >> On 19-01-2011 07:44, Patricia Shanahan wrote:
    >>> gk wrote:
    >>>> If I increase the Tiers of the application , does scalability and
    >>>> manageability inverse proportion ?
    >>>
    >>> It depends. Division into tiers may simplify an application. Division
    >>> into tiers is a form of modularization, the general strategy of dividing
    >>> a large, complicated design into smaller, simpler pieces. Done well, it
    >>> reduces complexity. Done badly, it makes things worse.

    >>
    >> I assume that you are using tiers as synonym for layers here.

    >
    > I would assume that tiers implies more of at least potential hardware
    > separation, which done well can simplify hardware requirements. Each box
    > in a tiered system sees a simpler, more homogeneous, workload than would
    > be the case for a single box running the whole application. However, my
    > comment also applies to software layers in the same box, or indeed to
    > any other form of modularization.


    OK, then I understand what you are saying.

    Arne
    Arne Vajhøj, Jan 20, 2011
    #7
  8. gk

    gk Guest

    On Jan 19, 5:43 am, Lew <> wrote:
    > On 01/19/2011 02:35 AM, gk wrote:
    >
    >
    >
    > >> Let me ask you, in hopes that you'll answer this question at least, in inverse
    > >> proportion of what to what?

    >
    > > What to What ?  well ok..what I meant was if I increase the Tiers say
    > > 1 Tier, 2 Tier , 3 Tier likewise  does the manageability of the system
    > > decreases ?

    >
    > That's what I thought you meant, and the question I answered.


    No. You are wrong. You are thinking as a direct relationship. But I
    meant the other way. You know INDIRECTLY, when you increase the
    Tiers , the Scalability increases (modular nature) . So, my question
    stands this way , when you increase Tiers , does the Scalability and
    manageability are in inverse proportion ?

    Hopefully, you got the picture now. Let me know if you still have
    doubt.
    gk, Jan 20, 2011
    #8
  9. gk

    Lew Guest

    Lew wrote:
    >>>> Let me ask you, in hopes that you'll answer this question at least, in inverse
    >>>> proportion of what to what?


    gk wrote:
    >>> What to What ? well ok..what I meant was if I increase the Tiers say
    >>> 1 Tier, 2 Tier , 3 Tier likewise does the manageability of the system
    >>> decreases ?


    Lew wrote:
    >> That's what I thought you meant, and the question I answered.


    As a reminder, the answer was "no".

    gk wrote:
    > No. You are wrong. You are thinking as a direct relationship. But I


    You said "inverse proportion" and "increase the [number of} tiers", which
    denotes "decreases reliability", which is also exactly what you said in the
    post you yourself quoted: "manageability of the system decreases". Inverse
    relationship is when the movement is in the opposite direction - one
    increases, the other decreases.

    > meant the other way. You know INDIRECTLY, when you increase the
    > Tiers , the Scalability increases (modular nature) . So, my question


    That is direct relationship: increase leads to increase. Inverse is when
    increase leads to decrease, i.e., the movement is in the opposite (inverse)
    direction.
    http://en.wikipedia.org/wiki/Direct_relationship
    http://en.wikipedia.org/wiki/Inverse_relationship
    http://en.wikipedia.org/wiki/Inverse_proportion

    It's also the exact opposite of what you said just above: "manageability ...
    decreases".

    > stands this way , when you increase Tiers , does the Scalability and
    > manageability are in inverse proportion ?
    >
    > Hopefully, you got the picture now. Let me know if you still have
    > doubt.


    I answered that question already, when I said, "Not necessarily, but maybe,"
    and, "Scalability and manageability are not related to how many tiers there
    are but how well those tiers are engineered and how they connect to one
    another and how encapsulated they are from one another." Patricia Shanahan
    made the same point, as you might recall, "It depends."

    In other words, there is neither a direct nor an indirect relationship. Let
    me know if you still have doubt.

    --
    Lew
    Ceci n'est pas une pipe.
    Lew, Jan 20, 2011
    #9
  10. gk

    gk Guest


    > "Scalability and manageability are not related to how many tiers there
    > are but how well those tiers are engineered and how they connect to one
    > another and how encapsulated they are from one another."  Patricia Shanahan
    > made the same point, as you might recall, "It depends."
    >
    > In other words, there is neither a direct nor an indirect relationship.  Let
    > me know if you still have doubt.
    >
    > --
    > Lew
    > Ceci n'est pas une pipe.


    Anyway, I have found my answer. What I have found after consulting
    some materials is this, when you increase the tiers , the scalability
    increases and as there is now more machine components manageability
    decreases . And so scalability and manageability are in inverse
    proportion in this context . Looks like meaningful to me.

    Remember we have 3 parameters here . Tier / scalability /
    manageability
    gk, Jan 20, 2011
    #10
  11. gk

    Lew Guest

    Please attribute citations. It's only polite.

    Lew wrote:
    >>> "Scalability and manageability are not related to how many tiers there
    >>> are but how well those tiers are engineered and how they connect to one
    >>> another and how encapsulated they are from one another." Patricia Shanahan
    >>> made the same point, as you might recall, "It depends."
    >>>
    >>> In other words, there is neither a direct nor an indirect relationship. Let
    >>> me know if you still have doubt.


    gk wrote:
    >> Anyway, I have found my answer. What I have found after consulting


    Here, in this forum, from more than one person.

    >> some materials is this, when you increase the tiers , the scalability
    >> increases and as there is now more machine components manageability
    >> decreases . And so scalability and manageability are in inverse
    >> proportion in this context . Looks like meaningful to me.


    But incorrect.

    >> Remember we have 3 parameters here . Tier / scalability /
    >> manageability


    And they have no direct or inverse relationship between each other.

    Patricia Shanahan wrote:
    > I strongly disagree. The real issue is the right set of tiers for the
    > application.
    >
    > If you get that right, manageability and scalability will both increase.
    > The essence of modularization as a strategy for building complex systems
    > is the fact that managing n simple subsystems plus some simple
    > interactions between them is often easier than managing one system that
    > does their combined function. Adding tiers, if they are the right tiers,
    > can improve manageability.
    >
    > On the other hand, increasing the number of tiers for the sake of doing
    > so, on the assumption that it will automatically increase scalability,
    > can have the effect of reducing scalability. Even when tiers are run on
    > the same hardware, communication between them tends to be more expensive
    > than intra-tier communication. With a bad tier design, the inter-tier
    > communication can be the limiting factor for scalability.


    Patricia is right. The "materials" you consulted are wrong.

    --
    Lew
    Ceci n'est pas une pipe.
    Lew, Jan 20, 2011
    #11
  12. On 20/01/2011 09:35, Patricia Shanahan allegedly wrote:
    > The real issue is the right set of tiers for the
    > application.
    >
    > If you get that right, manageability and scalability will both increase.
    > The essence of modularization as a strategy for building complex systems
    > is the fact that managing n simple subsystems plus some simple
    > interactions between them is often easier than managing one system that
    > does their combined function. Adding tiers, if they are the right tiers,
    > can improve manageability.
    >
    > On the other hand, increasing the number of tiers for the sake of doing
    > so, on the assumption that it will automatically increase scalability,
    > can have the effect of reducing scalability. Even when tiers are run on
    > the same hardware, communication between them tends to be more expensive
    > than intra-tier communication. With a bad tier design, the inter-tier
    > communication can be the limiting factor for scalability.


    A quick inquiry if I may. In the general (IT) parlance, is the term
    "scalability" used in the sense of both high and low-end scalability, or
    only high-end?

    For increasing tiers certainly doesn't increase low-end scalability. It
    might not decrease it, but I can't really imagine how it could increase
    it (as generally every tier will have a minimum "cost" attached to it).

    df.
    Daniele Futtorovic, Jan 20, 2011
    #12
  13. On 20/01/2011 20:02, Patricia Shanahan allegedly wrote:
    > On 1/20/2011 10:21 AM, Daniele Futtorovic wrote:
    >> On 20/01/2011 09:35, Patricia Shanahan allegedly wrote:
    >>> The real issue is the right set of tiers for the
    >>> application.
    >>>
    >>> If you get that right, manageability and scalability will both increase.
    >>> The essence of modularization as a strategy for building complex systems
    >>> is the fact that managing n simple subsystems plus some simple
    >>> interactions between them is often easier than managing one system that
    >>> does their combined function. Adding tiers, if they are the right tiers,
    >>> can improve manageability.
    >>>
    >>> On the other hand, increasing the number of tiers for the sake of doing
    >>> so, on the assumption that it will automatically increase scalability,
    >>> can have the effect of reducing scalability. Even when tiers are run on
    >>> the same hardware, communication between them tends to be more expensive
    >>> than intra-tier communication. With a bad tier design, the inter-tier
    >>> communication can be the limiting factor for scalability.

    >>
    >> A quick inquiry if I may. In the general (IT) parlance, is the term
    >> "scalability" used in the sense of both high and low-end scalability, or
    >> only high-end?
    >>
    >> For increasing tiers certainly doesn't increase low-end scalability. It
    >> might not decrease it, but I can't really imagine how it could increase
    >> it (as generally every tier will have a minimum "cost" attached to it).
    >>
    >> df.

    >
    > My understanding of scalability is specific to increases in size of
    > system and workload. I don't know what you mean by "low-end scalability"
    > unless you are using "scalability" as a synonym for performance.
    >
    > Scalability is not the only important performance issue. For example, in
    > some systems, response time under light load may be more important.
    >
    > Patricia


    Sorry for being unclear. That way I meant it was as follows:

    If high-end scalability be the measure how a component's performance and
    resource use evolve when its system and workload are increased, then
    low-end scalability would be the measure of how these evolve when system
    and workload are decreased.

    Inasmuch as I would venture to say that every component (software
    architecture, software layer, software component, hardware architecture,
    hardware component, etc. etc.) has, depending on its design, a kind of
    median size and load for which it is best suited, I find it interesting
    to look at how it behaves not only when these factors increase, but also
    when they decrease.

    At least that's something I've been thinking of the other day, and I was
    curious whether that was already taken into consideration when speaking
    of scalability.

    df.
    Daniele Futtorovic, Jan 20, 2011
    #13
  14. On Thu, 20 Jan 2011 21:05:39 +0100, Daniele Futtorovic wrote:

    > At least that's something I've been thinking of the other day, and I was
    > curious whether that was already taken into consideration when speaking
    > of scalability.
    >

    In this context each component of the application should do a well-
    defined task and is implemented as a module that can be instantiated as a
    process or thread. Each version of a module will have a maximum
    throughput on any given hardware regardless of its level of optimisation.

    My usual definition of a scalable system is one whose throughput can be
    increased by identifying any module(s) that limit overall throughput and
    allows the throughput to be increased by running additional copies of
    that module. This implies that the system is well enough instrumented for
    bottlenecks to be identified and is sufficiently configurable that module
    populations can be changed without any need for code changes or impacting
    the controllability of the running system.

    In general a threaded system that requires all copies of a particular
    module to be contained in a single process via multi-threading and/or
    only uses in-memory commmunication to pass data between modules will have
    only limited scalability because either restriction will prevent a module
    from being replicated across a set of servers.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
    Martin Gregorie, Jan 20, 2011
    #14
  15. gk

    Arne Vajhøj Guest

    On 20-01-2011 03:35, Patricia Shanahan wrote:
    > The real issue is the right set of tiers for the
    > application.


    Agree.

    > If you get that right, manageability and scalability will both increase.
    > The essence of modularization as a strategy for building complex systems
    > is the fact that managing n simple subsystems plus some simple
    > interactions between them is often easier than managing one system that
    > does their combined function. Adding tiers, if they are the right tiers,
    > can improve manageability.


    If manageability means that it is easy to manage by operations,
    then they are usually not affected much (neither positive or
    negative) from the structuring of the systems, because
    they tend to have a black box view of the system.

    > On the other hand, increasing the number of tiers for the sake of doing
    > so, on the assumption that it will automatically increase scalability,
    > can have the effect of reducing scalability. Even when tiers are run on
    > the same hardware, communication between them tends to be more expensive
    > than intra-tier communication. With a bad tier design, the inter-tier
    > communication can be the limiting factor for scalability.


    I would define:

    performance = much bang for the buck

    scalability = the ability to get double bang for double buck

    Too many tiers decrease performance not scalability.

    Arne
    Arne Vajhøj, Jan 21, 2011
    #15
  16. gk

    Arne Vajhøj Guest

    On 20-01-2011 15:05, Daniele Futtorovic wrote:
    > On 20/01/2011 20:02, Patricia Shanahan allegedly wrote:
    >> On 1/20/2011 10:21 AM, Daniele Futtorovic wrote:
    >>> On 20/01/2011 09:35, Patricia Shanahan allegedly wrote:
    >>>> The real issue is the right set of tiers for the
    >>>> application.
    >>>>
    >>>> If you get that right, manageability and scalability will both
    >>>> increase.
    >>>> The essence of modularization as a strategy for building complex
    >>>> systems
    >>>> is the fact that managing n simple subsystems plus some simple
    >>>> interactions between them is often easier than managing one system that
    >>>> does their combined function. Adding tiers, if they are the right
    >>>> tiers,
    >>>> can improve manageability.
    >>>>
    >>>> On the other hand, increasing the number of tiers for the sake of doing
    >>>> so, on the assumption that it will automatically increase scalability,
    >>>> can have the effect of reducing scalability. Even when tiers are run on
    >>>> the same hardware, communication between them tends to be more
    >>>> expensive
    >>>> than intra-tier communication. With a bad tier design, the inter-tier
    >>>> communication can be the limiting factor for scalability.
    >>>
    >>> A quick inquiry if I may. In the general (IT) parlance, is the term
    >>> "scalability" used in the sense of both high and low-end scalability, or
    >>> only high-end?
    >>>
    >>> For increasing tiers certainly doesn't increase low-end scalability. It
    >>> might not decrease it, but I can't really imagine how it could increase
    >>> it (as generally every tier will have a minimum "cost" attached to it).
    >>>
    >>> df.

    >>
    >> My understanding of scalability is specific to increases in size of
    >> system and workload. I don't know what you mean by "low-end scalability"
    >> unless you are using "scalability" as a synonym for performance.
    >>
    >> Scalability is not the only important performance issue. For example, in
    >> some systems, response time under light load may be more important.

    >
    > Sorry for being unclear. That way I meant it was as follows:
    >
    > If high-end scalability be the measure how a component's performance and
    > resource use evolve when its system and workload are increased, then
    > low-end scalability would be the measure of how these evolve when system
    > and workload are decreased.


    I don't think that is a commonly used terminology.

    And if the bang/buck curve is smooth, then they should be
    identical.

    Arne
    Arne Vajhøj, Jan 21, 2011
    #16
  17. gk

    Arne Vajhøj Guest

    On 19-01-2011 23:23, gk wrote:
    > Anyway, I have found my answer. What I have found after consulting
    > some materials is this, when you increase the tiers , the scalability
    > increases and as there is now more machine components manageability
    > decreases . And so scalability and manageability are in inverse
    > proportion in this context . Looks like meaningful to me.
    >
    > Remember we have 3 parameters here . Tier / scalability /
    > manageability


    I would suggest you put those materials an appropriate place.

    And that is the trash bin.

    It is oversimplifying a complex matter to the point
    where it is useless.

    Arne
    Arne Vajhøj, Jan 21, 2011
    #17
  18. On 19-01-2011 22:59, Lew wrote:
    > Patricia Shanahan wrote:
    >>>>> It depends. Division into tiers may simplify an application. Division
    >>>>> into tiers is a form of modularization, the general strategy of
    >>>>> dividing
    >>>>> a large, complicated design into smaller, simpler pieces. Done
    >>>>> well, it
    >>>>> reduces complexity. Done badly, it makes things worse.

    >
    > Arne Vajhøj wrote:
    >>>> I assume that you are using tiers as synonym for layers here.

    >
    > Patricia Shanahan wrote:
    >>> I would assume that tiers implies more of at least potential hardware
    >>> separation, which done well can simplify hardware requirements. Each box
    >>> in a tiered system sees a simpler, more homogeneous, workload than would
    >>> be the case for a single box running the whole application. However, my
    >>> comment also applies to software layers in the same box, or indeed to
    >>> any other form of modularization.

    >
    > Arne Vajhøj wrote:
    >> OK, then I understand what you are saying.

    >
    > This form of "hardware/software" distinction is ever-more outmoded.
    > Clouds, clusters and multiple servers per node blur the differences, at
    > least from the architectural point of view.


    No.

    All this is just new physical forms of old concepts.

    > If I run two instances of
    > GlassFish on a node, each one pretends it is the sole owner of the
    > hardware and only performance suffers. This does not make the
    > application architecture, e.g., a multi-tier system with one each of
    > those GlassFish servers per tier, any less a tiered architecture.
    >
    > That it is a tiered architecture is revealed by the ease with which one
    > can move one of those servers to a different physical node. (Yep, "at
    > least potential hardware separation", for certain understandings of the
    > term "hardware".)


    I don't think anyone has said otherwise.

    And it is not obvious to me what the point for the topic is.

    Arne
    Arne Vajhøj, Jan 21, 2011
    #18
  19. gk

    Lew Guest

    Daniele Futtorovic wrote:
    >> Sorry for being unclear. That way I meant it was as follows:
    >>
    >> If high-end scalability be the measure how a component's performance and
    >> resource use evolve when its system and workload are increased, then
    >> low-end scalability would be the measure of how these evolve when system
    >> and workload are decreased.


    Arne Vajhøj wrote:
    > I don't think that is a commonly used terminology.


    I agree with you, Arne.

    > And if the bang/buck curve is smooth, then they should be
    > identical.


    "Scalability" is usually understood as the ability to get (reasonably) close
    to n times performance increase of a component by increasing its resources by
    n. More generally, it's the ability to adjust the performance of a software
    system by adjusting resources without changing code. There is no concept of
    "high-end" or "low-end" scalability that I've ever encountered. There's only
    "scalability".

    If a system is scalable, it can be adjusted readily for high or low workloads
    and achieve its performance goals.

    The number of tiers in the system is no determinant of scalability, nor of
    manageability, at any level.

    --
    Lew
    Ceci n'est pas une pipe.
    Lew, Jan 21, 2011
    #19
  20. gk

    Lew Guest

    On 01/20/2011 08:42 PM,
    Lew wrote:
    >> If I run two instances of
    >> GlassFish on a node, each one pretends it is the sole owner of the
    >> hardware and only performance suffers. This does not make the
    >> application architecture, e.g., a multi-tier system with one each of
    >> those GlassFish servers per tier, any less a tiered architecture.
    >>
    >> That it is a tiered architecture is revealed by the ease with which one
    >> can move one of those servers to a different physical node. (Yep, "at
    >> least potential hardware separation", for certain understandings of the
    >> term "hardware".)


    Arne Vajhøj wrote:
    > I don't think anyone has said otherwise.


    And I don't think I was disagreeing with them. In fact, you can see by my
    citation of Patricia's point that I'm illustrating it.

    > And it is not obvious to me what the point for the topic is.


    Obviously I'm endorsing points made earlier and adding examples of the concept
    to the discussion.


    --
    Lew
    Ceci n'est pas une pipe.
    Lew, Jan 21, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. tharma
    Replies:
    4
    Views:
    484
    Jason Kester
    Sep 13, 2005
  2. tharma
    Replies:
    1
    Views:
    416
    Roedy Green
    Sep 13, 2005
  3. tharma
    Replies:
    5
    Views:
    1,090
    Jim Higson
    Sep 13, 2005
  4. tharma
    Replies:
    0
    Views:
    361
    tharma
    Sep 13, 2005
  5. Elaine
    Replies:
    0
    Views:
    342
    Elaine
    Nov 27, 2007
Loading...

Share This Page