Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Orchestration in meatspace

Orchestration in meatspace

Traditional enterprises typically rely on a lot of orchestration to deploy their software, which makes the whole process slow and error prone. How can we move them to a more autonomous approach, in order to speed up the feedback cycle from idea to production?

This slideshow was presented at ChefConf 2014 and DevOps Summit Amsterdam 2014.

A recorded video of the presentation at ChefConf can be found at https://www.youtube.com/watch?v=lj8TwsM8xl0

For more details on this topic see my blog http://niek.bartholomeus.be

Niek Bartholomeus

April 17, 2014
Tweet

More Decks by Niek Bartholomeus

Other Decks in Technology

Transcript

  1. in meatspace
    Orchestration

    View Slide

  2. Niek Bartholomeus

    @niekbartho
    DevOps consultant with a dev
    background
    Me
    http://niek.bartholomeus.be

    View Slide

  3. Two parallel universes
    http://music.cbc.ca/#/blogs/2013/11/Remembrance-Day-playlist-
    songs-from-the-Great-War
    … in a traditional
    enterprise:
    … in a modern company:
    Software delivery

    View Slide

  4. Two parallel universes
    http://music.cbc.ca/#/blogs/2013/11/Remembrance-Day-playlist-
    songs-from-the-Great-War
    … in a traditional
    enterprise:
    … in a modern company:
    Software delivery
    Orchestration Autonomy
    Releasing
    software is
    DIFFICULT
    Releasing
    software is
    EASY

    View Slide

  5. !
    Traditional enterprises:
    - company-wide infrequent orchestrated releases
    - whole infrastructure is brought down
    - lots of teams involved, lots of manual work
    - high ceremony, brittle, error prone
    !
    Modern companies:
    - Autonomous self-empowered teams
    - ops embedded in dev teams
    - loosely coupled architectures
    - continuously deploying new features
    Notes

    View Slide

  6. Foundations of configuration management
    Mark Burgess
    Move from

    centrally managed, tightly coupled
    systems

    to

    autonomous systems

    making promises to each other

    to improve the reliability of our
    infrastructure

    View Slide

  7. This need for autonomy is also found in the book “In Search of Certainty” of Mark
    Burgess.
    This mindset is also the foundation of the modern configuration management tools
    which prefer a loose coupling with the systems they manage (i.e. the nodes decide
    when and how they commit to their promise)
    Therefore these tools thrive in the autonomous “universe”
    Notes

    View Slide

  8. How can we move
    traditional enterprises to
    more

    autonomy?
    Our mission:

    View Slide

  9. It seems that if we want to improve software delivery in enterprises we have to move
    them towards more autonomy so our mission of today will be to find ways to do that.
    Notes

    View Slide

  10. 1. Problem space

    2. Scientific foundation

    3. Solutions
    Agenda:

    View Slide

  11. Study of the

    problem space
    Step 1:

    View Slide

  12. Problem space
    1. Hierarchical organization chart
    T
    o
    p

    !
    d
    o
    w
    n
    n

    View Slide

  13. Decisions making is centralized at the top of the hierarchy and is imposed to the
    lower layers who simply execute the instructions
    Issues:
    1 Technical decisions are made far away from where the knowledge sits
    2 Not motivating for knowledge workers at the bottom of the hierarchy (results in
    lack of good people and poorly designed systems)
    => needs a huge communication channel top-down
    Notes

    View Slide

  14. Problem space
    2. Standardization

    View Slide

  15. False assumption that the environment is stable and that the users’ needs and the
    way the world behaves (and therefore the automation work that needs to be done)
    can all be exactly planned upfront (reductionism, determinism, “follow the plan”)
    Improve efficiency by standardizing the work flows and high job specialization
    (functional silos)
    “Optimization of resources over speed of delivery”
    Notes

    View Slide

  16. Problem space
    3. Tightly integrated application landscape

    View Slide

  17. Many heterogeneous and tightly integrated applications and consequently many
    multi-application feature requests
    This and standardization are the main cause for company-wide releases: just follow
    the plan and make sure your part is ready in time
    The smallest deviation from the plan within one team can cause major chain reactions
    in the other applications
    Notes

    View Slide

  18. Problem space
    4. Manual work

    View Slide

  19. Software configuration management like
    - keeping track of which versions of the software components belong together
    - What is deployed in which environment
    Deployment requests and follow ups (Word, Excel and email)
    Release orchestration (planning, approvals, deployments, …)
    Notes

    View Slide

  20. My personal theory
    Automating business
    processes is

    complex

    creative

    dynamic

    View Slide

  21. My personal theory
    Automating business
    processes is

    complex

    creative

    dynamic
    Therefore we need a quick
    feedback cycle from idea to
    production

    View Slide

  22. My personal theory
    Automating business
    processes is

    complex

    creative

    dynamic
    Can only work when
    releasing software is easy
    Therefore we need a quick
    feedback cycle from idea to
    production

    View Slide

  23. My personal theory
    Automating business
    processes is

    complex

    creative

    dynamic
    Can only work when
    releasing software is easy
    Therefore we need a quick
    feedback cycle from idea to
    production
    For this we need
    autonomy

    View Slide

  24. requires
    My personal theory
    Automating business
    processes is

    complex

    creative

    dynamic
    Can only work when
    releasing software is easy
    Therefore we need a quick
    feedback cycle from idea to
    production
    For this we need
    autonomy

    View Slide

  25. Complex: both on business (inherent complexity of business and unpredictable nature
    of human behavior) and technical (lots of technologies, huge infrastructures) side
    Creative: every problem is a new problem, it’s always “the first time”, no recurrence
    (all recurrent processes should be automated)
    Dynamic: both business needs as technical capacities change at a rapid pace
    !
    In such an environment we need specialists of all domains (business and technical)
    using all their creativity, closely collaborating, continuously validating their ideas with
    the reality
    => quick feedback cycle needed
    => performant release process needed
    => as we just saw, this requires autonomy
    !
    Notes

    View Slide

  26. What is autonomy?
    Autonomous unit = a unit(1) that has the freedom
    to do its work(2) independently(3)
    (1) unit = the development team
    Definition:
    In our context:
    (2) work = building new features
    (3) independent = be self-sufficient for all services or
    technologies that are needed to do the work

    View Slide

  27. What is autonomy?
    Possible dependencies:
    • On infrastructure
    Very tight - keep them within the team

    => Build cross-functional teams

    View Slide

  28. What is autonomy?
    Possible dependencies:
    • On infrastructure
    • On other applications
    Very tight - keep them within the team

    => Build cross-functional teams
    Avoid them where possible, limit them otherwise

    => Support decoupled architectures, backward
    compatibility

    View Slide

  29. What is autonomy?
    Possible dependencies:
    • On infrastructure
    • On other applications
    • On management
    Very tight - keep them within the team

    => Build cross-functional teams
    Avoid them where possible, limit them otherwise

    => Support decoupled architectures, backward
    compatibility
    Technical decisions must be made inside the team

    => Create self-empowered teams

    View Slide

  30. Building our solution on a
    scientific
    foundation
    Step 2:

    View Slide

  31. A theory of organization structuring
    Henry Mintzberg
    Published in 1979, “The Structuring of
    Organizations” is an empirical study
    of how organizations structure
    themselves to consistently bring value
    based on the environment they work
    in

    View Slide

  32. The Structuring of Organizations
    Organized human activity =

    division of labor + coordination of
    the tasks
    Definition:

    View Slide

  33. The Structuring of Organizations
    Coordination mechanisms:
    Mutual
    adjustment
    Direct
    supervision
    Standardization

    View Slide

  34. The Structuring of Organizations
    Design parameters:

    !
    • Job specialization

    • Behavior formalization

    • Unit grouping

    • Unit size

    • Decentralization of decision making

    • …

    View Slide

  35. The Structuring of Organizations
    Situational factors:

    !
    • Complexity of the environment

    • Stability of the environment

    • Diversity of the environment

    • Age and size of the organization

    • …

    View Slide

  36. The Structuring of Organizations
    Common configurations:

    !
    • Administrative bureaucracy

    • Professional bureaucracy

    • Adhocracy

    • …

    View Slide

  37. Applying the theory to our environment 1/2
    • Job specialization:

    specialists are needed but they should have
    general knowledge

    !
    • Behavior formalization:

    limited - mostly through training and
    knowledge-sharing (work shops, communities,
    …)

    View Slide

  38. Applying the theory to our environment 2/2
    • Unit grouping:

    by end-to-end service, not by specialization

    !
    • Unit size:

    small because we must rely on mutual
    adjustment as the coordination mechanism

    !
    • Decentralization of decision making:

    yes - technical decisions must be made where
    the knowledge is: on the work floor

    View Slide

  39. Mintzberg’s findings
    Environment is

    complex

    creative

    dynamic
    requires
    Small units

    grouped by service

    coordinating through mutual
    adjustment and

    empowered to take technical
    decisions

    View Slide

  40. Conclusion
    requires
    requires

    Small units

    grouped by service

    coordinating through mutual
    adjustment and

    empowered to take technical
    decisions
    cross-functional teams

    self-empowered teams
    Environment is

    complex

    creative

    dynamic

    View Slide

  41. Choice of organization structure
    complex

    creative

    dynamic
    requires adhocracy
    simple

    stable requires
    administrative
    bureaucracy

    View Slide

  42. Choice of organization structure
    complex

    creative

    dynamic
    requires adhocracy
    simple

    stable requires
    administrative
    bureaucracy
    Traditional
    enterprises

    View Slide

  43. An environment that is complex, creative and dynamic requires an adhocracy
    An environment that is simple and stable require an administrative bureacracy
    Traditional enterprises are organized like an administrative bureaucracy
    It seems that traditional enterprises have chosen the wrong organization structure!
    Notes

    View Slide

  44. How can we move
    traditional enterprises to
    more

    autonomy?
    Our mission:

    View Slide

  45. How can we move
    traditional enterprises to
    more

    autonomy?
    Our mission:
    from an administrative
    bureaucracy to an adhocracy?
    Revised

    View Slide

  46. Put the theory into
    practice!
    Step 3:

    View Slide

  47. Our action plan
    3.1. Enhance the existing communication flows





    between the teams

    !
    !
    3.2. Increase autonomy


    a. between the different development teams and



    their applications

    !
    !

    b. between the components of each application
    Tactical
    solution
    Strategi
    c
    Unicorn
    solution

    View Slide

  48. Enhance the existing
    communication
    flows
    Step 3.1: Tactical
    solution

    View Slide

  49. Enhance the communication flows
    Feature
    tracking

    View Slide

  50. Enhance the communication flows
    Version
    control
    Feature
    tracking

    View Slide

  51. Enhance the communication flows
    Version
    control
    Continuous
    integration
    Feature
    tracking

    View Slide

  52. Enhance the communication flows
    Version
    control
    Software
    repository
    Continuous
    integration
    Feature
    tracking

    View Slide

  53. Define a simple and consistent process of software delivery and automate it where
    possible
    Each tool should be integrated with the other tools so that the users can see all the
    relevant information for their domain
    !
    Steps
    - integrate feature tracking with version control
    - set up continuous integration and a software repository for all built components
    !
    !
    !
    Notes

    View Slide

  54. Visualize the information

    View Slide

  55. The resulting build artifacts must be well visualized with all the necessary context so
    each team can quickly see what they are interested in

    View Slide

  56. Enhance the communication flows
    Version
    control
    Software
    repository
    Continuous
    integration
    Feature
    tracking

    View Slide

  57. Enhance the communication flows
    Version
    control
    Software
    repository
    Continuous
    integration
    Feature
    tracking
    Deployment
    automation
    !
    Infrastructure

    View Slide

  58. Enhance the communication flows
    Release
    orchestration
    Version
    control
    Software
    repository
    Continuous
    integration
    Feature
    tracking
    Deployment
    automation
    !
    Infrastructure

    View Slide

  59. set up deployment automation
    facilitate release orchestration with tooling and integrate it with the existing tools
    This is the least common area of automation in the schema so let us have a closer look
    at what I mean exactly
    !
    !
    Notes

    View Slide

  60. Multi-application features
    Application 1
    Application 2
    Application 50

    Feature A Feature B Feature C
    Organization XYZ - Release 2014.1
    X
    X X
    X
    X
    X

    View Slide

  61. Because of the tightly integrated application landscape a lot of features span multiple
    applications.
    !
    Notes

    View Slide

  62. dev + unit test
    Release orchestration
    Application 1
    Application 2
    Application 50

    Organization XYZ - Release 2014.1
    dev + unit test system test
    UI test
    dev + unit test API test
    integration test acceptance test release
    release orchestration
    Development Integration Acceptance Prod
    Environment

    View Slide

  63. Because of a false belief in planning (see earlier) traditional enterprises think that
    introducing company-wide releases is the easiest way to tackle integration issues
    As soon as more than one application is under test, we must move into shared
    environments for all apps
    The tactical solution is to industrialize the orchestration that is required to make this
    work: move from Word, Excel and mail to a tool that allows for
    - creation of deployment requests by devs
    - approval of deployment requests by release management, based on the status
    of the implemented features
    - groups the deployment request in one big run for deployment
    - coordinate with the ops teams who will do the deployment
    - manual steps and manual interventions if an automation fails (happens frequently
    in traditional enterprises)
    Notes

    View Slide

  64. Visualize the information

    View Slide

  65. The developer selects an application and a release. Automatically a list of the
    applicable change requests is shown, including their statuses. This made it easier for
    the release coordinator to validate the deployment requests
    For each deployment of a component he appends a step and selects the applicable
    version number. Automatically the relevant deployment related information is shown.
    !
    Notes

    View Slide

  66. Dependencies on the infrastructure
    Application
    Packages
    Packages
    Packages
    Packages
    Packages
    Config
    files
    Packages
    Packages
    User
    acounts
    Packages
    Packages
    Dirs

    Files
    Packages
    Packages
    Services
    Packages
    Packages
    Cron
    schedules
    Server
    Model

    Packages





    Configs




    {
    Development Operations
    maintain
    consult
    sync

    View Slide

  67. Besides the dependencies between the dev teams there was also the more tight
    dependency on the infrastructure side
    This can be tackled by using a declarative model to communicate the system
    configurations of the infrastructure to Development
    - Improves the visibility of the dependencies (devs can easily see the current state
    of the infrastructure, no more false assumptions) - no more need to wade
    through historic deployment instructions to find out what exactly and how it was
    installed on a particular server
    - Makes it possible to easily provision test systems that are similar to production
    (infra-as-code/infra-as-model)
    Notes

    View Slide

  68. Increase the autonomy
    between the
    development teams
    Step 3.2: Strategic
    solution

    View Slide

  69. dev + unit test
    Orchestrated releases
    Application 1
    Application 2
    Application 50

    Organization XYZ - Release 2014.1
    dev + unit test system test
    UI test
    dev + unit test API test
    integration test acceptance test release
    orchestration
    Development Integration Acceptance Prod
    autonomy
    Environment

    View Slide

  70. The tactical solution was to streamline and automate the existing communication
    flows of release orchestration in order to have a better visibility on all the
    dependencies that exist between the different teams.
    But if one team fails to keep its commitment to the plan it will still cause a chain
    reaction in the other teams.
    The strategic solution is to get rid of this orchestration, to move towards autonomy.
    Notes

    View Slide

  71. Feature C
    Wait time
    Application 1
    Feature A
    Feature X
    Feature Y
    Feature Z
    multi-app feature
    single-app feature
    Orchestrated

    Release
    wait time

    View Slide

  72. Orchestrated releases can also cause considerable wait time causing a missed
    opportunity to bring value quickly the the end users.
    Notes

    View Slide

  73. Single-application releases
    Application 1
    Application 2
    Application 50

    Feature A Feature B Feature C
    Organization XYZ - Release 2014.1
    X
    X X
    X
    X
    X

    View Slide

  74. Single-application releases
    Application 1
    Feature A Feature C
    App 1 - Release 2014.1.3
    Requires
    backward
    compatibility
    Application 2
    Application 50

    Feature A Feature B Feature C
    Organization XYZ - Release 2014.1
    X X
    X X
    X X

    View Slide

  75. We can move away from company-wide orchestrated releases by making our
    application backward compatible with the other applications
    Notes

    View Slide

  76. Backward compatibility
    App 1
    App 2
    App 3
    App 4

    View Slide

  77. Backward compatibility
    App 1
    App 2
    App 3
    App 4
    Modification
    e.g. change fName to firstName
    1

    View Slide

  78. Backward compatibility
    App 1
    App 2
    App 3
    App 4
    Modification
    e.g. change fName to firstName
    1

    View Slide

  79. Backward compatibility
    App 1
    App 2
    App 3
    App 4
    Modification
    e.g. change fName to firstName
    1

    View Slide

  80. Backward compatibility
    App 1
    App 2
    App 3
    App 4
    Modification
    e.g. change fName to firstName
    1

    View Slide

  81. Backward compatibility
    App 1
    App 2
    App 3
    App 4
    Modification
    e.g. change fName to firstName
    1
    Breaking
    change

    View Slide

  82. Backward compatibility
    App 1
    App 2
    App 3
    App 4
    Modification
    e.g. change fName to firstName
    1
    2
    Breaking
    change

    View Slide

  83. Backward compatibility
    App 1
    App 2
    App 3
    App 4
    Modification
    e.g. change fName to firstName
    1
    2
    Breaking
    change

    View Slide

  84. Backward compatibility
    App 1
    App 2
    App 3
    App 4
    Modification
    e.g. change fName to firstName
    1
    2 3
    Breaking
    change

    View Slide

  85. Backward compatibility
    App 1
    App 2
    App 3
    App 4
    Modification
    e.g. change fName to firstName
    1
    2 3
    Breaking
    change

    View Slide

  86. Backward compatibility
    App 2
    App 3
    App 4
    App 1

    View Slide

  87. Backward compatibility
    App 2
    App 3
    App 4
    Addition
    e.g. add firstName
    1
    App 1
    Deprecation
    e.g. keep fName expand

    View Slide

  88. Backward compatibility
    App 2
    App 3
    App 4
    Addition
    e.g. add firstName
    1
    App 1
    Backward
    compatible
    Deprecation
    e.g. keep fName expand

    View Slide

  89. Backward compatibility
    App 2
    App 3
    App 4
    Addition
    e.g. add firstName
    1
    2
    App 1
    Backward
    compatible
    Deprecation
    e.g. keep fName expand

    View Slide

  90. Backward compatibility
    App 2
    App 3
    App 4
    Addition
    e.g. add firstName
    1
    2
    3
    App 1
    Backward
    compatible
    Deprecation
    e.g. keep fName expand

    View Slide

  91. Backward compatibility
    App 2
    App 3
    App 4
    Addition
    e.g. add firstName
    1
    2
    3
    App 1
    Backward
    compatible
    4
    expand
    contract

    View Slide

  92. Backward compatibility follows the expand/contract principle (add/deprecate) which allows for
    a grace period for the depending apps to upgrade
    As soon as we support backward compatibility we become independent from the organisation-
    wide release: whatever delays occur there we are not impacted
    With this approach there is still quite some orchestration happening (4 steps), but the
    difference is that the decision making power has moved down from the organization to the
    application. Cf our scientific section we have changed the coordination mechanism from direct
    supervision (central orchestration) to mutual adjustment between the autonomous
    applications. They only have to take into account one dependency: make sure that we deliver
    our multi-app feature BEFORE the organization-wide release date.
    Supporting backward compatibility requires applications to have a well-structured/modular
    code base and a decoupled architecture
    There are several scales on which to apply the backward compatibility (two apps side by side, a
    v2 path in a rest resource, adding a field in
    It also requires that the depending apps are released frequently, to avoid the need to support
    too many deprecated features in parallel
    Notes

    View Slide

  93. Feature C
    Reduced wait time
    Application 1
    Feature A
    Feature X
    Feature Y
    multi-app feature
    single-app feature
    Feature Z
    Orchestrated

    Release
    App

    Release
    wait time

    View Slide

  94. Another advantage of becoming independent from the company-wide release is that
    we can start releasing on our own tempo. As a result the wait time decreases and the
    feedback cycle increases so the users will get added value sooner.
    Notes

    View Slide

  95. Increase the autonomy
    between the components
    of the application
    Step 3.2.b: Unicorn
    solution

    View Slide

  96. Feature C
    Increase the feedback cycle
    Application 1
    Feature A
    Feature X
    Feature Y
    multi-app feature
    single-app feature
    Feature Z
    feature flag
    wait time

    View Slide

  97. Feature C
    Increase the feedback cycle
    Application 1
    Feature A
    Feature X
    Feature Y
    multi-app feature
    single-app feature
    Feature Z
    feature flag
    wait time

    View Slide

  98. Feature C
    Increase the feedback cycle
    Application 1
    Feature A
    Feature X
    Feature Y
    multi-app feature
    single-app feature
    Feature Z
    feature flag
    wait time

    View Slide

  99. Feature C
    Increase the feedback cycle
    Application 1
    Feature A
    Feature X
    Feature Y
    multi-app feature
    single-app feature
    Feature Z
    feature flag
    wait time

    View Slide

  100. Feature C
    Increase the feedback cycle
    Application 1
    Feature A
    Feature X
    Feature Y
    multi-app feature
    single-app feature
    Feature Z
    feature flag
    wait time

    View Slide

  101. Feature C
    Increase the feedback cycle
    Application 1
    Feature A
    Feature X
    Feature Y
    multi-app feature
    single-app feature
    Feature Z
    feature flag
    wait time

    View Slide

  102. If we want an even faster feedback cycle we can use feature flags for not-yet-finished
    features to reduce the wait time to zero for each feature.
    This causes an increase in the number of releases and consequently a faster feedback
    cycle, which is a good thing.
    It may also have a negative side effect if the application requires down time during
    the deployment because of a temporary inconsistency period that may arise when the
    components of the application are deployed, e.g. the new version of the application
    code requires the new version of the db schema and vice versa.
    This is a similar problem as with the company-wide release, only on a lower level: the
    level of the application.
    The solution is also similar: we have to make the components backward compatible
    (and in general more autonomous) to arrive at zero-downtime deployments
    Because the communications on this component level is much more granular
    supporting backward compatibility on this level is much more difficult.
    Notes

    View Slide

  103. Database
    fName
    Application
    read

    fName
    write

    fName
    Backward compatibility

    View Slide

  104. Database
    fName
    fName firstName
    Add
    e.g. add firstName
    1
    Deprecate
    e.g. keep fName
    expand
    Application
    read

    fName
    write

    fName
    Backward compatibility

    View Slide

  105. Database
    fName
    fName firstName
    Add
    e.g. add firstName
    1
    Deprecate
    e.g. keep fName
    expand
    Application
    read

    fName
    write

    fName
    Backward compatibility
    2
    write

    firstName
    Duplicate write

    View Slide

  106. Database
    fName
    fName firstName
    Add
    e.g. add firstName
    1
    Deprecate
    e.g. keep fName
    expand
    Application
    read

    fName
    write

    fName
    Backward compatibility
    2
    write

    firstName
    Migrate data
    3
    Duplicate write

    View Slide

  107. Database
    fName
    fName firstName
    Add
    e.g. add firstName
    1
    Deprecate
    e.g. keep fName
    expand
    Application
    read

    fName
    write

    fName
    Backward compatibility
    2
    write

    firstName
    Migrate data
    3
    read

    firstName
    4 Duplicate write
    Modify read
    Deduplicate write

    View Slide

  108. Database
    firstName
    Add
    e.g. add firstName
    1
    expand
    Application
    read

    fName
    write

    fName
    Backward compatibility
    2
    write

    firstName
    Migrate data
    3
    read

    firstName
    4
    contract 5
    Duplicate write
    Modify read
    Deduplicate write

    View Slide

  109. Making database changes backward compatible, e.g. changing the name of a field,
    requires a lot of orchestration
    Notes

    View Slide

  110. Unicorns

    View Slide

  111. This solution is typically applied at some of the most successful digital companies that
    exist because they apply extremely fast feedback cycles (the reason of their success)
    and cannot afford any downtime. Having a centralized orchestrator is not interesting
    for them because they work in huge infrastructures with high scalability needs and
    high numbers of applications and components that continuously need changing.
    !
    !
    Fully cross-functional and self-empowered teams
    Huge infra with high scalability needs
    Fully automated release pipeline (deployments and testing)
    No-downtime deployments
    Fully decoupled architectures with autonomous applications and components (e.g.
    app code and db changes, communication with load balancers and monitoring
    systems)
    Backward compatibility, feature flagging, dark launching
    Notes

    View Slide

  112. Traditional separation
    Application
    Packages
    Packages
    Packages
    Packages
    Packages
    Config
    files
    Packages
    Packages
    User
    acounts
    Packages
    Packages
    Dirs

    Files
    Packages
    Packages
    Services
    Packages
    Packages
    Cron
    schedules
    Server
    Model

    Packages





    Configs




    {
    Development Operations
    maintain
    consult
    sync

    View Slide

  113. Modern separation
    Application
    Packages
    Packages
    Packages
    Packages
    Packages
    Config
    files
    Packages
    Packages
    User
    acounts
    Packages
    Packages
    Dirs

    Files
    Packages
    Packages
    Services
    Packages
    Packages
    Cron
    schedules
    Server
    Model

    Application




    Packages





    Configs




    sync
    Creative Automated
    Devs & infra
    specialists
    maintain

    View Slide

  114. We have to move from the traditional separation between dev and ops to a
    separation between creative and automated/standardized
    Functional and operational evolutions of the app are done in the Creative side
    Repetitive work (i.e. traditional day-to-day ops work) is automated in the Automated
    side
    Include the application in the model:
    - one declarative model for the application with the system configurations it needs
    - one tool for app deployment and CM (makes sense because we now have only
    one team anyway)
    - drift management for the application
    - orchestration needs can be covered by the components through mutual
    coordination using the information from the model (or by tooling if it gets too
    complex: it must calculate the exact deployment process from the model/
    desired state and the current state)
    - provisioning and upgrading becomes possible for less-technical people
    Notes

    View Slide

  115. Summary:
    Orchestration problems
    Enhance the existing flows
    Increase autonomy

    View Slide

  116. Niek Bartholomeus

    @niekbartho
    Contact me!
    http://niek.bartholomeus.be
    [email protected]

    View Slide