Hacker News Reader

Comment by buremba | Hacker News Reader

I thought that the deployment pipelines are part of their core business considering AWS has such products that are meant to be used by customers. I assume that the internal tools are different than what AWS customers use for deployments?

View on HN

A lot of internal teams don't use the AWS software for various reasons. So like, CodePipeline might be great, but there's an internal analogue (I'm not sure the detail I can go into here) that is awful that a lot of teams use. There's been an internal movement to try to get all teams onto AWS services, but it's incredibly slow moving and there's no timeline that I know of.

> So like, CodePipeline might be great

The entire CodeBuild suite kind of sucks when you stack it up to options available on the market including GitHub Actions, GitLab Runners, Azure DevOps, literally almost anything.

If the internal analogue is worse than the CodeStar suite, then yikes.

Codestar is simpler than and has too many feature gaps compared to the internal offerings, which makes building and deploying Amazon scale multi-tier, multi-environment services difficult.

Clearly a mistake. They should be dogfooding their offerings. A lot of tooling will probably just be better if they can host it on AWS.

Maybe they are dogfooding their future offerings, hence the experience.

Oh man, we disagree! I miss Pipelines (the internal version of CodePipeline). Having worked at startups and now at Google, that tool is honestly best in class.

FWIW, I don't miss Quilt, or VersionSets, or Apollo, or Hydra, or TOD, or NAWS Pipelines bridge. But Pipelines itself, brining all of those tools together is amazing!

I was referring to Apollo specifically, since we're naming things.

I was once pitched a startup by some Amazon vets whose elevator pitch was "Apollo for everyone". I literally laughed out loud, which was followed by some very awkward assurances from them that they were not, in fact, trying to be funny.

Reply on news.ycombinator.com