DEV Community: Morgan Wowk

Deploying an HTTP app using Docker + GKE + Cloudflare

Morgan Wowk — Thu, 23 Feb 2023 23:26:59 +0000

Recap
Living document intention
Serving an HTTP app using Docker, GKE and Cloudflare
- 1. Write an HTTP app
- 2. Build the app into an image
- 3. Register and onboard with Google Cloud
- 4. Setup a Google Artifacts Registry project
- 5. Tag the Docker image based on Google's Artifact Registry
- 6. Install the gcloud command on your machine
- 7. Configure and authenticate gcloud
- 8. Push the Docker image to Artifact Registry
- 9. Set up a Shared VPC project
- 10. Set up a shared GKE cluster project
- 11. Set up Cloud SQL instances
- 12. Create a Kubernetes cluster
- 13. Prepare secrets for staging and production
- 14. Create your first GKE workload
- 15. Apply secrets to GKE workloads
- 16. Prepare Cloudflare for Total SSL
- 17. Expose your application using Cloudflare Tunnel
- 18. See your application live 🎉
Where does our trip take us next? 🚀
Changelog
Stay connected 💬

Recap

Software Engineering Entrepreneurship » Issue 5 » Up and running with Google Cloud

Morgan Wowk ・ Feb 18 '23

In issue 4-5 of my series Software Engineering Entrepreneurship we covered the technology stack serving the foundation of our future apps as a Software Engineer-by-day turned Entrepreneur.

Living document intention

At the start of this series I disclosed that I would not give a step-by-step tutorial at any point. This document, however, will serve as the most important log and perhaps the one exception for myself and others to avoid hurdles building this stack in the future.

Find below an ordered, roughly detailed guide to setting up this technology stack. I will update this document as new discoveries are made or as new steps are introduced. See the bottom of this document for a changelog documenting such edits. Use this document only as an assistant to setting up infrastructure based on your distinct use case and requirements.

Serving an HTTP app using Docker, GKE and Cloudflare

Subject to change (see changelog)

1. Write an HTTP app

In your language of choice write an HTTP app that when ran, serves on a specified port.

In an ideal world, use Docker for both your development and your production build. You may have a different Dockerfile for development and production. Your production Dockerfile should run an executable (using the CMD keyword) that serves a long running process on a port you specify. For example, in Go you might have a Dockerfile.dev that runs an air command and a separate production Dockerfile that runs a go build and then CMD ["yourapp"].

2. Build the app into an image

docker build -t example-api-build-<build-version> -f ./deployment/docker/api/Dockerfile .

Replacing the name appropriately and <build-version> with a versioning mechanism you have decided on (or test if you wish to defer that task for later). See Container Image Versioning by Rahul Sharma.

3. Register and onboard with Google Cloud

This step is likely the most time consuming.

Budget decision

First, make sure you're in a position with enough available budget to commit to using Google Cloud. Deploying Google Cloud VMs and services could easily exceed $100 / month and this may come as a surprise to some. You should be careful with the resources you create as you can unintentionally rack up costs. Google will strive for minimum costs in many cases and provide estimates as much as possible. I would still recommend getting into the habit of looking up "[Insert GCP Product] Pricing" and at least doing a rough estimate of your own.

Check out Google's free tier as well.

Registering with Google Cloud

If you're comfortable moving forward you can roughly follow the steps below:

If you haven't already, register a domain and setup an email with the domain you're going to use to administrate Google Cloud.
Register with Google Cloud.
Warning: Be cautious following Google's on-screen onboarding flow. Its purpose is to scaffold Google products for you based on your needs and answers to prompts. While I went through it and learned from it I ended up re-doing all the work it did on my own and actually removed most of the scaffolding it had done on my behalf. The reason was that over time I learned more about what "projects" are and how I wanted resources to be organized within GCP. I also discovered that some of the resources Google scaffolded for me actually immediately started incurring costs which consumed all of my initial GCP credits. After speaking with Google's support I was able to confirm there is no cost or credit forgiveness policy at Google either.
As part of onboarding, set up a billing account you will attach to all the projects you later create.

Example project structure

For your inspiration, below is the project structure I have implemented:

Some notes on this structure:

Element	Description
Common folder	Folder containing projects that will hold resources pertaining to both staging and production environments.
Production folder	Folder containing projects that will hold resources only pertaining to production.
Staging folder	Folder containing projects that will hold resources only pertaining to staging.
apps-artifacts	Project which will contain a resource of Google's Artifact Registry. The registry will be available to staging and production.
apps-shared-cluster	Project which will contain a Google Kubernetes Cluster (GKE) that is shared between staging and production. This is only to be used prior to launch and will be deprecated in favor of a more fault tolerant system closer to launch.
apps-shared-sql	Project which will contain a Cloud SQL instance that will be shared between staging and production. This is only to be used prior to launch and will be deprecated in favor of a more fault tolerant system closer to launch.
apps-shared-vpc	This important project should be setup first. It contains a Shared VPC that will allow resources (Cloud SQL, GKE, etc.) to communicate with each other across projects via private IP.
production-resources	Project that is empty to start off. It will later be used to contain a production-specific GKE cluster, replacing the existing shared cluster.
staging-resources	Project that is empty to start off. It will later be used to contain a staging-specific GKE cluster, replacing the existing shared cluster.

