Scaling up and scaling out to meet new business demands
By Jason Tee
Despite recent economic trials there are still small businesses succeeding and growing. Many of these businesses will find it necessary to either scale up or scale out their application infrastructure in order to keep up with demand.
Many businesses have the foresight to start out with a setup that meets current needs and allows for a certain amount of expansion (or scalability) in the future. As the business continues to grow, however, they often reach a point where existing database capability just isn’t adequate.
That’s a good problem to have. However, it does require reevaluation of server hardware and a plan for ramping up systems to handle more load. There are a couple of different options: scaling up vertically, or scaling out horizontally. Here are some issues to consider as you make your decision.
In simple terms, scaling up means upgrading existing servers or replacing them with more powerful hardware. It could be as straightforward as adding more memory if that’s what causes problems. Or, it might be spending big bucks on a monster “big box” server to increase storage throughput and/or computing power.
On the plus side, buying more memory is one of the cheapest ways to scale up. On the downside, every individual server has an upper limit to the amount of extra memory it can support. Once the existing servers reach full capacity, it's time to upgrade to a new server.
If the main issue is a lack of processing power, scaling up to a newer version of a 2 socket server or doubling up with a 4 socket processer is an effective way to scale up. Going from 4 to 8 sockets isn’t going to happen on a small business budget. Fortunately, that kind of CPU power isn’t really necessary for non-enterprise systems.
Perhaps the bottleneck in performance is coming from lack of storage throughput. Scaling up for faster throughput in this area may entail some combination or variation of the following:
- Adding more local storage with a direct attached storage device – this option is cheap but limited in its connectivity capability for multiple hosts.
- Switching to a Storage Area Network (SAN) approach – which is more expensive but allows flexibility for further scalability down the road.
- Purchasing solid state drive (SSD) storage – which is very fast and flexible but with a steep price tag.
Scaling out involves adding more servers to increase your storage and computing capacity by distributing the load. This can be done on-site with blades servers (although some people consider adding blades to be a form of scaling up), or it can be done with virtual machines and servers in the cloud. Deciding what type of “horizontal scaling” is needed involves asking questions like:
- Do you want a pair of servers writing to the same database at the same time so all changes are replicated across the system immediately? This is a benefit when real-time synchronization of data is critical.
- Would read-only capacity run on multiple servers set up behind a load balancer suffice? This approach can be highly effective for handling a high volume of queries at low cost.
- Is the idea of loosely coupled interconnections a plus or a minus? Isolating components and processes can be good for minimizing interaction and isolating problems, but it’s not so great when you need a high level of synchronization.
- Are you using open source software? This will have a huge impact when comparing your licensing costs for scaling out vs. hardware costs for scaling up.
- Will switching to multiple servers necessitate significant changes in how our applications work or in network connectivity requirements? Factors like these can easily rack up additional expenditure of IT resources.
Sometimes, scaling out means not just adding more servers but also varying the types of server used. For example, SQL servers may be great for storing and handling one type of data but not the best solution for another type of data. The way customer data is handled for sales and logistics may be completely different than the way internal data is handled for other business processes.
It’s important to think about what type of data are stored, how the data is used and how it’s all connected. These factors will help determine whether to switch or blend servers. But it’s worth the extra effort if it means getting better performance and more efficiency out of the IT budget.
When thinking about scaling out, it’s also time to consider outsourcing. This is especially important for small businesses that have few IT personnel on hand or on call. Many of the processes for managing scaled out servers can be readily automated. But there’s still a lot of admin work that needs to be done to ensure against failures with so many “moving parts” or scripts.
Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) are options to explore for databases and the servers that support them. In fact, some small businesses do away with virtually all their on-site server hardware and move fully into the cloud for all their database requirements.
The third option
Before laying out hard-earned cash to scale existing servers up or out, consider this: If the existing infrastructure isn't being used efficiently, that’s not going to change by buying more space and power. One of the best investments you can make is a thorough review and tune-up of the code that’s being run on the servers. An investment in software can put off hardware purchases for now and improve the efficiency of new hardware purchases when scaling the hardware does become necessary.
11 May 2012
Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.