microservice architecture

Download Microservice Architecture

Post on 16-Apr-2017

970 views

Category:

Software

1 download

Embed Size (px)

TRANSCRIPT

  • Microservice Architecture

    Viraj Brian Wijesuriya

    vbw@ucsc.cmb.ac.lk

    1

    SCS 4120 - Software Engineering IV

    BACHELOR OF SCIENCE HONOURS IN COMPUTER SCIENCEBACHELOR OF SCIENCE HONOURS IN SOFTWARE ENGINEERING

    All in One Place Lecture NotesDistribution Among Friends Only

    All copyrights belong to their respective owners

  • Definition: In short, the microservice architectural style is an approach to 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. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies [martinfowler.com]

    On the logical level, microservice architectures are defined by a functional system decomposition into manageable and independently

    deployable components

    SEIV Microservices Introduction

    2

    What is Microservices Architecture?

  • 2011: First discussions using this term at a software architecture workshop near Venice

    May 2012: microservices settled as the most appropriate term

    March 2012: Java, the Unix Way at 33rd degree by James Lewis

    September 2012: Service Architecture at Baruco by Fred George

    All along, Adrian Cockroft pioneered this style at Netflix as fine grained SOA

    SEIV Microservices Introduction

    3

    History

    James Lewis

    Fred George

    Adrian Crockcroft

  • Area of consideration

    Web systems

    Built collaboratively by several development teams

    With traffic load that requires horizontal scaling (i.e. load balancing across multiple copies of the system)

    Observation Such systems are often built as monoliths or layered systems

    SEIV Microservices Introduction

    4

    The Problem

  • One build and deployment unit.

    One code base.

    One technology stack (Linux, JVM, Tomcat, Libraries).

    Benefits Simple mental model for developers

    one unit of access for coding, building, and deploying

    Simple scaling model for operations just run multiple copies behind a load balancer

    SEIV Microservices Introduction

    5

    Software Monolith

  • Huge and intimidating code base for developers.

    Development tools get overburdened refactorings take minutes

    builds take hours

    testing in continuous integration takes days

    Scaling is limited Running a copy of the whole system is resource intense

    It doesnt scale with the data volume out of the box

    Deployment frequency is limited Redeploying means halting the whole system

    Redeployments will fail and increase the perceived risk of deployment

    SEIV Microservices Introduction

    6

    Problems with Software Monolith

  • SEIV Microservices Introduction

    7

    Monolith Architecture

    Load Balancer

    Monolithic App

    Account Component

    CatalogComponent

    RecommendationComponent

    Customer ServiceComponent

    Database

    Monolithic applications can be successful, but increasingly people are feeling frustrations with them - especially as more applications are being deployed to the cloud .

  • SEIV Microservices Introduction

    8

    Monolith vs Microservices

  • A layered system decomposes a monolith into layers.

    Usually: presentation, logic, data access.

    At most one technology stack per layer Presentation: Linux, JVM, Tomcat, Libs, EJB client,

    JavaScript

    Logic: Linux, JVM, EJB container, Libs

    Data Access: Linux, JVM, EJB JPA, EJB container, Libs

    Benefits Simple mental model, simple dependencies

    Simple deployment and scaling model

    SEIV Microservices Introduction

    9

    Layered Systems

  • Still huge codebases (one per layer).

    ... with the same impact on development, building, and deployment.

    Scaling works better, but still limited.

    Staff growth is limited: roughly speaking, one team per layer works well Developers become specialists on their layer.

    Communication between teams is biased by layer experience (or lack thereof).

    SEIV Microservices Introduction

    10

    Problems with Layered Systems

  • SEIV Microservices Introduction

    Service Oriented Architecture

    Maximum reuse [GOOD]

    Maximum canonicality [GOOD] 11

    Service Oriented Architecture

  • SEIV Microservices Introduction

    Service Oriented Architecture

    Incremental change [BAD]

    Operationally complex [BAD] 12

    Problems with Service Oriented Architecture

  • SEIV Microservices Introduction

    13

    Lot of Services!!!

  • Applications and teams need to grow beyond the limits imposed by monoliths and layered systems, and they do in an uncontrolled way.

    Large companies end up with landscapes of layered systems that often interoperate in undocumented ways.

    These landscapes then often break in unexpected ways.

    How can a company grow and still have a working IT architecture and vision? Observing and documenting successful companies (e.g. Amazon, Netflix) lead

    to the definition of microservice architecture principles.

    SEIV Microservices Introduction

    14

    Growing Beyond Limits

  • SEIV Microservices Introduction

    15

    Need of an Architectural Pattern

  • Yesterdays best practice is tomorrows

    anti-pattern.

    We inadvertently build architectures to solve outdated problems.

    SEIV Microservices Introduction

    16

    Problem with Architectural Patterns

  • organizations which design systems ... are constrained to produce designs which

    are copies of the communication structures of these organizations

    Melvin Conway

    SEIV Microservices Introduction

    17

    Conways Law

  • SEIV Microservices Introduction

    18

    Valued Business Drivers

    Better

    Resilient

    Technology choice

    Cheaper

    Test effort

    Cost of maintaining

    Faster

    Change

    Deployment

    Execution

  • SEIV Microservices Introduction

    19

    Trends in Software Development

    Platform as a Service

    Autonomous teams

    Continuous Delivery

    Agile Organization

    Reactive manifesto

  • SEIV Microservices Introduction

    20

    Availability

    A single missing ; brought down the Netflix website for many hours (~2008)

  • The term micro refers to the sizing: a microservice must be manageable by a single development team (5-9 developers).

    Functional system decomposition means vertical slicing (in contrast to horizontal slicing through layers).

    Independent deployability implies no shared state and inter-process communication (often via HTTP RESTish interfaces).

    Microservice is the first architectural style developed for post-Continuous Delivery.

    SEIV Microservices Introduction

    21

    What is Microservices Architecture?

  • SEIV Microservices Introduction

    22

    Other definitions

    Small and focused on doing one thing well

    Autonomous

    Loosely coupled service oriented architecture with bounded contextsAdrian Cockcroft (Netflix)

    SOA done rightAnonymous

    services are independently deployable and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages.Martin Fowler (Thoughtworks)

  • Each microservice is functionally complete with Resource representation Data management

    Each microservice handles one resource (or verb), e.g. Clients, Shop Items, Carts, Checkout

    Microservices are fun-sized services, as in still fun to develop and deploy

    Independent Deployability is key

    It enables separation and independent evolution of code base technology stacks scaling and features, too

    SEIV Microservices Introduction

    23

    Points about Microservices Architecture

  • Each service has its own software repository.

    Codebase is maintainable for developers it fits into their brain.

    Tools work fast building, testing, refactoring code takes seconds.

    Service startup only takes seconds.

    No accidental cross-dependencies between code bases.

    SEIV Microservices Introduction

    24

    Independent Codebase

  • Each service is implemented on its own technology stacks.

    The technology stack can be selected to fit the task best.

    Teams can also experiment with new technologies within a single microservice.

    No system-wide standardized technology stack also means No struggle to get your technology introduced to the canon No piggy-pack dependencies to unnecessary technologies or libraries Its only your own dependency hell you need to struggle with

    Selected technology stacks are often very lightweight A microservice is often just a single process that is started via

    command line, and not code and configuration that is deployed to a container.

    SEIV Microservices Introduction

    25

    Independent Technology Stack

  • Each microservice can be scaled independently

    Identified bottlenecks can be addressed directly

    Data sharding can be applied to microservices as needed

    Parts of the system that do not represent bottlenecks canremain simple and un-scaled

    Microservices can be extend