Better Code AWS Boto3 using Factory Method
“Opinions expressed are solely my own and do not express the views or opinions of Amazon”
What to expect from this article:
- What is the Factory Method?
- How to implement Factory Method
- Performance Before and After
- Logging Before and After
- Final Thoughts
- *This is going to be a tutorial on how to make a Blue/Green Canary Deployment using AWS ECS + AppMesh + StepFunctions. If you ‘re looking for the AWS portions, and less about the software development skip this article and go to part 2.
We will cover more in depth what’s a Blue/Green Deployment, and a Canary Deployment and why we want to combine these in a later article, Here’s a quick example of what we’re aiming for.
What is the Factory Method?
Design patterns became a popular topic in late 90s after the published book Design Patterns: Elements of Reusable Object-Oriented Software. This book goes over several design patterns as solutions to reoccurring problems in software. The book describes the Factory Method as a creational design pattern. Creational design patterns are related to the creation of objects, and Factory Method is a design pattern that creates objects with a common interface. In modern programming this is a method that is one of the most widely used design patterns, and I’m going to show you how to apply that to python and Boto3.
How to Implement the Factory Method
This is an example interface to show how you using the factory method we can guarantee logging on all function calls using this Boto3 AppMesh library.
Utilizing concepts of naming, and reduced inputs from Clean Code
- Classes are Nouns (AppMesh)
- Functions are Verbs (create_mesh)
- Reduce Function inputs to absolute minimum that makes sense.
We create our simple factory for AppMesh. The check_mesh_exists() and the create_mesh() are both concrete implementation methods of the product. Our product (AppMesh Object) is the outcome of using “buisness logic” to actually piece to initiate the client (AppMesh Interface). To do this we use our business logic which would be referred to as the creator component. For simplicity stakes here, Let me post a translation of this technical jargon.
Product = Library | (mesh.py)
Client = Object | (mesh = AppMesh(logger, mesh=”canary”)
Creater = Deployment | canary_deployment.py
Performance Before and After
Before we implore this method we are missing a few important things
- Logging with TimeStamps
- Try/Catch Blocks
- Function Calls for Easier Debugging
BUT since we forego all of these it should be way faster right?
Wrong it’s slightly faster, but the 5% speed increase we are getting here doesn’t make up for the fact we lose all those other important items when developing and troubleshooting.
Logging Before and After
- Due to the Default Boto3 version used in Lambda being 9 months old, we need to upload a newer version into our ZIP packages to use the AppMesh API. Adding this makes our ZIP’s over the 10mb local editing limit in the lambda console.
- We will be using SAM to upload/change code rapidly in Lambda/Stepfunctions
We will rely on local development initially, and trust SAM to package and upload correctly. This is a comparison of the logging I get locally and in Cloudwatch using a Class with a logging interface, and without.
The 2nd option is more readable, and easier to write follow up logic with this way since I can see what’s a list vs dict. This will also print into Cloudwatch in a collapsable json format, vs printing a blob format.
Final Thoughts
There is no need to reinvent_wheel() Since the factory method is a well defined, and documented standard in modern programming. It’s less code to write, and comes with the guardrails of logging/error handling/tracing built into every object as we write our canary deployment.
Stay Tuned for Part 2 of this series where we Go into detail setting up our AppMesh!!!
Be Sure to keep updated on the Github too!
