Todemy architecture
As cloud providers expand and improve their offerings it allows developers to easily implement event driven architecture without by just leveraging tried and true solutions.
‘Serverless’
As the cloud ecosystem has developed the concept of the infrastructure that runs your code is being further and further abstracted. At first abstracting the physical machine away to now abstracting the actual instance. The contract is becoming much more app developer friendly and less understanding is required. Just give the provider code in some form and they will ensure it runs.
This is quite a powerful concept as it allows developers to focus more on application logic which I think is a good thing assuming the developer has some understanding of what is actually happening under the hood as without this understanding it is difficult to make logical decisions in regards to architecture.
I am quite a big fan of the the concept of Lambda as it allows a developer to easily orchestrate an event driven architecture without the tedious set-up (although that code can be quite fun to write). There are many advantages for smaller projects and for Todemy it seemed like the perfect solution:
- Cheap for initial start-ups as there is very low usage :( (compared to always on instances)
- Nearly all Todemy functions is based of a two sided marketplace events
- Easily emit and subscribe to events such as student / expert actions
- Scale without worry if usage picks up
- Easily deploy and spin up all environments
There are cons however:
- Requires more management of both infrastructure and functions together
- Not suitable for heavy computational loads (Todemy currently doesn’t have any)
- Limited access to the filesystem (Todemy utilizes AWS’s storage options S3 and Dynamodb)
With only a limited overhead it seemed like a logical choice.
Deciding the cloud provider
There were only 3 options of cloud providers for us in Sydney: AWS, Google and Azure. I have explored each providers ecosystem but concluded AWS as my choice. Firstly AWS utilize lambda themselves and has the most mature serverless offering. With them being the largest serverless player there was always first class support and bindings available. I was also quite familiar with the ecosystem as for work AWS has always been the primary choice.
Orchestrating it all together
I utilize terraform , serverless and a few custom scripts to glue everything together. I think the biggest barrier to entry is the understanding of how to set-up the infrastructure as code from the beginning. Tutorials usually show the UI console and its easy to click around and not be able to reproduce set-ups. Now that all of this infrastructure is now ironically exposed you will require additional scripts to properly handle the deployment. I personally prefer this as it is almost (maybe a few more iterations) to the amount of abstraction to what is desirable.
A change that I am still working on is folder structure. One of the biggest advantages of Java in my mind is you always know where everything is as there is a pretty simple set standard. Golang has also tried to implement a standard. I’m finding as the codebase matures this is one of the weaknesses as Todemy already has quite a few functions but thats just the software engineer in me at the end of the day a clean structure or not with the same code the end user will experience the same product.