One of the parts of doing things properly at scale is being able to describe your infrastructure as code and deploy it as such. If we already treat our infrastructure as code, why not apply all the best practices of software delivery to infrastructure delivery.
In this session we look into Infrastructure as Code solutions, best practices and patterns on AWS.
Here is a few things we will be talking about today – I promise to make it more interesting than this slide!
So, the first question of today is - well what is Infrastructure as Code? Why Should you use it? Should you use it at all? Hmm … let’s just step back in time a bit … click
Long gone are the times of racking and stacking – with the move towards the cloud, our speed and agility has increased. And the way to keep up with it to change our approach to provisioning infrastructure.
(Story about provisioning from the past)
And this is how it all looks now – wow – lot less cables and a lot less racking and stacking.
You can use the same tools and processes as for software development: versioning & version control, reusability, automation, CI/CD, code reviews and automated testing.
You can use the same tools and processes as for software development: versioning & version control, reusability, automation, CI/CD, code reviews and automated testing.
So, the first question of today is - well what is Infrastructure as Code? Why Should you use it? Should you use it at all? Hmm … let’s just step back in time a bit … click
Launched in 2011
Here is how a CloudFormation code snipped looks like – and you have seen this before in one of my slides.
In essence we write code into templates – it can be JSON (if you are a robot) or YAML if you like tab-spacing. Once that code is ”executed” we create these things called stacks – and it said stacks we have our resources.
Those resources (of which cloudformation supports over 490) can be configured with a predefined set of properties (eg. An instance size for an EC2 instance), and CloudFormation takes care of dependancies for us – but we can also declare some for ourselves.
The Resources section is the only mandatory section required in a template file
Parameters and Mappings can help make a template reusable across environments, regions, and other use cases
Conditions, as in other programs, can change the behavior of an operation from, for example, development to production environments
Outputs can aid users to quickly access managed resources
Last week, we announced and released Cloud Formation registry, a new open extensibility model for Cloud Formation. With the AWS CloudFormation Registry, you can develop and submit, discover, and manage custom or external resource providers. Once a resource provider is published in the AWS CloudFormation Registry, it can be used to manage third party resources in the same way as native AWS resource providers. It differentiates between Private and Public Resources.
This new functionality will also work out of the box with services such as AWS Control Tower and AWS Service Catalog to help you with governance and resource compliance, and AWS CloudFormation StackSets for cross-account and cross-region management.
You can develop your own resource providers using the AWS CloudFormation CLI, a new open source developer tool, ( documentation & CLI in GitHub as of November 14th ), and publish them to the Registry. The new CLI includes code generation and local testing capabilities to streamline your development process. To help you get started, you can also use the open sourced AWS Simple Email Service and CloudWatch Logs examples.
But think about what technology partners can do with an open extensible model. This is the really exciting news here..
So, the first question of today is - well what is Infrastructure as Code? Why Should you use it? Should you use it at all? Hmm … let’s just step back in time a bit … click
So lets walk through a couple of different tools for iac, that are specific to serverless.
One is the serverless application model for developers of serverless applications.
This is a open source framework for build serverless applications on aws.
You can think of this as a short hand syntax to express functions, apis, the databases that your functions are using and the event source mappings.
So what happens when you deploy this sam template, it that it all gets expanded out into CloudFormation syntax.
Because it is based on CloudFormation, it supports all the resource types out of the box automatically.
This is an example of a sam template. It is a short hand syntax for your serverless application.
I m expressing a serverless function and I am expressing the api that will trigger the function, the api gateway.
But notice that I don’t need to specify that api gateway.
And lower down you can see serverless simple table.
These are less than 20 lines of yml that actually expand into a lambda function, all the necessary iam roles and policies, an api gateway that trigger the lambda and a table.
So, the first question of today is - well what is Infrastructure as Code? Why Should you use it? Should you use it at all? Hmm … let’s just step back in time a bit … click
So in essence CDK is a Multi language framework that allows you to model your infrastructure as … well … code !
We can use common languages to define our Infrastructure:
JS/TS,
Python
Java
C#
Before going anywhere further – I need to talk about one of our customers on this topic!
How it works is you write constructs – Apps, Stacks and resources – that gets synthesized by CDK CLI turned into CloudFormation anll the required Assets (like Lambda functions to S3) and the by usingCloudFormaton it gets deployed to the cloud.s
CFN resource constructs – all resources in specification
AWS Serbice constructs – higher-level abstractions with sensible defaults
Design Patterns constructs – opinionated reference architectures and design patterns using multiple AWS services
So, the first question of today is - well what is Infrastructure as Code? Why Should you use it? Should you use it at all? Hmm … let’s just step back in time a bit … click