There’s a line item for “integrated log analysis” that needs to be met, but there’s less analysis on how useful that feature may be in reality.

Enterprise IT processes are filled with these kind of word-docs filled with checkboxes, and for that, AWS's featureset excels.

It does seem like as of last week's announcement they are starting to try to fix this. I was annoyed we had to log stuff to both Cloudwatch and Splunk to try to get decent logging.

About the only thing I don't like doing is managing my own DB server... so I'm really happy to see DO expanding into this space. For applications and services, dokku gets me where I need to be with the least fuss. I know if anything took off it would mean some pain, but I'll take that when/if it ever happened.

The integration aspect really matters for security and compliance, as well as standardisation: all of which become bigger concerns the larger your organization. If you use the AWS service, you can re-use IAM, CloudTrail, CloudFormation etc. If you attach a third-party service to your AWS setup, then there's a bunch of things to work out.

That being said, they excel at building things that are scalable, reliable and secure, and while you may only see that as 10% of the features, for a lot of ppl that is 80-90%, especially if data is involved. They do tend to improve their products over time as well and for better or worse I am sure a lot of those resourcing decisions are driven by data/revenue rather than how crappy the product is.

At the end of the day this allows others to continue to compete with them, which is a good thing.

Whether or not that's enough remains to be seen.

Reality is, they didn't want to pay FEE's big money because they weren't worth it, and now the company is starving for good UX and they want to pretend they invented a solution to the problem by creating a role that's existed at Google for more than 10 years.

Amazon finally rectified it by introducing the FEE role, which has the same pay scale as SDE's. Perhaps more importantly, the WDE role terminated at WDE III and even that was incredibly difficult to achieve.

That is just your opinion, I love McD burgers. I can also guarantee that in a line up of 5 burgers you wont be able to figure out which one is from McD with blindfold on.

I mean, we've all got a limited amount of time to learn and try new things... being very hard to get some simple SaaS endpoints setup from AWS is often an exercise in frustration. And while I appreciate all the detailed IAM and Firewall options, on Azure (by comparison), if I have the correct security token, I can generally connect over a secure connection from anywhere in the world to pretty much any of their services without friction.

And if I'm going to have to learn a bunch of crap, I'd just assume learn a little more and roll my own on Linode or DO, or any number of much less expensive compute options.

It works because if you are already using a bunch of AWS services, and then you need something that they are providing, you will give that a go first. If it doesn't provide enough, you will move to something else.

Many, many projects, will meet business or contract requirements with the lowest friction product. A great example is "IDS/IPS" or "Anti-malware". Unless specific metrics, requirements, or fine/fee structures exist, 9/10 times, people will check the box on the easiest to deploy.

This is a broad statement :-)

Compliance is mandatory and often sales advantage for being able to sell to certain class of enterprises.

IMHO, quality vs. rich feature set are different things and I see that being mixed up in the overall discussion. All AWS services exceed certain quality standards. Services are built to solve customer problems first. It's not unusual to find gap in feature set vs. competition.

Disclaimer: I used to work for AWS, but do not work there anymore.

This is pretty much spot on.

We use a ton of AWS's services because AWS is already on-boarded for our enterprise. It's way easier to use a AWS feature than to on-board a specialized vendor.

They should brand it 'AWS Basics'.

Having to manage across multiple different system vendors is not a trivial task, if AWS offers a half baked, yet good enough solution, the customers at least will be willing to give it a try.

Ultimately, the competitiveness of your service shouldn't be defined as whether Amazon choose to compete with you or not. If it is indeed the case, then that is something you need to rethink how to position yourself in the market.

Or is it that they hope people would rather get everything from 1 vendor even if it's sub par?

I've noticed for example, that Prime Video and Music are inferior Netflix and Spotify. But I could see myself, if I wanted to tighten my belt, dropping the latter two to save some monthly fees.

Depends on what you're trying to do... I find that dokku goes a long way if you just want to coordinate a few things on a small scale. It's also relatively easy to put 2-3 instances behind a load balancer and just doing blue-green deploys that way. Elastic Beanstalk was also pretty easy with a simple Dockerfile in place. In terms of having a modestly flexible service layer.

I can't speak to the rest, but I just tend to avoid friction as much as possible for as long as possible. I'd rather have a good enough solution that I can work with quickly and not have to spend a lot of time/effort on over more complex solutions.

I don't know what Samsung did with the stuff that was being done by Joyent, but theirs was always an interesting approach in my mind.

Or pay overpriced “Implementation Consultants”. I have no sympathy for people who don’t take the time to learn the subtleties of the platform they choose to use.

On the other hand, I’ll gladly charge them a nice hourly rate to help them.

There is no way to get something really that way but getting away from IT is already worth it even if the result is still not very good.

So so did everything like I would do on prem with a bunch of VMs.

I asked them to set up a dev, qa, uat, and production subnet. All with multiple VMs.

I used 7 VMs for Hashicorp’s Consul, 7 for Nomad, and 7 for Mongo. (1 for each non production environment and a cluster of 3 for production.) I also used Fabio. Between all of that I had my configuration key/value store, service discovery, job scheduling (Nomad), and data store. I also had build boxes for Team Foundation Server (or whatever MS is calling thier hosted TFS version these days with local agents.)

It wasn’t until after I was getting ready to leave the company that I realized how dumb this setup was for an AWS hosted solution. Don’t get me wrong, I wouldn’t have done too much differently today for a self hosted solution.

I left the company, self demoted to an individual contributor role at a smaller company that was “cloud native” and I spent the next year learning AWS inside and out and taking advantage of reimbursements for certifications.

I’m still at the company now, but when and if so do decide to leave, I’m. It going back to being an architect for a company. Consulting is way more lucrative.

Historical reasons. The technology has evolved, and AWS has simply continued to add new services. Sometimes there is overlap. Perhaps if they were starting from scratch they might offer only one product.

They have nothing that is feature complete, but if it were just 10% they wouldn't get buyin.

Even their API interfaces are dated and cumbersome to use.