JAX DevOps 2019 takeaways: Security pitfalls and how to influence DevOps culture

Share
Technology

JAX DevOps 2019 wound to a close after a four-day conference with six tracks for software professionals to explore. For our readers who could not make it to London this year, we have the key takeaways from keynotes and sessions.

What did we learn during the conference? Let us pass on the knowledge to you.

Taking back Software Engineering – Craftsmanship is not enough: Dave Farley

In his opening keynote, Dave Farley discussed software engineering, the history of craftsmanship, and why we should rethink the meaning and definition and software engineering. Where does the software industry belong?

He explained the evolution of production and its three phases: craft, mass production, and lean production techniques.

  • Craft:
    • Art rather than science, no work standards, each piece of work is individually crafted and unique, based on individual expertise
  • Mass production:
    • Assembly line, standardized components, standardized steps. Piece-based metrics (measure how long to create a component)
  • Lean production techniques:
    • Quality at source. Pull-based system. Minimize work in progress and waste. One-piece flow.

According to Farley, software development doesn’t have a production problem; it has a design problem and is currently in the ‘craft’ phase.

Notable points from his keynote:

  • Developers should aim to achieve lean production techniques.
  • Be experimental! It is important to experiment no matter the scale of the problem of you’re working on.
  • “Engineering is the application of an empirical scientific approach to finding efficient solutions to practical problems.”
  • What are the fundamentals of an ‘engineering approach’? It is iterative, employs feedback, incremental, experimental, empirical.

Seven Security Sins: the seven biggest Security Problems of Agile Projects: Christian Schneider

What are the big deadly security sins?

  • Lack of whiteboard hacking
    • It can be derived from evil user stories and threat modeling. Identify it in security architecture reviews and brainstorm by playing a mental game.
  • Lack of security architecture
  • Lack of security automation
    • Things we can automate: DAST, SAST, IAST, dependency management
  • Lack of organizational change
    • There must be security roles in every team. Not necessarily security specialists, but rather a team member with more in-depth security training.
  • Lack of continuous training
  • Lack of breach preparation

SEE ALSO: DevOps and neuroscience: Trying to influence culture as part of a DevOps evolution

Taking the Scissors away: make your Kubernetes Cluster safe for DevOps: Jussi Nummelin

One of the most central things in DevOps thinking is to release often, go faster than the competition, learn faster and adapt.

Containers can help us do that.

But when working with containers and Kubernetes you have a bunch of different toggles that you have to define and use and this makes it very easy for things to go really wrong. So how do we enforce a safe, or rather safer, workload?

  • Securing the cluster kernel:
    • Use benchmark tools, lock all doors by default.
    • Things to watch out for: Ensure there are no exposed APIs, that everything has proper TLS, and authorization is configured properly.
    • Audit: API server does auditing. It can be pushed to webhook.
    • RBAC: Fine-grained controls, scoped.
  • Ensuring workload safety
    • No root allowed and no root in images: Requires effort, easy for greenfield.
    • Pod security policy: Control for pod security aspects, can also set some defaults.
    • PSP pains: Easy to cap your cluster, enforced policy selected via RBAC
    • Resource quota: Limit aggregate resources consumption. Create limits on CPU, MEM, and storage.
  • Secure your cluster kernel
    • Auth
    • RBAC
    • Secure all components
  • Customize K8S
    • Custom operators
    • Operator SDK
    • Custom admission webhooks

DevOps Culture: the Neuroscience of Behavior: Helen Beal

In this keynote, Helen Beal discusses the concept that we cannot change culture, but we can change behavior.

Here are her DevOps talking points:

  • Customers keep asking us “Culture is difficult, how do we understand it, how do we change it?”
  • Culture is indeed nebulous and difficult to grasp.
  • DevOps essentially is asking a bunch of humans to think and work in a way different from what they have learned before, moving from a waterfall to an agile model.

Infrastructure as Code: Lessons learned from Dev to Ops: Emma Button

Have you ever had to re-write an entire template rapidly after discovering a flaw in production?

Let’s catch some of Emma Button’s key takeaways and lessons she has learned about the world of infrastructure.

  • Simplicity
    • Code re-usage
    • Public libraries
    • Open source communities
  • Quality
    • Unit testing/terraforming testing
    • Static code analysis
    • Peer review and peer programming
    • Acceptance criteria
  • Technical excellence
    • Logical separation
    • Parameter injection and dependency management
    • Design review: People over process and tools
  • Purpose
    • Shared ownership

Rip it up and start again?: Sam Newman

In his keynote, Sam Newman explains that feature-based teams equal collective ownership.

He explains that the collective code ownership struggles with scale. Organizations with collective code ownership structures tend to have more global consistency in their technological practices. Microservices are an architecture that optimizes for autonomy. You have to decide how much autonomy you want.

Services owned by teams:

  • Clear lines of ownership
  • Increased autonomy
  • Easier to align to the business
  • Orphaned services. Where is the source code? Who owned this service?
  • Local vs. Global optimization

Going FaaSter: Cost-Performance Optimizations of serverless on Kubernetes: Erwin van Eyk

In this talk, Erin van Eyk reviews optimizations used in popular FaaS platforms and recent research findings that aim to optimize the trade-off between cost and performance.

How can we optimize the performance-cost trade off?

The central trade-off in serverless computing:

  • High performance
    • “Infinite” scaling
    • High availability
    • Low latency
  • Low cost
    • No costs when idle
    • No operational costs
    • Granular billing

SEE ALSO: I deploy on Fridays (and maybe you should too)

Beyond the Spotify model: Using team topologies for fast flow and organization evolution: Matthew Skelton

The Spotify model helps to:

  • Encourage flow of charge
  • Establish and clarify team responsibilities
  • Promote good kind of team collaboration
  • Plan and budget for cross-team enablers

Limitations of the Spotify model:

  • Software sizing and cognitive load
  • Heuristics for Conway’s law
  • Patterns for team interactions
  • Triggers for change and evolution

Team topologies for fast flow:

  • Team-first thinking
    • The team is the means of delivery
    • Design for team cognitive load
    • Choose boundaries for team ownership
    • Physical and digital workspace
  • Conway’s law
    • Reverse Conway to mitigate worst effects
    • Constraint on solution search space
  • Team interactions
    • Collaboration: two teams working together
    • X-as-a-service: one provides, one consumes
    • Facilitating: one team helps another

How do you get started? 

Thinnest viable platform

  • How is your platform defined
  • What is the thinnest platform that could work
  • What’s needed to run and support it

The post JAX DevOps 2019 takeaways: Security pitfalls and how to influence DevOps culture appeared first on JAXenter.

Source : JAXenter

You may also like...