AWS Case Study 8: Product Backlog Refinement Timer for AGILE teams
How it all began..
After writing my previous AWS Case Study in October last year, I was somewhat a little bit struggling about what next I should write about.?
As inspiration was simply not coming, I decided to let the things go on their own and not to worry much about that.
It all suddenly changed in the first week of 2022.
During the Scrum Retrospective meeting with my 2 teams, we came together to a conclusion that we needed a timekeeping application that could replace the need for having someone in the team to play the role of the timekeeper during our product backlog refinements.
What reason does timekeeping serve during backlog refinements?
It is one of the good practices you may come across in highly productive teams operating within the SCRUM framework.
This practice is nothing else than assignment of a time limit which an entire team agrees on to spend on discussing each individual user story during their refinement meeting.
Usually, there is a someone who does this timekeeping job and shouts the famous "Enough Let’s Move On” if the team happens to spend too much time refining one item.
If you can't find it on Google, does it exist?
We tried googling a timekeeping app that would suit our requirements, but unfortunately couldn't find any particularly helpful and usable.
And you know what you do in case you can't find an app which you are looking for??
You develop it :-)
Which features should a good Timer App have?
It should:
What do we need to develop it?
Making an architectural decision..
Do we need a specially crafted and complex cloud architecture to host a simple App?
Absolutely not.
As I have never described in my previous case studies how one can leverage Amazon S3 (Simple Storage Service) together with Amazon CloudFront for the purpose of static webpage hosting, I decided it was now the highest time to do it and use it for our use case.
High level architecture
/click here to download the high level diagram from above in higher resolution/
If you read below what the mentioned AWS webservices are able to do, you may get a very strong impression that we are using quite "a big cannon to kill a sparrow". But why not if these webservices are so ridiculously cheap and so available?
What purpose do these individual architecture components serve?
Amazon S3 - is one of the most famous Amazon AWS webservices. It is an object storage service that stores data as objects within containers that are called buckets. Amazon S3 has low latency and high throughput performance. It is designed for durability of 99.999999999% and for 99.99% availability over a given year. We are going to use it to host our static index.html file there.
Amazon CloudFront - is a global content delivery network (CDN) service built for high-speed, low-latency performance, security, and developer ease-of-use. When a user requests content that we're serving with CloudFront, the request is routed to the edge location that provides the lowest latency (time delay), so that content is delivered with the best possible performance. We are going to use it in combination with Amazon Route 53 to ensure that we are not required to use a standard and technical default Amazon S3 bucket URL, but rather our own domain/subdomain URL.
领英推荐
Amazon Route 53 - is a highly available and scalable cloud Domain Name System (DNS) web service. It is designed to provide us with extremely reliable and cost effective way to route end users to Internet applications by translating names like www.example.com into the numeric IP addresses. We are going to use it to ensure traffic flowing to our domain/subdomain goes exactly to Amazon CloudFront.
Amazon Certificate Manager - this is a component that is not depicted in the high level diagram above, but we definitely need it to generate a public SSL certificate for our domain/subdomain so that we can have our app running not just on URLs beginning with HTTP but also with HTTPS protocol.
Frequently asked questions
1) Could you share some more details about how I can deploy such architecture on my own and host my own Timer App?
Sure, please feel free to download my instructions in which you can find documented all steps that are necessary to follow to configure all of the mentioned AWS webservices.
2) Amazon S3 has a native support for Static website hosting. As I can see from your instructions file, you are not using it but instead you do it differently. Why is that so?
Because of security and the principle of least privilege. This principle is about allowing only enough access to perform the required job. In our case as we are delivering website content to users via Amazon CloudFront, we don't need to make our S3 bucket public, we just need to allow the access to the S3 bucket for Amazon CloudFront.
From the configuration point of view, when you are setting up Amazon CloudFront distribution, you need to allow the usage of so called origin access identity (OAI) and then configure S3 bucket policy to allow read access to OAI (this is something CloudFront can do for you on your behalf so you save some time by doing policy configuration yourself).
3) How come that the Timer App consists of just 1 one file (index.html) and still it also displays some neat graphics and plays various MP3s?
The reason how this is possible is because all graphics and MP3 sounds are embedded directly in the HTML code using the data URI scheme.
The main benefit of this approach is that internet browser is able to download entire app using just 1 http request which makes the app to download extremely fast.?
4) In the JavaScript source code that is included in your index.html file I can see some weird code passages mentioning nosleep or audiosWeWantToUnlock. What purpose do these serve?
The code of the Timer App is both optimized for desktop web browsers and also for mobile phone browsers that are running Android or iOS (iPhone) operating system.?
As Timer App was created just during a period of 1 weekend, it may not function on all of the mobile phones available on the market. If that is your case, try it on the different phone or use it via your desktop PC / on your notebook.
5) Why do you host your app both on HTTP and HTTPS addresses at the same time? Why not just on HTTPS?
The reason behind is that for some mobile users using certain browsers HTTPS version doesn't work well - the NoSleep.js library may not able to prevent the display from turning off after some time of their inactivity. For those, use of HTTP version is recommended.
6) May I ask from which source you downloaded the audio files that state how much time has elapsed?
I used a free service called TTSMP3.
It can generate for you an MP3 audio file containing pronounced version of sentences you type in the text area. You can choose from more than 30+ different accents that reflect both genders.
7) I can hear application sounds but others on my videoconference call can't.
By default, your local computer sounds are not transmitted while you are on a videoconference call. You need to enable them. This is how you can do it in MS Teams and this is how you can do it in ZOOM.
8) Does it cost much to run this app in AWS?
Domain costs: if you use Route 53 for domain name registration, you need to make a yearly payment that represents the registration costs of the domain name (actual price depends on the chosen domain name extension, e.g. my serverless.click domain costs me just $3/year). Additionally you need to pay $0.50/month for the usage of Amazon Route 53 as it hosts your "domain name" (that is your hosted zone and associated records).
Amazon CloudFront costs: costs occur only if your app generates more than 1 TB of data transfer out traffic or your app is visited by more than 10mil. of times per month. As Timer App consists of just 1 file that is 83kB of size, your app would have to be downloaded by more than 10mil. times during the month to incur any costs at all.?
Amazon Certificate Manager costs: Public SSL certificates are generated by this service for free and also they are automatically extended for you each year for free.
Amazon S3 costs: they are not needed to calculate as we cache content via Amazon CloudFront for which you can define caching policy with time-to-live corresponding to 365 days. If that is the case, Amazon CloudFront needs to perform just 1 GET request to fetch index.html file from Amazon S3 per entire year. Storage costs for having 83kB hosted inside Amazon S3 bucket are basically zero.
9) Can I contact you in case I have questions or get stuck with the solution implementation?
Yes, don't hesitate and feel free to contact me. You can reach me via my LinkedIn profile - I accept all requests to connect and will be glad to discuss this or other AWS architectures with you.
If you find this article insightful, please share it. Thank you!
IT at DHL
2 年Simple yet effective example of using AWS cloud services. Good one, Rastislav!
Software Test Engineer | Test Automation Team Lead
3 年Really nice and useful time tracking app. Thank you Rastislav for you innovation!