[HN Gopher] AWS Publishes Reference Architecture, Implementation...
       ___________________________________________________________________
        
       AWS Publishes Reference Architecture, Implementations for
       Deployment Pipelines
        
       Author : rbanffy
       Score  : 81 points
       Date   : 2023-02-19 15:16 UTC (7 hours ago)
        
 (HTM) web link (www.infoq.com)
 (TXT) w3m dump (www.infoq.com)
        
       | voytec wrote:
       | AWS blog post:
       | 
       | https://aws.amazon.com/blogs/aws/new_deployment_pipelines_re...
        
       | Spivak wrote:
       | My only nit with their build stages is I don't see them
       | mentioning that the pipeline stages they outline are _logical_.
       | When it comes to how the real pipeline actually runs you should
       | ignore the stages and just specify the minimal dependency graph
       | and let everything that can be run in parallel run. This usually
       | means produce your build artifact first and then run _everything_
       | immediately after. If you're feeling fancy you can have the steps
       | remember the logical stage they're in and bail out of later
       | stages on failure.
        
         | jvanderbot wrote:
         | Not necessarily. You could do staged deployment or a release
         | train built around beta vs gamma testing before prod.
        
       | bobnamob wrote:
       | Not mentioned in the article but I'd recommend an end to end test
       | pipeline as well. Deploy your tests like they're your customers,
       | independent and "adversarial".
       | 
       | Also, one-box/one-cell deployment stage before your production
       | stage. Beta/gamma are well and good, but they'll never perfectly
       | replicate an actual prod deployment
        
       | Dowwie wrote:
       | How much of this is really meant for AWS sized problems?
        
         | twblalock wrote:
         | If you deploy to multiple regions or datacenters it doesn't
         | matter how big you are -- you should orchestrate deployments so
         | you don't deploy to all of them at the same time. If something
         | breaks, you'd rather break a subset of regions than all of
         | them.
         | 
         | You should also deploy new code to some kind of non-production
         | environment before going to prod. Even companies with the best
         | possible canarying in prod will still do that.
         | 
         | Some of the technology involved is definitely AWS-scale, but
         | the principles of software rollout are broadly applicable.
        
       | xenophonf wrote:
       | It's nice to see something like this. I maintain a reference
       | implementation of some open-source software on AWS, but that was
       | pieced together over the years from other people's work, now
       | deleted blog posts (God bless the Internet Archive), and
       | unmaintained sample code on GitHub. Hopefully, a fully worked
       | example like this will fill in a lot of the blanks in my
       | understanding, like how to best implement blue/green deployments
       | (the CodeDeploy hook for CloudFormation has a lot of weird
       | limitations), unit test automation, and monitoring.
       | 
       | Edit: It's blog spam, sadly. Here are direct links to the actual
       | blog posts and tools.
       | 
       | https://aws.amazon.com/blogs/aws/new_deployment_pipelines_re...
       | 
       | https://pipelines.devops.aws.dev/
       | 
       | https://github.com/aws-samples/aws-deployment-pipeline-refer...
       | 
       | https://aws.amazon.com/builders-library/automating-safe-hand...
        
       | ldjkfkdsjnv wrote:
       | This looks similar to the internal pipelines framework that all
       | of amazon uses to deploy code. Funny to see truly how much value
       | amazon has gotten out of developing frameworks for the retail
       | business, and then making those frameworks available publicly.
       | The abstractions work because they have already been vetted
       | across amazon for a decade
        
         | faizshah wrote:
         | I think the last missing piece is getting reproducible builds
         | which I think you can get from buildpacks [0], NixOS [1], or
         | Bazel [2] running in your CodeBuild.
         | 
         | [0]: https://buildpacks.io/docs/features/reproducibility/
         | 
         | [1]: https://nixos.org/
         | 
         | [2]: https://testdriven.io/blog/bazel-builds/
        
       | faizshah wrote:
       | I also found this post on Cell based architectures this morning,
       | I didn't know this was public:
       | https://aws.amazon.com/solutions/guidance/cell-based-archite...
       | 
       | And a talk on what a cell based architecture is here:
       | https://youtube.com/watch?v=HUwz8uko7HY
       | 
       | Cells are basically subsets or shards of customer resources with
       | infrastructure isolated from other cells. The reference
       | deployment pipeline in the blog post [0] would deploy to each
       | cell individually in different waves depending on how your team
       | configures the waves ultimately limiting the blast radius of a
       | deployment to a smaller subset of customers.
       | 
       | [0]:
       | https://aws.amazon.com/blogs/aws/new_deployment_pipelines_re...
        
       | nimbius wrote:
       | I've always seen AWS as a rather expensive answer to the build.
       | Any other vps provider or even dedicated Colo is likely much
       | cheaper and less locked-in than the amazon ecosystem.
       | 
       | That having been said, the "reference architecture" being offered
       | just feels like a slow day in the AWS marketing department during
       | a recession. Nothing really special about it unless I've
       | completely missed something?
        
         | [deleted]
        
       ___________________________________________________________________
       (page generated 2023-02-19 23:00 UTC)