1. Home
  2. /
  3. Blog
  4. /
  5. To the Cloud and...
Jun 21,2023 No comments yet By Origo

To the Cloud and Back

TL;DR: While AWS is great for scaling your web-scale start-up, not all projects are web-scale, and not everyone can afford a team of devops. If you have a great idea, don’t have millions in the bank, maybe the complexity, cost and lock-in of the cloud is not the answer. If you are looking for something simpler, reach out.

To the Cloud

Recently I agreed to help a start-up that had lost their lead developer and were in quite a pickle. This gave me an opportunity to dig into some of the more obscure corners of Amazon’s offerings. Their stuff was built on, and ran in AWS. The task at hand: Process audio from players on a sports team recorded during a game or a training session, transcribe it to text, do some statistics on the words found and present the results in a UI. The idea: to analyze and improve team performance through improved communication. I took over their existing code and tech stack which tried to do all of that.

Based on this and other projects, I can confirm confirm David Heinemeyer’s (of Ruby on Rails-fame) observation, that our industry is to some extent rebuilding the Death Star. It did not help that this particular back-end was written in Enterprise Java (the Spring Boot variant). The front-end was React + TypeScript. The end deployables were two more or less stateless containers. Running a couple of containers – that’s easy-peasy, you say. But hold on, being stateless, these containers need somewhere to put their data, traffic needs to be routed to and from them, and why handle a few user accounts ourselves, when we can complexify the hell out of this little task using Amazon Cogito? The amount of moving parts needed to run, what is basically a simple web application, is somewhat crazy:

  1. AWS S3 (for simple object storage)
  2. AWS Amplify (to host a few web pages)
  3. AWS EC2 Load Balancers (to route traffic)
  4. AWS RDS (we need a database)
  5. Amazon Transcribe (speech-to-text service)
  6. AWS Simple Queue Service (to queue up transcribe tasks)
  7. AWS Elastic Container Service (to the containers)
  8. AWS Route 53 (to host the domain)
  9. AWS Cogito (to handle user authentication)

Bear in mind, that each of these services come with literally hundreds of pages of documentation. To multiply the overall complexity, most new web projects today are built using JavaScript frameworks like React, Angular or Vue. This one was no exception (React + TypeScript).

And Back

All the little bugs, errors and short-comings that usually come with building and maintaining stuff with enterprise tools, but without enterprise ressources, were abundantly apparent in this project. Doing things “by the book”, following “best practices” with only a couple of developers, is how this project ended up with the complexity of a modern tech stack, Java EE and the burden of AWS complexity and lock-in. The cloud, frameworks etc. were supposed to make things easier. By now things have turned out quite differently. I think a lot of great ideas and projects get suffocated by this.

To suggest how they could get out of the overwhelming tech stack complexity they had ended up with, I spent a weekend implementing some of the new features they were looking for, using the simplest of web technologies – jQuery + Python, while throwing in the command line utility Whisper from OpenAI for language processing (instead of Amazon Transcribe). The result was a little tech preview powered by about 350 lines of plain Python code and 530 lines of simple Javascript code, packaged as a Docker image of course. It is a rough prototype with all the accompanying caveats. You can check it out here:


Leave a Comment

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.