The Architect Elevator – Visiting the Upper Floors | Gregor Hohpe

Gregor Hohpe; The Architect Elevator – Visiting the Upper Floors; In Martin Fowler’s Blog; 2017-05-24.

tl;dr → an architect must be able to speak argot to a wide range of cultures; the architect travels to meet the client & the service workers, they do not travel to meet him.  The elevator is a metaphor for SES in the workplace.

Overview

Photo of Gregor Hohpe<quote> is an IT architect who’s been building systems in a start-up, consultancy, internet giant, and corporate IT environment. He likes to untangle complex topics to make them approachable without dumbing them down, while spicing things up with pointed metaphors. He likes to tinker with Raspberry Pi’s and IT organizations. His Internet home is EnterpriseIntegrationPatterns.com</.quote>

Actualities

Choose design over architecture | 18F

Choose design over architectureKane Baccigalupi; In 18F; 2015011-17.

tl;dr → just do it; use craftsmanship, use devops, always be launching; planning is old school and bad, but perhaps necessary

Mentioned

  • Robert C Morris; Design Principles and Design Patterns; 2000; 34 pages.
    Mentions

    • Object-Oriented Design Principles
      • Open-Closed Principle (OCP)
      • Liskov Substitution Principle (LSP)
      • Dependency Inversion Principle (DIP)
      • Interface Segregation Principle (ISP)
      • Rlease Reuse Equivalency Principle (RREP)
      • Common Closuer Principle (CCP)
      • Acyclic Dependencies Principle (ADP)
  • In Jimi Wales’ Wiki

Digging into Microservices | SD Times

Digging into Microservices; Christina Mulligan; In SD Times; 2015-04-02.

tl;dr => Micoservices of 2015 are the “frameworks” of the 1990s (ahem 1980s).

Instead

  • James Lewis, Martin Fowler; Microservices; In His Blog (Fowler); 2014-03-10, with revisions; ~175 paragraphs; 7200 words; with diagrams & sidebars.

Mentions

  • Gauzy, generalist linkbait
    • Article spread over 8 pages.
    • Single-sentence paragraphs; two-sentence paragraphs.
    • Each statement supported by a quote from a source.
    • Lots of “best practice” listicles.
    • Dramatic hooks at the page end to keep you reading;
      <quote>While there are many promising benefits to the approach, there is also a dark side to microservices</quote>
    • First page is the largest, each page smaller after that.
    • 8-9 lines/paragraphs/page
    • 500-800 words/page.
  • Definition
    • <quote>Microservice architecture is the idea that rather than building large monolithic applications, where you have one enormous thing that tries to cover thousands and thousands of different pieces of functionality and lots of different business services, we are going to try to break these out into smaller components, each of which represent an individual business action</quote> attributed to Andrew Phillips, Xebia Labs.
    • <quote>Microservices are the architectural approach that allows you to design your system in these small or autonomous components that do one thing and do it well</quote> attributed to Bob Familiar, BlueMetal Architects
    • <quote>an approach to delivering application functionality that invites the functionality into very discrete units of execution and delivery</quote> attributed to Gary Olliffe, Gartner.
  • Sam Newman; Building Microservices; O’Reilly Media; 2015-02-20; 280 pages; kindle: $25, paper: $46+SHT.
  • James Lewis, Martin Fowler; Microservices; In His Blog (Fowler); 2014-03-10, with revisions.
    Chapters:

    • what microservices are
    • the evolutionary architect
    • how to model services
    • integration
    • splitting the monolith
    • deployment
    • testing
    • monitoring
    • security
    • Conway’s Law and system design,
    • microservices at scale
    • bringing it all together.
  • Argot
    • Service-Oriented Architecture (SOA)
    • Extreme Programming (XP)
    • Strangler Pattern
    • Enterprise Service Bus (ESB)
  • Tenets
    1. Consumption of services separate from the provision of services
    2. Separation of infrastructure management from the delivery of the application capability
    3. Separation
      1. of teams.
      2. of services.
  • Aspects
    Not diagnostic, but some common themes; Fowler & Lewis

    • Componentization via services
    • Organized around business capabilities
    • Products, not projects
      (something about continued team ownership upon completion; devops; “you run what you wrote”)
    • Smart endpoints and dumb pipes
    • Decentralized governance
    • Decentralized datqa management
    • Infrastructure automation
    • Design for failure
    • Evolutionary design
  • Claims
    • There is a difference between SOA and Microservices.
    • There is a difference between Microservices and “an API”
    • There is a difference between ESB and Microservices.
    • Can adopt the theory incrementally; embrace & extend.
  • Concerns
    • Testing, yup, testability and test coverage is a concern.
  • Exemplars
    • Xebia Labs
    • BlueMetal Architects
      • training
      • an advice shop
      • Boston MA
    • Red Hat
    • ThoughtWorks
      • training
      • an advice shop
  • Quoted
    • Andrew Philips, vice president of product management. XebiaLabs.
    • Bob Familiar, practice director of cloud and services, BlueMetal Architects.
    • Pierre Fricke, director of product marketing. Red Hat.
    • Sam Newman, staff, ThoughtWorks; Building Microservices.
    • Gary Olliffe, research director, Gartner.
    • Alistair Farquharson, CTO, Akana (formerly SOA Software).
    • Ian Goldsmith, vice president of product management, Akana (formerly SOA Software).
    • Martin Fowler, chief scientist, ThoughtWorks.
    • James Lewis, principal consultant at ThoughtWorks.

Richardson Maturity Model: Steps Toward the Glory of REST | Martin Fowler

Martin Fowler; Richardson Maturity Model: Steps Toward the Glory of REST; In His Blog; 2010-03-18.

Original Sources

Actualities

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5