Recap

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

Morgan Wowk ・ Feb 9

#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

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

#googlecloud #kubernetes #docker #startup