Shari O. and Cory joined and were talking to John and I about server costs. I was impressed, they had a multiple page spreadsheet and were trying to really dial in exact costs and even semi associated costs. In the past, we primarily just looked at raw costs, and didn't take into consideration maintenance, monitoring, upgrades, and primum server support for our servers and boxes. Lots of back and forth. I'm excited to see us looking at real costs. We have flown by the seat of our pants for way too many years.

We got pretty deep in to costs and what we gain from having Fusion Reactor and server monitors in place. We are being charged by the minute that those servers are being monitored. The costs stack up really quickly. We've quadrupled our costs in the last couple of months. We looked at ways to possibly bring that down or manage it better.

John keeps bring up this concept of providing a white-glove type service for our big clients (tons of server monitoring, optimization, and access to reports and even system admin personnel). Anyways, just throwing things around. We were also getting into deep level configuration scripts and how to manage some of our existing servers and assets. One of things that we were talking about was dealing with old corps and inactive accounts (old or dead data) and how to clean some of that stuff up and make it faster and smoother.

We talked about monitoring our clients and their storage levels, media/content files, number accounts, amount of data, traffic, and overall usage. We have some that we know that are big and there are others that slide under the radar because they don't call us or complain. We need to help those who want to play and charge accordingly. Some of our clients are so different, based on their habits, usage, and system needs.

There was some talk about wiping data and starting fresh for certain sandbox and smaller accounts. We need to load up certain servers with more clients to make it economically feasible to keep certain servers up and running. Basically, manual load balancing and monitoring what clients are on what boxes and how those boxes (servers) are doing (sever health). We have some of the servers that we probably need to kill and get rid of them. The other option is loading them up with more clients and then really using them.

We have a project out there that has and keeps circling around. It is called the datasource or world building project. Currently, we have a perfect one-to-one relationship between a data server and a supporting database server. We would like to allow for a single data server (code box) to interact with multiple databases, as needed. Make it more configurable. This datasource project would allow us to do those types of things. This has been referred to as getting our clients off the bus and getting them setup with their own virtual motorcycles (quick and speedy smaller databases). We would love to split some of these things up and make everything faster.

Another big project is paring down some of the big corp-wide settings tables. We have two huge ones right now that are over 400+ columns (going across or horizontal). We would like to rebuild this system and stack things vertically (data records per setting - going down vs a single column going across or a unique field per setting). Anyways, this project keeps rearing its ugly head as well. We are starting to work on it (Wayne and John).

The last section of the meeting got back to budgets, checking and monitoring usage and traffic, checking CPU's and RAM allocations per server, and adjusting as needed. Along with these budget type questions and topics, we would also like to look at possible up sales and offering other services to our clients. Including targeted or specific offerings to certain clients. Trying to harness more out of our existing clients.