The new COBOL program is the cloud formation template, it does not matter that it is an YAML/JSON.
Few years ago, the main drive for bringing JAVA/.NET framework into the shop was to de couple the giant multi thousand line COBOL programs. These programs had a library of key words. This could be used and the main logic for those programs were based of specific Boolean flags or at least the COBOL programs that I migrated were of this kind of as such.
Fast forward to my new world of writing cloud formation templates, these are the next set of monoliths that are a few thousand lines. The few keywords/logics that can be written are called intrinsic function.
There are different sections in a COBOL program, the same applies to a cloud formation template, for example you have a program, divisions, section etc. The same parallels can be applied to a cloud formation template, there is a section for declaring parameters, conditions, resources and the output.
The next item in a cloud formation are the conditions., this is the section where the parameters passed to the cloud formation templates are evaluated, so that right resources can be provisioned. If you have seen a COBOL program flag logic, this section is the same.
The resources section of the cloud formation template uses the conditions that you defined earlier to provision the resources that is needed.
The output section of the cloud formation stitches all these above sections so that there is an user friendly output.
All these sections are closely tied together, if one fails or errs out, then the entire stack is a dud.
Thinking about doing a cloud formation template, as an engineer it is a challenging feeling to support this development practice. Is this the correct thing to do for the modern world? Cheers.
We will go over a working example that uploads a photo to Azure Container as a Blob. The final codebase will run to upload a photo-based on a CURL command
Now let us see how to go about getting this to work with Azure functions. The reason I chose Azure functions is the free tier that you get for doing a quick app. The first million calls are free and there is a 5GB free space in the Azure storage. The API is front-ended with Azure API services. Few configurations can be done, but we will keep that in another post. The first block we are going to look is the Function, to get this going, we will use the maven archetype for developing Azure functions.
This creates a bare Azure function that can get an Http Post call to a URL. Two files will be created from the archetype. The first one is host.json and local.settings.json. Now the other important item to look is the pom.xml file.
The function name is uploadSathishPhoto
<functionAppName>uploadSathishPhoto</functionAppName>
We have to make sure the function name here matches with the Java Function API. So here is the JAVA API function
public class UploadSathishPhotoFunction {
public static final String PHOTOPATH = "photopath";
@FunctionName("uploadSathishPhoto")
public HttpResponseMessage run(
@HttpTrigger(name = "req", methods = {HttpMethod.GET,
HttpMethod.POST}, authLevel = AuthorizationLevel.FUNCTION) HttpRequestMessage<Optional<String>> request,
final ExecutionContext context) {
context.getLogger ().info ("Java HTTP trigger processed a request.");
String photometer;
photometer = request.getQueryParameters ().get (PHOTOPATH);
String photograph = request.getBody ().orElse (photometer);
if (photograph == null) {
return request.createResponseBuilder (HttpStatus.BAD_REQUEST)
.body ("Please pass a photo path on the query string or in the request body").build ();
} else {
BlobServiceClient blobClient;
BlobContainerClient container1;
try {
blobClient = BlobClientProvider.getBlobClientReference ();
context.getLogger ().info ("\nCreate container ");
container1 = createContainer (blobClient);
context.getLogger ().info ("\n\tUpload a file as a block blob.");
BlobClientProvider.uploadFileBlocksAsBlockBlob (container1, photograph);
context.getLogger ().info ("\t\tSuccessfully uploaded the blob.");
} catch (Throwable e) {
context.getLogger ()
.log (Level.SEVERE, "Java HTTP trigger processed a request.", e.fillInStackTrace ());
}
return request.createResponseBuilder (HttpStatus.OK).body ("Hello, " + photograph).build ();
}
}
}
Now the function relies on the Azure model, where there is a Need for a BlobClient to start the entire upload function. Then there is a container that holds on the blob. Finally, the blob item will be stored. In our application, we have two classes that are going to take care of the initializing a BlobClient and Container. We are going to upload all the pictures in this function to a specific container. The source code for these classes is checked into.
To run the function run the maven commands
mvn clean install
mvn azure-functions:run
When doing the install, keep an eye on When doing the install, keep an eye on the console output to make sure there is an Azure function being built. This gives an indication to us that the function is being packaged.
[INFO] Step 1 of 7: Searching for Azure Functions entry points
[INFO] 1 Azure Functions entry point(s) found.
In order to run the application locally, the maven command is
mvn azure-functions:run
Keep an eye on the console to make sure the function is started
uploadSathishPhoto: [GET,POST] http://localhost:7071/api/uploadSathishPhoto
Hosting environment: Production
Content root path: /Users/sathishjayapal/IdeaProjects/blob-azfunction-start/target/azure-functions/uploadSathishPhoto
Now listening on: http://0.0.0.0:7071
Application started. Press Ctrl+C to shut down.
[01/13/2020 02:47:54] Host lock lease acquired by instance ID '0000000000000000000000004DD021D9'.
We have a simple cloud formation file in a YAML format. There are couple of parameters that need to be passed to this template. We want to make sure the parameters that are being passed are based on whether it is a PROD/Test environment.
Here is the sample simple S3 upload file template
AWSTemplateFormatVersion: 2010-09-09
Metadata:
...
Parameters:
S3BucketName:
...
Type: String
CorsIDRuleName:
Default: DEVCorsRuleID
Description: Cors ID Rule information for the s3 bucket to post
Type: String
Resources:
S3B3SR4G:
Type: 'AWS::S3::Bucket'
Properties:
BucketName: !Ref S3BucketName
AccessControl: PublicRead
CorsConfiguration:
CorsRules:
...
Id: !Ref CorsIDRuleName
MaxAge: '3600'
Now based on the environment, we have two parameter files that have to be used. For test we will use the test-config.json file and production we will use the prod-config.json file.
I was not able to pass parameters from another yaml file
Template can be yaml, but when parameters are to be externalized then it is had to be from a JSON file only
Parameter file though in JSON had to follow some specific conventions for yaml file. In our example “ParameterKey”, “ParameterValue” had to be in the format for CF/YAML config. To pick up.
