Following on from Part 1 and subsequent posts, I now have the app deployed locally on WildFly 17, up and running, and also redeployed to a small 1 cpu 1 GB VPS: http://www.spotviz.info . At this point I’m starting to think about how I’m going to redesign the system to take advantage of the cloud.
Here are my re-design and deployment goals:
- monthly runtime costs since this is a hobby project should be low. Less that $5 a month is my goal
- take advantage of AWS services as much as possible, but only where use of those services still meet my monthly cost goal
- if there are AWS free tier options that make sense to take advantage of, favor these services if they help keep costs down
Here’s a refresher on my diagram showing how the project was previously structured and deployed:
As of September 2019, the original app is now redeployed as a monolithic single .war again to WildFly 17, running on a single VPS. MongoDB is also running on the same VPS. The web app is up at: http://www.spotviz.info
There’s many options for how I could redesign and rebuild parts of this to take advantage of the cloud. Here’s the various parts that could either be redesigned, and/or split into separate deployments:
- WSJT-X log file parser and uploader client app (the only part that probably won’t change, other than being updated to support the latest WSJT-X log file format)
- Front end webapp: AngularJS static website assets
- JAX-WS endpoint for uploading spots for processing
- MDB for processing the upload queue
- HamQTH api webservice client for looking up callsign info
- MongoDB for storing parsed spots, callsigns, locations
- Rest API used by AngularJS frontend app for querying spot data
Here’s a number of options that I’m going to investigate:
Option 1: redeploy the whole .war unchanged as previously deployed to OpenShift back in 2015, to a VM somewhere in the cloud. Cheapest options would be to a VPS. AWS LightSail VPS options are still not as a cheap as VPS deals you can get elsewhere (check LowEndBox for deals), and AWS EC2 instances running 24×7 are more expensive (still cheap, but not as cheap as VPS deals)
Update September 2019: COMPLETE: original app is now deployed and up and running
Option 2: Using AWS services: If I split the app into individual parts I can incrementally take on one or more of these options:
- Route 53 for DNS (September 2019: COMPLETE!)
- Serve AngularJS static content from AWS S3 (next easiest change) (December 2019: COMPLETE!)
- AWS API Gateway for log file upload endpoint and RestAPIs for data lookups
- AWS Lambdas for handling uploads and RestAPIs
- Rely on scaling on demand of Lambdas for handling upload and parsing requests, removing need for the queue
- Refactor data store from MongoDB to DynamoDB
Option 3: Other variations:
- Replace use of WildFly queue with AWS SQS
- Replace queue approach with a streams processing approach, either AWS Kinesis or AWS MSK
More updates coming later.