Live data from Hacker News

Amazon's cloud business is competing with its own customers

cnbc.com

171–180 of 182 posts

Re: Amazon's cloud business is competing with its own customers

#171
post #141

Earlier quoted context omitted.

trying to see how this is the Trader Joe's model. i thought what Trader Joe's did was find food makers that sell products at other retailers (e.g. Naked Juice, sold for example at at Whole Foods) and then negotiate a deal with that same food maker to supply that same product to TJ's under the store label and at a lower price. if I'm not mistaken, TJ's also develops its own product concepts (e.g. Thai Chili Cashew Nut…

Hmm I was under the impression that they were ripping off those companies, but you could certainly be right. I just saw the pattern of (for example) Snap Pea crisps under a non-TJ brand get popular at TJ's, then TJ's labeled version comes out and the other one disappears.

You could be right too. I'm not sure.

Trader Joe's is very secretive about who supplies its products. When I google for something like "Who makes Trader Joe's $product" I find various articles that seem like they've actually uncovered suppliers in certain cases, and I think those suppliers are pretty willing to sell a version of their existing products at TJs for lower prices. But I certainly don't know the whole story.

One other thing I notice about TJs is that it does not carry a "full" product line like a normal grocery store. TJ's often seems to cherry pick or negotiate relatively good deals from outside food suppliers where they can. And if they can't do that, in many cases, they just don't offer that product at all. Still, they offer a wide enough product line to keep the customers flowing in.

http://www.time.com/money/4894722/who-makes-trader-joes-prod...

https://www.eater.com/2017/8/9/16099028/trader-joes-products

Re: Amazon's cloud business is competing with its own customers

#173

The trend I've noticed is that AWS makes a lot of very half-baked services that appear to compete with third-parties, but provide about 10% of the features and usability. 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. Take CloudWatch for example. It's technically "competing" with Splunk, Data…

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

> 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.

Re: Amazon's cloud business is competing with its own customers

#174
post #34

The trend I've noticed is that AWS makes a lot of very half-baked services that appear to compete with third-parties, but provide about 10% of the features and usability. 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. Take CloudWatch for example. It's technically "competing" with Splunk, Data…

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.

> 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.

Re: Amazon's cloud business is competing with its own customers

#175

Earlier quoted context omitted.

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 compa…

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.

Re: Amazon's cloud business is competing with its own customers

#176

Earlier quoted context omitted.

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 ma…

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.

Re: Amazon's cloud business is competing with its own customers

#177

The trend I've noticed is that AWS makes a lot of very half-baked services that appear to compete with third-parties, but provide about 10% of the features and usability. 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. Take CloudWatch for example. It's technically "competing" with Splunk, Data…

> 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.

Re: Amazon's cloud business is competing with its own customers

#178
post #15

That's why I think MongoDB's new license which prevents AWS etc from hosting as a service without open sourcing makes sense ( https://news.ycombinator.com/item?id=18229452 ). Amazon barely contributes anything back to the community and is known for destroying OSS businesses.

I wonder with Amazon if we’re seeing a failure mode of Apache and BSD licenses, and if the future OSS might trend back towards more aggressively being copy left... or some place in between.

Even GPL wouldn't stop Amazon from offering API interfaces to services built on GPL software. They're not selling/distributing the software. AGPL and similar provisions might work, but then you risk alienating most commercial interest.

Many either don't understand or don't want to take on any risk associated with some kinds of licensing or barriers in certain situations. Right now I've had to work around calling a GPL executable (pngquant), simply because we don't want to have to require it as a separate install. So switched to an alternative implementation.

It just depends on where you are, where your business is, and what you're working towards/against. It's hard to find a balance. And it will take some time to flush out. MongoDB and Redis come to mind here. They have to make some money to pay their bills and developers, also profit isn't a bad word. At the same time, huge cloud providers are offering services using their software and the devs make nothing. I get both sides here. There's no perfect solution here.

Re: Amazon's cloud business is competing with its own customers

#179
post #160

Earlier quoted context omitted.

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.

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.

Re: Amazon's cloud business is competing with its own customers

#180

Earlier quoted context omitted.

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.

Post reply on HN