Welcome to the next issue of the Tidy Cloud AWS newsletter! In this issue, we mainly cover a new neat thing from Pulumi, and some AI-related news from AWS. I am also planning to change the cadence for publishing Tidy Cloud AWS issues to a weekly schedule. The plan is also to have a more focused theme for each issue as well. So in this issue, the theme is enhancements using AI.
The big news from Pulumi recently is the announcement of Pulumi Insights. This is a set of features of Pulumi Cloud, the service formerly known as Pulumi Service. It includes extensive search capabilities, both with a query language and natural language processing capabilities. There are also additional features for retrieving data for analysing and visualisation, and it can be handled both via the web user interface and with API calls, with options to export data to other tools.
There is also an AI assistant to help build infrastructure with code, both as a web-based tool and a command-line tool. It allows for natural language descriptions of what infrastructure you want, and it will generate the code for you, in any of the supported languages.
You can try the code generation AI assistant yourself at https://www.pulumi.com/ai/.
I have experimented with it a bit, and it is pretty neat. Do not expect to have a fully functional infrastructure solution right away. It may take a few steps in the dialog, or a few iterations in describing the infrastructure you want. Sometimes it stopped in the middle of the code generation and started all over again, although not quite with the same code as before. Asking it to output the complete code again helped.
There is also a command-line version of the tool. It requires an OpenAI API key to work, though. The API key I had is for GPT-3, and I also have a free trial account where all token have been used up, so I could not use it any further with that account. Thus, the pulumi-ai tool only gave me error responses because of the API key.
An example of a text description I used for Pulumi AI to generate code for the infrastructure was this:
I want a container service with 2 instance running ECS Fargate behind an application load balancer. An API Gateway HTTP API should integrate with the application load balancer to expose a public API. The container is provided via a dockerfile. An existing VPC shall be used, whose VPC is read from the parameter store. The name of the parameter store parameter is read from pulumi config, as well as the desired count of the service. The API gateway shall use a domain name "api.awesome.com". The subnets to use are tagged with the tag name "subnettype" and the value "private". Generate a certificate for the domain name and suitable task execution role.
A few fun facts:
- The Python code was straight generation and logic, resource by resource. It uploaded the docker image to ECR.
- The Go code was sometimes divided up into functions for some resources. It was also the most confused one, in that started all over and output a different version of the code more than the others.
- The Java code used the Pulumi CDK to leverage AWS CDK to build the above infrastructure.
- The Typescript code used the AWSX module, and Dockerhub.
- C# put the docker image in ECR as well, same as Python. It also started all over when generating the code a few times, similar to Go.
- In YAML, it skipped defining an ECS cluster and asked me to provide the reference to it. Then it changed its mind and added to the ECS cluster.
Some differences are interesting, since it shows a bit what code the tool has been trained to leverage. You should expect to do tweaking and corrections of the code, at the very least some refactoring for modularity and better names for resources.
The next experiment I did was to ask Pulumi AI to translate a bit of CloudFormation into Pulumi code. The text buffer in the web interface is a bit small to handle verbose CloudFormation, so I asked it to translate a CloudFormation sample at a public URL:
It converted the CloudFormation code successfully at an initial glance. It picked a t2.micro instance for the server, and also choose to use a long-term support (LTS) version of Amazon Linux 2, instead of the older machine images (AMIs) in the CloudFormation template.
Next experiment was to translate a Terraform sample to Pulumi. Again, I used a public sample, which in this case comprised 11 Terraform files.
It understood correctly what was included. However, in the middle of the code generation, it started all over again, and lost the RDS instance. A gentle reminder fixed the problem, though, and it added it to the result.
I really like that Pulumi is trying out novel approaches to managing infrastructure with software. While tools like Terraform and CloudFormation have a larger share of the market, I think a lot of new interesting development is coming from players like Pulumi.
It is nice to see that the translations from other tools generate something that is a good starting point at least. Keep it up, Pulumi!
AWS code assistant tool, CodeWhisperer, is now available. It is free to use for individual use. Here, you typically use an AWS Builder ID, which is a personal id not connected to any specific AWS account or organization. You get CodeWhisperer as part of the AWS Toolkit that is available for multiple code editors and integrated development environments, including the tools from JetBrains and Visual Studio Code.
I have used it for code editing and so far my feelings are mixed. Sometimes its code suggestions are pretty good, sometimes not so much. To some extent, it changes how I write the code to minimise the annoying suggestions.
Overall, I am positive, but only time will tell.
You can find older newsletters and more at Tidy Cloud AWS. You will also find other useful articles around AWS automation and infrastructure-as-software.
Until next time,