4. Setup a Google Artifacts Registry project

Create a project apps-artifacts or apps-docker-artifacts.
Open the project.
In the left navigation select Artifact Registry.
Enable the Artifact Registry API.
Create a registry to hold Docker images following the prompts in the UI to your liking.

5. Tag the Docker image based on Google's Artifact Registry

The format to use for tagging Artifact Registry images is LOCATION-docker.pkg.dev/PROJECT-ID/REPOSITORY/IMAGE.

Command synopsis:

docker tag <image-to-tag-from-earlier-step> <tag>

Example command:

docker tag example-api-build-test northamerica-northeast2-docker.pkg.dev/apps-artifacts/docker-images/example-api-build-test:latest

6. Install the `gcloud` command on your machine

On your local machine you're going to be using the gcloud CLI every day soon enough. Now's a good time to install it. Follow Google's instructions to install gcloud CLI.

7. Configure and authenticate gcloud

The first exciting thing to do with your new gcloud command is to setup your configuration.

See your existing configurations:

gcloud config configurations list

Create a new configuration:

gcloud config configurations create config-example-company

Set the google account on your currently active configuration:

gcloud config set account yourname@exampleapps.net

Authenticate gcloud with your Google account:

gcloud auth login

Other useful commands:

gcloud projects list
gcloud config set project <project-name>

8. Push the Docker image to Artifact Registry

Configure Docker for pushing to Artifact Registry

gcloud auth configure-docker LOCATION-docker.pkg.dev

# Example: gcloud auth configure-docker northamerica-northeast2-docker.pkg.dev

Push the Docker image to Artifact Registry

docker push <tag-from-earlier-step>

# Example: docker push northamerica-northeast2-docker.pkg.dev/apps-artifacts/docker-images/example-api-build-test:latest

9. Set up a Shared VPC project

If you're following the same structure of projects as I have then you're going to want to setup a Shared VPC project; A project that will serve as your networking "host" for resources spread across multiple projects. This will allow your resources across projects to communicate over private IP, reducing latency and improving security compared to public IP without the Shared VPC.

Create a project apps-shared-vpc in the directory Apps/Common.
Within the project navigate to VPC Network -> Shared VPC.
Create a Shared VPC. Reference the section Create a network and two subnets from Google's Setting up clusters with Shared VPC article.
Navigate to Kubernetes Engine -> Clusters.
Enable the Kubernetes Engine API. It will remain unused but is required for the Shared VPC to later work with GKE.

10. Set up a shared GKE cluster project

From issue 5 of my series Software Engineering Entrepreneurship you would have heard my recommendation to use a shared GKE cluster while you are in a pre-seed / development phase of building your own apps. You can repeat the steps below for one or many GKE projects you create depending on your use case.

Create the project

Create a project apps-shared-cluster in the directory Apps/Common.

Grant permissions to Artifact Registry

Because the Artifact Registry is in a separate project you need to explicitly allow the apps-shared-cluster project to read images from the apps-artifacts project. Without doing so, your Kubernetes deployments will fail with an image pull error.

Within the apps-shared-cluster project navigate to IAM & Admin.
Copy the Principal email for the name Google APIs Service Agent, Compute Engine default service account - as well as the email that resembles <id>@cloudbuild.gserviceaccount.com.
For each Principal email, navigate to the apps-artifacts project.
Navigate to IAM & Admin for the artifacts project.
Select "Grant access" and assign the role Artifact Registry Reader and Compute Image User to each Principal copied from the previous step.

Grant permissions to networking within the Shared VPC

In later steps you will deploy a Kubernetes cluster and relevant workloads. As part of this process GKE will attempt to automatically create firewall rules for you based on what services are available to the outside world. In order for GKE to do this it needs access in the apps-shared-cluster project to control networking in the apps-shared-vpc project that is the networking host. Follow the steps below to configure necessary permissions:

Open the project apps-shared-cluster.
Navigate to IAM & Admin.
For both the Principals named Google APIs Service Agent and Compute Engine default service account select "Grant access" and assign the principals (by email) the following roles:
- Compute Network Admin
- Service Networking Service Agent

11. Set up Cloud SQL instances

If your app is using Cloud SQL similar to my use case then you may follow the steps below to get setup.

Create a project apps-shared-sql if you plan on using a single shared VM for both your staging and production databases during initial development. Otherwise, create or select the project of your choosing to host your Cloud SQL instance (e.g. staging-resources).
Within the chosen project navigate to SQL.
Continue to create a Cloud SQL instance.
1. Ensure the instance is created on the Shared VPC you put together earlier.
2. If prompted and you do are not familiar enough with writing your own IP ranges, choose to let Google automatically allocate an IP range (still within the Shared VPC network).
With the instance created you can use Google's UI to create databases if you like. I recommend creating databases such as example_app_staging, example_app_production. Including the environment in the database name is helpful when you are using a shared instance or migrate to a shared instance in the future - you will avoid conflicts with database names.
You can also use Google's UI to create users. I recommend creating users such as <lastname><firstinitial>_RW, code_example_app_staging and code_example_app_production. Following best practices of ensuring app environment have separate users from those that your team members connect to on their own clients.
Securely store the username, passwords and connection details for each user created.

