DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 963,673 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Arpit Mohan
Arpit Mohan

Posted on • Originally published at insnippets.com

Kubernetes myths; app security 101; & change management in teams

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


Top comments (0)

🌚 Friends don't let friends browse without dark mode.

Sorry, it's true.