In the fall of 2018, I decided it was time to put my application design and development knowledge to use in order to provide a modernized solution for my mother-in-law's small business. Her business is designed to help find living accommodations for those relocating to the southeast part of the United States. Since the weather is warm there throughout the entire year, her clientele typically are seeking a nice climate for their retirement years.

The design of the original application she used wasn't optimal and included fields to track aspects related to the purchase and sale of the home. Since there were real estate agents that helped put the deal together, she had fields on each record to track the commission each agent would receive.

Here is a screenshot of the original state, with the content removed for security reasons:

Property details page

One of the biggest challenges, aside from the lack of cosmetic appeal, is that there was a column in the data source for each agent. As new agents were added, new columns were created for each agent. When agents moved on to other opportunities, the columns remained but were hidden from the form's view. There was also a lot of work involved when the management structure for the agents changed.

New Application Journey

Since I wanted to become more familiar with running an application in the Amazon Web Services (AWS) ecosystem, I decided to use my mother-in-law's needs to assist with this effort.

My goal was to leverage the following frameworks:

• Angular/Angular CLI.
• ng-bootstrap.
• angular-font-awesome.
• jQuery.
• Spring Boot (Java API).
• MySQL Database.
• Okta.
• GitLab.

As part of the free trial, I planned to utilize the following AWS components:

• Elastic Beanstalk for the Java API and MySQL Database.
• S3 container to house the static Angular client.
• AWS Certificate Manager and CloudFront.

Within a collection of hours, over a series of weeks where I could locate some free time (having a toddler in the house), I was able to finish the development of the Java API and the Angular client. I found that connecting Okta into the solution was relatively simple. Once I had an understanding of how the solution works.

Application workflow

I was already using a MySQL database in AWS during my initial development. The "gotcha" that I encountered is that Elastic Beanstalk likes to create the application and database instance at the same time. While it is possible to utilize an existing database, I was not able to spend a lot of time getting up to speed with security and configuration concepts within the AWS collection of services. Instead, I was able to export the existing data and move into the new instance AWS created.

The updated application's main form (with test data) is displayed below:

Updated application form

The new form design better grouped the data, and a table of agents was introduced. As a result, only the agent(s) involved in the proper sale were on display — yielding to a better overall application experience.

Life After the Free Trial

AWS is great, in that there is a free trial that lasts an entire year. The AWS console is pretty good about letting you know what qualifies and what does not qualify as "free" during those first 12 months.

Aside from some additional database usage that I encountered for a personal research project, the cost to run my mother-in-law's application was really nothing during the free-trial period. When the final quarter of the free trial started, I tried to dive into the console in order to figure out just how much the services in use were going to cost me for month 13 and beyond. I never quite figured out how to compute all of the costs, but I did not expect to see significant invoices as a result of my new application journey.

Since the free trial has ended, I find that I am spending about $25 per month for my mother-in-law to have a modernized application. Not a bad deal at all, even if I am paying for the services for her.

History Repeating Itself

Eighteen months later, I have found myself in a similar situation as my mother-in-law before the new application journey started. When there are updates to be made to her system, I have a README.md file that I need to review in order to update, validate, and deploy new features and fixes to her application. Since I am not a DevOps person by trade, my personal notes are extremely valuable for me to utilize, since not everything is straightforward in my personal view.

I have steps I need to perform when client updates are performed, both with the Angular framework and with the AWS S3 service that is serving up the static website content. On the back-end side, I have steps that need to be performed when changes are made to the Java API running on Spring Boot. If changes are made to the security layer, I have notes around how those updates are integrated as well.

My fear is that some time along the way, processes will change with AWS, causing my README.md file to no longer be valuable. When this happens, I will likely end up in a scramble mode — the updates waiting while I attempt to determine the new manner in which these DevOps actions need to be handled.

Updated Application Journey

Innovation is certainly the key to success at any level in life. The professional athlete hones their skills on a continual basis to remain competitive. The savvy business professional is always looking two steps ahead in order to find differentiators to keep their product or service at high demand. Software engineers are always looking at ways to best meet the needs of their customers, building upon what was learned from past endeavors.

The size of the project or application does not really matter, as I found myself in the very same position. While the backlog of items I need to do for my mother-in-law's application is small in size, I feel like the project is carrying some technical debt that needs to be resolved:

• I rely on a list of steps to perform updates — not an ideal situation.
• I don't know how my current costs compare to other options.
• I would like a solution that requires less of a DevOps investment.

Considering Heroku

Performing some analysis, I was able to locate some alternatives for my situation. While Microsoft Azure, Google Cloud, and other "cloud" options exist, I wanted to find something that was more than a 1:1 replacement. After all, cost should not be the sole factor when making a technology decision, which is why I had at least two other items (maintaining a helper list of deployment steps and requiring DevOps skills) I wanted to satisfy if I was actually going to depart from using AWS.

I really wanted to consider Platform-as-a-Service (Paas) options at this point of my project. I decided to focus on Heroku, despite having some interest in CloudBees, Firebase, and Engine Yard because Heroku appears to be the clear leader in this space. Honestly, this is the very same reason why I decided to utilize AWS with the original application journey in late 2018.

Setting Expectations

From my early research, I was able to conclude the following differences between my current application space (AWS) and my target space (Heroku):

This exercise allowed me to understand and set expectations for my updated application journey.

The goal of my exercise and this series of articles will be to understand not only the conversion from AWS to Heroku, but to comprehend the new landscape that I am able to develop against.

If I am able to focus my time on addressing business needs for the target application and not have to worry about DevOps specific tasks, the conversion will be considered a win. If the monthly cost is less than or equal to what I am used to paying, that will only add to the benefit of making the transition to Heroku.

Looking Ahead

In the next articles in the series, I am going to start my updated application journey.

The first thing I plan to understand is if there is a "Hotel California" scenario at play for my current application. While it is easy to get started with AWS and Elastic Beanstalk, just how easy is it to take an existing application and move it to Heroku?

From there, I plan to create a new containerized API for use in Heroku. There are some aspects (logged as technical debt) that I wish to refactor on the new journey to Heroku for nothing else than my personal piece of mind. At the same time, I plan to make some adjustments to the client as well, based upon conversations with my mother-in-law.

I will also need to figure out how the static files (in Angular) will be handled in Heroku, as I do wish to move everything to the target destination. I fully expect to apply some security updates as well.

With everything ready to go, I will walk through the process of establishing a new application presence inside Heroku. While my application is quite small, I do hope that this experience can translate to other candidates in a similar situation.

As a conclusion, I plan to provide a comparison of this new application experience to what I have known to become normal in using the AWS ecosystem for the past 18 months. This information will allow a decision to be reached if Heroku is a valid option.

Have a really great day!