4 ms·

> In terms of infrastructure, this meant using Ansible for quickly deploying new servers where needed and adding them to the right load balancer. Currently all

> In terms of infrastructure, this meant using Ansible for quickly deploying new servers where needed and adding them to the right load balancer. Currently all I need to do is spin up a new instance with the right tag & run the relevant Ansible script To me, this still sounds awfully manual. You still need to always have an eye on load/health and proactively provision instances or risk not having the necessary capacity. Why go that route and not a template with auto-scaling and an init script or image to pull the dependencies?

ransom1538 9y ago
Or, just not use servers. Aws lambda, etc - and never care ever.
- zenlikethat 9y ago
  Until you run out of your starter account limits. AWS magic still needs to be monitored and alerted on.
  - ransom1538 9y ago
    Click on the email? Create a ticket? really? Compared to devops?
graystevens 9y ago
Valid point, and something I considered initially. However we've a security startup – the likelihood hood of us getting a huge wave of visitors, the hug of death, is highly unlikely. Our landing page is static & anything remotely intensive requires an account. We are more likely to be hit by a DDoS, which I would hate to consume by upscaling servers and burning any potential profits we have. Additionally, I have multiple alerts setup for any signs of downtime, so that any deployment can be invoked as soon as possible. However, I completely understand your perspective, and if this was a different type of startup or industry, I would probably implement it the way you mentioned.
- zenlikethat 9y ago
  I think you’re fine, personally — a workload has to have very well defined characteristics to be automatically scalable. Just paying when health checks fail and figuring out how to fix it when there’s a problem is a much better strategy than implementing “scaling automation” that might go awry.

ransom1538 9y ago

Or, just not use servers. Aws lambda, etc - and never care ever.

zenlikethat 9y ago
Until you run out of your starter account limits. AWS magic still needs to be monitored and alerted on.
- ransom1538 9y ago
  Click on the email? Create a ticket? really? Compared to devops?

graystevens 9y ago

Valid point, and something I considered initially. However we've a security startup – the likelihood hood of us getting a huge wave of visitors, the hug of death, is highly unlikely. Our landing page is static & anything remotely intensive requires an account. We are more likely to be hit by a DDoS, which I would hate to consume by upscaling servers and burning any potential profits we have. Additionally, I have multiple alerts setup for any signs of downtime, so that any deployment can be invoked as soon as possible. However, I completely understand your perspective, and if this was a different type of startup or industry, I would probably implement it the way you mentioned.

zenlikethat 9y ago
I think you’re fine, personally — a workload has to have very well defined characteristics to be automatically scalable. Just paying when health checks fail and figuring out how to fix it when there’s a problem is a much better strategy than implementing “scaling automation” that might go awry.