Microservices Architecture

Microservices Architecture

• 1.
  Microservices Migrating cloud-native applicationsfrom monolithic to microservices architectural pattern Rishabh Karajgi Computer Science and Engineering, NIT Warangal
• 3.
  Underlying principle “functional systemdecomposition into manageable and independently deployable components” Microservices usually managed by a single development team (5-7 members). • 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 REST-ish interfaces)
• 5.
  More specifically Each microserviceis functionally complete with Resource allocation Database consistency Each microservice handles one resource (or verb), e.g. Clients Sale items Checkouts
• 6.
  Independant deployability It enablesseparation and independent evolution of code base technology stacks scaling and features, too 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
• 7.
  Independent technology stacks Independantservices can have independant technology stacks The technology stack is selected as a best-fit to the task Teams can also experiment with new technologies within a single microservice No system-wide standardized technology stack also means No piggy-pack dependencies to unnecessary technologies or libraries 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
• 8.
  Independent Scaling Each microservicecan 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 can remain simple and un- scaled
• 9.
  Stable Interfaces –standardized communication Communication between microservices is often standardized using HTTP(S) REST JSON – simple data representation format REST and JSON are convenient because they simplify interface evolution (more on this later)
• 10.
  Microservices Architecture
• 11.
  Characteristics of MicroservicesArchitecture Componentization via services Organized around business capabilties Products not Projects Smart endpoints and dump pipes Decentralized Governance Decentralized Data Management Infrastructure Automation Design for Failure
• 12.
  Componentization via services
• 13.
  Organized around businesscapabilities
• 14.
  Smart endpoints anddumb pipes Rather than stressing importance on the communication mechanism itself (for eg. Enterprise Service Bus, which produces sophisticated facilties for message routing, choreography, transformation and applying business rules) Microservices adopt a dumb pipe (ie. only routing mechanism) and request-response mechanisms using REST and HTTP.
• 15.
  Decentralized Governance Principle: focuson standardizing the relevant parts, and leverage battle-tested standards and infrastructure Treats differently What needs to be standardized Communication protocol (HTTP) Message format (JSON) What should be standardized Communication patterns (REST) What doesn‘t need to be standardized
• 16.
  Infrastructure Automation Having todeploy significant number of services forces operations to automate the infrastructure for Deployment (Continuous Delivery) Monitoring (Automated failure detection) Managing (Automated failure recovery) Consider that: Amazon AWS is primarily an internal service Netflix uses Chaos Monkey to further enforce
• 18.
  Service Oriented Architecture Functionaldecomposition is also adopted by SOA: Not usually required to be self contained within Data and UI. It is often thought as decomposition within tiers, and introducing another tier – the service orchestration tier In comparison to microservices Focused on enabling business-level programming through business processing engines and languages. Does not focus on independent deployment units and its consequences Microservices can be seen as the “good-parts” of SOA.
• 20.
  Conclusion Should we simplyadopt it? No. But they are a possible evolution for web systems due to rise in Cloud Computing. Community often complains about existing challenges, prerequisites and difficulties. Just the new fad? Maybe/maybe not. Microservices is a new term, and an evolution of long-known architectural principles applied in a specific way to a specific type of systems. Dev-ops-heavy, and less managerial. Due to open source tech landscape, there is faster growth and development.
• 21.
  That’s all folks!