The problem with sharding
New SaaS startups rarely think about how to scale their applications. Sure, they envision the day they will need to expand, and they build growth into their financial plans, but they rarely architect their applications for scalability early on. Rather, they more often focus on completing features that they can sell.But the time to think about scaling is at the very beginning—before your first customer signs up for your service. As the company rolls out feature after feature, and customers continue to sign up, the business grows. As the business grows, scaling becomes a point of concern.[ Also on InfoWorld: 3 reasons centralizing your data is a bad idea ] The need to scale often becomes evident when a new SaaS service hits a resource capacity limit, specifically data access resource capacity. Often the database, whatever the technology, is too small to meet growing demands and can’t be expanded past a certain point.To read this article in full, please click here
New SaaS startups rarely think about how to scale their applications. Sure, they envision the day they will need to expand, and they build growth into their financial plans, but they rarely architect their applications for scalability early on. Rather, they more often focus on completing features that they can sell.
But the time to think about scaling is at the very beginning—before your first customer signs up for your service. As the company rolls out feature after feature, and customers continue to sign up, the business grows. As the business grows, scaling becomes a point of concern.
The need to scale often becomes evident when a new SaaS service hits a resource capacity limit, specifically data access resource capacity. Often the database, whatever the technology, is too small to meet growing demands and can’t be expanded past a certain point.
