DEV Community: shirtctl

Breaking News! Startup develops stronger architectural foundation by gathering requirements first!

Anthony Wales — Thu, 07 Nov 2019 21:50:22 +0000

The start of any project is exciting, and shirtctl is no different. Last month Blair and I announced we’re working a brand new project to bring continuous delivery to tech tees.

We set out with a goal to help tech brands create and ship cool t-shirts reliably to their fans at any time. 👕👚

From our experience, we know just how easy it is to get carried away with building technology solutions before we even understand our requirements.

This article is a summary of the principles we developed throughout first #shirtday hack, and how they informed certain architecture decisions. And since we’re building shirtctl in the open, expect to see more posts about how we implement these as our project develops.

Our Mission:

We make it super easy for companies to build their brand and connect with the community by harnessing the awesome power of t-shirts.

How: Our MVP: For shirtctl to work, we need to be able to join brands and fans together for the reliable transfer of merchandise.

With our MVP defined, we had everything we need to consider what high level platform architecture decisions we would need to make to build a strong technology foundation.

Requirement Principles:

    * [Flexibility](#Flexibility)
    * [Relentless Focus](#Relentless-Focus)
    * [Security in Depth](#Secure)
    * [Frugal by Design](#Frugal-Architecture)
    * [Easy to Consume](#Easy-to-Consume)

Flexibility

We are going to make mistakes. Our path, like any startup, is unclear. Recognising that we are only a small team, we have to live and breath the fail-fast approach to bring shirtctl to life as soon as possible.

If we need to change directions, we need to be able to do so quickly without having to rebuild from scratch.

Image Source

Adopting Architectures:
Hybrid Cloud Architecture provides:

Rapid deployment.
Horizontally scalable.
Heavily automated.
Standardisation.
Minimum commitment (some services are billed per 100ms).

Continuous Delivery Architecture (Continuous Integration with Continuous Delivery):

Short software deployment cycles releasing software with greater speed and frequency.
Incremental updates for patching and feature enhancement.
Software release governance.

Relentless Focus

We know our main goal is to connect tech brands and their fans, not to host and manage infrastructure. We don’t have time to do the Design, Build and Run of a new infrastructure and platform service. In addition, the management overhead of a single tenancy wouldn't be time or cost effective. We are trying to shift as much as possible to managed services so we can worry just about shirtctl and leave the rest to the to the infrastructure experts.

Image Source

Adopting Architectures:
Managed Cloud Architecture:

Responsibility abstraction (just worry about the code, 'Serverless').
Consumption based billing.
Pre-architected building blocks.

Serverless Architecture provides; outsourcing as much responsibility as possible so we can just worry about the code.

Security in Depth

With cyberattacks on the rise, and increasing consumer awareness of the risks of personal information being exposed, we need a modern approach to security that is simple and effective. We want to keep shirtctl free of traditional approaches to security that are prone to failure and costly to design, build and manage.

Image Source

Adopting Architectures:
Zero Trust Security Model:

An alternative security model to not trust anything remediating the rudimentary fault in traditional strategies to only protect from the outside. In this architecture, every pillar is verified.
All communication paths need to be encrypted especially for micro-services.
Validation and authentication are performed between all services.
Low cost with minimal special tooling required.

Frugal by Design

As a super interesting side-project, shirtctl has no funding to splurge on unnecessary expenses. Just like a 1990’s startup using the garage as an office, we’re using modern architectures for their opportunities to save big on cost and time. As a public cloud consumer, we’re capitalising on the opportunities that cloud presents to pay for only what we consume.

We don’t expect to ever have to invest big in infrastructure development projects to enable our data lake or deployment pipeline, and just like we see the biggest disruptors changing their markets, we’re hoping it works for tech tees too.

Image Source

Adopting Architectures:
Public Cloud Architectures:

Consumption based billing with some products such as serverless allowing you to only pay for the CPU/RAM cycles used to run the code not the OS and below.
Free tier pricing for certain services to help get you started allowing for experimentation with different technologies ensuring you pick the best one.
Startup credits to be used on any service allowing you to try services that have costs associated.

Easy to Consume

With our small team and non-existant budget, we need shirtctl to be usable by as many people as possible. So we’re starting out with a web app at https://shirtctl.com. We think you’ll like it when ready. A lot.

Image Source

Adopting Architectures:
Web App Architecture:

Availability to be accessed over the internet.
Compatibility with many different platforms and devices.
Very low time to get your product into the hands of your potential consumers.

Building a super fast serverless container deployment pipeline on Google Cloud

Blair Hudson — Wed, 06 Nov 2019 03:10:11 +0000

One of our driving principles for shirtctl is #frugalbydesign - we simply don’t want to be paying for anything that we don’t use.

Our architecture needs to balance cost alongside other core capabilities like application security 🔒, design flexibility 💪 and developer collaboration 👩‍💻👨‍💻.

In this post, we’ll be sharing the some of the details of our continuous deployment pipeline. We’ve combined BitBucket with Google's Cloud Build service, which deploys our applications onto Cloud Run in an average of 1-2 minutes per build!

For development, we’ve also created a local build workflow to:

Speed up local code iteration 🏎💨
Minimise the number of Cloud Build jobs and Cloud Run revisions (#frugalbydesign) ☁️
Keep our commit log tidy! 🧹

Here’s a high level view of our approach:

Now let’s take a closer look at some of the major components. 🔎

Speedy local builds

Our MVP sign-ups API is a Python Flask app. It relies on a few various Python packages that provide the REST framework, email, storage and other capabilities. Right now it’s a simple api.py file and a requirements.txt that represents our package dependencies.

Our Dockerfile for local and cloud deployment is purposefully identical, so we can focus on API development.

FROM python:slim

# install python dependencies
RUN python3 -m venv /app/env
COPY requirements.txt .
RUN /app/env/bin/pip install -r requirements.txt

# configure port (Cloud Run requires 8080)
ENV PORT=8080
EXPOSE $PORT

# setup application runtime
WORKDIR /app/src
ENV GOOGLE_APPLICATION_CREDENTIALS="/app/sa-key.json”

COPY entrypoint.sh .
RUN chmod +x entrypoint.sh

COPY api.py .

CMD ["sh", "-c", "./entrypoint.sh"]

We have a localbuild.sh script that emulates Cloud Run deployment locally using Docker, which means we can iterate our development tasks very quickly without having to redeploy to Cloud Run.

#!/bin/bash
REPO=$(basename -s .git $(git config --get remote.origin.url))
BRANCH=$(git rev-parse --abbrev-ref HEAD)

gcloud iam service-accounts keys create sa-key.json \
 --iam-account service-account@project.iam.gserviceaccount.com
SA_KEY_FILE_BASE64=$(cat sa-key.json | base64)

docker build -t shirtctl-${REPO}-${BRANCH}:latest .

docker run --rm -it \
 -e K_SERVICE=localbuild \
 -e SA_KEY_FILE_BASE64 \
 -p 8080:8080 \
 -v $(pwd):/app/src \
 shirtctl-${REPO}-${BRANCH}:latest

We can “hot reload” 🔥 our changes to develop even faster! entrypoint.sh determines at run time whether to run Flask or Gunicorn depending on the value of $K_SERVICE. This way our Flask service restarts automatically when changes to the source code are detected:

#!/bin/bash
echo $SA_KEY_FILE_BASE64 | base64 -d > $GOOGLE_APPLICATION_CREDENTIALS

if [ "$K_SERVICE" = "localbuild" ] ; then
    export FLASK_APP="api.py"
    export FLASK_DEBUG=1
    /app/env/bin/flask run --host=0.0.0.0 --port=$PORT
else
    /app/env/bin/gunicorn --bind=0.0.0.0:$PORT api:app
fi

BitBucket to Cloud Source Repository

Code is committed and pushed to a private BitBucket repo. Our branching structure is simple:

⚙️ dev for feature-based development (we can have as many of these as required!)
✅ test where all feature dev branches are merged to (by pull request only)
🚀 prod where test is released to (also by pull request only, with dual approval required)

The BitBucket repo is automatically synced to a Cloud Source Repository of the same name and branch structure.

Deploying with Cloud Build

Cloud Build allow a build job to trigger on a push to our repo. This runs submits the cloudbuild.yaml file from our repo to Cloud Build, which accomplishes the following steps for the current branch:

Pulls the previous Docker image from Google Container Registry

docker pull gcr.io/$PROJECT_ID/$REPO_NAME-$BRANCH_NAME:latest

Builds and tags a new Docker image from our Dockerfile above:

docker build . \
 --cache-from gcr.io/$PROJECT_ID/$REPO_NAME-$BRANCH_NAME:latest \
 -t gcr.io/$PROJECT_ID/$REPO_NAME-$BRANCH_NAME:$SHORT_SHA \
 -t gcr.io/$PROJECT_ID/$REPO_NAME-$BRANCH_NAME:latest

Pushes the latest image to Google Container Registry:

docker push gcr.io/$PROJECT_ID/$REPO_NAME-$BRANCH_NAME:$SHORT_SHA
docker push gcr.io/$PROJECT_ID/$REPO_NAME-$BRANCH_NAME:latest

Deploys the latest image to Cloud Run, and maps the appropriate domains to access the service:

gcloud beta run deploy $REPO_NAME-$BRANCH_NAME \
         --image gcr.io/$PROJECT_ID/$REPO_NAME-$BRANCH_NAME:$SHORT_SHA
gcloud beta run domain-mappings create \
         --service $REPO_NAME-$BRANCH_NAME \
         --domain $BRANCH_NAME.$REPO_NAME.shirtctl.com

That's all for now! Keep an eye on shirtctl.com for our MVP sign-ups launch! 👕👚

shirtctl --blog: a series on building a tech tee startup

Blair Hudson — Thu, 31 Oct 2019 08:53:00 +0000

Hey there and welcome to shirtctl --blog.

This is the very beginning of the official blog of shirtctl! Pronounced “shirt control”, we’re bringing continuous delivery to tech tees. 👕👚

Ok, what in the world are you talking about?

In the world of DevOps, continuous delivery is an approach to building and shipping great software to users at any time, with a focus on reliability. 👨‍💻👩‍💻📦🚢

In the world of tech merch, that means creating and shipping cool t-shirts reliably to fans at any time. 😎

So what is this blog about then?

We’re building shirtctl out in the open!

In this blog we’ll be publishing a series of short posts around all of the product, user, architecture, engineering and design challenges we have. We'll be detailing the options we explore and how we make key decisions, all to show you the steps we take building shirtctl from scratch as a cloud-native data-driven DevSecBizFinOps startup! 🚀

And you can ask us anything along the way! (Just leave a comment.)

Hmm... who are you anyway?

shirtctl began in the warmth of down-under October 2019 by Sydneysiders Blair Hudson and Anthony Wales. Initially one of those this-is-so-crazy-it-just-might-work ideas, we’re combining our experience across Australia’s technology sector to sprint 🏃‍♂️, hack 💻 and ship 📦 our way to tech tee haven. How exciting!

Wait, I’m still confused. What is your product?

How would you like free tech tees delivered to your office every* month?

🤩 Sounds good? We think so too!

(*Assuming we can find something in your size. We think we can!)

You said free?

We’re making it super easy for technology companies to build their brand and connect with the community by harnessing the awesome power of t-shirts. ✨ They provide the goods and cover shipping. You provide your size and office address. shirtctl makes it all happen. Simple!

I love it! Where do I sign up?

While we haven’t launched yet, we plan to start sign-ups for developers working in Sydney very soon. 🥳

In true MVP style, devs will be able to sign-up using our awesome API and the programming language of their choice! Follow our blog (dev.to/shirtctl) and keep an eye on shirtctl.com for docs to get started.

Once we prioritise it (#agile), we’ll be building out a sign-up form for everyone else to join in on the free tee fun too (including the lazy devs)! 👫👬👭

I want to build my brand, how do I make tees available?

Watch this space. shirtctl is working with a small number of launch partners in Sydney to create a fantastic SX (we coined it, shirt experience is the next big thing). Then we'll open up to all!

If you’re really really interested to be involved early, reach out to us in the comments or using the links to our LinkedIn profiles above (since we haven’t prioritised building a contact form yet...).

👕👚