Please enable JavaScript.

Coggle requires JavaScript to display documents.

NETFLIX Development Frameworks (Overview (Since 2012: Netflix originals…

- - - - In the past, Edge Engineering had ops-focused teams and SRE specialists who owned the deploy+operate+support parts of the software life cycle
        
        When things didn’t go well, the costs added up. Communication and knowledge transfers between devs and ops/SREs were lossy, requiring additional round trips to debug problems or answer partner questions.
        
        To improve on this, Edge Engineering experimented with a hybrid model where devs could push code themselves when needed, and also were responsible for off-hours production issues and support requests.
        
        Even though devs could do their own deployments and debug pipeline breakages, they would often defer to the ops release specialist
  - - - Having teams of specialists who each own a slice of the life cycle can create silos that slow down end-to-end progress.
        Grouping differing specialists together into one team can reduce silos
        
        Operating What You Build Image netflix3:
        “Operate what you build” puts the devops principles in action by having the team that develops a system also be responsible for operating and supporting that system.
        Each development team owns deployment issues, performance bugs, capacity planning, alerting gaps, partner support, and so on.
        
        Scaling Through Developer Tools Image netflix4:
        Netflix created centralized teams (e.g., Cloud Platform, Performance & Reliability Engineering, Engineering Tools) with the mission of developing common tooling and infrastructure to solve problems that every development team has.
        Empowered with these tools in hand, development teams can focus on solving problems within their specific product domain.
        
        Communication and alignment are the keys to success.
        
        Full Cycle Developers - Netflix today Image netflix5
        By combining all of these ideas together, we arrived at a model where a development team, equipped with amazing developer productivity tools, is responsible for the full software life cycle: design, development, test, deploy, operate, and support.
        Full cycle developers are expected to be knowledgeable and effective in all areas of the software life cycle.
        We run dev bootcamps and other forms of ongoing training to impart this knowledge and build up these skills.
        Tools for deployment pipelines (e.g., Spinnaker) and monitoring (e.g., Atlas) are also needed for effective full cycle ownership.
        A full cycle developer thinks and acts like an SWE, SDET, and SRE.
        Teams need to be staffed appropriately with enough headroom to manage builds and deployments, handle production issues, and respond to partner support requests.
        Time needs to be devoted to training
        
        Many companies won’t have the staffing to invest in centralized teams like at Netflix or won't need the complexity
        Netflix’s tools are often open source
        The breadth increases each developer’s cognitive load and means a team will balance more priorities every week than if they just focused on one area.
    - - Netflix Asgard
      - Spinnaker
      - Chaos engeneering
- - - - A Jenkins job is configured to invoke Nebula to build, test and package the application code.
        
        Every deployment at Netflix begins with the creation of a new Amazon Machine Image, or AMI. To generate AMIs from source, we created “the Bakery”.
        
        Let’s analyze the steps they take.
        
        Another test is executed after it is deployed.
        
        They deploy.
        
        A continuous integration server – Jenkins – is used build, test, and package the code. The same tool is used to build and test the code on the continuous integration server as is used on each developer’s machine (common environment).
        
        Changes are checked-in.
        
        Code is built/tested on the developer’s machine using a tool.
  - - - Prevent loosing time on issues with different compiler versions, different tools, different dependencies etc
      - Using a dependency/environment tool to enforce these dependencies IS part of a repeatable process.
    - - You must cultivate the right culture to support these improvements. Hopefully I’ll cover this in a future post.
      - If you don’t use continuous integration already, start using it. You can start by writing a unit test against a very small piece of code. Then find a server that can check out that code and run that test. Preferably, run it in an environment/dependency tool that can be run on your local machine.
      - If you have a special process for deploying your code, make it automatic. Once again, start small and work your way up.
      - Test after you deploy.
  - - - Could result in being less interesting for developers who'd like to go in depth into one technology