is it the size? Does size really matter?
truckfit
Banned Posts: 78 ■■□□□□□□□□
Hello Guys,
I just want to know if size does matter?
What I mean by that is it the number of users in the company that makes the infrastructure complex and hard to deal with or is it the business requirements.
For an example I work for a software development firm that has 18 employees and we have a bigger set up than what is needed for a 18 people network.
We have a vm platform where we host our vms where the developers work on and test stuff.
This vm platform has 5 servers (128 gb ram each) it is connected to a SAN and goes via switch. We also have 20 production servers.
however if it was something like a small accounting firm which has 20 people it would be like. 1 server and a couple of switches a router and a firewall and thats it.
I just want to know if size does matter?
What I mean by that is it the number of users in the company that makes the infrastructure complex and hard to deal with or is it the business requirements.
For an example I work for a software development firm that has 18 employees and we have a bigger set up than what is needed for a 18 people network.
We have a vm platform where we host our vms where the developers work on and test stuff.
This vm platform has 5 servers (128 gb ram each) it is connected to a SAN and goes via switch. We also have 20 production servers.
however if it was something like a small accounting firm which has 20 people it would be like. 1 server and a couple of switches a router and a firewall and thats it.
Comments
-
dontstop Member Posts: 579 ■■■■□□□□□□Hello truckfit,
It all comes down to the Business and it's requirements, Users and the problem domain. Take for example my School (1000 Students) vs. my previous place of work (a Nuclear Reactor, 1000 users). If we went by numbers alone, you would think both would have the same Infrastructure requirements. If you actually visited both of their Computers Rooms you would be very wrong.
My School with it's 1000 users had 3 Servers in a single Rack, while at the Reactor we had a 4,500 ft.^2 Data Center. The main problem we faced with this large DC was the fact that our I.T. staff and budget didn't match our user requirements, also due to the weird and wonderful needs of systems such as SAP, Exchange and other large ERP, EMS's we had a kludge of machines and services running with only a handful of people (who if they left, we would be up the creek) who fully understood how they worked/how to set them up.
I think in any situation building a system that is complex enough (for Redundancy, Performance, Scalability) while at the same time being simple enough in regards to Management, Repair, Documentation and use should be your goal.
Try steer clear of locked in Vendor specific Technologies, use open or industry standards compliant equipment/software. Don't also fall into the trap that complexity == better, at the end of the day the simplest solution will also be better.however if it was something like a small accounting firm which has 20 people it would be like. 1 server and a couple of switches a router and a firewall and thats it.
In this example you give here, size has no direct relation to customer needs. You would really need to speek with this Company and try to understand their needs/wants and requirements.
Some examples:
* They are an accounting firm, therefore they have some obligation to keep records for 'x' number of years. Does this single Machine Network have some type of storage redundancy or backup policy? (Complex or Simple, it will still need one)
* They may only have 20 people, but if they are working with multi-Million dollar firms can they handle downtime if their single Server were to crash? - How many $/hr could they lose or how much could their customers potentially lose? Could this also lead to some type of litigation?
* 20 people is small, are they trying to grow? Will this setup handle 200% growth if they decide to onboard a large number of staff through recruiting or via a marge?
Here you need to talk with each customer and determine what their needs are and their budget. Then with your Technical knowledge give them a solution that lies somewhere between their Budget and their Needs. i.e. If they are adamant that they need the fastest Machines possible, while having 99% uptime but only give you a budget of $X Dollars then you need to manage their expectations in regard to how much reliability/performance they will get for the Dollar.
Hopefully this helps,
jml. -
phaneuf1 Member Posts: 131My girlfriend says the size doesn't matter, it's how you use it!
Ok i'm out of here -
JDMurray Admin Posts: 13,106 AdminMy girlfriend says the size doesn't matter, it's how you use it!
-
truckfit Banned Posts: 78 ■■□□□□□□□□My girlfriend says the size doesn't matter, it's how you use it!
Ok i'm out of here -
paul78 Member Posts: 3,016 ■■■■■■■■■■It's really not about size. You are correct in your comparison about a software development organization where you may need different servers with different configurations, etc. for testing, development, release engineering versus an accounting organization.
It's about the mission that the infrastructure needs to serve. -
ptilsen Member Posts: 2,835 ■■■■■■■■■■I'll second the thought that the nature of the organization can transcend any assumptions we might have about the "size" of an organization based on number of users, or even based on similar metrics like revenue, number of locations, number of nodes, etc.
However, "size" on its own does often change the nature of how infrastructure is managed and what your job will be. Taking a non-specific measure of all of the above (users, nodes, revenue, locations, business, number of business units or business), you will see big differences in how things are done. A large enterprise (tens of thousands of users; hundreds of locations) is ultimately going to be very different from smaller enterprise or small business, no matter the industry.
Even taking the nuclear facility datacenter as an example, or perhaps a high-value web company (think Amazon), you can make some inferences about what the work will entail. You may have a large datacenter and a team to manage it, but you won't have some of the departments you'd have in, say, a multinational financial services conglomerate. The former examples will have a few smaller teams focused on relevant areas (e.g. hardware, virtualization, network, web), while the latter will have the same teams and then many more (multiple ERP teams, desktop engineering, application delivery, and so on). Some job postings I've seen, for example, were for teams as specific as desktop encryption or IIS.
The point to my long post is that you can make some assumptions about truly "large" organizations based on size alone. If you're dealing with 100,000 users, you're going to see a huge diaspora of IT -- lots of departments doing very specific functions. Revenue and industry won't matter. A "smaller" company with the same revenue but fewer sites and users is going to be a very different experience. At the "smaller" levels, these differences aren't as predictable. Smaller enterprises with a few thousand users might not be run differently or with much more infrastructure than small business with only a few dozen users. So, size matters, but unless you're going to somewhere really, really big, it's not the only factor to consider.