Recently, I moved the IT Hub from Pivotal Cloudfoundry to Amazon Web Services (AWS). This article highlights some of the decisions and illustrates the resulting architecture.
Some weeks ago, Pivotal announced the end of availability (EOA) for Pivotal Web Services (PWS), effective as of January 15, 2021. As the maintainer of the IT Hub, this forced me to move the application to a different solution pretty fast.
Where to go?
Cloudfoundry provided the luxury of a Platform as a Service (PaaS), meaning it only takes a .jar for the backend and the static frontend-files as input, plus some environment variables. Everything else like networking, connecting services or configuring gateways is done by the platform. Because the migration had to be realized quickly, a similar simple solution would have been a logical solution. A number of platforms offer PaaS so there is plenty to choose from.
At the same time, I received the notification from Pivotal, I studied AWS for the projects of my daytime job. That put me in an interesting position. Do I invest in learning yet another PaaS to deploy my application there or do I use the knowledge I’m already getting familiar with? Although using a PaaS may have been the faster solution, in career investment thinking it would also be a dead end. It would solve my immediate problem but would not provide the most learning and self-development experience like AWS does. In other words, I can solve more problems learning and using AWS than using another PaaS. Because of the unmatched potential of AWS, the IT Hub also benefits from this dynamic and huge environment. I decided to at least give it a try and migrate the application to AWS. If that would not work out, there would be plenty of time to use another PaaS. Spoiler alert: AWS is great, and the migration went smoothly.
How Things were
Back in Cloudfoundry, the architecture was straight-forward. Two identically configured spaces, one for testing and one for production, held two apps each: A 1 GB RAM / 512 MB disk instance for the Spring Boot backend and a 64 MB RAM / 128 MB disk instance for the Angular backend. Both apps were not configured to autoscale. An ElephantSQL with a free Tiny Turtle plan held the data and a quite expensive Pivotal SSL service provided the TLS certificate.
The monthly costs of $42,95 consisted of $21,60 for the backend plus $1,35 for the frontend plus $20,00 for the SSL service.
The main benefit of having nothing to configure was paid by the relatively high monthly bill and by the fact that the database did not support automatic backups and the TLS service did not support certificate renewal. Both conditions produced additional manual workload for me.
In short: Running on Pivotal Cloudfoundry worked, but it was expensive and needed some manual work.
How Things are now
The image below describes the current architecture on AWS, including the prices based on on-demand options.
The frontend sits in an S3 bucket with activated “website-mode”. A page request is answered by CloudFront, which caches the whole page worldwide.
The backend runs on an EC2 instance which is managed by Beanstalk, which also has a RDS database. The load balancer in Beanstalk uses the Certificate Manager to deliver TLS.
As mentioned above, the main goal was to move the application to AWS without investing in huge architectural changes yet. It’s more like a lift & shift from Cloudfoundry to AWS. That is the reason why I decided to use Beanstalk as an easy-to-use PaaS to run the backend.
The ~ $2 price for the frontend is calculated with one deployment per week, which uploads the ~200 files from the frontend to S3 and includes invalidation of the CloudFront cache.
Using one-year-plans and paying all upfront, the calculated monthly total cost can be lowered to $16,41 = 14,04€, which is only 35% of the original Cloudfoundry costs.
Implications
In the current configuration, I could move the application to other cloud services easily because none of the AWS-only services are used.
A nice improvement is the automatic certificate renewal of the Certificate Manager and the automatic database backup.
The application can be scaled easily, however that would have been possible with Cloudfoundry, too. AWS offers more options, though.
The complexity of this architecture is way higher than with Cloudfoundry. There are many more nuts and bolts that must work together, and a solid understanding of the used services is required to maintain the application. The many specialized services that cause this complexity open a lot of future options for the platform to grow and scale. With the end of Cloudfoundry and the ongoing raise of AWS, know-how for this kind of architecture will be available more and more.
Prospects
To reduce the monthly cost even more, I could replace the ever-running backend on beanstalk with lambda functions. However, this would mean a total rewrite of the Spring Boot backend to only save ~$4 a month.
Summary
The migration from Cloudfoundry to AWS caused additional complexity while giving more flexibility and more maintainability while lowering the monthly cost.