Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

Migrate to Microservices Judiciously!

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 27 Publicité

Plus De Contenu Connexe

Diaporamas pour vous (20)

Similaire à Migrate to Microservices Judiciously! (20)

Publicité

Plus récents (20)

Migrate to Microservices Judiciously!

  1. 1. Migrate to Microservices Judiciously! Petru Flueras Software Architect - Visma Software @pflueras Codecamp Timisoara, Oct. 2017
  2. 2. About Me ● C# software engineer ● Software engineer and software architect at Océ Software ○ Huge (monolith) product ~ 1M+ LOC ● Software architect at Visma Software ○ Microservice (AWS) ● Timisoara Java User Group ● @pflueras
  3. 3. Why about Migration? 80% lifecycle of software = maintenance! We have to evolve, modernize, adapt, … software repeatedly to context changes! Recipes for building new software may not apply
  4. 4. Definition Microservices architectural style: … a single application as a suite of small services … communicating with lightweight mechanisms … built around business capabilities (SRP) … independently deployable, upgradeable, replaceable! … minimum centralized management of services Decomposition + Distributed Network calls (HTTP) + API Again decomposition + API CI/CD Decentralized, dump pipes Source: https://martinfowler.com/articles/microservices.html
  5. 5. Why about Microservices? ● Builds, broken builds, integration day(s) ○ Days/weeks to fix blocking point bugs ● We could not simply add new functionality (OutOfMemory)! ○ Single point of failure ● Highly coupled components (no clear interfaces/API) ○ Almost all classes are public ● Difficult to run system tests ○ Only at UI level (not at API level) ● Took ages to deliver business value ○ Continuous delivery ● Risk management
  6. 6. Frontend migration Application decomposition Database migration
  7. 7. Decomposition - Parnas On the Criteria To Be Used in Decomposing Systems into Modules (1972): "We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others." Source: https://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf
  8. 8. Decomposition - UNIX UNIX Time-Sharing System: Forward (Douglas McIlroy - 1978): ● Make each program to do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”. ● Expect the output of every program to become the input to another, yet unknown, program. Don’t clutter the output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input. ● Design and build software, even operating system, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them. Source: https://archive.org/details/bstj57-6-1899
  9. 9. Decomposition - Domain Driven Design ● A way to mark boundaries and relationships between different domain models ● A BOUNDED CONTEXT defines the range of applicability of each model ● CONTEXT MAP gives a global overview of project’s contexts and relationships between them ● Think about what is shared and what is hidden! ● BOUNDED CONTEXTS are good candidates for microservices Source: Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans, 2003)
  10. 10. Decomposition - Transactions ● First decomposition should be around transactional context and not around structure! ● Avoid distributed transactions as much as possible (2PC) ● Local transactions, eventually consistent (CAP) ○ Compensating transaction?
  11. 11. Decomposition - Strangler Pattern
  12. 12. Decomposition - Strangler Pattern #2
  13. 13. UI (Web) Migration/Integration 1. Gateway Aggregator 2. Links 3. Web Components
  14. 14. AWS - Links Example
  15. 15. Database Migration -> Decentralized, Schema Split ● Each service owns its data! ● The hardest part of microservices is data (C. Posta) ● Code is easy, state is hard (E. Yanaga)
  16. 16. Database Migration ● ACID vs BASE ○ Atomic, Consistent, Isolated, Durable ○ Basic Availability, Soft-state, Eventual Consistency ● Extremely difficult to split databases! ○ Even if splitting schemas works, moving data from one schema to splitted schemas is HARD! ● Handle inconsistent situations at code level (CAP)! ○ No foreign keys ○ No transactions
  17. 17. Distributed Systems - Network fallacies 1. The network is reliable. 2. Latency is zero. 3. Bandwidth is infinite. 4. The network is secure. 5. Topology doesn't change. 6. There is one administrator. 7. Transport cost is zero. 8. The network is homogeneous. Source: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
  18. 18. Distributed Systems - Design for failure A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable - L. Lamport, May 1987 ● Netflix ○ Chaos Monkey: … randomly terminates one of the services/instances ○ Simian Army: … consists of services (Monkeys) in the cloud for generating various kinds of failures ○ FIT: … a platform that simplifies creation of failure within our ecosystem with a greater degree of precision for what we fail and who we will impact ● Google ○ DiRT (Disaster Recovery Test): … where systems are taken down with little or no notice to verify that all the failure protection systems work => Monitoring
  19. 19. Distributed Systems - Stability Patterns Avoid (cascading) failures: ● Timeouts ● Circuit breakers ● Bulkheads ● Retry (Exponential back-off, Idempotent!) ● Throttling
  20. 20. Deployment ● Build Pipelines and Continuous Delivery ○ Any commit represents a potential release ● Infrastructure automation!!! ○ Immutable infrastructure ○ Infrastructure as Code ○ Ansible, Terraform At Visma: AWS test env. -> AWS staging env. ->AWS production env.
  21. 21. Team and Organization ● “Microservices” is a organizational change! ● Independent (decentralized) teams who fully own their services: ○ Requirements/Specifications ○ Source code ○ Quality ○ Deployment ○ Technology selection ?! ● Cross functional teams Conway’s Law (1967)
  22. 22. Security ● Service to service Authorization and Authentication (service accounts?) ○ Allow? operations (inside) to an internal service ● Single Sign-On ○ SAML ○ OAuth2, Open ID ○ LDAP ● Client-side certificates ● API Keys Considerable increase of surface attacks!
  23. 23. Logging ● Push logs outside service! ● Correlation IDs ● Log Aggregation (Logstash, Fluentd, Kibana, ...) ● Standardize log message format AWS CloudWatch
  24. 24. Monitoring ● Inside services ○ Memory usage ○ CPU usage ○ SQL queries per minute ● Incoming to service ○ Request rate (# requests per second) ○ Error rate ○ Service latency ● Health checks (service itself + downstream services) ● Implement Alerts! AWS CloudWatch, AppDynamics, OpsGenie
  25. 25. Monolith Microservices Business Agility Low High Team technical knowledge Good Higher Complexity High (coupled dependencies!) Reasonable Scalability Vertical Horizontal API Poor quality, optional? Good if done right, mandatory Frontend (UI) Complexity Medium Higher Deployment Manual? - Entire application CD - by service Logging In one place (good) Distributed Monitoring Not necessary: all or nothing Distributed systems => Necessary! End to end testing Relatively easy Complicated DevOps Complicated Easy
  26. 26. Takeaway Microservices: Small autonomous services which work together, modelled around a business domain Sometimes the necessary step! Add a lot of complexity!

×