Hacker News Reader

This is not unique, it is the “integrated” vs “best of breed” offering. It’s like the oldest business school IT case. Amazon isn’t trying to sell the best anything, they’re selling one spot where you can get everything you need even if some of it is crappy.

"Overwhelming mediocrity"

Software industry's evolution in a nutshell. New tools are this to old tools. SaaS are this to desktop software.

It seems like your qoute is a common saying but neither me nor google seems to really know it. So I would guess your downvotes come from not providing enough context about what you want to say.

This makes a lot of sense because most of us aren't going to work with a different company for each and every part of our infrastructure. If it's super critical it be the best, I'm going to seek out the right tool for the job. If I just need to have something, at a basic level, I'd rather work with a company I already work with.

Absolutely. I think the parent poster is massively overgeneralizing that CloudWatch is only good for "hobbyist users". Nearly every product I've worked on that's utilized AWS has sent to CloudWatch, because unless they have special needs CloudWatch doesn't meet then you might as well use it because nearly every AWS product and docs are already sending their logs there by default and it's one less infrastructure company to keep track of.

I have been super-unsatisfied with the status quo of Cloudwatch; it is not a production grade logging system if it allows you to keep zillions of streams in logs but provides A) no way to search through them all to find the last time you had a certain error containing a certain string (grep -r -i on EFS plain text logs is better than Cloudwatch!), and B) no way to trend specific errors/issues over time.

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.

Have to agree... I generally log to line separated json for logging, and what CloudWatch does offer for this works out really well for the times I've used it. TBH, for small/personal projects, I'm more likely to use, and have used dokku on Digital Ocean.

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.

It’s also a result of feature-driven RFPs or similar check-the-box driven evaluation.

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.

This.

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

> This is not unique, it is the “integrated” vs “best of breed” offering.

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.

UI/UX is definitely not their strong suit and CloudWatch is one of the worst offenders. I really hope they aquire a company to deliver a completely revamped observability platform in the same vein as where Stackdriver is headed. They really seem to stuggle building things in house that have a great user experience.

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.

A big part of that was because until recently Frontend Engineers were second class citizens at Amazon. It became easier and easier to work for a year here then move to Facebook/Google and a variety of unicorns and get a huge pay raise.

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

It’s kinda crazy that the whole FEE thing was treated like a lightbulb moment for the company when everyone else in the industry had them.

Amazon moves incredibly fast when it comes to products and incredibly slow when it comes to employee growth. They are treating it like a lightbulb moment, but several of the people involved in this have been working on it for a decade.

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.

I hope there is buy in from at least the Product Manager level as well. The issues are deeper than just a new coat of paint.

What changed?

Previously Amazon separated frontend focused engineers (WDE's) and software engineers (SDE's) but the former had a lower payscale than the latter. The end result, every single time, is that great FEE's would simply work at Amazon for 1-2 years and move to Google or Facebook where they were paid considerably more.

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.

API gateway is one of the worst UI's i've ever used.

Being the worst is not as bad as people think. McDonalds has the worst burgers and Taco Bell the worst tacos, yet both massively successful operations.

I doubt McDs has the worst burgers but I get your point. The pros of McDs, you go anywhere in the world, you can expect reasonable quality, the familiarity of the brand/ products at reasonable prices. They won't be the best or the worst but do the job.

They are absolutely the worst burgers in the world. I'd take a burnt freshly grilled burger over a McDisappointment.

They're definitely not the worst burgers in the world. I've had worse from commercial and non commercial sources.

> They are absolutely the worst burgers in the world.

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.

Clearly you have not had Jack in the Box tacos.

Clearly you have not seen Azure's UI.

Aws CodePipe or Workdocs does not agree with this...

They're revamping some of the console pages, like RDS and ActiveMQ with a new design language, but I think their official stance is that no one in their right might should be using the console at scale anyway. The console itself uses the APIs, so anyone doing anything respectable should just use the APIs. The console is really a second class citizen, and I assume the designers who work on it are as well.

