Features I wish are supported in AWS CloudFormation

Several of the below states features are implemented – http://blogs.aws.amazon.com/application-management/post/Tx3DV2UYG9SC38G/Using-the-New-CloudFormation-Parameter-Types

There is a specific set of people who love CloudFormation and few use cases like DR network setup / restoration, redundant hadoop cluster which work the best for CloudFormation. When I personally tried to create a 3 tier application stack with Private / Public Subnet with EC2 it was an amazing experience, slowly when I tried to do this over and over again the excitement started to fade off – then I found CloudFormation and to compose a text file which will literally translate a bunch of Clicks,Configurations, attachments, launches, reconfigurations was enlightening. I was very proud to tell or enable people to “Version Control the Infrastructure now”.

I really enjoyed when I first wrote a 3 tier VPC stack with multiple Subnets and Security Groups and was able to answer / proclaim to the team that – I can run this template in any Region with Option of selection of AZ ( Thanks to the Mapping Entity in CloudFormation )

Over the period of time, I felt the necessity of few features, better to put it as ways to add more glory to CloudFormation; these are my wishes for this Christmas from Amazon CloudFormation team.

1. Online IDE

2. Ordering of Parameters 
  • Now :
    • CloudFormation empowers flexibility and the principal way how we achieve that is by dynamically having the ability to “key in” the parameters  – the real power was that the parameters can be made used to create the NETBIOS name of the AD in the stack or the AZ of the stack or the selection of the Instance size based on that value; I can go on.
    • Lot of time we end up having nearly 20 parameters ( effect of uttering the word flexibility to your boss 🙂 ) – and the ordering would be in no particular format ( most of the time is in Alphabetical) it would be really hard to look into each and every parameter and the chances of missing to change the key value like CIDR range will backfire you. 
  • Nice if:
    • The logical or best way to solve this issue is to put the key Parameters like CIDR – Range – AZ in the top followed by name of the Instance Tag towards the end, so essentially a way to specify the order / defined sequence of the Parameters.
3. Inbuilt Error Check based on Values Type
  • Now :
    • This is again with respect to Parameters. Chances are both the VPC CIDR and Subnet CIDR are accepted as parameters by your template.
    • There is very high probability that the User ( certainly during demo ) for the user to enter the CIDR for VPC as 10.10.0.0/16 and the subnets’ to be in the range of 10.0.10.0/24
  • Nice if:
    • We can chain the parameter lists to check for use cases like CIDR ranges and sub net CIDR ranges. We have an option to check for the format of CIDR range / IP range using Regular Expressions but we can’t specify if the subnet range is a valid range inside a VPC
4. Drop Down List of Available Values ( Valid Values ) – Improved GUI
  • Now :
    • The easiest way to restrict the user from not entering the dumb values like i1.mini just because there is iPad Mini is to restrict the allowed values like [“m1.small”, “m1.large”, “t2.micro”] etc.
    • When we launch the template the user can change the values and CFN will check if the user entered value is among the allowed values before proceeding for launch ( cool ! )
  • Nice if:
    • There was a clear drop down list to show the list of allowed values – chances are one will choose t1.micro rather than t2.micro in doubt. If the drop down list showed the t2.micro it is easy and intuitive.
5. Improved Error ( Static / Syntax ) Check 
  • Now :
    • When we upload the CFN template for deployment there are several Syntax checks like missing comma, colon, improper nesting etc.
    • There is one type of check which can still be performed in the compilation state – the data type of the property – especially between a direct parameter and the parameter between [ ] (a list)  i.e. for example the ELB can have n number of Security Groups but chances are during the unit testing phase we tend to put a { “Ref” : “ELBSG” } and run it but, the CFN starts deploying and then after launching the subnets, instances, VPC, SGs etc. then when CFN tries to materialize the ELB then it would tell that – it would like the parameter like [ { “Ref” : “ELBSG” } ].  – Works like Interpretation / Interpretor. 
  • Nice if :
    • Here we can completely agree about the syntax to be with [ ] but if the same was checked along with JSON “well-formed” error – it would save a bunch of unwanted launches – roll back – delete stack by extension money.
Advertisements
Categories AWS

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s