Thinking the wrong thing and feelings getting hurt. Picking the person who doesn't pick you. Forgetting someone and making them feel unimportant. Not choosing your kids firstly and when they don't choose you and your next choice is your biggest mistake. Getting lost in love that doesn't exist.letting media control you. Listening to rumors. Bad communication, and discernment. Letting anyone control you or take your rights away. Running away. Illegally being blocked by someone using our services and it effecting my pursuit of happiness. Letting go of discrimination against me, and not pursuing Justice for myself and family and friends. Not checking and fixing paperwork and getting involved in govt. Fraud. From banks, public agencies and law. Not fighting for my rights as a human being and continuing to let these assholes invade my privacy. Letting others steal my ideas and my life. Letting the law say I'm guilty before innocent. Having instincts and not reacting fast enough. Letting others talk bad to me without hitting them.Not tracking my money. Writing my brother. Not getting a career as a secret shopper and shutting down all bad utility companies for fraud and bad businesses. Letting others control my thoughts. Ever admitting I was an addict. Getting excited over nothing. Being too humble that it weakens you. Not accepting I'm crazy. Feeling sorry for everyone but myself. Helping everyone over ME. Letting my son leave. Not cleaning the other room so there's more room. Waiting on someone to save you when all you have is yourself. Believing in dreams come true.
AWS mistakes to avoid
261–270 of 276 posts
Re: AWS mistakes to avoid
#262Earlier quoted context omitted.
AWS is insanely overpriced. It's weird to me that everyone jumping on AWS and some of their customers never come close to attracting the internet traffic required to set up CloudFormation. I think if you're starting a webapp out of your own pocket and not millions of dollars of investors, it makes sense to save where you can. Using locust.io, I've seen that my current site on two $10/month Linodes can scale up to app…
You're right, but I know of a few startup teams that chose Linode, Rackspace etc. at start to account for future 'scalability' concerns. Well the number of users never came and they spent a lot of time just configuring stuff. Of course I have also seen teams that couldn't build a decent business on AWS. I think the net cost of an extra personnel (a server admin) in a startup team, is more than the cost of the server.
Huh? In general AWS is chosen for 'scalability' concerns given it's auto-scaling functionality, not Linode/Rackspace/etc.
If anything, I see a lot of people choose AWS for 'scalability' concerns when they never end up needing to scale.
Re: AWS mistakes to avoid
#263Earlier quoted context omitted.
Most of the reasons to go with AWS as a major strategic decision are to avoid paying for 3-4 (or perhaps... 40+) ops engineers to run and manage so many things that really don't add much business value in themselves and that you could hold to some form of an SLA (especially with enterprise support accounts) and recoup some costs if things came down to it. Furthermore, engineering a lot of AWS services would cost you…
"I've seen executives file AWS support requests to reboot VMs at 3 am" Isn't this falls outside amazon's responsibly area? Atleast the documentation I read and a few aws promotional talks I attended seems to suggest the contrary. Or I have understood completely wrong and amazon is now also providing managed IT services?
There are some legitimate cases where AWS support is the right place to issue a request. Just the other day I had a VM go down and I issued a request to stop the instance and it just hung there with no valid way to keep shutting it down. Turns out AWS support is the only way for most users to get an instance on a host that suddenly goes down while stopping your VM to be correctly stopped because the underlying API call does not go through and it seems like a small critical section of sorts.
But when you pay AWS so much they are pretty beholden to your requests and can wind up becoming a lot like an MSP. I've spent countless hours with those poor guys waiting on a traceroute failure or for mtr or sat to give some anomalous event that everyone suspects is something wrong in AWS when I've insisted AWS is almost never at fault because our incompetence is almost certainly the problem.
The AWS support team's worst engineer is probably at least in the top 25% of our support engineers I'd argue so I'm sure if my customer had the option they'd want to pay to have them troubleshoot our own internal networks but that's what my team is for I guess.
Re: AWS mistakes to avoid
#264Earlier quoted context omitted.
It depends on which services, but for simpler services with well understood open source equivalents (e.g. route53 and BIND) you can probably manage two per sysadmin at a similar quality to AWS with a basic API. For something like RDS or Redshift, if you're very lucky you'll get away with one sysadmin per service. This covers not just running the services, but keeping up to date with security updates, scaling the syst…
"Something like Cloudfront would cost you a million just to get going." We've used CDNs in the past, way below a million/year for a medium, growing startup. care to elaborate?
Ti believe the context is running a CDN as opposed to using.
Re: AWS mistakes to avoid
#265From the article: "The biggest problem with Auto Scaling Groups is that people assume that they are about auto scaling which they are not!"
Hmm... Then maybe the biggest problem with them is actually that they are misnamed?
Re: AWS mistakes to avoid
#266I 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…
I built a JSON templating system[0] (based on Handlebars) that is project based. Basically, you create new JSON files for each project and the system generates a CFN template that contains everything that project needs (EC2 instances, RDS instances, security groups, etc.) It's still a work in progress but I'm using it in production in my day job and I'm pretty happy with how it works. More help is always accepted. :)
Re: AWS mistakes to avoid
#267Earlier quoted context omitted.
"The cost benefits get better the more incompetent / incapable your internal IT organization is. " Yes. There will always be a less stupid solution out there that is not as bad as the bad solution. Or, you could fix IT. But that takes thought. Easier to give money to a vendor you can blame...?
Fixing completely dysfunctional F500 IT organizations is something that many, many people have tried across completely different company cultures with maybe a handful of successes I've heard of. Leading huge organizations (especially ones damaged by previously failed leadership efforts - think how attempts to refactor a legacy codebase go and multiply by an order magnitude in number of variables) is very hard and bec…
Change is tricky. What you said reminded me of an interesting tweet I came across: https://twitter.com/JICare/status/662339652825780224
Re: AWS mistakes to avoid
#268Earlier quoted context omitted.
Google Cloud is not just App Engine now. Its pretty much the equivalent to aws in features. Let me also say I have PhD in Cloud and big data (graduated in 2013), worked for Amazon aws, worked for an rackspace for year and half, I was a core contributor to OpenStqck for the products OpenStack Poppy and OpenStack Zaqar. I hope you his puts se more weight behind my statements. If you are interested to know the details a…
They aren't even close to each other in featuers. All the various additional Services AWS supports go way beyond what Google has at the moment. Numerous Database offerings, Queueing, transcoder, ... Go way beyond what Google has in place. And no the ability to run it yourself on Google is not the same.
Your statement is simply false.
Here's a material answer - https://cloud.google.com/docs/google-cloud-platform-for-aws-...
In short, Google has parity with AWS on many fronts, and exceeds AWS on many others. Only material AWS advantage at this point is full IAM. Biggest thing you gotta remember is AWS is stuck in "VM" world and only slightly deviates from that. Google's advantage is in its fully managed services, which AWS does poorly (don't tell me Redshift is "fully managed").
Google has Bigtable, which AWS has no competitor for. Google's Pubsub is vastly superior to SQS. Google doesn't need Firehose because Google's services scale to Firehose levels without needing a new product and a new price. Google has Zync transcoder service.
Google has BigQuery, which is vastly superior to Redshift in price, performance, scale, and manageability. Google has Dataflow, which AWS has no competitor for.
Even for VMs, Google offers better networking, faster disks, more reliability (live migration), better load balancer, etc.
And to put the cherry on top, Google's no-committment, no-contract price is only beat if you lock yourself into AWS's 3-year contract.
(disclaimer: work on BigQuery)
Re: AWS mistakes to avoid
#269Earlier quoted context omitted.
This is super important - I've run a number of 'oversized' instances just to get better networking. AFAIK none of the cloud providers offer a way to create a 'network' optimized instance, though containerized deployments should help with under utilizing the rest of the instance.
This was a big issue for me too. Google Compute Engine seems to have no throttling like AWS does, or at least it's a much higher cap. On an n1-standard-1 I routinely get 250+ MB/s, and near 1 GB/s for n1-standard-4 and larger. The only high bandwidth AWS instances I've found are the few expensive ones that spec 10 Gbit.
According to this page, you can get ~14Gbit networking on Google Cloud's n1-standard-8
http://googlecloudplatform.blogspot.com/2015/11/bringing-you...
Re: AWS mistakes to avoid
#270Earlier quoted context omitted.
This is categorically false. If you have large capacity needs talk to your TAMs/Account Manager and they can make it happen.
It's been true five times in the last three years for me. The elasticity isn't always there and service limits are not always granted when needed. I don't know what an AWS TAM is but the SAs have tried and failed. Make a new account and try to run 1000 c4.4xl in parallel for 1 hour. It won't happen. That's not what happened the five times, but it's illustrative. And who defines what is a need and what is a want?
That's because of a history of bitcoin mining abuse.
People post their API keys on github every day and Amazon refunds almost all of the lost compute time.