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

[ZendCon EU 2013] The Evolution of DevOps

Davey Shafik
November 20, 2013

[ZendCon EU 2013] The Evolution of DevOps

With the rapid adoption of new software development methodologies and infrastructure as a service (IaaS), we’ve seen a new role emerge, DevOps.

The DevOp is a master of this new domain: The Cloud. But just as quickly as we’ve seen DevOps emerge, we’re seeing the role evolve as advanced platforms and services enter on to the scene.

During this talk, we’ll explore how DevOps is evolving, what that means to you, and your role in the ever changing landscape of development and the cloud.

Davey Shafik

November 20, 2013
Tweet

More Decks by Davey Shafik

Other Decks in Programming

Transcript

  1. •Community Engineer at Engine Yard •Author of Zend PHP 5

    Certification Study Guide, Sitepoints PHP Anthology: 101 Essential Tips, Tricks & Hacks & PHP Master: Write Cutting Edge Code •A contributor to Zend Framework 1 & 2, phpdocs, and PHP internals • @dshafik Davey Shafik
  2. chef puppet apache aws azure bash bower cassandra composer config

    ec2 elastic ip elb fabric grunt ha haproxy heartbeat ini javascript json linux mariadb memcached mongodb mysql nginx node.js openstack oracle pear phing php php-fpm postgresql python redis riak ruby sass shell squid storage terramark vagrant varnish yaml pecl
  3. chef puppet apache aws azure bash bower cassandra composer config

    ec2 elastic ip elb fabric grunt ha haproxy heartbeat ini javascript json linux mariadb memcached mongodb mysql nginx node.js openstack oracle pear phing php php-fpm postgresql python redis riak ruby sass shell squid storage terramark vagrant varnish yaml pecl
  4. chef puppet apache aws azure bash bower cassandra composer config

    ec2 elastic ip elb fabric grunt ha haproxy heartbeat ini javascript json linux mariadb memcached mongodb mysql nginx node.js openstack oracle pear phing php php-fpm postgresql python redis riak ruby sass shell squid storage terramark vagrant varnish yaml pecl Both happen to be written in Ruby
  5. Infrastructure Platform Nginx PHP Ruby/Rails Node.js Varnish PostgreSQL MongoDB Other:

    Memcached, Gearman, etc. MySQL Riak Cassandra Application
  6. Infrastructure Platform Nginx PHP Ruby/Rails Node.js Varnish PostgreSQL MongoDB Other:

    Memcached, Gearman, etc. MySQL Riak Cassandra Application
  7. Infrastructure Platform Nginx PHP Ruby/Rails Node.js Varnish PostgreSQL MongoDB Other:

    Memcached, Gearman, etc. MySQL Riak Cassandra Application
  8. Infrastructure As A Service (IaaS) ! Platform Nginx PHP Ruby/Rails

    Node.js Varnish PostgreSQL MongoDB Other: Memcached, Gearman, etc. MySQL Riak Cassandra Application
  9. Infrastructure As A Service (IaaS) ! Platform Nginx PHP Ruby/Rails

    Node.js Varnish PostgreSQL MongoDB Other: Memcached, Gearman, etc. MySQL Riak Cassandra Application
  10. Infrastructure As A Service (IaaS) ! Platform Nginx PHP Ruby/Rails

    Node.js Varnish PostgreSQL MongoDB Other: Memcached, Gearman, etc. MySQL Riak Cassandra Application
  11. Infrastructure As A Service (IaaS) ! Platform Nginx PHP Ruby/Rails

    Node.js Varnish PostgreSQL MongoDB Other: Memcached, Gearman, etc. MySQL Riak Cassandra Application
  12. Infrastructure As A Service (IaaS) ! Platform Nginx PHP Ruby/Rails

    Node.js Varnish PostgreSQL MongoDB Other: Memcached, Gearman, etc. MySQL Riak Cassandra Application
  13. Infrastructure As A Service (IaaS) ! Platform Nginx PHP Ruby/Rails

    Node.js Varnish PostgreSQL MongoDB Other: Memcached, Gearman, etc. MySQL Riak Cassandra Application
  14. Service-oriented architecture (SOA) is […] based on discrete pieces of

    software providing application functionality as services to other applications. […] It is independent of any vendor, product or technology. Source: Wikipedia! (Emphasis Mine)
  15. Separation of concerns (SoC) is a design principle for separating

    a computer program into distinct sections […]. A concern is a set of information that affects the code of a computer program.! ! The value of separation of concerns is simplifying development and maintenance of computer programs. When concerns are well separated, individual sections can be developed and updated independently. Of especial value is the ability to later improve or modify one section of code without having to know the details of other sections, and without having to make corresponding changes to those sections. Source: Wikipedia! (Emphasis Mine)
  16. Isolation • Object Oriented Design at the Systems Level •

    Process Encapsulation • System Isolation Services should be independent of each other
  17. Isolation • Plan well defined Boundaries • Code • Resources

    • Features • Use separate resource for each service, e.g. database • Use separate URLs for each • e.g. accounts.api.example.org & reviews.api.example.org • This allows you to eventually use separate servers and eventually, separate clusters for each !42
  18. Reusable • Use the same service to get the same

    data for different purposes • e.g. Getting an items rating, and getting it’s reviews Services should encapsulate a concern entirely
  19. Interoperable Services should work with each other • Loosely couples

    integration from implementation • Allows mixing technology to meet your needs
  20. Interoperable • Similar data should be consistent • Similar actions

    should be consistent • HTTP + JSON are supported everywhere !47
  21. Robust • Consistent and informative errors • Treat all services

    the same as third-party • Trust nothing • Assume problems • Cache Everything !51
  22. BULLET • Bullet point • Bullet point • Bullet point

    BULLET • Bullet point • Bullet point • Bullet point BULLET • Bullet point • Bullet point • Bullet point BULLET • Bullet point • Bullet point • Bullet point Reuse (What you want to) Refactor (What you can) Rewrite (What you need to) The 3 R’s of Software Development
  23. Reuse • Models • Business Logic • Libraries • Data

    sources • Almost anything but your views Pros: Quickly piggy-back off your current code. Cons: Will likely lead to REST-like (or RESTy/RESTful) APIs that are RPC in reality.
  24. Reuse: Best Practices for APIs • Design your API first

    • APIs are like URIs: They should be permanent • Don’t let bad legacy decision drive new development Do: Pretend your API is a re-write. Create the best API you can for your application. Then implement it using legacy code any way you can. Even if it sucks. Don’t: Make compromises based on old code. Instead, plan to later refactor the old code.
  25. Refactor • Two types of refactoring: • Refactor your app

    to use your services instead of legacy code. Then make the APIs better by: • Refactor the underlying implementation of your APIs to migrate away from legacy code Do: Test. Unit Tests and Integration Tests. Don’t: change your API! If you designed it right during the Reuse phase, this should be easy!
  26. Rewrite • Rewriting should be your last step • You

    now have separation of concerns, so you can re-write your application piece meal Do: Discard any and all bad legacy code. Treat it as a clean slate. Don’t: Rewrite just to rewrite! Legacy code isn’t inherently bad code. Focus on new features. Build them as services!
  27. Step-By-Step 1. Design your API 2. Build by Reusing legacy

    code (Do whatever it takes!) 3. Release 4. Refactor Application to use API instead of Legacy code 5. Refactor (or Rewrite) API to not use Legacy code. 6. Reuse API in Legacy application Rewrite (or Reuse in an entirely new application!)