- What are Microservices
- Presently a lot of hype!
- Best described as:
- An architectural style
- An alternative to more traditional 'monolithic' applications
- Decomposition of single system into a suite of small services, each running as independent proceses and intercommunicating via open protocols
- With all the benefits / risks this implies.
- Definitions from the Experts
- 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.
2. Fine-grained SOA
- Adrian Cockcroft - Netflix
- Microservices - Working Definition:
- Composing a single application using a suite of small services
- (rather than a single, monolithic application)
2. ... each running as independent processes
- (not merely modules / components within a single executable)
3. ... intercommunicationg via open protocols
- ( Like HTTP/REST, or messaging)
4. Separately written, deployed, scaled and maintained
- ( potentially in different languages)
5. Services encapsulate business capability
- ( rather than language constructs (classes, packages) as primary way to encapsulate.
6. Services encapsulate business capability
- ( rather than language constructs (classes, packages) as primary way to encapsulate.
7. Services are independently replaceable and upgradable
- Microservices are not:
- SOA is about integrating various enterprise applications.
Microservices are mainly about decomposing single applications
2. A silber bullet
- The microservices approach involves drawbacks and risks
3. New! You may be using microservices now and not konw it!
4. New type of persistence / services
- Current Trends
1. Twitter moved from Ruby/Rails monolith to Micorservices.
2. Facebook moved from PHP monolith to Microservices.
3. Netflix moved from Java monolith to Microservices.
- Microservices Example
1. Consider a monolithic shopping cart application:
- Web / mobile interfaces
- Functions for:
i) searching for products
ii) Product catalog
iii) Inventory management
iv) Shopping cart
v) Checkout
vi) Fufillment
- How would this look with microservices?
- Monlolithic Application Example
2. Understanding the Monolithic Architecture
3. New types of client applications
4. New type of persistence / services
- Monolithic Challenges
2. Using Teams / Language Constructs
- Easy to comprehend, but not to digest.
- Must be written in a single language.
2. Modularity based on Program Language
- Using the constructs available in that language (packages, classes, functions, namespaces, frameworks)
- Various storage / service technologies used
=> REBMS, Messaging, eMail, etc.
- Entire app written with single technology stack. Cannot experiment / take advantage of emerging technologies
2. Digestion
- Single developer cannot digest a large codebase
- Single team cannot manage a single large application
=> Amazon's "2 Pizza" rule
3. Deployment as single unit
- Cannot independently deploy single change to single component.
- Changes are "held-hostage" by other changes
- Understanding the monolithic implementation
- Easy to comprehend, but not to digest.
- Must be written in a single language.
2. Modularity based on Program Language
- Using the constructs available in that language (packages, classes, functions, namespaces, frameworks)
- Various storage / service technologies used
=> REBMS, Messaging, eMail, etc.
- Monolithic Advantages
- Easy to comprehend(but not digest)
- Easy to test as a single unit (up to a size limit)
- Easy to deploy as a single unit.
- Easy to manage (up to a size limit)
- Easy to manage changes (up to a point)
- Easy to scale (when care is taken)
- Complexity managed by language constructs.
- Monolithic Drawbacks
- Entire app written with single technology stack. Cannot experiment / take advantage of emerging technologies
2. Digestion
- Single developer cannot digest a large codebase
- Single team cannot manage a single large application
=> Amazon's "2 Pizza" rule
3. Deployment as single unit
- Cannot independently deploy single change to single component.
- Changes are "held-hostage" by other changes
- Enter Microservices architecture
- Compoentization via Services
- NOT language constructs.
- Where services are smaill, independently deployabl applications
- Forces the design of clear interfaces
- Changes scoped to their affected service
- Microserices: Composed using suite of small services
- Services are small, independently deployable applications
- Not (necessarily) a single language / framework
- Modularization not based on language / framework constructs
- Microservices: Communication based on lightweight protocols
- HTTP, TCP, UDP, Messaging, etc.
2. Forces the design of clear interfaces
3. Netflix's Cloud Native Architecture - Communicate via APIs
- NOT Common Database
- Microservices: Services encapsulate business capabilities
- Not based on technology stack
- Vertical slices by business function (i.e. cart, catalog, checkout)
- ...Though technology chunk also practical (email service)
- Suitable for cross-functional teams
- Micoroservices: Services easily managed
- Easy to comprehend, alter, test, version, deploy, manage, overhaul, replace
- Decentralized Governance
- Use the right tool ( language, framework) for the job.
- Services evolve at different speeds, deployed and managed according to different needs.
- Make services be "Tolerant Readers"
- Consumer-0Driven Contracts
- Antithesis of ESB
- Polyglot Persistence
- Freedom to use the best technology for the job
- Very controversial! Many DBAs will not like this!
i) No pan-enterprise data model!
ii) No transactions!
- Microservice Advantages
- Easy to digest each service (difficult to comprehend whole)
- VERY easy to test, deploy, manage, version, and scale single services
- Change cycle decoupled
- Easier to scale staff
- No Language / Framework lock
- Challenges with Microservices
- Complexity has moved out of the application, but into the operations layer
2. Services may be unavailable
- Never needed to worry about this in a monolith!
- Design for failure, circuit breakers
i) "Everything fails all the time" - Werner Vogels, CTO Amazon
- Much more monitoring needed
3. Remote calls more expensive than in-process calls
4. Transactions: Must rely on eventual consistency over ACID
5. Features span multiple services
6. Change management becomes a different challenge
- Need to consider the interaction of services
- Dependency management / versions
7. Refactoring Module Boundaries
- Fallacies of Distributed Computing
- The network is reliable.
- Latency is zero.
- Bandwidth is infinite.
- The network is secure.
- Topology doesn't change.
- Therre is noen administrator.
- Transport cost is zero.
- The network is homogeneous.
- How Do You Break a Monolith into Microservices?
- Primary consideration: business functionality:
- Verb-based (search, checkout, shipping)
- Single Responsibility Principle
=> http://programmer.97things.oreilly.com/wiki/index.php/The_Single_Responsibility_Principle
- Bounded Context
=> http://martinfowler.com/kliki/BoundedContext.html
- How Micro is Micro?
- Size is not the compelling factor
- Small enough to be built and managed by small team
i) Amazon's two pizza raule
- Documentation small enough to read and understand
i) Social Security Act of 1935 - 63 pages
ii) Affordable Care Act of 2010 - 906 pages
- Dozens of secrets, not hundreds.
- Predictable. Easy to experiment with
- Differences with SOA
- SOA addresses integration between systems.
2. SOA relies on orchestration.
- Microservices rely on choreography
3. SOA relies on smart integration technology, dumb services
- Microservices rely on smart services, dum integration technology
- Consider: Linux commands, pipes and filters
- Are Monoliths Always Bad?
- Consider etsy.com
- 150 developers deploy single WAR 60 tiems a day
- Practices: Cl; push button deployment; good monitoring; developers deploy to the site on the first day; VMs per developer; GitHub; Chef; IRC to controll releases; dashboards; no source control branches.
댓글 없음:
댓글 쓰기