AWS CDK: Your Infrastructure is Code!

Editor's Notes

• #2: Hello! Thank you for being here! I am energized, because I would like to share some exciting news with you. I really think that it provides a fresh and novel ideas to the Infrastructure as Code space.
• #3: My name is Wojtek, afronski on the internet. Cloud Architect and Co-founder of the Pattern Match. That lovely avatar is made by my friends from Pattern Match after I bragged about that I can write a bash loop from memory (and obviously failed). ;) In PM we’re doers - experienced and trusted advisors in best practices of software delivery, efficiency, performance and availability. We do that by employing successfully cloud computing, cloud native approach and destroying walls between business and technical teams.
• #4: Why me? Am I qualified to whine about this topic? That is just a snapshot from one of the projects that I bootstrapped and maintained for more than a 2 years. YAML here is representing a pile of AWS CloudFormation. So I know a thing or two about Infrastructure as Code from design, implementation and maintenance points of view. Nowadays I am writing more Python than bash, but pile of text files is not smaller surprisingly.
• #5: The amount of YAML and CloudFormation was so overwhelming that I thought it would be a great idea to write a separate tool that will perform an opinionated linting, validation, and other helpful operations on it. Name of this tool is Perun and its written in Go. I am the creator of this tool, most of us from Pattern Match contributed to this tool - it stayed in the good hands of our colleagues at Appliscale. At this point of time I think it was a Stockholm Syndrome. Reasoning and justification sounded perfectly fine to me. From the perspective of couple more projects I think we did a huge mistake there to not employ better tools at that time.
• #6: Knowing a bit about me, allow me to show you the current landscape of the Infrastructure as Code. And I will start with a rant about the current state of IaC. WARNING: bear with me, when I will hyperventilate.
• #7: Oh boy there are a lot of yaks to be shaved here. YAML anyone? I have a bad news to you - if you are throwing YAML files back and forth you are not an engineer, nor a programmer. Anyone recognizes this cute error up in the corner? Yup, that is Terraform that blown up and if you will have luck, you will be able to restore state from the remote backend without nitpicking JSON via scissors and glue.
• #8: Those who work with CloudFormation on a daily basis and are old enough to remember the JSON representation of it will have a goosebumps right now. I know it sounds, but YAML is a better part of the CloudFormation. But here it comes the best part! This YAML is a subset of an original YAML specification. What is missing? E.g. no anchors (very useful), no variables, no way to reuse fragments.
• #9: Why am I talking about this? Because more smarter people than me are seeing the shortcomings of those methods. Here you have a screenshot from the latest Technology Radar by Thoughtworks where they’ve marked Handwritten CloudFormation as a Hold (so you should avoid that). I am surprised tho, that they are naming Terraform as a sensible default - as it has its downfalls too and does not provide a sensible rollback, where CloudFormation does.
• #10: Current state of IaC sucks, and it’s covered by a lot of DSLs or YAML files that eventually will blow up in our faces. Nowadays most of the decisions are made between Terraform (supposedly free of vendor lock-in) and Cloud Vendor specific tools. Which is represented by the new and official logo of AWS CloudFormation, but you can use any logo e.g. Google Deployment Manager. Our friends that pray to the Kubernetes god are smiling in the corner - they will powerful and superior. They are supposedly agnostic of “this crap” and … they use tool specific YAML format. Those people are sharing the smirk with the guys doing serverless apps with use Serverless Framework. Guess what? This YAML is problematic too, and maintaining a significant serverless system causes a lot of pain. At least it is much easier and more maintainable than using Terraform for that. God forbid! All those techniques are susceptible on main issues: Configuration Drift. State Management. Dealing with stateful resources. How to sensibly test this crap? All those problems are showing clearly: Is it a proper battle to fight in a first place?
• #11: Let’s see what is missing and how it can be improved. For sure we can benefit from having a real programming language and its expressiveness. You may ask: what with my declarativeness? Well, as a functional programmer I can tell you that in most cases YAML is as declarative as the API allows for it. Declarative programming has roots in functional programming and is about telling what we want to do, without describing how we want to do it. We express the logic of a computation without describing its control flow, which is perfectly possible with regular programming languages. How to handle configuration drift? Assuming we are dealing with distributed environments, on-calls and so on. Managing state when provisioning is also problematic, as you have to deal with many shortcomings, and people that are using Terraform and nested CloudFormation stacks are having goosebumps now. Sensible testing mechanism to shorten the feedback loop and maintainability. Sensible local development - again for shortening the feedback loop and experimentation.
• #12: Let’s investigate alternatives and how they map with the deficiencies that we have described previously: So you can go with Ansible for orchestration and its wrappers - we are using that, and it works sensibly, although it’s not a real code, and you are moving above the original abstraction. You can use Sceptre (provided by CloudReach), but still it is a Jinja2 templating smacked on top of YAML with added orchestration. AWS SAM has the same deficiencies and its serverless specific. Stack Deployment Tool is basically the same story I have described with Perun - it’s a Stockholm Syndrome. Terraform was covered previously - I do not treat it as a viable alternative here. No rollback, share most of the issues with CloudFormation, just has different syntax. Last three options are the closest to the real code and they can be considered a viable alternative. To be precise only AWS CDK, because Troposphere and Pulumi for now are not providing a sensible testability. Also Pulumi is serverless specific. With Troposphere it is possible, although it’s not available out of the box.
• #13: Let’s talk about our “savior” now. AWS CDK was originally created around September 2018 and released as a beta around that time. I have used the beta version in Autumn 2018, where it was available just for TypeScript and at that time it already looked promising. I have gathered my thoughts and observation in the blog post attached to this slide. In June 2019 AWS announced that Cloud Development Kit is generally available for TypeScript and Python. Yet, it supports additionally Java and C# too.
• #14: How it works? It basically allows you to model your infrastructure with use of code and programming languages using a library of constructs. With use of this library you are create, manage, implement, and maintain infrastructure as code definitions that at the end are translated directly to the AWS CloudFormation. It allows you to build on top of well-known patterns and behaviors of this service - including rollback, configuration drift, state management. Yet, you have capabilities of a first-class programming languages.
• #15: I deliberately said translates. If you will treat CloudFormation templates as an intermediate language (e.g. assembly), it works exactly like the compiler. For us, programmers, it is a bread and butter - we work on a higher level of abstraction, reusing higher level constructs and modules that are compiling to the low-level elements delivered by the platform or runtime. In that case CloudFormation service is our runtime or execution engine.
• #16: Let’s discuss briefly its the most interesting features before we will dive into the details during demo session.
• #17: I’ve already said that they are supporting multiple programming languages - the best and official support is for TypeScript and Python. Java and C# are still in beta, but perfectly usable. It’s fully based on CloudFormation service and templates, so you have all benefits and traits of those built-in. That includes rollbacks, configuration drifts, full support on the AWS side, and many others. It means, that even if the library maintainers are a little bit behind, you are able to spit our regular CloudFormation with use of L1 constructs and fill out the gaps with pure CloudFormation syntax. It is fully testable locally, and even encourages local development - with checking configuration drift, diffs, generating synthesized template, etc. It gives you the flexibility of the programming language and ability to create modular, reusable abstractions with use of constructs. Which is a game changer for the most of the alternatives mentioned previously. It allows for an easy migration from the pure CloudFormation templates with use of many techniques: You can rewrite your templates into CDK using overrides for simpler templates. You can include your existing more complicated templates into CDK and rewrite them bit by bit. You can use built-in disassembler that creates a raw AWS CDK code in a given language from AWS CloudFormation. Even if it does not fully use the power of CDK (it’s of course a limited tool), it really helps with kickstarting the effort and starting the project.
• #18: Here you have just one example of the diff between the current managed state and the CDK definition stored locally. It shows you the exact difference, and you can use the same mechanism doing local tests (e.g. with unit testing).
• #19: Speaking about abstractions and helpers: AWS CDK provides a lot of existing abstractions and constructs, including permissions and dependency management as written on the slide. Behind the line with grant we have already impemented the IAM and permissions management for many resources.
• #20: Let’s now pray to the demo gods to not screw up with me!
• #21: Let me recap the demo, by unveiling the current problems - no pain, no gain: Documentation sucks currently - most of the examples are written and prepared for TypeScript only. It has some learning curve especially if you used to CloudFormation. Outside of constructs, the most surprising change is related to parameters. CloudFormation parameters are resolved when deploying, so you can generate a CloudFormation template with parameters, but you cannot deploy it with use of CDK, there is no way to type check/validate that on the code level - instead CDK recommends to use contexts. Again, it is the controversial decision that is a tradeoff. They did that because of compile-time guarantees. You can read more about that here. Even it is generally available, it has no support for StackPolicies. Also on the same note, some things requires override in the resulting CloudFormation, if they are not supported. When it comes to debugging - it is not so user-friendly as handwritten template (which is kinda obvious if we are using it like assembly language), and it may be harder to analyze those. However, it is possible and it just requires practice, nothing else.
• #22: Let me wrap up the presentation by talking about possible future enhancements and direction where it can drive us: First they need to work on the documentation, but I think it is a matter of time. The more important thing is that we finally treating Infrastructure as Code. That gives us interesting capabilities and opens new doors for future. A few years back nobody thought that we will configure CI/CD deployment pipelines alongside with the code - we may observe similar trend thanks to such solutions. Additionally starting the discussion about abstraction allows us to think about real solutions for abstracting cloud providers. I think that such frameworks are the first step for that. In future we may observe trends and moves related with the type-safe AWS Infrastructure or describing infrastructure needed for serverless applications in the same language we write the compute layer.
• #23: Here you can find most important resources that I have used for preparing the presentation.