Microservices Architecture and Apps for Libraries PDF
Document Details
Uploaded by UnaffectedCadmium
Tags
Summary
This presentation discusses microservices architecture, including its benefits, use cases, and comparison with monolithic applications. The document explores the concept of microservices, their internal architecture, and their implementation within various business contexts. It also covers related topics like containerization, API gateways, and DevOps practices.
Full Transcript
Microservices Architecture and Apps for Libraries Microservices Current prevailing approach for large scale globally distributed applications Common choice for new development projects for business software Many organizations are also evolving existing monolithic applications to Micr...
Microservices Architecture and Apps for Libraries Microservices Current prevailing approach for large scale globally distributed applications Common choice for new development projects for business software Many organizations are also evolving existing monolithic applications to Microservices What are microservices? A model of technical architecture Small independent functional applications Each microservices built on appropriate technical components A software development pattern Decentralization of technical components Distributed programming / DevOps teams Responsibility to deploy, operate, and maintain services From apps to systems Many microservices are assembled to create a complex business application Separate independent components Brought together via middleware or API gateway Software Development Styles Monolithic Applications Codebase of application deployed as a single bundle of executables and libraries on a unified platform Microservices Architecture Multiple independent software components orchestrated to form a unified application Common infrastructure: User interface toolkit API Gateway Persistence layer An internal architecture Not necessarily apparent to users whether the application is based on microservices Needed for fast performance, high availability, extreme transaction loads Who uses Microservices UBER NETFLIX AMAZON EBAY TWITTER PAYPAL Alternative approach: Monolithic software Consolidated executable application Plus supporting libraries and modules Can be massively distributed across computing clusters Entire application based on a uniform technology stack: Server platform Operating system Programming language Database layer Enhancements mean recompilation of entire application Monolithic Application Conceptual Model Scripts/ User Third Party Systems Interfaces API endpoints Web service Presentation Layer Application software Business Logic Run time libraries Database Engine Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Services-oriented Architecture Longstanding approach to business application development Monolithic application based on reusable services Complex applications rely on an enterprise service bus to manage communications among services, database connectivity, event triggers, etc Single uniform technology platform Code assembled into a monolithic package Scales to very high performance through clustered deployment Services are closely interrelated throughout the application Developers must understand all aspects of the SOA application developme Single technology stack nt issues Small changes require full recompilation Complex applications can hit hardware or OS limits Operations separated from Development Monolithic Application: Enterprise SOA Model Scripts/ User Third Party Systems Interfaces API endpoints Web service Presentation Layer Application software Business Logic Reusable } Composable Services Enterprise Service Bus Database Engine Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Building a microservice Small unit of functionality Complete and independent technology stack Separate data stores Synchronization with other services as needed through persistence layers Invoked through API Request / Response Usually: REST, HTTP, JSON Self-contained components Inner workings not exposed externally Developers have free reign to select tech components Microservice conceptual model Request Response REST / HTTPS Web service Service components Microservice Application software Run time libraries Data Store Assembling an application Each microservice performs a small limited task Not intended to be standalone applications Surrounded by specialized infrastructure Manage communications Orchestrate services into complex chains of tasks Load balancing API Gateway User Interface layer Externally exposed APIs Multiple instances of any microservice launched as needed Microservices-based Application Scripts/ User Third Party Systems Interfaces API endpoints Presentation Layer / UI Toolkit API Gateway Web service Service compone Web Web nts service Web service service Service Service Web compone Service compone service Microservic nts compone nts e Service nts compone Web nts Web Web service Applicati service Microservic service Microservic Web on e Microservic Web e service Service Service Service e service compone software compone compone Service Microservic Service nts nts Applicati nts Applicati compone e Applicati compone nts Run time on nts on libraries software on software Applicati Microservic Microservic Microservic software on Microservic e e Run time e Microservic Run time software libraries Run time libraries e libraries e Applicati Applicati Applicati Data Store Applicati on Run time on on Applicati libraries on software software software on software software Run time Run time Data Store Run time Data Store libraries libraries libraries Data Store Run time libraries Run time libraries Data Store Data Store Data Store Data Store Data Store Data Store Persistence / System Layer Beyond Virtual Machines to Containers Virtual machines are a common technology for optimizing use of computing hardware Most applications use a small portion of computing and storage capacity VM managers enable multiple instances of operating environments to co-exist on each physical server Virtual Machine Environment Multiple Virtual Machines can VM-1 VM-2 VM-3 VM-4 share a single physical server VMs allocated via a Virtual Apps Apps Apps Apps Machine Monitor or Hypervisor Code librari es Code librari es Code librari es Code librari es Each VM contains its own operating system, code Gues t OS Gues t OS Gues t OS Gues t OS libraries, applications, web services, and other Virtual Machine Monitor components Host operating system Each VM independent: can host any OS, libraries, apps Server Hardware Containers Server hardware provides OS Kernel to any container Code libraries and binaries, memory, disk m i m i m i m i m i m i m i m i storage, and other resources residing on c c c c c c c c the server can be provisioned to any r r r r r r r r container o s o s o s o s o s o s o s o s Containers can be rapidly deployed based e e e e e e e e on pre-defined configuration sets r r r r r r r r v v v v v v v v Containers require fewer resources: do not i i i i i i i i run an entire copy of OS and support c c c c c c c c e e e e e e e e services Binaries / Libraries set A Bins / Libs B Containers can differ or replicate High demand microservices may require Container Engine (eg: Docker) many instances Host operating system Containers share resources but are designed to be independent Server Hardware API Gateway Requests to microservices usually not made directly from external agents Need a layer to manage access to Microservices to enable flexible deployment Multiple microservices may be required to perform a complex task Usually many instances of each microservice API Gateways provide a single entry point for all requests into the application. Developers do not need to know physical address of each service (nothing should be hardwired) Manage authentication, protocol conversions, communications, routing, load balancing DevOps Merges development with operations A single team takes responsibility for development, deployment, operations, and maintenance of a microservice Make independent technology decisions Programming language Databases (probably limited to contain technical overhead for the organization) No need to understand all aspects of the application Contracts Any given microservice will not necessarily be aware of all the ways in which it is consumed Microservices must be persistent to avoid failures in the broader application / ecosystem Agreement to provide specific requests/responses Versioning is an essential characteristic Any deprecation must be (technically) negotiated and propagated through the microservice ecosystem Functionality cannot be withdrawn until it is no longer required Docker Leading technical environment for the management of containers Supported in most infrastructure environments Amazon Web Services Containers Allocate computing resources in even smaller increments than Virtual Machines Share low-level components Self-contained pre-configured operating environment Container management environments provide fast and easy approach to deploy microservices or other computing components Used in all types of computing environments, but especially well suited to microservices. Container orchestration In a complex environment tools are needed to manage the deployment of containers Components need to be allocated and deallocated dynamically based on load and demand Examples: Docker Swarm Kubernentes (developed by Google) Apache Mesos Benefits of Microservices Rapid development Quick path to MVP (minimal viable product) Distributed teams Modularity Scalability Evolving from the Monolith to Microservices Many organizations eventually press the limits of applications built with SOA monolithic style Gradually offload selected tasks to microservices Full-fledged migration to microservices can be long and expensive