{"id":1156,"date":"2020-02-07T15:04:25","date_gmt":"2020-02-07T14:04:25","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=1156"},"modified":"2021-03-24T16:58:29","modified_gmt":"2021-03-24T15:58:29","slug":"troposphere-a-better-way-to-build-manage-and-maintain-a-cloudformation-based-infrastructure-on-aws","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/troposphere-a-better-way-to-build-manage-and-maintain-a-cloudformation-based-infrastructure-on-aws\/","title":{"rendered":"Troposphere: a better way to build, manage and maintain a Cloudformation based infrastructure on AWS"},"content":{"rendered":"

Nowadays most of the modern SaaS applications are developed and deployed on Cloud providers and, in particular, Amazon Web Service, the first real Cloud provider, took and held the lead of this market due to the quality and the flexibility of its services.\u00a0<\/span><\/p>\n

AWS hosted Cloud Infrastructures keep getting larger and more complex with time in order to take full advantage of new services released by AWS. In fact, the number of services offered directly by Amazon is gargantuan<\/a><\/span>\u00a0and keeps growing every year. Using AWS services whenever possible instead of custom solutions deployed on EC2 virtual machines results in a huge decrease in the infrastructure setup and maintenance costs since Amazon is responsible for the deployment, Cloud optimization, security and maintenance of each service. Furthermore, most of the AWS services are designed to be highly available without any additional configuration, saving another significant configuration burden for the DevOps.\u00a0<\/span><\/p>\n

Using the AWS services as building blocks allows developer to create almost every type of application, for example, a typical serverless web application leverages Amazon Cognito for authentication,\u00a0 AWS Lambda\/ApiGateway for the backend, DynamoDB for the database, SNS\/SES for push and mail notifications to users, S3\/Cloudfront for the frontend and SQS for internal queuing. However most applications are much more complicated than that (they often needs machine learning, datalakes, vpn connections to other services, different databases, batch processing and so on) and the number of different services and resources needed quickly escalates resulting in infrastructure so big and complicated that cannot be safely managed \u2018by hand\u2019 anymore. In fact, sometimes modifications to just one component (e.g. a security group or a routing table) to could result in unexpected side effects impacting several services and has the potential to take the whole Application offline.\u00a0<\/span><\/p>\n

In these cases, IaC (Infrastructure as Code) comes to the rescue. Through IaC it is possible to describe the whole AWS infrastructure writing regular code, so you can version it using Git just like any other code project. When the IaC code is executed it will create or update the infrastructure in order it to be exactly like you wrote in your code! If you need to change the infrastructure you update the IaC commit your change and rerun the code<\/span><\/p>\n

If all this sounds too good to be true you are probably right! Every abstraction level we add to our software development flow comes with its own problems and IaC is no exception. The first problem we had when we decided to go with the IaC paradigm is the choice of the right tool, in fact there two main several IaC frameworks for AWS out there: Terraform and CloudFormation. We tried Terraform but found several issues which were a no-go for us:\u00a0<\/span><\/p>\n