What are Microservices

• What are Microservices

1. Presently a lot of hype!

1. Best described as:
2. An architectural style
3. An alternative to more traditional 'monolithic' applications
4. Decomposition of single system into a suite of small services, each running as independent proceses and intercommunicating via open protocols

       - With all the benefits / risks this implies.

• Definitions from the Experts

1. Developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API.                 

      - Martin Fowler    

    

     2. Fine-grained SOA

      - Adrian Cockcroft - Netflix

• Microservices - Working Definition:

1. Composing a single application using a suite of small services

       - (rather than a single, monolithic application)

    2. ... each running as independent processes

       - (not merely modules / components within a single executable)

    3. ... intercommunicationg via open protocols

       - ( Like HTTP/REST, or messaging)

    4.  Separately written, deployed, scaled and maintained

       - ( potentially in different languages)

    5.  Services encapsulate business capability

      - ( rather than language constructs (classes, packages) as primary way to encapsulate.

    6. Services encapsulate business capability

      - ( rather than language constructs (classes, packages) as primary way to encapsulate.

    7. Services are independently replaceable and upgradable

• Microservices are not:

    1. The same as SOA

       - SOA is about integrating various enterprise applications.

         Microservices are mainly about decomposing single applications

    2. A silber bullet

       - The microservices approach involves drawbacks and risks

    3. New! You may be using microservices now and not konw it!

• Current Trends

    1. Twitter moved from Ruby/Rails monolith to Micorservices.

    2. Facebook moved from PHP monolith to Microservices.

    3. Netflix moved from Java monolith to Microservices.

• Microservices Example

    1. Consider a monolithic shopping cart application:

      - Web / mobile interfaces

      - Functions for:

          i) searching for products

          ii) Product catalog

          iii) Inventory management

          iv) Shopping cart

          v) Checkout

          vi) Fufillment

       - How would this look with microservices?

• Monlolithic Application Example

    1. Monolithic shopping cart application:

    2. Understanding the Monolithic Architecture

 

   3. New types of client applications

   4. New type of persistence / services

• Monolithic Challenges

    1. Single Codebase, Deployment, Versioning, Team Size
 

           

     2. Using Teams / Language Constructs

• Understanding the monolithic implementation

       1. Single application executable
          - Easy to comprehend, but not to digest.
          - Must be written in a single language.
       2. Modularity based on Program Language
          - Using the constructs available in that language (packages, classes, functions,                namespaces, frameworks)
         - Various storage / service technologies used
           => REBMS, Messaging, eMail, etc.

• Monolithic Advantages

1. Easy to comprehend(but not digest)
2. Easy to test as a single unit (up to a size limit)
3. Easy to deploy as a single unit.
4. Easy to manage (up to a size limit)
5. Easy to manage changes (up to a point)
6. Easy to scale (when care is taken)
7. Complexity managed by language constructs.

• Monolithic Drawbacks

   1. Language / Framework Lock
      - Entire app written with single technology stack. Cannot experiment / take                    advantage of emerging technologies
   2. Digestion
      - Single developer cannot digest a large codebase
      - Single team cannot manage a single large application   
        => Amazon's "2 Pizza" rule
   3. Deployment as single unit
     - Cannot independently deploy single change to single component.
     - Changes are "held-hostage" by other changes     

• Enter Microservices architecture

• Compoentization via Services

1. NOT language constructs.
2. Where services are smaill, independently deployabl applications
3. Forces the design of clear interfaces
4. Changes scoped to their affected service

• Microserices: Composed using suite of small services

1. Services are small, independently deployable applications

      - Not a single codebase
      - Not (necessarily) a single language / framework
      - Modularization not based on language / framework constructs

• Microservices: Communication based on lightweight protocols

1. HTTP, TCP, UDP, Messaging, etc.

      - Payloads: JSON, BSON, XML, Protocol Buffers, etc.
    2. Forces the design of clear interfaces
    3. Netflix's Cloud Native Architecture - Communicate via APIs
      - NOT Common Database

• Microservices: Services encapsulate business capabilities

1. Not based on technology stack
2. Vertical slices by business function (i.e. cart, catalog, checkout)
3. ...Though technology chunk also practical (email service)
4. Suitable for cross-functional teams

• Micoroservices: Services easily managed

1. Easy to comprehend, alter, test, version, deploy, manage, overhaul, replace

       - By small, cross-functional teams (or even individuals)

• Decentralized Governance

1. Use the right tool ( language, framework) for the job.
2. Services evolve at different speeds, deployed and managed according to different needs.
3. Make services be "Tolerant Readers"
4. Consumer-0Driven Contracts
5. Antithesis of ESB

      - Services are not Orchestrated, but Choreographed

• Polyglot Persistence

1. Freedom to use the best technology for the job

      - Don't assume single RDBMS is always best
      - Very controversial! Many DBAs will not like this!
         i) No pan-enterprise data model!
         ii) No transactions!

• Microservice Advantages

1. Easy to digest each service (difficult to comprehend whole)
2. VERY easy to test, deploy, manage, version, and scale single services
3. Change cycle decoupled
4. Easier to scale staff
5. No Language / Framework lock

• Challenges with Microservices

1. Complexity has moved out of the application, but into the operations layer

       - Fallacies of Distributed Computing

    2. Services may be unavailable
       - Never needed to worry about this in a monolith!
       - Design for failure, circuit breakers
        i) "Everything fails all the time" - Werner Vogels, CTO Amazon
       - Much more monitoring needed
 
     3. Remote calls more expensive than in-process calls

     4. Transactions: Must rely on eventual consistency over ACID

     5. Features span multiple services

     6. Change management becomes a different challenge
        - Need to consider the interaction of services
        - Dependency management / versions
 
      7. Refactoring Module Boundaries

• Fallacies of Distributed Computing

1. The network is reliable.
2. Latency is zero.
3. Bandwidth is infinite.
4. The network is secure.
5. Topology doesn't change.
6. Therre is noen administrator.
7. Transport cost is zero.
8. The network is homogeneous.

• How Do You Break a Monolith into Microservices?

1. Primary consideration: business functionality:

       - Noun-based (catalog, cart, customer)
       - Verb-based (search, checkout, shipping)
       - Single Responsibility Principle
         => http://programmer.97things.oreilly.com/wiki/index.php/The_Single_Responsibility_Principle
       - Bounded Context
         => http://martinfowler.com/kliki/BoundedContext.html

• How Micro is Micro?

1. Size  is not the compelling factor

      - Smaill enough for an individual developer to digest
      - Small enough to be built and managed by small team
        i) Amazon's two pizza raule
      - Documentation small enough to read and understand
        i) Social Security Act of 1935 - 63 pages
        ii) Affordable Care Act of 2010 - 906 pages

       - Dozens of secrets, not hundreds.
       - Predictable. Easy to experiment with

• Differences with SOA

1. SOA addresses integration between systems.

       - Microservices address individual applications
    2. SOA relies on orchestration.
       - Microservices rely on choreography

    3. SOA relies on smart integration technology, dumb services
       - Microservices rely on smart services, dum integration technology
       - Consider: Linux commands, pipes and filters

 

• Are Monoliths Always Bad?

1. Consider etsy.com

       - As of Rebruary 2013: 1.49 billion page views, 4,215,169 items sold, $94.7 million             of goods sold, 22+ million members
       - 150 developers deploy single WAR 60 tiems a day
       - Practices: Cl; push button deployment; good monitoring; developers deploy to             the site on the first day; VMs per developer; GitHub; Chef; IRC to controll                     releases; dashboards; no source control branches.