[kbanman]

Speaking as a former AWS Engineer, I disagree with the sentiment that they are able to glue AWS services together better than what a competing non-AWS company can do. Internally the use of AWS is subject to the same constraints and APIs you and I have.

Their competitive advantage is their captive customer base, which will much rather pay a premium to use an AWS-managed service than use another vendor.

[threeseed]

AWS biggest advantage is in the enterprise space.

Which is that companies do not procure individual AWS services but rather AWS itself. Meaning that whenever AWS releases a new tool it is instantly approved and available for use across the company (baring internal processes e.g. security hardening).

Compare this with a startup which has to go through a 6 month long procurement process complete with vendor bake-offs in order to sell their similar tool.

If AWS continues to move into the application space they will surely dominate the enterprise because of this.

[rorykoehler]

Our whole cloud procurement strategy is based on this page https://aws.amazon.com/compliance/services-in-scope/

Just yesterday I selected SNS for a project instead of a local provider because AWS put it through the security audits we care about and we don't win prizes for spending time on these decisions.

[lmeyerov]

Yep, the two-step:

-- AWS advertises the tool via the console and preintegrates it from both directions

-- IT+Procurement already approved AWS for projects, so PMs can skip vendor/tool approval+onboarding dances and focus on the budget one

True of not just AWS but Azure + GCP too

Startups can compete, but gets into stuff like deep tech or cross-vendor integrations, where the visibility and integration advantages don't apply as much to the cloud vendors so they rather go after easier targets until they can't. (Folks here posted about UI, but for b2b, I disagree for most cases, unless there's something deeply technical about it that a 20 person team can't copy.)

[peterwwillis]

The exception is open source software. Free Software's biggest risk to the org is patent and license encumbrance. If we can develop an easy way to detect such things in Free Software, and we develop communities where enterprises can freely contribute to them (to make them more Enterprsey), then it has a chance to replace incumbent managed solutions.

[lmeyerov]

I'm mixed here --

- Historically, OSS seems to be free product dev for big cloud (... cue AWS's paid PR people to say otherwise ... ). Their integration, advertising, and procurement advantages makes it MUCH easier to win contracts before the OSS devs may even know it is being used and without a bid process. For a fraction of the effort and contribution, they are switching it to a model of monopoly channel owners vs content producers and and driving the sw margins to 0 on the content side. That's why anti-big-cloud LGPL-when-SaaS style licenses are emerging. There are always exceptions, but it's not the axis to compete on unless you do such a license..

- I agree about the community aspect, indirectly. If the software, in addition to being OSS, relies somehow on community and its steward -- not just source code -- and participation in it is somehow what's paying for the OSS dev, yes. For example, maybe the community is also a social network (Slack/Teams across orgs), or generating threat intel -- the software (post-scale) matters less post-scale, so forking is ok.

[justicezyx]

The ability to stop by the desk of S3 team member and ask whatever technical questions and get authoritative answers is enough to defeat any competitors who want to build products on top of S3.

Note mentioning accessing to road-map, strategic investment, genuine appreciation of product strength and weakness etc.

[devcpp]

Don't forget being able to get high priority in the backlog if you need a feature from another service in order to launch.

Former AWS engineer who launched a service here. That, access to source code and being able to setup an hour-long meeting with any engineer are the big points. Not that I think that lacking these is insurmountable, but they're very nice to have.

[protomikron]

You underestimate how hard it is in large companies to actually speak to the people in charge that can help you concerning your problem.

[justicezyx]

I did not, I am comparing that to a random guy from some random startup, who is ranking even behind the poor customers who cannot get hold any devs for their confusing issues of using AWS...

[orf]

> Internally the use of AWS is subject to the same constraints and APIs you and I have.

Is that true though? IAM isn’t open, and things like service accounts and service chaining (a can only access b through c) are also not.