The underlying goal of Springs.io is to ensure that users only pay for what they use or consume rather than what they provision. This might seem like semantics but far from it. Cloud providers have long used the word consumption when what they really mean is provision.
Springs.io targeting over provisioning to save costs
For example provisioning a cloud instance with 2 processor cores, 8GB RAM, 50GB storage and 1TB network capacity means you pay for these resources. The reality is that many people rarely use the maximum resources that they provision.
In the example above, it might be that while both cores are used, RAM usage stays below 4GB, storage is no more than 10GB and network traffic peaks at 350GB. Under Springs.io this is exactly what you will end up paying for saving money and reducing hidden costs.
If you are using capacity management tools, it should be easy to identify that you have over provisioned your cloud instance allowing you to reduce it and save money. This sounds good on paper but is rarely enacted in the real world. There are two main reasons for this. The first is that people don’t use capacity management tools and even those that do often ignore many of the reports that showed underutilisation.
The second reason is that developers and operations staff are predisposed to provisioning based on peak requirements rather than average requirements. As a result, they will overprovision to ensure that applications continue to run even when they hit that once a year peak load point. The irony here is that one of the core benefits that cloud supporters promote is the ease of adding and shrinking resources to manage normal and peak loads thereby reducing costs.
What many in the cloud industry overlook is that configuring cloud instances to automatically grow and shrink or scale, is not easy unless you have the time to spend understanding how to configure it. As the use of cloud continues to attract many non technical people, especially in the SME space, cloud providers are failing to deliver the level of support customers require to make this work.
It is just this point that Richard Davies, founder of Springs.io commented on at launch: “We have been listening to the market and what we are hearing is that people are craving simplicity. They just want to be able to sign up to a service without having to choose instance sizes or worry about over-paying, just as you would with your gas or electricity. While some customers need greater support and configuration, many don’t, and we wanted to provide a service for users that are looking for a more simplistic offering.
For example, having to configure the environment so that it can automatically scale; this is a skill that many SMEs may not have in-house. Springs.io is very clear and easy to navigate, and best of all it automatically scales and bills users based on their actual usage – so it really does the thinking for you.”
Conclusion
The cloud has grown up with the mantra “pay as you go” but that has become “pay as you provision.” As customers increase move to cloud the savings that they first experienced are being eroded by lots of hidden costs.
Whether Springs.io can reverse this trend and grab a significant slice of the market is yet to be seen. One step towards that will be ElasticHosts packaging the Springs.io solution and selling it to other cloud providers.
One final issue will be how many customers don’t arrive at Springs.io because they ended up at Spring.io, a cloud platform owned by Pivotal Software.
