What is AWS CloudFormation and what are its top alternatives?
AWS CloudFormation is a service that enables you to model and provision AWS resources using templates. Key features include infrastructure as code, automation of resource creation and management, and support for multiple AWS services. However, some limitations include the learning curve associated with its complex JSON or YAML templates and the lack of support for non-AWS resources.
Terraform: Terraform is an open-source tool from HashiCorp that allows you to define and provision infrastructure as code. Key features include multi-cloud support, ease of use with HCL configuration language, and a vibrant community. Pros include support for various cloud providers, while a potential con is the need to manage state files.
Azure Resource Manager (ARM) Templates: ARM Templates are the infrastructure as code tool for Azure, enabling you to define and deploy Azure resources. Key features include integration with Azure services, parameterization, and the ability to create complex resource configurations. Pros include deep integration with Azure, while a limitation is the lack of cross-cloud support.
Google Cloud Deployment Manager: Google Cloud Deployment Manager is Google Cloud's infrastructure deployment service that allows you to define resources using templates. Key features include version control, resource reuse, and declarative configurations. Pros include seamless integration with Google Cloud services, while a con is the learning curve for beginners.
Pulumi: Pulumi is an infrastructure as code tool that supports multiple cloud providers and languages. Key features include programming language support, state management, and modular development. Pros include using familiar programming languages, while a potential con is the need for developers to learn the Pulumi SDK.
Ansible: Ansible is a configuration management tool that can also be used for infrastructure as code. Key features include agentless architecture, playbook automation, and support for various platforms. Pros include ease of use and broad support for different environments, while a con is its focus on configuration rather than infrastructure provisioning.
Chef: Chef is a configuration management tool that supports infrastructure automation using recipes and cookbooks. Key features include idempotent configuration, role-based management, and support for multiple platforms. Pros include granular control over configurations, while a con is the complexity of managing Chef environments.
SaltStack: SaltStack is a configuration management and infrastructure automation tool that is known for its speed and scalability. Key features include remote execution, event-driven automation, and support for managing large-scale infrastructures. Pros include scalability and performance, while a limitation is the learning curve for new users.
Juju: Juju is a cloud orchestration tool that simplifies the deployment and management of complex applications. Key features include model-driven operations, charm-based deployment, and support for multi-cloud environments. Pros include its focus on application-centric deployments, while a con is the limited support for certain cloud providers.
OpenStack Heat: OpenStack Heat is an orchestration service in the OpenStack cloud platform that allows you to define and manage infrastructure using templates. Key features include integration with OpenStack services, autoscaling, and rolling updates. Pros include deep integration with OpenStack, while a limitation is its focus on OpenStack environments.
Rancher: Rancher is a container management platform that includes infrastructure as code capabilities. Key features include a user-friendly interface, multi-cluster management, and integration with Kubernetes. Pros include container-focused infrastructure management, while a con is the limited support for non-containerized workloads.
Top Alternatives to AWS CloudFormation
- AWS CodeDeploy
AWS CodeDeploy is a service that automates code deployments to Amazon EC2 instances. AWS CodeDeploy makes it easier for you to rapidly release new features, helps you avoid downtime during deployment, and handles the complexity of updating your applications. ...
- Chef
Chef enables you to manage and scale cloud infrastructure with no downtime or interruptions. Freely move applications and configurations from one cloud to another. Chef is integrated with all major cloud providers including Amazon EC2, VMWare, IBM Smartcloud, Rackspace, OpenStack, Windows Azure, HP Cloud, Google Compute Engine, Joyent Cloud and others. ...
- Terraform
With Terraform, you describe your complete infrastructure as code, even as it spans multiple service providers. Your servers may come from AWS, your DNS may come from CloudFlare, and your database may come from Heroku. Terraform will build all these resources across all these providers in parallel. ...
- AWS Elastic Beanstalk
Once you upload your application, Elastic Beanstalk automatically handles the deployment details of capacity provisioning, load balancing, auto-scaling, and application health monitoring. ...
- AWS Config
AWS Config is a fully managed service that provides you with an AWS resource inventory, configuration history, and configuration change notifications to enable security and governance. With AWS Config you can discover existing AWS resources, export a complete inventory of your AWS resources with all configuration details, and determine how a resource was configured at any point in time. These capabilities enable compliance auditing, security analysis, resource change tracking, and troubleshooting. ...
- Azure Resource Manager
It is the deployment and management service for Azure. It provides a management layer that enables you to create, update, and delete resources in your Azure subscription. You use management features, like access control, locks, and tags, to secure and organize your resources after deployment. ...
- AWS Service Catalog
AWS Service Catalog allows IT administrators to create, manage, and distribute catalogs of approved products to end users, who can then access the products they need in a personalized portal. Administrators can control which users have access to each application or AWS resource to enforce compliance with organizational business policies. AWS Service Catalog allows your organization to benefit from increased agility and reduced costs because end users can find and launch only the products they need from a catalog that you control. ...
- AWS CLI
It is a unified tool to manage your AWS services. With just one tool to download and configure, you can control multiple AWS services from the command line and automate them through scripts. ...
AWS CloudFormation alternatives & related posts
- Automates code deployments17
- Backed by Amazon9
- Adds autoscaling lifecycle hooks7
- Git integration5
related AWS CodeDeploy posts
The recent move of our CI/CD tooling to AWS CodeBuild / AWS CodeDeploy (with GitHub ) as well as moving to Amazon EC2 Container Service / AWS Lambda for our deployment architecture for most of our services has helped us significantly reduce our deployment times while improving both feature velocity and overall reliability. In one extreme case, we got one service down from 90 minutes to a very reasonable 15 minutes. Container-based build and deployments have made so many things simpler and easier and the integration between the tools has been helpful. There is still some work to do on our service mesh & API proxy approach to further simplify our environment.
At Kloud.io we use Node.js for our backend Microservices and Angular 2 for the frontend. We also use React for a couple of our internal applications. Writing services in Node.js in TypeScript improved developer productivity and we could capture bugs way before they can occur in the production. The use of Angular 2 in our production environment reduced the time to release any new features. At the same time, we are also exploring React by using it in our internal tools. So far we enjoyed what React has to offer. We are an enterprise SAAS product and also offer an on-premise or hybrid cloud version of #kloudio. We heavily use Docker for shipping our on-premise version. We also use Docker internally for automated testing. Using Docker reduced the install time errors in customer environments. Our cloud version is deployed in #AWS. We use AWS CodePipeline and AWS CodeDeploy for our CI/CD. We also use AWS Lambda for automation jobs.
- Dynamic and idempotent server configuration110
- Reusable components76
- Integration testing with Vagrant47
- Repeatable43
- Mock testing with Chefspec30
- Ruby14
- Can package cookbooks to guarantee repeatability8
- Works with AWS7
- Has marketplace where you get readymade cookbooks3
- Matured product with good community support3
- Less declarative more procedural2
- Open source configuration mgmt made easy(ish)2
related Chef posts
In late 2013, the Operations Engineering team at PagerDuty was made up of 4 engineers, and was comprised of generalists, each of whom had one or two areas of depth. Although the Operations Team ran its own on-call, each engineering team at PagerDuty also participated on the pager.
The Operations Engineering Team owned 150+ servers spanning multiple cloud providers, and used Chef to automate their infrastructure across the various cloud providers with a mix of completely custom cookbooks and customized community cookbooks.
Custom cookbooks were managed by Berkshelf, andach custom cookbook contained its own tests based on ChefSpec 3, coupled with Rspec.
Jenkins was used to GitHub for new changes and to handle unit testing of those features.
Since #ATComputing is a vendor independent Linux and open source specialist, we do not have a favorite Linux distribution. We mainly use Ubuntu , Centos Debian , Red Hat Enterprise Linux and Fedora during our daily work. These are also the distributions we see most often used in our customers environments.
For our #ci/cd training, we use an open source pipeline that is build around Visual Studio Code , Jenkins , VirtualBox , GitHub , Docker Kubernetes and Google Compute Engine.
For #ServerConfigurationAndAutomation, we have embraced and contributed to Ansible mainly because it is not only flexible and powerful, but also straightforward and easier to learn than some other (open source) solutions. On the other hand: we are not affraid of Puppet Labs and Chef either.
Currently, our most popular #programming #Language course is Python . The reason Python is so popular has to do with it's versatility, but also with its low complexity. This helps sysadmins to write scripts or simple programs to make their job less repetitive and automating things more fun. Python is also widely used to communicate with (REST) API's and for data analysis.
Terraform
- Infrastructure as code121
- Declarative syntax73
- Planning45
- Simple28
- Parallelism24
- Well-documented8
- Cloud agnostic8
- It's like coding your infrastructure in simple English6
- Immutable infrastructure6
- Platform agnostic5
- Extendable4
- Automation4
- Automates infrastructure deployments4
- Portability4
- Lightweight2
- Scales to hundreds of hosts2
- Doesn't have full support to GKE1
related Terraform posts
Context: I wanted to create an end to end IoT data pipeline simulation in Google Cloud IoT Core and other GCP services. I never touched Terraform meaningfully until working on this project, and it's one of the best explorations in my development career. The documentation and syntax is incredibly human-readable and friendly. I'm used to building infrastructure through the google apis via Python , but I'm so glad past Sung did not make that decision. I was tempted to use Google Cloud Deployment Manager, but the templates were a bit convoluted by first impression. I'm glad past Sung did not make this decision either.
Solution: Leveraging Google Cloud Build Google Cloud Run Google Cloud Bigtable Google BigQuery Google Cloud Storage Google Compute Engine along with some other fun tools, I can deploy over 40 GCP resources using Terraform!
Check Out My Architecture: CLICK ME
Check out the GitHub repo attached
We recently moved our main applications from Heroku to Kubernetes . The 3 main driving factors behind the switch were scalability (database size limits), security (the inability to set up PostgreSQL instances in private networks), and costs (GCP is cheaper for raw computing resources).
We prefer using managed services, so we are using Google Kubernetes Engine with Google Cloud SQL for PostgreSQL for our PostgreSQL databases and Google Cloud Memorystore for Redis . For our CI/CD pipeline, we are using CircleCI and Google Cloud Build to deploy applications managed with Helm . The new infrastructure is managed with Terraform .
Read the blog post to go more in depth.
- Integrates with other aws services77
- Simple deployment65
- Fast44
- Painless28
- Free16
- Well-documented4
- Independend app container3
- Postgres hosting2
- Ability to be customized2
- Charges appear automatically after exceeding free quota2
- Lots of moving parts and config1
- Slow deployments0
related AWS Elastic Beanstalk posts
Back in 2014, I was given an opportunity to re-architect SmartZip Analytics platform, and flagship product: SmartTargeting. This is a SaaS software helping real estate professionals keeping up with their prospects and leads in a given neighborhood/territory, finding out (thanks to predictive analytics) who's the most likely to list/sell their home, and running cross-channel marketing automation against them: direct mail, online ads, email... The company also does provide Data APIs to Enterprise customers.
I had inherited years and years of technical debt and I knew things had to change radically. The first enabler to this was to make use of the cloud and go with AWS, so we would stop re-inventing the wheel, and build around managed/scalable services.
For the SaaS product, we kept on working with Rails as this was what my team had the most knowledge in. We've however broken up the monolith and decoupled the front-end application from the backend thanks to the use of Rails API so we'd get independently scalable micro-services from now on.
Our various applications could now be deployed using AWS Elastic Beanstalk so we wouldn't waste any more efforts writing time-consuming Capistrano deployment scripts for instance. Combined with Docker so our application would run within its own container, independently from the underlying host configuration.
Storage-wise, we went with Amazon S3 and ditched any pre-existing local or network storage people used to deal with in our legacy systems. On the database side: Amazon RDS / MySQL initially. Ultimately migrated to Amazon RDS for Aurora / MySQL when it got released. Once again, here you need a managed service your cloud provider handles for you.
Future improvements / technology decisions included:
Caching: Amazon ElastiCache / Memcached CDN: Amazon CloudFront Systems Integration: Segment / Zapier Data-warehousing: Amazon Redshift BI: Amazon Quicksight / Superset Search: Elasticsearch / Amazon Elasticsearch Service / Algolia Monitoring: New Relic
As our usage grows, patterns changed, and/or our business needs evolved, my role as Engineering Manager then Director of Engineering was also to ensure my team kept on learning and innovating, while delivering on business value.
One of these innovations was to get ourselves into Serverless : Adopting AWS Lambda was a big step forward. At the time, only available for Node.js (Not Ruby ) but a great way to handle cost efficiency, unpredictable traffic, sudden bursts of traffic... Ultimately you want the whole chain of services involved in a call to be serverless, and that's when we've started leveraging Amazon DynamoDB on these projects so they'd be fully scalable.
We initially started out with Heroku as our PaaS provider due to a desire to use it by our original developer for our Ruby on Rails application/website at the time. We were finding response times slow, it was painfully slow, sometimes taking 10 seconds to start loading the main page. Moving up to the next "compute" level was going to be very expensive.
We moved our site over to AWS Elastic Beanstalk , not only did response times on the site practically become instant, our cloud bill for the application was cut in half.
In database world we are currently using Amazon RDS for PostgreSQL also, we have both MariaDB and Microsoft SQL Server both hosted on Amazon RDS. The plan is to migrate to AWS Aurora Serverless for all 3 of those database systems.
Additional services we use for our public applications: AWS Lambda, Python, Redis, Memcached, AWS Elastic Load Balancing (ELB), Amazon Elasticsearch Service, Amazon ElastiCache
AWS Config
- Backed by Amazon4
- One stop solution2
- Not user friendly2
related AWS Config posts
From firebase Crashlytics, everything is simple, we install SDK and configs, and then we can see all the crashes. With AWS, it is not clear to me which service to use for the same purpose as configuring it. Correctly I understand that for automatic sending of all crashes, you need to use AWS Config?
Azure Resource Manager
- Bicep - Simple Declarative Language3
- Infrastructure-as-Code1
- Over 1K samples the QuickStart repo1
- Deep integration with Azure services like Azure Policy1
- Day 1 resource support1
- RBAC and Policies in templates1
- Versioned deployment via Blueprints1