TL;DR versions of articles I read today on software engineering. Sign up for my newsletter to receive these in your inbox every weekday.

Kubernetes in production vs. Kubernetes in development: 4 myths

• Myth #1: Running Kubernetes in dev/test gives you a firm handle on your operational needs.
• Myth #2: You have got reliability & security all figured out.
• Myth #3: Orchestration makes scaling a cinch.
• Myth #4: Kubernetes runs the same in every environment.

Here is what I have realized about running anything (not just k8s) in dev/test environments vs running it in production: Running services locally is like playing with lego blocks - you join small simple pieces together to make what you want. Running in production is like building the Windsor Castle. It must be robust and stand the test of time.

Full post here, 12 mins read

How to make your app's architecture secure right now

A good starting point for building secure application architecture

• Separate your storage: Don’t mix core application files & assets with other data. Keep user-uploaded files and activity logs separate from the main app.

• Customized configuration: review the configurable features of all architecture components. Look for unattended areas such as:

  • Default accounts, especially with default passwords, left in service
  • Unnecessary ports left in service, or ports left open to the Internet
  • Unrestricted permitted HTTP methods
  • Default configured permissions in managed services

• Controlled access and user scope: focus on access control configurations in the early stages of development. Consider factors such as sensitive tokens, or keys passed as URL parameters, or whether a control fails securely or insecurely. 

Full post here, 7 mins read

How should you structure your engineering team?

Answer: No one size fits all. Structure your team in accordance with what works best in your company's context. Here are 5 things to think about before and during the process of making changes to your engineering team structure:
 

• Know what you want to solve with the change - a collaboration, communication, clarity or direction problem
• Consider the impact of the change on other teams & the organization 
• Don’t make change a big deal
• Decide who decides on what 
• Over-communicate all aspects & consequences of change 

Full post here, 8 mins read