I don't want to have to learn to interface with a bunch of arcane APIs or terminal interfaces to string together a proof of concept on a cloud provider. In my experience Azure was by far the easiest (and most costly) to get off the ground and something built with.

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.

Amazon’s goal with this is to check the boxes. Enterprise customers don’t give a hoot about quality, just compliance.

Not true, they clearly do care about quality.

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.

Dont you think your statement contradicts between the first sentence and the second?

Nope

They care about quality as long as it's "good enough".

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.

"Enterprise customers don’t give a hoot about quality, just compliance."

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.

Any recommendation for someone who cannot relocate but has an AWS solutions architect certification to work remotely?

> Enterprise customers don’t give a hoot about quality, just compliance.

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.

> Maybe they're hoping that's enough for the bulk of users (and maybe it is)

They should brand it 'AWS Basics'.

There are many products that they sell as PaaS that are much more beginner friendly. Elastic Beanstalk seems like a good starting point for people looking for "basics"

It's a take on "Amazon Basics" from their retail presence; simple/lower-quality versions that are good enough for 90% of people.

I think you would be surprised to see how the enterprise see simplicity as an important part of defining quality.

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.

This is so true. For example, AWS ElasticSearch, only a tiny fraction of plugins are supported, it doesn't even support gzip compression for requests and responses....

>Maybe they're hoping that's enough for the bulk of users (and maybe it is), but from what I've seen, if you want to do anything serious, you still have to use a third-party.

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.

Absolutely. Netflix in 4k is, what, $13? And Spotify is $10. Amazon Prime is getting to be a better deal every year, but not if you subscribe only for shipping speed.

> I want to run a container. Should I use ElasticBeanstalk? ECS? Fargate? EC2 with Docker?

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.

Another issue I have with AWS is that they simply provide too many ways to do the same thing. I want to run a container. Should I use ElasticBeanstalk? ECS? Fargate? EC2 with Docker? I've been using AWS for years, so I get the subtle differences, but some users just want to click a button and be done with it, which is where third-parties can excel.

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.

In a lot of companies you simply don't get the time to study things. I am right now working on porting a project to the cloud that was previously supported (and fucked up) by our IT department but it's hard to do it right. Ths director has declared that AWS is best and there is a lot of pressure to show something soon or the move to cloud may get cancelled.

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.

I feel your pain. I was the dev lead at a company and responsible for a decently complex new green field project. They decided to “move to the cloud” at the time I didn’t know anything about AWS and the “consultants” that were brought in only knew networking and the best they could help us do is a “lift and shift”. I was neither given the time to research, given good consultants that knew anything about the development and Devops portions of AWS or given the access to a dev account to experiment and do proof of concepts.

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.

> ElasticBeanstalk? ECS? Fargate? EC2 with Docker?

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.

Also companies get stuck in their stack and then demand features that don't really make sense for the core AWS product. Like "I wish my Lambda container would live forever"

This is what MVPs are all about, surely? Amazon may have vast resources, but they are not infinite. Amazon strategy seems sound from a business perspective.

This is true, but 10% really isn't fair.

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

There's also EKS now, which is competing directly with ECS / Fargate I guess?

It’s also them realizing people are willing to switch to Google for managed Kubernetes over using mediocre ECS.

Somebody noticed! I thought it was just me.

Even their API interfaces are dated and cumbersome to use.

Could you elaborate? Genuinely curious.

Not OP, but the problems I remember are: Inconsistent use of query parameters. Retrieving metrics for managed Elasticsearch requires more parameters than almost anything else. Inability to get arbitrary percentiles in the same query as “standard” percentiles. Documentation is awful. I found it was mostly good enough to get you to raw JSON output, and then it was on you to figure out how things worked. The delay is a killer. I understand eventual consistency is a thing, but that’s not really useful for metrics. Please, for the love of $DIETY, record them in a fast store and long term store and don’t make me wait 10-15 minutes for ELB metrics.

Splunk competes not with CloudWatch, but with Elasticsearch Service, that includes Kibana.

take a look at insights