Server Containers

Would there be an appropriate way to classify containers? For example, Apache could be considered a web container whereas Tomcat and OC4J could be considered application containers... Maybe I'm over-thinking things? It gets a little hairy for me with this because some things could be construed in multiple ways (not to mention that the brunt of my experience deals mostly with Apache and Tomcat). I mean, Tomcat can do both web and app stuff...

That said, the reason I'm asking about this is because I'm creating a wiki at work which provides a way to create server pages that help keep track of things ranging from last updates performed to which apps might be installed, etc. One of our templates has a way to select from a category of "Web Containers" when creating one of these pages but due to specifics, it should probably be changed or extended to provide a clearer distinction between both "Web Containers" and or "Application Containers" as our shop does a lot of Java work among general web stuff...

I'd like to know your thoughts on this. Would "Web Container" and "Application Container" suffice? Is there such a thing as a "Database Container" (i.e. - could "MySQL", "Oracle", etc. be considered database containers?)

Hi Wolf_22,

Firstly, I don't think your 'Over Thinking This', the fact that you are trying to organize these relationships in a meaningful way is a great thing.

In my companies we have described these as 'Stacks' we had 'Web Stacks' , 'Desktop Stacks', 'Mobile Stacks'

Stacks are made up of layers, for example a 'Web Stack' may have a stack structure of:

Web Application
------------------------
Server:
- Server Configuration:

- RAID 10

- Centos 6.1

- Proxmox Barebones 'Cluster Cloud Config'

- Data-pooling Session Manager

- 120GB RAM

- Xenon 4 Processors (4 core) X 8

- Server Entities

- Apache 2.x Server

- MySQL 5.x Database

- Quantum LDAP

- Web

- PHP 5.3.1

- APC cache

- ... More Web Specifics

- CODE

- Top (landing pages)

-- style.css

-- mobile.css

-- tablet.css

-- ...

- Classes ROOT -> lib

- common

- security

- ...

- Scripts ROOT -> scripts
- ...
-------------------------

The above is a very rough idea of what we would do.

Whether you use Stacks or Containers, I don't think it matters. This documentations needs to be clear for new hires, contractors and new team members. The less you have to describe your conventions and the more natural understanding of this structured data will help with better up-take.

I don't know if this helps, but hope it does?

Regards,
Steve

Steve, that's a great idea about the "stacks" parlance (sorry for the late reply, btw).

But I don't know what to think about your comment...

Quote:

---

Whether you use Stacks or Containers, I don't think it matters. This documentations needs to be clear for new hires, contractors and new team members. The less you have to describe your conventions and the more natural understanding of this structured data will help with better up-take.

---

I'm going to have to think about that one.

Hi Wolf_22,

Quote:

---

Originally Posted by Wolf_22

... But I don't know what to think about your comment...

Quote:

---

Whether you use Stacks or Containers, I don't think it matters. This documentations needs to be clear for new hires, contractors and new team members. The less you have to describe your conventions and the more natural understanding of this structured data will help with better up-take.

---

I'm going to have to think about that one.

---

What I meant by this, is that any time there can be less description as the information is on sight clear, it makes it easier for people not knowing the information to understand.

Regards,
Steve

Now that makes sense. :)

Thanks again. I plan on putting your idea into play this week.