2 ms·

Monitor the resources, look for over-provisioning. I see a lot of that. Use reserved instances rather than spot pricing. Multiple tools/services in the space

Monitor the resources, look for over-provisioning. I see a lot of that. Use reserved instances rather than spot pricing. Multiple tools/services in the space you describe.

ja-mu 3y ago
Do you see any scheduling around off hours? The tools I was referring to specifically have this capability to schedule downtime for your resources outside of the hours when they are normally used.
- oriettaxx 3y ago
  many have this in mind, that at the end do not do much: you can automatically scale down EC2 instances at night, but then spider comes and hit all your alarms (and you want to avoid night alarms).
- gregjor 3y ago
  That hasn't come up with my customers. They run web applications they need live 24/7. We do see traffic patterns but no times with zero activity. I have seen over-provisioning with almost every customer I take on. Once we look at actual usage we can scale back. Often they have things like multiple web servers and load balancers they don't need, excessive database replication and backup retention. I've seen fully redundant setups in secondary regions for failover, but no failover plan or testing. That can all add up.
  - ja-mu 3y ago
    How do you customers develop these 24/7 web applications they have? Are these development resources needed 24/7?
    - gregjor 3y ago
      I'm not sure what you're asking. Sometimes development happens on developer computers, staged for review to instances/databases spun up for that purpose. Sometimes the developers have a parallel but scaled-down copy of the production environment. The web applications I work on, with one or two exceptions in the past, don't have complex dev requirements. Often deployment amounts to "git pull." If you work with complex dev environments and CI/CD pipelines that cost enough to care about, maybe look at how to simplify that. How development and deployment happens varies tremendously, so I don't have any general advice beyond "simplify" and examine the processes and resources your developers use and say they need. Every process and resource should have cost, benefit, and risk assigned. Left to themselves programmers too often add complexity and process for its own sake, or out of unexamined adherence to "best practices."
      - ja-mu 3y ago
        Sorry for being vague. It's these a bit larger and more complex dev environments and pipelines that I had in mind. I've worked with many companies where these are the norm - and very rarely see anything done about the costs. Largely this seems to be because existing tooling doesn't really support more complex dev team use cases.

Monitor the resources, look for over-provisioning. I see a lot of that. Use reserved instances rather than spot pricing. Multiple tools/services in the space you describe.

ja-mu 3y ago

Do you see any scheduling around off hours? The tools I was referring to specifically have this capability to schedule downtime for your resources outside of the hours when they are normally used.

oriettaxx 3y ago
many have this in mind, that at the end do not do much: you can automatically scale down EC2 instances at night, but then spider comes and hit all your alarms (and you want to avoid night alarms).
gregjor 3y ago
That hasn't come up with my customers. They run web applications they need live 24/7. We do see traffic patterns but no times with zero activity. I have seen over-provisioning with almost every customer I take on. Once we look at actual usage we can scale back. Often they have things like multiple web servers and load balancers they don't need, excessive database replication and backup retention. I've seen fully redundant setups in secondary regions for failover, but no failover plan or testing. That can all add up.
- ja-mu 3y ago
  How do you customers develop these 24/7 web applications they have? Are these development resources needed 24/7?
  - gregjor 3y ago
    I'm not sure what you're asking. Sometimes development happens on developer computers, staged for review to instances/databases spun up for that purpose. Sometimes the developers have a parallel but scaled-down copy of the production environment. The web applications I work on, with one or two exceptions in the past, don't have complex dev requirements. Often deployment amounts to "git pull." If you work with complex dev environments and CI/CD pipelines that cost enough to care about, maybe look at how to simplify that. How development and deployment happens varies tremendously, so I don't have any general advice beyond "simplify" and examine the processes and resources your developers use and say they need. Every process and resource should have cost, benefit, and risk assigned. Left to themselves programmers too often add complexity and process for its own sake, or out of unexamined adherence to "best practices."
    - ja-mu 3y ago
      Sorry for being vague. It's these a bit larger and more complex dev environments and pipelines that I had in mind. I've worked with many companies where these are the norm - and very rarely see anything done about the costs. Largely this seems to be because existing tooling doesn't really support more complex dev team use cases.