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

Microservices - Yet another buzzword?

Microservices - Yet another buzzword?

Microservices architecture is garnering attention as a modern pattern for building application that scale well, deploy often, have better fault tolerance and can be built out of multiple technologies. We will go through the advantages and drawbacks of going Microservices way and when the pattern is a good fit. We will also touch on Docker, yet another buzzword, strongly emerging as a Microservices delivery mechanism for Linux based systems. If you are looking to refactor your monolithic application, to build a new cloud native application or simply to get your geek on this session is for you.

Ovidiu Dimulescu

March 28, 2015
Tweet

More Decks by Ovidiu Dimulescu

Other Decks in Programming

Transcript

  1. The opinions and views expressed in this talk are my

    own, and do not necessarily reflect the opinions or views of my employer.
  2. 11 Monolith App PM QA DEV DBA SA NetEng “On

    Premise” No / SQL (single datastore*)
  3. 17 APP UI Data Access Bussines Domain … APP UI

    Data Access Bussines Domain APP UI Data Access Bussines Domain Scalability model
  4. 18 ESB WS-* SOAP XML Svc I Svc II Svc

    N PM QA DEV DBA SA NetEng “On Premise” No / SQL (single datastore *) …
  5. 19 (Not so) Old world Layers oriented Scaling per app

    instead of per component Process oriented / friction prone Single language * Single datastore *
  6. 23 * http://en.wikipedia.org/wiki/Conway%27s_law Organizations which design systems ... are constrained

    to produce designs which are copies of the communication structures of these organizations Melvin Conway, 1968 Conway’s Law
  7. 25 Web size Team size Team skills and geo distribution

    Systems Architecture Time to market Scalabilities
  8. 29 Self - serve Convenience oriented / low friction Polyglot

    language and persistence Fast & affordable experimentation Uniform & disposable environments New world
  9. 31 UNIX Philosophy Write programs that do one thing and

    do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. Doug McIlroy * http://en.wikipedia.org/wiki/Unix_philosophy
  10. 32 Initial Stands for (acronym) Concept S SRP [4] Single

    responsibility principle a class should have only a single responsibility (i.e. only one potential change in the software's specification should be able to affect the specification of the class) O OCP [5] Open/closed principle “software entities … should be open for extension, but closed for modification.” L LSP [6] Liskov substitution principle “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract. I ISP [7] Interface segregation principle “many client-specific interfaces are better than one general-purpose interface.”[8] D DIP [9] Dependency inversion principle one should “Depend upon Abstractions. Do not depend upon concretions.”[8] * http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29 SOLID (OOP)
  11. 35 Microservices Micro is about scope not size Independently deployable

    (group level) Lightweight communication Single process (lightweight containers) Smart endpoints, dumb pipes
  12. 36 Right tool for a job Different code changing speeds

    Organizational splits Multiple scaling profiles Multiple security zones Cross functionality Microservices - Pros
  13. 37

  14. 38 Splitting / Merging / Defining boundaries Micro frameworks /

    containers availability & reliability Wiring complexity Configuration Management Testing / Deployment / Monitoring Data Management (MDM, Eventual Consistency) Cognitive complexity Org structure and culture Microservices - Challenges
  15. 39 Conway’s Law Adrian Cockcroft (Battery Ventures, ex-Netflix) suggested that

    instead of designing software that copies our current organizational structure, figure out how we want our software to look, then (re) design the organization so it copies the software.
  16. 41 * http://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/ 1) All teams will henceforth expose their

    data and functionality through service interfaces. 2) Teams must communicate with each other through these interfaces. 3) There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared- memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network. 4) It doesn’t matter what technology they use. HTTP, Corba, Pubsub, custom protocols — doesn’t matter. Bezos doesn’t care. 5) All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions. 6) Anyone who doesn’t do this will be fired. Jeff Bezos, CEO, Amazon - Big Mandate
  17. 42 “You build it, you run it” Werner Vogels, CTO,

    Amazon * ACM Queue interview, 2006. https://queue.acm.org/detail.cfm?id=1142065
  18. Startup speed Resource density Layered file system with changes tracking

    Hierarchical images with registry hub Portable Single process* Features
  19. The Twelve-Factor App - www.12factor.net coding {the} architecture - www.codingthearchitecture.com

    Pass for Microservices - gilliam.github.io Martin Fowler - martinfowler.com/articles/microservices.html Chris Richardson - microservices.io/patterns/microservices.html High Scalability - highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html The Arm Blog - the-arm.com/2013/09/30/microservices-and-solid-principles-of-object-oriented-design/ Dare to dream blog - davidmorgantini.blogspot.com/2013/08/micro-services-introduction.html Charles Young Blog - geekswithblogs.net/cyoung/archive/2014/12/20/hexagonal-architecturendashthe-great-reconciler.aspx Docker Website - docker.com Google Search Engine - last but not least :) Resources