Last 18 November, AWS announced the release of its AWS CloudFormation Registry and CLI, an extension of AWS CloudFormation that supports the creation of third-party resources through the AWS CloudFormation console. It is also the first time the AWS service has been associated with launch partners such as Spotinst and Fortinet.
Now, thanks to support for these third-party resources, AWS improves the whole practice of building infrastructure in the Cloud, because provisioning now extends beyond AWS resources to also include SaaS tools from other vendors, strengthening the way we build in the Cloud.
The purpose of this article is therefore to show the importance of IaC ‘Infrastructure as Code’ in the field of Cloud computing and to highlight the importance of AWS’s developments for its AWS CloudFormation service.
TABLE OF CONTENTS
- The principles of IaC
- CloudFormation and its benefits with CloudFormation Registry
- One step further with AWS CloudFormation CLI
- A recap of what AWS CloudFormation means for DevOps
The principles of IaC
IaC, short for Infrastructure as Code, is the practice whereby resources are described by scripts, as opposed to using management consoles to create resource environments manually.
Therefore, in the case of AWS CloudFormation, you do not need to use the AWS console or an SDK to create AWS resources. Moreover, with AWS CloudFormation Registry, you no longer need to use the console of third-party tools to use their resources.
These readable scripts allow resources to be deployed automatically, along with the required services that go with them. IaC tools will indeed create all the necessary resources, for example: networks, virtual machines, load balancers and the various access paths for your applications.
Moreover, each time an IaC script is applied, the result is always the same environment as the one described in the script.
A common practice for DevOps
The benefits therefore become obvious. IaC is a common practice for DevOps because the goal of DevOps is to automate the production process. Indeed, with IaC we are able to automate the building of the infrastructure, which is even more crucial in Cloud environments.
Even though Cloud environments hide much of the underlying architecture from developers, they require tedious resource configurations that depend on the constraints of the chosen Cloud provider. IaC services such as AWS Cloudformation therefore provide a certain form of relief from the need for repetitive configurations.
Other benefits include the independence between states and templates. Since IaC allows us to model our infrastructure in a script-based format, we can define the desired state of our Cloud infrastructure.
Therefore, if the infrastructure drifts too far from the desired state, we can automate its recovery using the template initially used.
Likewise, we can use the same template to replicate the desired state across several environments (Production/Pre-Production/Acceptance, for example). This is extremely advantageous for testing purposes, because it makes it possible to have real-world scenarios. So, instead of having to configure each component laboriously to mirror the infrastructure to be tested, we can simply automate the provisioning of an identical infrastructure, followed by automated tests made easier by the various CI / CD tools provided by the Cloud Provider.
IaC tools can therefore be seen as recipe books for our Cloud infrastructure. In fact, the use of this recipe-book analogy for IaC services is so common that Jeff Barr – AWS Chief Evangelist aptly titled his blog post introducing AWS CloudFormation , in 2011.
https://aws.amazon.com/blogs/aws/cloudformation-create-your-aws-stack-from-a-recipe/
However, people do not realise that IaC tools are not like your ordinary recipe books, but rather like fully automated kitchens that analyse those recipes and cook complete Cloud infrastructures for you.
We can agree that IaC, in general, is imperative for a complete DevOps experience. The question now is which services the largest Cloud provider, AWS, provides in terms of IaC? Previously, the answer was CloudFormation and its CDK generator (AWS Cloud Development Kit).
AWS Amazon Web Services managed services
AWS CloudFormation provides a common language for you to describe and provision all the infrastructure resources in your Cloud environment.https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/registry.html
CloudFormation lets you define the AWS resources you want, along with their configurations and connections, in blueprint documents called CloudFormation templates. These templates are then run in the AWS CloudFormation console to provision the defined infrastructure.In doing so, the service guarantees that the Cloud infrastructure components are deployed in the right way according to the dependencies described in the CloudFormation template.
For example, if you want an EC2 instance to run in a VPC, CloudFormation guarantees that the VPC is provisioned first, then the EC2 instance. It also means that we no longer need to use AWS management to configure and manually add the EC2 instance into the VPC.
However, one area AWS CloudFormation did not cover was the provisioning of third-party resources. Yes, AWS resources form the core of the application infrastructure, but these components most likely communicate with third-party SaaS tools somewhere in the workflow of your applications. To come back to the example of an EC2 instance in a VPC, we may need that EC2 instance to then interact with the Stripe API.
Therefore, even though we managed to automate with your DevOps on the AWS side, we still had no tools when it came to connecting our third-party infrastructures to the main AWS infrastructure. This would often bring us back to square one, because the IaC benefits discussed above were limited to AWS resources alone.
This is where AWS Cloud Registry comes in!
Now, with the new release, the ability of AWS CloudFormation to connect to external resources is resolved. The AWS CloudFormation registry allows these external third-party tools to be provisioned with AWS resources.
With the release of this new service, there are a total of seven SaaS tools offering their resources on the registry. For example, with the support of Atlassian Opsgenie by the AWS CloudFormation registry, you can now provision Opsgenie resources such as users, teams and integrations with your AWS resources. You can therefore automate the configuration of Opsgenie incident management services within your AWS infrastructure.
This means that we can now benefit more from DevOps practices, because AWS has extended its IaC services to external technology stacks and is not limited to AWS alone. Moreover, AWS CloudFormation Registry is open source, so the community can constantly create more custom resources that can be provisioned automatically through the AWS CloudFormation CLI. This improves Cloud adoption, in particular by using IaC to deploy your AWS architectures.
AWS CloudFormation provides third-party resources to include in the recipe books of the Cloud infrastructures you want.
If we are to follow this recipe analogy, the CloudFormation registry can be seen as your resource pantry, where your pantry stores the resources provided by third-party SaaS partners.
The question then is whether you want to extend that pantry?
This is where the CLI component comes into the new release of AWS CloudFormation. The AWS CloudFormation CLI gives us a set of utensils that lets us create our own custom resources, which we can then include in AWS CloudFormation templates, giving us the freedom to extend our pantries indefinitely.
CloudFormation Command Line Interface
AWS provides the CFN ( CloudFormation Command Line Interface ), which lets us initialise our custom resource projects, automatically generates the base code structure for us and then lets us test the resources we have built while registering them in our private AWS CloudFormation registries .
AWS provides us with a complete set of resources to start creating these new resources. Moreover, the open source push with AWS CloudFormation open source means that we can expect many resource libraries to be available and easy to include in our AWS CloudFormation templates.
Thereby improving the whole experience of using the IaC service, increasing the speed at which we build in the Cloud.
With the AWS CloudFormation registry and the CLI interface, we see the benefits of having non-AWS third-party resources in our Cloud infrastructure processes.
We can be assured that using AWS CloudFormation for applications and Cloud infrastructure management now covers all of your needs and not just specific AWS resources.
The flexibility of the AWS CloudFormation CLI and the reliability of the expansion of the AWS CloudFormation registry can only mean that, over time, as more and more resources become available, we can expect that development in the Cloud will become much easier. We no longer have to reinvent the wheel, we now only need to care about the destination.
Contact us for more information!