Need advice about which tool to choose?Ask the StackShare community!
AWS CloudFormation vs AWS CodeDeploy: What are the differences?
Introduction
This Markdown code provides a comparison between AWS CloudFormation and AWS CodeDeploy, focusing on their key differences. Both services are part of the Amazon Web Services ecosystem and are used for different purposes in the deployment and management of applications and infrastructure.
Deployment Process: AWS CloudFormation is a service that allows users to define their infrastructure and provisioning resources in a declarative manner using templates. It enables the consistent creation and management of resources, such as EC2 instances, S3 buckets, and RDS databases, through a JSON or YAML script. On the other hand, AWS CodeDeploy is a fully managed deployment service that automates the application deployment to Amazon EC2 instances or on-premises servers. It focuses on application-level deployments by providing advanced features like blue/green deployments and canary deployments.
Scope: AWS CloudFormation operates at the infrastructure level and allows for the provisioning of various AWS resources and services. It supports the creation and configuration of networks, security groups, load balancers, and more. AWS CodeDeploy, on the other hand, focuses solely on application-level deployments. It helps in deploying code changes and coordinating the application deployment process across fleets of instances or servers.
Rollback Mechanism: AWS CloudFormation provides a built-in rollback mechanism in case of errors or failures during the stack creation or update process. It can automatically roll back changes to the previous known working state. AWS CodeDeploy also offers a rollback mechanism but is primarily focused on application-level rollback. It allows the rollback of application revisions to a previous version or an earlier stage, providing a convenient way to revert problematic deployments.
Integration with Development Tools: AWS CloudFormation plays a crucial role in infrastructure as code (IaC) practices and integrates well with various development tools. It can be used with integrated development environments (IDEs) like AWS Cloud9 or other popular code editors to manage infrastructure definitions. AWS CodeDeploy integrates more closely with software development tools like AWS CodeCommit, AWS CodePipeline, and third-party platforms such as Jenkins, enabling end-to-end automation of application deployments and continuous delivery workflows.
Supported Environments: AWS CloudFormation is agnostic to the type of workload or application being deployed. It supports both infrastructure deployments and application deployments. AWS CodeDeploy, on the other hand, is specifically designed for application deployments. It provides support for a variety of application types, including web applications, microservices, and legacy monolithic applications.
Deployment Target Types: AWS CloudFormation can deploy resources to various AWS accounts and regions, enabling multi-account and multi-region deployments. It helps in managing complex architectures. AWS CodeDeploy primarily targets EC2 instances and on-premises servers. It can deploy the application revisions across fleets of instances, allowing for easier scaling and management in complex deployments.
In summary, AWS CloudFormation focuses on infrastructure provisioning and management using declarative templates, while AWS CodeDeploy is primarily geared towards application deployments and provides advanced deployment features like blue/green deployments and canary deployments.
Because Pulumi uses real programming languages, you can actually write abstractions for your infrastructure code, which is incredibly empowering. You still 'describe' your desired state, but by having a programming language at your fingers, you can factor out patterns, and package it up for easier consumption.
We use Terraform to manage AWS cloud environment for the project. It is pretty complex, largely static, security-focused, and constantly evolving.
Terraform provides descriptive (declarative) way of defining the target configuration, where it can work out the dependencies between configuration elements and apply differences without re-provisioning the entire cloud stack.
AdvantagesTerraform is vendor-neutral in a way that it is using a common configuration language (HCL) with plugins (providers) for multiple cloud and service providers.
Terraform keeps track of the previous state of the deployment and applies incremental changes, resulting in faster deployment times.
Terraform allows us to share reusable modules between projects. We have built an impressive library of modules internally, which makes it very easy to assemble a new project from pre-fabricated building blocks.
DisadvantagesSoftware is imperfect, and Terraform is no exception. Occasionally we hit annoying bugs that we have to work around. The interaction with any underlying APIs is encapsulated inside 3rd party Terraform providers, and any bug fixes or new features require a provider release. Some providers have very poor coverage of the underlying APIs.
Terraform is not great for managing highly dynamic parts of cloud environments. That part is better delegated to other tools or scripts.
Terraform state may go out of sync with the target environment or with the source configuration, which often results in painful reconciliation.
I personally am not a huge fan of vendor lock in for multiple reasons:
- I've seen cost saving moves to the cloud end up costing a fortune and trapping companies due to over utilization of cloud specific features.
- I've seen S3 failures nearly take down half the internet.
- I've seen companies get stuck in the cloud because they aren't built cloud agnostic.
I choose to use terraform for my cloud provisioning for these reasons:
- It's cloud agnostic so I can use it no matter where I am.
- It isn't difficult to use and uses a relatively easy to read language.
- It tests infrastructure before running it, and enables me to see and keep changes up to date.
- It runs from the same CLI I do most of my CM work from.
Amazon CloudWatch
AWS CloudFormation
AWS CodeBuild
AWS CodeDeploy
AWS CodePipelineWe will use AWS CloudFormation, as it is ideal for deploying and replicating infrastructure as code. Amazon CloudWatch Events will be used to send info based on the trigger that initiated the event to developers using Amazon SNS. Amazon SNS will also be used in the AWS CodePipeline after the application has been tested and deployed successfully to the development environment, notifying users to approve the application before it can be deployed to a production environment. AWS CodeBuild will be used for running tests on the application and AWS CodeDeploy will be used to deploy the application to Lambda and Alexa Skills Kit. AWS CodePipeline is a service that will organize the steps taken (building/testing and deployment) when code is pushed to the master branch in our source repository in Github.
Pros of AWS CloudFormation
- Automates infrastructure deployments43
- Declarative infrastructure and deployment21
- No more clicking around13
- Any Operative System you want3
- Atomic3
- Infrastructure as code3
- CDK makes it truly infrastructure-as-code1
- Automates Infrastructure Deployment1
- K8s0
Pros of AWS CodeDeploy
- Automates code deployments17
- Backed by Amazon9
- Adds autoscaling lifecycle hooks7
- Git integration5
Sign up to add or upvote prosMake informed product decisions
Cons of AWS CloudFormation
- Brittle4
- No RBAC and policies in templates2
Cons of AWS CodeDeploy
Sign up to add or upvote consMake informed product decisions
What is AWS CloudFormation?
What is AWS CodeDeploy?
Need advice about which tool to choose?Ask the StackShare community!
What companies use AWS CloudFormation?
What companies use AWS CodeDeploy?
Sign up to get full access to all the companiesMake informed product decisions
What tools integrate with AWS CloudFormation?
Sign up to get full access to all the tool integrationsMake informed product decisions
Blog Posts
+29
+42+47
+26
+23
+39
+35