Blog

Heroku Wow!

In this blog, I want to discuss the cost of having services in the cloud. In particular, it’s about Platform as a Service (PaaS), because I only want to be able to deploy my service and don’t want to care about managing the servers. I’m going to use my page speed comparison app for this, which I recently moved to Heroku after my Google Cloud trial ran out.

Going from $130 per month to $27. Heroku, is that a play on words for Hero KO !?!

Usually, anyone interested in building an app is first concerned with what programming language or how do I find the right company or devlopers to build it, however, after the initial investment of building the software you are going to have to pay something, even if it’s just the electric for a server and the SSL certificate.

Let’s start with the architecture I opted for with Google. The web application is on Firebase which has been left there for the time being and the web services were consolidated during the move.

 

c4 diagram google cloud architecture

I’m going to look at this without too much regard for the best practices for production setup and concentrate on a just get the app into the cloud. The service on Google was High Availability (HA), so I will do same in the examples. Also, note there is hardly any traffic on my example app.

The cost for hosting my web services for one month could have been $130, but luckily Google is generous and provided a trial service.

google cloud platform bill

The following comparison is not completely fair because I am not showing the CPU or Memory being provided, but, actually I don’t care, I just want the lowest cheapest compute that was available. This is an estimate had I done a similar HA setup using an Amazon Linux nano instances and it might have been about $78. If you are in the first year (free tier) it would only have been only $38.

amazon cloud platform estimate

There is a big difference in the two platforms I’ve discussed so far. I did briefly look at Amazon’s container service, which might have been even cheaper, but got fed up with the complexity and tutorials.

On Google, I would be using Docker Containers and Kuberentes to deploy, with Amazon to automate I’d probably have to use Elastic Beanstalk. These cloud providers have many additional features and services that make them very relevant for small businesses when they need to do more than just hosting an app, for example running automated batch jobs on data. I’ve not investigated the data storage options on Heroku, which is the platform I’m about to cover, but, what makes it interesting is how easy it was to deploy and scale services.

I can’t remember how I came across Heroku which came up on my radar a couple of months ago. Their tutorials are easy to follow, and as I already said, the speed in which you can move a web service over is amazing – it only took me an afternoon. Keeping in line with the above example, the monthly cost for their standard plan would be $75 for three containers, called dyno’s (which is equivalent to the setup I had), and there is an additional $20 for managing the SSL endpoint.

heroku architecture

I actually signed up to using the Heroku hobby plan, so currently my costs are only $27 per month; 7$ for one dyno and $20 for SSL. I will have to upgrade to standard if I need more compute resources, but for the moment I am very satisfied. Only maybe a little happier if maybe I were still with the Amazon free tier, then this might only be about 5$. If you have come across a similar service, I can review, please do leave a comment below.  

Blog

Gantt Charts vs Scrum Agile Processes

This week while catching up with a little technology and media news, I came across a recommendation at the end of the article. This was a link to a blog written in 2010 titled 'The Blueprint for Your Project’s Success – A Project Charter'.

The advertising company Outbrain had targeted me accurately and knew this was a topic I would have an interest in, and despite its age, I think the article is still providing some value, and, despite it primarily being a product placement - Seeing Gantt charts mentioned got me thinking, how can a tool which is essentially a relic of the 1st World War still be circulating as part of a blueprint for success?

I remember this was a question also asked in a project management book 'Scrum: The Art of Doing Twice the Work in Half the Time' by Jeff Sutherland.

Blog posts on pmi.org also warn that "tools are like the proverbial 'emperor’s new clothes.' The better they dress with fancier Gantt charts".

You'll not see a Gantt chart appear in a Scrum project. However, I would support that article and suggest using them on high-level dependency management, controlling workstreams or where you need to plan for multiple projects or application releases.

It can help communicate better even on a small project, they are usually touted as being cumbersome for planning and they can be as anyone who has used Microsoft Project might know.

Have a quick look at this simplified Gantt chart for my recent web app project.

gannt chart of a small project

My choice to place design and at the end might not have been the best.

Had this plan been presented to a team at the beginning, that might have come up in the discussion, because it is immediately visible, but, that is dependent on the circumstances, i.e. I have a background in corporate projects where design is not so important and there usually we try to prove a solution works early. If you are building an application that needs to be sold in an app store, then you would be best spending much more time on design upfront.

Using Gantt charts the tendency is to try to organise each step the team will need in great detail, which if your diligently updating week for week, not only will amount to a lot of work, but you won't be making use of the team's expertise and there will be a lot of guesswork.

I've been in projects where the design work held up work for several months, it kept us from actually building the product.

Gantt charts just don't help improve efficiency and don't concentrate enough on the minimum viable product (MVP), using a Scrum backlog you might have broken down the design into one screen and could have had something to look at with a customer very quickly, which is the reason why I would stay away from using a Gantt.

Generally building an application as fast as possible is just not going to happen by using a Gantt chart.

If you're using Scrum processes, then you are reviewing and reordering work items on a weekly if not daily basis. Working with a Gantt chart you plan everything out and map progress as you go along. The biggest problem then is that you start estimating how much time each step will take, which in any project can be somewhat difficult - some, even go as far as planning hourly tasks. I'm amazed people still think that way of planning works. In Scrum that is avoided by comparing work items based on complexity and unknown factors which the team might need to figure out.

Either way, I think we will be seeing Gantt Charts for a while yet. Having just listed several negative points, I wouldn't write them off altogether, even in a Scrum project there is a need to track how epic stories are progressing.