What is AWS CloudFormation and what are its top alternatives?
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 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. ...
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
- Mock testing with Chefspec30
- 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.
- Infrastructure as code118
- Declarative syntax73
- Cloud agnostic7
- It's like coding your infrastructure in simple English6
- Immutable infrastructure5
- Platform agnostic5
- Automates infrastructure deployments4
- Scales to hundreds of hosts2
- Doesn't have full support to GKE1
related Terraform posts
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.
We are in the process of building a modern content platform to deliver our content through various channels. We decided to go with Microservices architecture as we wanted scale. Microservice architecture style is an approach to developing an application as a suite of small independently deployable services built around specific business capabilities. You can gain modularity, extensive parallelism and cost-effective scaling by deploying services across many distributed servers. Microservices modularity facilitates independent updates/deployments, and helps to avoid single point of failure, which can help prevent large-scale outages. We also decided to use Event Driven Architecture pattern which is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. The event-driven architecture is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events.
To build our #Backend capabilities we decided to use the following: 1. #Microservices - Java with Spring Boot , Node.js with ExpressJS and Python with Flask 2. #Eventsourcingframework - Amazon Kinesis , Amazon Kinesis Firehose , Amazon SNS , Amazon SQS, AWS Lambda 3. #Data - Amazon RDS , Amazon DynamoDB , Amazon S3 , MongoDB Atlas
To build #Webapps we decided to use Angular 2 with RxJS
#Devops - GitHub , Travis CI , Terraform , Docker , Serverless
- Integrates with other aws services77
- Simple deployment65
- 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
- Backed by Amazon4
- One stop solution2
- Not user friendly1
related AWS Config posts
- Bicep - Simple Declarative Language2
- 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