4 ms·

Show HN: Awsboilerplate – Get live on AWS in minutes (react, lambda, cicd, cdk)

32 points by awsboilerplate 5y ago

deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
davidjdoherty 5y ago
Woop
davidjdoherty 5y ago
Woop!
leohonexus 5y ago
A CI/CD pipeline re-bootstrapping itself to config changes is pretty innovative - I wish more companies adopt this pattern.
- nsonha 5y ago
  Isn't this called gitops or smt, I'm not an infrastructure person but I've been hearing about this for the past 2 years or so
  - awsboilerplate 5y ago
    Agree that the direction of travel for several years has been to move monitoring and infrastructure to 'be code'. There are different names for different aspects - gitops (typically monitoring or ops activities) infrastructure as code, etc. However, it has been incomplete. Two ways in which awsboilerplate is a natural continuation/implementation of the concept: 1. (Codebuild is a project step within the pipeline and Codepipeline is the overall pipeline). In AWS the codebuild build spec has been dynamic - when you commit a change to a build spec it updates next time the pipeline runs. However, the codepipeline / pipeline definition itself was not dynamic. It was statically created typically in the CLI or cloudformation. If you wanted to evolve the pipeline (add a stage, change a stage, delete a stage) you had to redeploy the definition outside of the pipeline manually => In awsboilerplate using and extending CDKPipeline the pipeline definition itself is now dynamic. It is defined in code and when you update the pipeline the pipeline will 'rebootstrap', mutate to the new state before running. This is already a feature in other devops tools like gitlab - this feature brings AWS native to feature parity. 2. Awsboilerplate brings all the different concepts together such that all the different aspects are truly 1) 'in code', 2) in a single mono repo 3) deployed by a singular pipeline (not an app dev pipeline and an infrastructure pipeline that need to coordinate) 4) if a developer can learn AWS and CDK then they have complete control over everything (no need for a separate cloud platform team to manage terraform) 5) cloud native implementation on AWS. Previously, you had to cobble this self together with different tools - days or weeks of custom effort. In summary, I would agree with you that gitops/infrastructure as code have been the direction of travel for a while in the devops space. Awsboilerplate brings a number of these concepts together in a single cloud native implementations for all aspects of the project (app code, infrastructure code, pipeline code)

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]

davidjdoherty 5y ago

Woop

davidjdoherty 5y ago

Woop!

leohonexus 5y ago

A CI/CD pipeline re-bootstrapping itself to config changes is pretty innovative - I wish more companies adopt this pattern.

nsonha 5y ago
Isn't this called gitops or smt, I'm not an infrastructure person but I've been hearing about this for the past 2 years or so
- awsboilerplate 5y ago
  Agree that the direction of travel for several years has been to move monitoring and infrastructure to 'be code'. There are different names for different aspects - gitops (typically monitoring or ops activities) infrastructure as code, etc. However, it has been incomplete. Two ways in which awsboilerplate is a natural continuation/implementation of the concept: 1. (Codebuild is a project step within the pipeline and Codepipeline is the overall pipeline). In AWS the codebuild build spec has been dynamic - when you commit a change to a build spec it updates next time the pipeline runs. However, the codepipeline / pipeline definition itself was not dynamic. It was statically created typically in the CLI or cloudformation. If you wanted to evolve the pipeline (add a stage, change a stage, delete a stage) you had to redeploy the definition outside of the pipeline manually => In awsboilerplate using and extending CDKPipeline the pipeline definition itself is now dynamic. It is defined in code and when you update the pipeline the pipeline will 'rebootstrap', mutate to the new state before running. This is already a feature in other devops tools like gitlab - this feature brings AWS native to feature parity. 2. Awsboilerplate brings all the different concepts together such that all the different aspects are truly 1) 'in code', 2) in a single mono repo 3) deployed by a singular pipeline (not an app dev pipeline and an infrastructure pipeline that need to coordinate) 4) if a developer can learn AWS and CDK then they have complete control over everything (no need for a separate cloud platform team to manage terraform) 5) cloud native implementation on AWS. Previously, you had to cobble this self together with different tools - days or weeks of custom effort. In summary, I would agree with you that gitops/infrastructure as code have been the direction of travel for a while in the devops space. Awsboilerplate brings a number of these concepts together in a single cloud native implementations for all aspects of the project (app code, infrastructure code, pipeline code)