12. Create a Kubernetes cluster

A kubernetes cluster represents an instruction to Google to reserve a node pool (physical VMs) that will later host GKE workflows. When creating GKE clusters you will have the option to self manage nodes or use Google's recommended GKE Autopilot cluster - Autopilot will automatically allocate the minimum resources (CPU, RAM and storage) to meet the needs of your workloads.

Open your previously created GKE project (e.g. apps-shared-cluster).
Navigate to Kubernetes Engine -> Clusters.
Continue to create an Autopilot cluster (recommended) or manually manage a cluster. See GKE pricing.
- If you are going to be using a shared cluster for staging and production to save costs then use a name such as apps-shared.
- Ensure the GKE cluster is created within the Shared VPC network created earlier.
- Here is an example configuration for my own cluster based on the Shared VPC we created earlier.
- If you're unsure, choose to make the cluster public instead of private for now.

13. Prepare secrets for staging and production

One task you will need to endeavour is having a secrets strategy for your local, staging and production environments. In this section of the document I will share with you the secrets strategy I am personally using. This is before setting up any sort of continuous delivery approach.

Setup a Gitlab/Github organization to version control applications and secrets.
Setup an isolated group and projects to store secrets for applications. For example:
Have a folder for each environment within your secrets project. E.g staging and production.

Store files within those folders that will be pushed to Kubernetes as secrets later on. Here is an example secrets yml file:

