Weitere ähnliche Inhalte Ähnlich wie Microservices (20) Kürzlich hochgeladen (20) Microservices2. Copyright © 2015 AxEdge Consulting All rights reserved. 2
Microservices : Introduction
3. 3Copyright © 2015 AxEdge Consulting All rights reserved.
The Monolithic
Typical enterprise application
No restriction on size
Large codebase
Longer development times
Challenging deployment
Inaccessible features
Fixed technology stack
High levels of coupling
Between modules
Between services
Failure could affect whole
system
Scaling requires duplication of
the whole
Single service on server
Minor change could result in
complete rebuild
Easy to replicate environment
Microservices : The Monolithic | Why Now? | Benefits
Why Now?
Need to respond to change
quickly
Need for reliability
Business domain-driven design
Automated test tools
Release and deployment tools
On-demand hosting technology
On-line cloud services
Need to embrace new
technology
Asynchronous communication
technology
Simpler server side and client
side technology
Benefits
Shorter development times
Reliable and faster deployment
Enables frequent updates
Decouple the changeable parts
Security
Increased uptime
Fast issue resolution
Highly scalable and better
performance
Better ownership and knowledge
Right technology
Enables distributed teams
4. Copyright © 2015 AxEdge Consulting All rights reserved. 4
Small Autonomous services
that work together
Microservices : In Action
5. Copyright © 2015 AxEdge Consulting All rights reserved. 5
Microservices : In Action
6. 6Copyright © 2015 AxEdge Consulting All rights reserved.
The Twelve Factors
1. Codebase
One codebase tracked in revision control, many deploys
2. Dependencies
Explicitly declare and isolate dependencies
3. Configuration
Store configuration in the environment
4. Backing Services
Treat backing services as attached resources
5. Build, release, run
Strictly separate build and run stages
6. Processes
Execute the app as one or more stateless processes
7. Port binding
Execute services via port binding
8. Concurrency
Scale out via process model
9. Disposability
Maximize robustness with fast startup and graceful shutdown
10. Dev/Prod purity
Keep development, staging, and production environments as similar as possible
11. Logs
Treat logs as event streams
12. Admin processes
Run admin/management tasks as one-off processes
http://www.12factor.net/
In the modern era, software is commonly
delivered as a service: called web apps, or
software-as-a-service.
The twelve-factor app is a methodology for
building software-as-a-service apps that:
• Use declarative formats for setup automation,
to minimize time and cost for new developers
joining the project;
• Have a clean contract with the underlying
operating system, offering maximum portability
between execution environments;
• Are suitable for deployment on modern cloud
platforms, obviating the need for servers and
systems administration;
• Minimize divergence between development
and production, enabling continuous
deployment for maximum agility;
• And can scale up without significant changes to
tooling, architecture, or development practices.
Twelve-factor app
7. 7Copyright © 2015 AxEdge Consulting All rights reserved.
Enable Scalable
business
More customers/transactions
Self-service for customers
Support entry into
new markets
Flexible operational processes
New products and operational
processes
Support innovation
in existing markets
Flexible operational processes
New products and operational
processes
Strategic Goals
Reduce inertia
Make choices that favour rapid
feedback and change, with reduced
dependencies across teams.
Eliminate accidental
complexity
Aggressively retire and replace
unnecessarily complex processes,
systems, and integrations so that we
can focus on the essential complexity.
Consistent interfaces
and data flows
Eliminate duplication of data and
create clear systems of record, with
consistent integration interfaces.
No silver bullets
Off the shelf solutions deliver early
value but create inertia and accidental
complexity.
Standard REST/HTTP
Encapsulate legacy
Eliminate integration
databases
Consolidate and
cleanse data
Published integration
model
Small independent
Services
Continuous
deployment
Minimal customization
of COTS/SAAS
Architectural
Principles
Design and Delivery
Practices
Microservices : What, How, Why
8. 8Copyright © 2015 AxEdge Consulting All rights reserved.
Modelled
Around
Business
Domain
Culture Of
Automation
Hide
Implementation
Details
Decentralize
All The
Things
Highly
Observable
Isolate
Failure
Deploy
Independently
Microservices : Design Principles
9. 9Copyright © 2015 AxEdge Consulting All rights reserved.
Modelled
Around
Business
Domain
Microservices : Business Domain Driven
• Service represents business function
• Scope of service
• Bounded context from DDD
• Identify boundariesseams
• Shuffle code if required
Group related code into a service
Aim for high cohesion
• Responsive to business change
10. 10Copyright © 2015 AxEdge Consulting All rights reserved.
Microservices : Automation
Culture Of
Automation
Infrastructure Automation
Continuous Delivery
Automated Testing
Tools to reduce testing
Manual regression testing
Time taken on testing integration
Environment setup for testing
Tools to provide quick feedback
Integration feedback on check in
Continuous Integration
Tools to provide quick deployment
Pipeline to deployment
Deployment ready status
Automated deployment
Reliable deployment
Continuous Deployment
Why
Distributed system
Multiple instances of services
Manual integration testing too
time consuming
Manual deployment time
consuming and unreliable
11. 11Copyright © 2015 AxEdge Consulting All rights reserved.
Microservices : Decentralization
Decentralize All
The Things
Giving people as much freedom as possible to do the job at hand
SELF-SERVICE
SHARED GOVERNANCE
OWNER-OPERATOR
INTERNAL OPEN SOURCE
DUMB-PIPES, SMART ENDPOINTS
12. 12Copyright © 2015 AxEdge Consulting All rights reserved.
Microservices : Deploy ability
Deploy
Independently
ONE SERVICE PER-HOST
CONSUMER-DRIVEN CONTRACTS
CO-EXIST ENDPOINTS
PACT
13. 13Copyright © 2015 AxEdge Consulting All rights reserved.
Microservices :
Hide
Implementation
Details
HIDE YOUR DATABASE
14. 14Copyright © 2015 AxEdge Consulting All rights reserved.
Microservices :
HIDE YOUR DATABASE
Isolate Failure
Embrace failure
Another service
Specific connection
Third-party system
Degrade functionality
Default functionality
Multiple instances
Register on startup
Deregister on failure
Types of failure
ExceptionsErrors
Delays
Unavailability
Network issues
Delay
Unavailability
Validate input
Service to service
Client to service
15. 15Copyright © 2015 AxEdge Consulting All rights reserved.
Microservices :
Highly
Observable
System Health
Status
Logs
Errors
Centralized monitoring
Centralized logging
Why
Distributed transactions
Quick problem solving
Quick deployment requires feedback
Data used for capacity planning
Data used for scaling
Whats actually used
Monitor business data
AGGREGATION
LOGS
STATS
CORRELATION IDS
http://blog.ness-ses.com/microservices-
architecture-and-design-principles