scalability and manageability

[gk]

If I increase the Tiers of the application , does scalability and
manageability inverse proportion ?

 

[Lew]

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.

 

[gk]

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 ?

 

[Lew]

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.

 

[Arne Vajhøj]

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]

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]

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

 

[gk]

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.

 

[Lew]

As a reminder, the answer was "no".

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.

 

[gk]

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

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

 

[Lew]

Please attribute citations. It's only polite.

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

But incorrect.

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

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.

 

[Daniele Futtorovic]

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]

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.

 

[Martin Gregorie]

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.

 

[Arne Vajhøj]

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]

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]

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]

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

 

[Lew]

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]

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.