DB:
  Connections:
    Primary:
      Host: 11.22.70.4
      Port: 3306
      Username: code_example_app_production
      Password: A5odaPLjBo[o#f}A$TBQ
      Database: example_app_production

Commit these files to your repository. We will come back to this later on when we are ready to push secrets to your Kubernetes namespaces.

14. Create your first GKE workload

You're now getting really close to having a running, accessible application. Now's the time to create your GKE workload. Here you will deploy your previously created artifact (HTTP application). Disclaimer though, if your application relies on secrets to establish a database connection then your workload will fail to spin up pods until those secrets are applied. Regardless though, Google's UI will only let you deploy the workload first and then apply secrets after. Follow the steps below:

Create your workload

Open your GKE project in Google's console.
Navigate to Kubernetes Engine -> Workloads.
Select "Deploy".
1. Select "Existing container image".
2. Change the artifact registry source project to the project you created earlier to host your Artifact Registry (e.g. apps-artifacts).
3. Select the image tag/sha you wish you deploy (e.g. example-api-build-test:latest.
Continue.
Configure your workload
1. For the deployment name, think about what you are serving. For example, if it's an HTTP API use api or backend. Note: I recommend having separate namespaces for each environment. E.g. The namespace example-app-staging. If you do this, you don't need to include the environment staging or production in your deployment name. You can simply use api instead of api-staging. There are other scoping benefits later on such as the name of Kubernetes secrets.
2. For the labels I suggest the format app: example-app-staging to control workload scheduling based on app and environment.
3. For the GKE cluster select the one you created in the previous steps.
Select "Continue".
Select "Expose deployment as a new service" to allow Google to expose a public endpoint (IP) for your created service / HTTP app.
- "Port 1" should be the port that will be publicly accessible.
- "Target port" should be the port your HTTP app is told to run on within the codebase and/or Dockerfile.
- "Load balancer" is the appropriate service type if you wish to expose the application to the internet directly from the Kubernetes workload.
Important: Exposing your services at this level circumvents future layers of your infrastructure such as rate limiting, caching and API gateways. For the remainder of this article we will choose "Cluster IP" instead and expose the service through private IP and Cloudflare instead.
Select "Deploy"

Heads up

Your Workload will attempt to start running based on the Docker image pushed to Artifact Registry. However, if that application depends on a database connection or other secret information then it is likely going to fail to start and that is completely normal for now.

15. Apply secrets to GKE workloads

This step covers how you can apply secrets to your GKE namespaces in order for your dependent workloads to successfully run.

Connect to your cluster

Navigate to Kubernetes Engine -> Clusters.
Next to the relevant cluster select "Connect".
Choose to connect through your own command line. Tip: I recommend having the kubectx command on your machine to always have visibility on which K8 context you are in.
Once you are connected to the correct context you can now run through the following steps to apply secrets.

Navigate to your secret directory

Based on the environment you are applying secrets, navigate in terminal to the directory of your CI resources / secrets repository holding the relevant file(s).

Check your namespaces

kubectl get namespace
# Work within the relevant namespace for all the following commands using the '-n <namespace>' flag

Create the secret

Here is an example of applying a yml file as a secret to a staging application.

kubectl -n <namespace> create secret generic <secret-name>-<secret-environment> --from-file=./<secret-file>

# Example: kubectl -n example-app-staging create secret generic app-config-example-app-staging --from-file=./config.yml

Take notice that even though it's applied within the specific staging namespace we're still including the environment staging in the name of the secret. This is a future-proof incase our team decided to move multiple environments into a single namespace at any point (not recommended.

Update your deployment to mount the secret

Even though the secret is created, it's only holding a place in Kubernetes data store without actually being used in any particular workload / deployment. We now need to edit your failing workload to (1) register a volume derived from a secret and then (2) mount a volume within the created pods.

Open your GKE workload in Google Cloud.
Select "Edit".

Make the following additions to the deployment yml. Use this as a structural and naming reference.

spec:
  template:
    spec:
      containers:
      - image: <do-not-edit>
        volumeMounts:
          - mountPath: "/secrets"
            name: app-config-example-app-staging
            readOnly: true
      volumes:
        - name: app-config-example-app-staging
          secret:
            secretName: app-config-example-app-staging

Note that correct indentation / placement is important here.

Select "Save". Heads up: Because Kubernetes and your Autopilot cluster is always managing your deployment and making changes, you may be asked to "Forcefully apply" the new deployment. This is okay to select.

With the secret now mounted into the workload at the location /secrets/config.yml the workload will now refresh, generate new pods (allow some time) and should succeed. If you continue to encounter errors you can always look at the "Logs" section of your Google Cloud workload or the "Logs Explorer" product itself in your navigation.

16. Prepare Cloudflare for Total SSL

As part of our technology stack we are going to use Cloudflare as an edge DNS, SSL, Cacheing and Tunnel provider. Below are my recommendations for setting up Cloudflare:

Add your domain to Cloudflare.
Open your Cloudflare Dashboard.
Navigate to SSL/TLS -> Edge Certificates.
Enable "Total TLS" and opt-in to the paid add-on "Advanced Certificate Manager" ($10 / month at time of writing).

By enabling Total TLS, Cloudflare will automatically issue SSL certificates for new DNS records whether they're created manually or through a Tunnel. This serves as a huge convenience for live applications and local development.

17. Expose your application using Cloudflare Tunnel

Earlier we made the decision to expose our GKE Workload using "Cluster IP". This means the application itself is only served internally so we can add additional layers before it is exposed to the internet. In this case we are interested in placing Cloudflare between our application and the internet.

We will deploy a sibling GKE Workload that leverages Cloudflare Tunnel to expose our Cluster IP to the internet via custom domain.

Install the cloudflared CLI on your local machine.
Run cloudflared tunnel login to authenticate your CLI with Cloudflare. Select the appropriate domain you will be creating tunnels for.
Run cloudflared tunnel create example-app-staging replacing example-app-staging with your desired tunnel name.
Run cloudflared tunnel route dns example-app-staging tunnel.example.com again replacing the tunnel name appropriately.
Copy the created credential json file into your secrets storage (i.e. Gitlab repository) for tracking. Use a name such as cloudflare-tunnel-credential-example-app-staging.json.
Run kubectl -n example-app-staging create secret generic cloudflare-tunnel-credential-example-app-staging --from-file=credentials.json=/<path-from-earlier-output>/<tunnel-id>.json replacing the namespace, secret name and tunnel credential path appropriately.

Now create your Cloudflare Tunnel config using a name such as cloudflare-tunnel-config-example-app-staging.yml. Reference the following template or see the bottom of Cloudflare's K8 example yaml:

tunnel: example-app-staging
credentials-file: /etc/cloudflared/creds/credentials.json
# Serves the metrics server under /metrics and the readiness server under /ready
metrics: 0.0.0.0:2000
# Autoupdates applied in a k8s pod will be lost when the pod is removed or restarted, so
# autoupdate doesn't make sense in Kubernetes. However, outside of Kubernetes, we strongly
# recommend using autoupdate.
no-autoupdate: true
# The `ingress` block tells cloudflared which local service to route incoming
# requests to. For more about ingress rules, see
# https://developers.cloudflare.com/cloudflare-one/connections/connect-apps/configuration/ingress
#
# Remember, these rules route traffic from cloudflared to a local service. To route traffic
# from the internet to cloudflared, run `cloudflared tunnel route dns <tunnel> <hostname>`.
# E.g. `cloudflared tunnel route dns example-tunnel tunnel.example.com`.
ingress:
  # The first rule proxies traffic to the httpbin sample Service defined in app.yaml
  - hostname: example-app.staging.exampleapps.net
    service: http://api-service:80
  # This rule matches any traffic which didn't match a previous rule, and responds with HTTP 404.
  - service: http_status:404

Create a secret for the config within the same namespace as the service you're exposing.

kubectl -n example-app-staging create secret generic cloudflare-tunnel-config-example-app-staging --from-file=config.yaml=./cloudflare-tunnel-config-example-app-staging.yml

Construct a Kubernetes deployment (i.e. api-cloudflare-tunnel.yml) based on Cloudflare's example yml here.
- Use a deployment name of your choosing. One suggestion is cloudflare-tunnel-<deployment-to-expose> (e.g. cloudflare-tunnel-api).

Make the following edits to the deployment yml. Use this as a structural and naming reference.

spec:
  template:
    spec:
      containers:
      - image: <do-not-edit>
        volumeMounts:
          - mountPath: "/etc/cloudflared/creds"
            name: cloudflare-tunnel-credential-example-app-staging
            readOnly: true
          - mountPath: "/etc/cloudflared/config"
            name: cloudflare-tunnel-config-example-app-staging
            readOnly: true
      volumes:
        - name: cloudflare-tunnel-credential-example-app-staging
          secret:
            secretName: cloudflare-tunnel-credential-example-app-staging
        - name: cloudflare-tunnel-config-example-app-staging
          secret:
            secretName: cloudflare-tunnel-config-example-app-staging

Note that correct indentation / placement is important here.

Apply the new deployment under the same Kubernetes context and namespace as the service you're trying to expose. With our staging example app as an example, that would be:
```
kubectl -n example-app-staging apply -f api-cloudflare-tunnel.yml
```

Your GKE Workload pods will recognize the new changes and should now succeed in starting the tunnel.

Important: Be sure to set the maximum number of replicas for your Cloudflare GKE Workload to 1. This is to support only having 1 tunnel running as duplicates will fail.

18. See your application live 🎉

This is where all of your hard work pays off. While there are still many improvements to make to the current infrastructure you should see that your application is now available through your custom domain using private IP and a secure Tunnel to Cloudflare!

You now have an application available to the internet with a database and auto-scaling capabilities.

Where does our trip take us next? 🚀

The fun doesn't stop here. Continue visiting this page and following the Software Engineering Entrepreneurship series. I will take you along the journey as we work on improved security measures, building out CI/CD and more.

Changelog

February 24, 2023

Removed the previous use of exposing our GKE Workload using a public IP load balancer. This document now covers securing your application behind a private IP and establishing a Tunnel directly to Cloudflare and your custom domain.

Stay connected 💬

I would love to connect with you and follow journeys of your own in life. Connect with me on LinkedIn, Twitter or our home at DEV.

Software Engineering Entrepreneurship » Issue 5 » Up and running with Google Cloud

Morgan Wowk — Sat, 18 Feb 2023 06:12:13 +0000

Recap

Software Engineering Entrepreneurship » Issue 4 » Our tech. stack of choice

Morgan Wowk ・ Feb 9 '23

#productivity #architecture #startup #career

...[your leading cloud provider] combined with other edge technologies (DNS, API gateways, etc.) are constantly evolving and have steep learning curves. The payoff of having a resilient, scalable system that promotes fail-fast business is entirely what this series will focus on.

Terms on this page

Term	Description
GCP	GCP stands for Google Cloud Platform.
GKE	GKE stands for Google Kubernetes Engine.
GKE Cluster	A Kubernetes cluster managed by Google.
GKE Workload	Kubernetes services, deployments and pods managed by Google.
VM	Virtual Machine. AKA "server".

Our blind approach to getting started (bittersweet)

Learning Google Cloud has been and continues to be a long journey spanning over many months. The technology evolves quickly; Along with it thousands of supporting documents and resources have spread across the web and Google's domain. The sheer amount of content available to help you doubles as the largest factor capable of holding you back.

To counter this massive task of deciphering Google Cloud docs, you can take the approach of immersing yourself in the technology first and then optimizing later. This means having an understanding of which products you know you will use, and then literally going in and interacting with those products.

System design visualizations

Option A: Many VMs for high fault tolerance

When taking the head-first approach to learning GCP it was easy for me to strive to build the system that I figured would be the most performant and fault tolerant. There would be a staging environment isolated entirely to its own machines which would scale separately from production. Moreover, if any single component failed, be it staging, production, database or application, the rest of the network would have a good chance of still being available.

Where this mentality of striving for the optimal system falters itself however is the cost and unused resources. For each extra VM you operate you're paying $40-100+/month. During your initial stages of development this is not practical for individuals. The exception here is if you are working with a fast moving team and your launch phase is not far into the future.

Option B: Shared VMs for reduced costs

Below you can see an alternate infrastructure that demonstrates how you can achieve the same outcome while operating on fewer resources. One of many drawbacks here is that you have a single point of failure shared between staging and production for both your GKE cluster and database. If one goes, they both go. The huge benefit here is that you're saving heavily on VM costs while initially building your application.

Recommendation 📌

Use shared VMs then migrate to many VMs before launch. This approach requires that you maintain strong documentation for setting up your infrastructure. You will need to recall your experience working with cloud products to minimize the time you spend migrating closer to launching applications. By taking this approach you can save yourself hundreds of dollars each month during your pre-seed/development phase.

Further improvements

Our article above explains how to engineer a system that allows for shared VM vs per-environment VMs. The flaw of the above systems is that the Kubernetes systems are directly exposed to the internet using an external endpoint / public IP. The con of this approach is that your traffic is going directly to your workloads without additional layers such as an API gateway or Cloud provider to route and secure traffic through.

Find below an example of a more secure system design using Cloudflare Tunnels to secure traffic within the cluster:

Benefits of routing through a Cloud platform such as Cloudflare include:

Caching
Cyber attack detection, prevention, and more advanced edge protection
Automatic domain assignment and SSL rotation
Reduced latency using private IP and direct communicate to Cloudflare

Bonus issue (Continue reading)

Deploying an HTTP app using Docker + GKE + Cloudflare

Morgan Wowk ・ Feb 23 '23

#googlecloud #kubernetes #docker #startup

Software Engineering Entrepreneurship » Issue 4 » Our tech. stack of choice

Morgan Wowk — Thu, 09 Feb 2023 04:25:55 +0000

Recap

Software Engineering Entrepreneurship » Issue 3 » Investing in cloud technology

Morgan Wowk ・ Feb 7

#productivity #architecture #startup #career

Technology can be your greatest ally or your greatest threat.
...
Serious about your dream to start a company? Don't rush it.

Cutting edge vs. familiar tech. stacks

Let's go through an exercise.

One decision you could make for your startup is adopting serverless technology (e.g. Cloud Functions). There are cost, performance and time saving benefits. Yet, nearly everything you can achieve serverless can still be done in traditional, hosted applications that you're likely used to.

So the question is, do you spend your time learning a whole new technology or stick to what you're good at?

For this series we're going to go with the answer of:

For writing applications, stick to what you know. For your infrastructure however, choose a leading Cloud Service Provider. At time of writing that is a top 3 of AWS, Microsoft Azure or GCP. These providers, combined with other edge technologies (DNS, API gateways, etc.) are constantly evolving and have steep learning curves. The payoff of having a resilient, scalable system that promotes fail-fast business is entirely what this series will focus on.

Tip: If you're working on excelling in your day job in parallel, consider going with a provider that will make you more valuable to that team as well.

Disclaimer: The learning curve for a cloud provider giant is steep. Give yourself and your team several months to learn the technology and build a sample app if it is your first go at it.

Our tech. stack for the rest of this series

Below is the tech. stack we will piece together throughout this series along with a pricing estimate for each.

Edge / DNS provider

Service: Cloudflare
Products: Tunnel, Advanced Certificate Manager
Price: $10.00 USD / month

API gateway

Service: Kong
Products: Routing, Authentication, Dev Portal
Price: $0 - $250 / month

Cloud Service Provider

Service: Google Cloud Platform
Products: IAM, Cloud SQL, Artifact Registry, Kubernetes Engine
Price: Usage based

Version Control System

Service: Gitlab
Products: Version control
Price: Free

CI/CD

Service: Gitlab
Products: Gitlab CI, Advanced VCS
Price: $228 USD / year

Containerization

Service: Docker
Products: Images, Containers, Compose
Price: Free

Development

Language: Go
Editor: GoLand
Editor price: $150 - $250 USD / year
Free alternative: VS Code
Context: APIs

Language: JavaScript, Node.js
Editor: VS Code
Editor price: Free
Context: Web apps, mobile apps

Total cost estimate

~$348 USD / year + usage based fees (GCP)

The figure above is assuming we use the most probable plan for all the mentioned services and excludes paid editors. While starting out there's a good chance the free plan for Kong will suffice. Nonetheless it's best to be prepared for the paid tiers and explore competitors as generally business will lead you in that direction as requirements or limitations arise.

A note on saving costs

You can find substitute services or choose not to use some services. This depends on the problems you're concerned about solving and your budget. For example, manually implementing authentication, rate limiting, etc. and dodging the API gateway - Or managing your own SSL certificates and dodging Cloudflare's Total TLS. I would only caution that these services exist for your ultimate convenience, security and beyond. The more you choose to do on your own, the less you can focus on the innovative ideas and development that will allow you to grow.

Continue reading

Software Engineering Entrepreneurship » Issue 5 » Up and running with Google Cloud

Morgan Wowk ・ Feb 18

#googlecloud #architecture #startup #career

Sources

https://www.c-sharpcorner.com/article/top-10-cloud-service-providers/

Software Engineering Entrepreneurship » Issue 3 » Investing in cloud technology

Morgan Wowk — Tue, 07 Feb 2023 00:42:16 +0000

Recap

Software Engineering Entrepreneurship » Issue 2 » Resilient people and systems

Morgan Wowk ・ Feb 5 '23

#devrel #devto #announcement #community

Invest big now and save when it matters most

Technology can be your greatest ally or your greatest threat.

Growing your company fast in the future doesn't equate to working fast now. If you're willing to settle on the technology you invest in today then you have to understand that technology will demand your attention again in the future. Investing in a limited foundation early means the growth of your company in its most critical time of growth will stall significantly.

Let's paint a scenario.

January 2024 💡

I'm going to build a mobile app. I'll develop it entirely on my Windows machine. After each change I will commit my code to git, ssh into a Digital Ocean droplet and then pull the latest main branch. If I work hard enough I can make this app in a couple months, get it out there and start getting my first users.

April 2024 (3 months later) 📈

This is awesome. I now have 60 installs of my app, a few 5 star reviews and a couple 2 stars I am working on addressing.

June 2024 (2 months later) 😨

We have 300 installs. However, users are complaining about page loads up to 60 seconds. I now have more negative reviews than positive. I got a new laptop last month and it's going to take me a couple weeks to get everything working again on my machine. I'm afraid of losing all my users!

July 2024 (1 month later) 😭

I've received advice to invest in a larger server, implement rate limiting and switch to AWS or Google Cloud for advanced security controls to prevent attacks. I'm afraid all of this is going to take several months and I'll need to worry about transferring all my existing data. I've lost over half my users. This is a nightmare.

Give it time. Put in the time.

Serious about your dream to start a company? Don't rush it. Investing your time and money in a smart technology stack can be scary when you're only in a seed stage. Yet, I will guarantee that if you're confident in your ability to learn new tech. then making this investment will only set you up for success when it's time to go-to-market and grow fast. Launch your product and let it thrive.

Rinse-and-repeat mentality. Fail-fast always.

Throughout your journey you should always be prepared to go further, faster. In business in general you have to let innovation fuel your growth. Whether an idea has failed entirely or you're looking publish your nth new app, you should have a rinse-and-repeat mentality the whole way through.

The best case scenario is that every piece of a system your app depends on (servers, databases, permissions, pipelines, etc.) can be recreated faster the second time around. Always track your steps (document) and find a balance of automating tasks.

Concrete advice

Think about developing your company in years rather than months.
Embrace big infrastructure for your small startup.
Let your tech. stack solve common problems (e.g. SSL, firewalls, rate limiting, etc.) for you.
Build a prototype / sample app using big infrastructure.
Be obsessed with tracking your steps.
If you can anticipate repeating a task again in the future, leverage documentation or automation to save time.
Imagine hiring team members to do the jobs you're doing. Make your actions reproducible and your responsibilities transferable.

Continue reading

Software Engineering Entrepreneurship » Issue 4 » Our tech. stack of choice

Morgan Wowk ・ Feb 9 '23

#productivity #architecture #startup #career

Software Engineering Entrepreneurship » Issue 2 » Resilient people and systems

Morgan Wowk — Sun, 05 Feb 2023 19:53:32 +0000

Recap

Software Engineering Entrepreneurship » Issue 1 » Ice breaker

Morgan Wowk ・ Feb 2 '23

#crypto #blockchain #web3 #offers

In this first edition of Software Engineering Entrepreneurship I will take you through the journey of laying the groundwork for an ambiguous future as a technology leader.

Edition: Feb. 2023
Issue: 2
Dates covered: Feb. 2-5
Subject: Resilient people and systems

Why now and not yesterday or tomorrow?

I'll admit that in earlier stages of my life I would not be ready to take on the challenge we're about to endeavour. In fact, it was only an epiphany in the last year where I realized everything is lined up to not just start a business, but start executing a strategy that is resilient to failure. A combination of experience building Bold in the e-commerce space and developing skills over several years has enabled me to have a clear vision on starting a tech. company of my own.

Backstory: Waiting for just the right idea

Consistently since being young I have said to myself and those around me "I'm going to start a company one day." Meanwhile, all around we see talented people of all ages successfully starting up companies or failing to. For me however, it was always about waiting for the big idea that would come when the stars perfectly aligned; it would be a sure success.

Realization: The "big idea" is a fallacy

I have grown to realize over the years the idea of there being a "big idea" is a distraction from reality. That's not to say dreaming of a crystal clear business idea hasn't help me personally - but it doesn't paint the right picture to how successful companies come into existence.

If you listen close enough to successful companies and individuals you'll always hear a common theme: The first idea is never what got them where they are today; it's not even who they are today. They've had highs and lows, been defeated in the market and in many cases pivoted business altogether.

Our mission: Fail-fast with big infrastructure

Throughout this series we will dive deep into constructing a fail-fast infrastructure. The infrastructure will support a culture of continuous innovation and shorten the path to go-to-market on new ideas. It will support all the following requirements:

Launching a new app or API in days. Including:
1. A containerized development environment.
2. A staging and production environment.
3. A CI/CD pipeline with support for JS and Go applications.
4. Auto-scaling to meet new demands.
Deploying mobile apps, web apps and APIs.
An API gateway to reduce the network complexity (rate limiting, authentication, middleware, etc.) of individual apps or APIs.

With this infrastructure we have accepted the fact that there is no silver bullet to successful startups. Rather, we are preparing ourselves to hit the ground running on any given app idea. Further, we are preparing ourselves to be able to quickly develop and deploy multiple branches of the same business (e.g. multiple related apps) in short succession.

Continue reading

Software Engineering Entrepreneurship » Issue 3 » Investing in cloud technology

Morgan Wowk ・ Feb 7 '23

#productivity #architecture #startup #career

Software Engineering Entrepreneurship » Issue 1 » Ice breaker

Morgan Wowk — Thu, 02 Feb 2023 04:28:22 +0000

Edition: Feb. 2023
Issue: 1
Dates covered: Feb. 1
Subject: Ice breaker

What you're probably feeling right now

I'd like to answer 2 questions that are probably going through your mind:

"Will reading this help me personally?"
"If yes, who are you?"

What I can offer you

In this first edition of Software Engineering Entrepreneurship I will take you through the journey of laying the groundwork for an ambiguous future as a technology leader. I will define and implement the infrastructure and sample app of a company that's built to scale, fail fast (iterate) and provide a secure, reliable product to thousands of users.

Who is this targeted to?

Continue reading if this is you:

"I will start a tech. company of my own one day!"

With that, the important note here is that I will be speaking in the shoes of a Software Engineer-by-day. Yet, the topics covered would be considered advanced for any Engineer. At larger companies, part of what I'll cover would even fall under separate teams such as IT or DevOps.

"Okay, I'm sold. Now who are you?"

Hey that's super awesome! If you're seriously up for following along, I would love to hear your takeaways along the way. Please comment or reach out at any time.

I am happy to introduce myself. I am Morgan Wowk from the giant multi-biome land of Canada 🇨🇦. Originally from the fields of endless wheat and now on the West Coast taking a bath. I have worked in e-commerce for nearly 7 years and have been at a company Bold Commerce the whole way through - proudly cutting the taboo about staying at one place too long 😏.

Format and schedule

I won't promise a detailed tutorial as we take this journey.

Instead, I will promise learning advice, decisions, discoveries, successes and an inspirational perspective on how you can do more to unlock a life as the founder of your dream technology company.

I am so excited to share updates with you every Thursday throughout February 2023 with the occasional bonus days.

Continue reading

Software Engineering Entrepreneurship » Issue 2 » Resilient people and systems

Morgan Wowk ・ Feb 5 '23

#productivity #architecture #startup #career

DEV Community: Morgan Wowk

Deploying an HTTP app using Docker + GKE + Cloudflare

Table of contents

Recap

Software Engineering Entrepreneurship » Issue 5 » Up and running with Google Cloud

Morgan Wowk ・ Feb 18 '23

Living document intention

Serving an HTTP app using Docker, GKE and Cloudflare

1. Write an HTTP app

2. Build the app into an image

3. Register and onboard with Google Cloud

Budget decision

Registering with Google Cloud

Example project structure

4. Setup a Google Artifacts Registry project

5. Tag the Docker image based on Google's Artifact Registry

6. Install the gcloud command on your machine

7. Configure and authenticate gcloud

8. Push the Docker image to Artifact Registry

9. Set up a Shared VPC project

10. Set up a shared GKE cluster project

Create the project

Grant permissions to Artifact Registry

Grant permissions to networking within the Shared VPC

11. Set up Cloud SQL instances

12. Create a Kubernetes cluster

13. Prepare secrets for staging and production

14. Create your first GKE workload

15. Apply secrets to GKE workloads

16. Prepare Cloudflare for Total SSL

17. Expose your application using Cloudflare Tunnel

18. See your application live 🎉

Where does our trip take us next? 🚀

Changelog

Stay connected 💬

Software Engineering Entrepreneurship » Issue 5 » Up and running with Google Cloud

Recap

Software Engineering Entrepreneurship » Issue 4 » Our tech. stack of choice

Morgan Wowk ・ Feb 9 '23

Terms on this page

Our blind approach to getting started (bittersweet)

System design visualizations

Option A: Many VMs for high fault tolerance

Option B: Shared VMs for reduced costs

Recommendation 📌

Further improvements

Bonus issue (Continue reading)

Deploying an HTTP app using Docker + GKE + Cloudflare

Morgan Wowk ・ Feb 23 '23

Software Engineering Entrepreneurship » Issue 4 » Our tech. stack of choice

Recap

Software Engineering Entrepreneurship » Issue 3 » Investing in cloud technology

Morgan Wowk ・ Feb 7

Cutting edge vs. familiar tech. stacks

Our tech. stack for the rest of this series

Edge / DNS provider

API gateway

Cloud Service Provider

Version Control System

CI/CD

Containerization

Development

Total cost estimate

A note on saving costs

Continue reading

Software Engineering Entrepreneurship » Issue 5 » Up and running with Google Cloud

Morgan Wowk ・ Feb 18

Sources

Software Engineering Entrepreneurship » Issue 3 » Investing in cloud technology

Recap

Software Engineering Entrepreneurship » Issue 2 » Resilient people and systems

Morgan Wowk ・ Feb 5 '23

Invest big now and save when it matters most

Give it time. Put in the time.

Rinse-and-repeat mentality. Fail-fast always.

Concrete advice

Continue reading

Software Engineering Entrepreneurship » Issue 4 » Our tech. stack of choice

Morgan Wowk ・ Feb 9 '23

Software Engineering Entrepreneurship » Issue 2 » Resilient people and systems

6. Install the `gcloud` command on your machine