Getting our applications out of the cloud provided the main celebration for our exit, but seeing the actual spend tumble is the prize. See, the only way to get pricing in the cloud down from obscene to merely offensive is through reserved instances. This is where you sign up for a year or more in advance on a certain level of spend. Th...
The cloud isn’t just for storage or compute. There are a number of managed services that let you build a full application by snapping together lego building blocks.
For example, pop together a REST API handler, an auth service, a few functions-as-a-service, a database, and a storage service. Then add a static website server. Throw a CDN in front. You got yourself a dynamic application service that can be accessed globally for a few pennies and can scale up and down without you doing anything. Add multi-zone support and auto-DNS failover and you’ve got a production quality scalable, resilient back-end, for both web and mobile. When it’s not being used, it costs very little and when it goes big, hopefully it means you’re doing well. Wrap it all in an infrastructures-as-code script and you can bring all this up in 30m.
To host all that in-house, you would have to buy a lot of equipment, stage it, manage it, add cooling, electricity, security patches, upgrades, security, etc. Now you have part of your business just doing all this instead of focusing on what you do best. I won’t bother going into the tax implications of capex vs opex.
This, is what the cloud sales people call ‘undifferentiated heavy lifting.’ There are reasons to have on-prem hardware. For a lot of applications though, it makes more sense to let someone else take care of all that infrastructure cruft.
The cloud isn’t just for storage or compute. There are a number of managed services that let you build a full application by snapping together lego building blocks.
For example, pop together a REST API handler, an auth service, a few functions-as-a-service, a database, and a storage service. Then add a static website server. Throw a CDN in front. You got yourself a dynamic application service that can be accessed globally for a few pennies and can scale up and down without you doing anything. Add multi-zone support and auto-DNS failover and you’ve got a production quality scalable, resilient back-end, for both web and mobile. When it’s not being used, it costs very little and when it goes big, hopefully it means you’re doing well. Wrap it all in an infrastructures-as-code script and you can bring all this up in 30m.
To host all that in-house, you would have to buy a lot of equipment, stage it, manage it, add cooling, electricity, security patches, upgrades, security, etc. Now you have part of your business just doing all this instead of focusing on what you do best. I won’t bother going into the tax implications of capex vs opex.
This, is what the cloud sales people call ‘undifferentiated heavy lifting.’ There are reasons to have on-prem hardware. For a lot of applications though, it makes more sense to let someone else take care of all that infrastructure cruft.