91–100 of 276 posts
Check out http://convox.com/ (YC S15) for an alternative to avoiding manual infrastructure.
That's exactly right, avoid manual infrastructure.
Someday we will all have something like Rails for infrastructure. Strong conventions around best practices.
If you follow these conventions you can avoid bespoke or manual configurations and focus solely on your app logic.
We're building Convox to advance this goal.
CPU/Memory aren't the only measures of underutilization. If you require high instantaneous bandwidth throughput, then the networking capacity available to your instance roughly increases with the size of your instance. This includes both EBS as well as other Network traffic.
Table with Low/Medium/High: https://aws.amazon.com/ec2/instance-types/#instance-type-mat...
Example benchmark with c3 instances: http://blog.flux7.com/blogs/benchmarks/benchmarking-network-...
If you're more concerned with just EBS network throughput, check out the table on this page instead: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-ec2-...
Does anybody have experience with running a VoIP (e. g. Asterisk) on AWS?
Earlier quoted context omitted.
yes, use multiple accounts. you can use STS to grant permissions between the accounts if needed.
STS works, but I feel like multiple accounts linked is more of a hack than using a single AWS account. Of course, if you use a service that is not available in both regions, use STS.
Also, dont use Dynamo unless you have a really good reason. "It scales better than MySQL" is not a good reason. Have fun migrating data and re-indexing constantly!
Is local secondary indices and lower operational costs than Cassandra a good reason(s)?
So I'd modify these a bit. We run a very large AWS infrastructure as a engineering team (no dedicated ops). 1. Use CloudFormation only for infrastructure that largely doesn't change. Like VPC's, subnets/ internet gateways etc. Do not use it for your instances / databases etc, I can't recommend that enough, you'll get into a place where updating them is risky. We have a regional migration (like database migrations) th…
I like CloudFormation. Unfortunately it is very unwieldy to write CloudFormation templates directly, and we're not about to start using the AWS CFN GUI editor! It seems like the assembly of the AWS ecosystem. Does anyone else have a favourite hammer for this particular nail? I'd love to have something better than our home-baked solution, but I'm yet to find anything which doesn't introduce other flaws, such as an inc…
Some people like SparkleFormation ( http://www.sparkleformation.io/ ). I'll warn you, though, that it's not a good example of how to program in Ruby. It abuses method_missing to the point that it makes your implementations difficult to debug.
Earlier quoted context omitted.
If you'd consider something other than CloudFormation, there is also Hashicorp's Terraform. It has an AWS provider ( https://terraform.io/docs/providers/aws/index.html ) which creates resources and maintains the state in a file that you can store in version control ( https://terraform.io/docs/state/index.html ).
Terraform, as an idea, is brilliant. Mitchell and company isolated a hugely important need and tried to fill it, and I give them all the credit in the world for that. Cross-platform cloud provisioning? Gimme. But I cannot in good conscience not relate what a disastrous experience Terraform has been for me at both jobs and clients. Writing reusable code in Terraform is an exercise in frustration due to the extreme clu…
Honestly curious, can you point to one or two?
I'd like to add, if using Elastic Beanstalk, don't directly attach an RDS instance when creating the environment. If you do, you won't be able to destroy your environment without also deleting the RDS instance. Instead, create the RDS instance separately, and just add the proper security group for the environment to be able to access the host. Then you can easily create a new eb environment with any config changes (t…