Mdca Introduction
Mdca Introduction
Summary
◻ Get an introduction to the microservices architecture and how it differs
from the monolithic style of software development. Microservices have
emerged as the preferred approach for complex business applications
deployed at massive scale. This architecture has increasingly been
incorporated into new applications for libraries. Breeding provides
perspective on how this style of software development and
deployment will increasingly enter the library sphere.
Fundamental technology shift
◻ Mainframe computing
◻ Client/Server
◻ Cloud Computing
http://www.flickr.com/photos/carrick/61952845/
http://soacloudcomputing.blogspot.com/2008/10/cloud-computing.html
http://www.javaworld.com/javaworld/jw-10-2001/jw-1019-jxta.html
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
◻ Decentralized architecture does not imply fragmented user
experience
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
SOA development issues
◻ Services are closely interrelated throughout the application
◻ Developers must understand all aspects of the application
◻ Single technology stack
◻ Small changes require full recompilation
◻ Complex applications can hit hardware or OS limits
◻ Centralized development pattern
◻ Operations separated from Development
Monolithic Application: Enterprise SOA Model
Scripts/
User Third Party Systems
Interfaces API endpoints
Web service
Presentation Layer
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
API Gateway
Web service
Service
components
Web service Web service
Web service
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
libraries
Code
libraries
Code
libraries
Code
libraries
◻ Each VM contains its own
operating system, code
Guest
OS
Guest
OS
Guest
OS
Guest
OS libraries, applications, web
services, and other components
Virtual Machine Monitor
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 m m m m m m m storage, and other resources residing on the
i i i i i i i i server can be provisioned to any container
c c c c c c c c
r r r r r r r r ◻ Containers can be rapidly deployed based
o o o o o o o o
s s s s s s s s on pre-defined configuration sets
e e e e e e e e
r r r r r r r r ◻ Containers require fewer resources: do not
v v v v v v v v run an entire copy of OS and support
i i i i i i i i
c c c c c c c c
services
e e e e e e e e
◻ Containers can differ or replicate
Binaries / Libraries set A Bins / Libs B
High demand microservices may require many
Container Engine (eg: Docker) instances
Host operating system ◻ Containers share resources but are designed
to be rigidly independent
◻ Container engine ensures against resource
Server Hardware collisions
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
State of the Art
◻ Business environments based on monolithic style remain viable
◻ Trend to base new large-scale web applications on microservices
◻ Well accepted, modern approach among tech giants
◻ A technical style that supports a level of scale not previously possible
◻ Beginning to gain acceptance for mid-scale development projects.