![Moving to Microservice
• Data store
• Each MS should have its own database
• Example:
• Product: relational database
• Order: NoSQL
• User: LDAP
• Problem ?!
• If user changes his address it should be replicated in the entity found in order sub-domain.
• In MS world there is no distributed transaction [ in same transaction you update more than 1 table in
different databases] due to performance issures
• Therefore, data is not immediately consistent.](https://image.slidesharecdn.com/microservices-190516110355/85/Introduction-to-Microservices-13-320.jpg)
Introduction to Microservices
- 2. Software life cycle 2 16 May 2019 Gathering requirements. The goal of analysis is to determine where the problem is, in an attempt to fix the system. Plan sprint to meet requirements in given time. Operations are described in detail including business rules, process diagrams, etc. The output of this stage will describe the new system as a collection of modules or subsystems. The real code is written here. All the pieces are brought together into a special testing environment, then checked for errors, bugs, and interoperability. Putting a release into production Doing health checks Checking time for requests and responses … Plan & design Development Testing Analysis Release Monitor
- 3. What is a Microservice? • “The microservice architectural style is an approach to develop single application as a suite of small services, each running in its own process & communication with light weight mechanism.” . James Lewis & Martin Fowler. • “Microservices are SMALL & AUTONOMUS services that work together”. Book - Building Microservices, Sam Neuman. • There is no specific technology used to build MS. • Some Principles and architectural patterns are used to build MS. 3 16 May 2019
- 4. Microservice overview Micro • Big/small, who decide ? • Is it the number of lines in code ? • Is it the number of developers in team? • There is no universal measure . One microservice should do ONE THING & do it well. • It is micro because of the scope of functionality not line of code. • Subdomains should be identified to know the scope of functionality. • Bounded context • Should be built around business capability
- 5. Microservice overview Service • It is an independently deployed component for bounded context. • Interoperability. • Uses message based communication. • Independent from technologies. • Simply it is SOA
- 6. Monolithic application Simply a monolithic application consists of • Model • Single database • User interface • APIs can be exposed for third parties • You can have more than one instance running behind load balancer
- 7. Monolithic application Front end user Address Order Invoice Product Category Supplier
- 8. Monolithic application Pros • Simple to build • Simple to test • Simple to deploy • Simple to scale • Multiple instances • Simple to develop • Limited to one language. Cons • The bigger the app, the bigger the team. • New team members productivity is low. • Code harder to understand & modify. • Not updated with new technologies. • Startup of app will take long time. • Scale for bad reasons • Need more CPU for calculating invoices, you will scale the whole app.
- 9. Monolithic application • Taking monolithic app and dividing it to smaller services will lead to: • Concentrating on something smaller • Software life cycle is still the same, but moves faster. • Smaller teams • Small services will live side by side.
- 10. Moving to Microservice • Microservice should be “Domain Driven Design”. • Taking the monolith application and moving to domain driven design • Domain: • E-commerce • Sub-domains: • User: Auth, profile, address,… • Order: invoices, discount,… • Product: Prodcuts, suppliers,… • Dependencies: • Sub domians should be totally independent. If you find any dependencies duplicating entities is required.
- 11. Moving to Microservice Front end user Address Order Invoice Product Category Supplier user Product
- 12. Moving to Microservice • Organization • Teams will be divided by subdomain not domain • Right sized team for each subdomain • Each team will be solely responsible for their final product • Each team should be independent, but the communication between them should be handled by management • Each team should have their own repo.
- 13. Moving to Microservice • Data store • Each MS should have its own database • Example: • Product: relational database • Order: NoSQL • User: LDAP • Problem ?! • If user changes his address it should be replicated in the entity found in order sub-domain. • In MS world there is no distributed transaction [ in same transaction you update more than 1 table in different databases] due to performance issures • Therefore, data is not immediately consistent.
- 14. Moving to Microservice • Data store • Solution for data sync is using change data capture or event sourcing pattern. • Both are ways of modeling data, especially at scale, using a combination of a mutable database. • Service publishes event when data changes and other services will consume the event and update data. • Kafka can be used for keeping data in sync • UI • Composition pattern can be used to be consistent • Client side • Server side
- 15. Moving to Microservice • Services • Communication • Remote Procedure Invocation/call (RPC): User Order Product • Request / reply principle (purchase request product price) • Can be sync/async • REST or SOAP can be used
- 16. Moving to Microservice • Services • Communication • Messaging: • Message or events • On broker or channel • MS can publish an event & the MS who is in need can subscribe to broker & receive the message at a later time • Kafka can be used also. User ProductOrder Broker
- 17. Moving to Microservice • Services • Communication • Using any of the two methods you need protocol format exchange • Text (JSON, XML,…) readable and easy to implement • Binary (gRPC) more compact • MSs need contracts to know the APIs of other MSs. • Example: WSDLs & Swagger files.
- 18. Moving to Microservice • Distributed services • MSs are deployed where there network locations are changed dynamically. QUESTION? How can MSs communicate with each other when there locations are changed dynamically ? ANSWER Service registery
- 19. Moving to Microservice • Distributed services • Service registry • It is a phonebook of services • MSs should register them selves on startup and at shutdown • You can lookup by their logical names • Product: 127.0.0.1:8080 • Eureca can be used for this
- 20. Moving to Microservice • Distributed services • Best way for FE to call MS is putting an API gateway Front end user Order Product API Gateway
- 21. Moving to Microservice • Distributed services • Best way for FE to call MS is putting an API gateway • Unified interface • Can control the cross cutting functionalities (Authentication, Authorization, register, …) • API translation
- 22. Moving to Microservice • Security • Use identity and access mangement for authentication and authorization. • Once signed in Access-token can be used to move from one MS to another • Scalability • You can scale one MS or more. • Scaling can be: • Vertical: • adding more power to existing machine (more CPU/RAM …) • Horizontal: • replicate more machines. i.e. several instances • Client load balancing will choose from registry. (using round robin for example) Product1: x.y.z:80 Product2: a.b.c:81
- 23. Moving to Microservice • Availability • Minutes is up and operational • We have in this architecture some single point of failures • Broker • API Gateway • Registry • ALL POF should be scaled horizontally (multiple instances) & clustered to be in sync
- 24. Moving to Microservice • Monitoring • Should be centralized • Use log aggregation (Log stash can be used) • Should be visual in dashboard (Splunk/ Kibana can be used) • Health check • Service running. Cant handle requests. Should show database status, available space,… • Record exceptions in tracker system cyntralized • Gather statistics (DropWizard can be used) • Limit traffic to defend DOS attachks • A coorelation id (transaction_id) for the journey of the request (dapper can be used)
- 25. Moving to Microservice • Deployment • Can be on physical or virtual servers (still physical but can control CPU/RAM) • MS should be packaged with its dependencies in container image & deployed as a container • Images can be easily moved from one environment to another. ( Docker to be used) • Kubernetes is used to orchestrate the contianers • Jenkins is used for continuous delivery • There should be an external configuration for diff environments • Putting debug mode in dev environment only • Activating new functionality through configuration
- 26. Challenges • Business concerns • Integration between teams is difficult • Many trainings need to be done as different dev. Stacks • There is no standard in MS. • Solution will rely on some standards (HTTP,SQL,..) but not standard stack. • There is no single framework, but there is an integration of different technologies • No single support • Cost • Small team • Cheap start, cheap deployments on cloud • Time • Faster to market.
- 27. Challenges • Technical concerns • Design • How to partition the system to services (invoices could’ve been services) • How small !? • Technical diversity • Choose programming language • Right database • Distribution • Communication over network • How to deal with network failures (circuit breaker) • Data store • Database per subdomain • Keep data in sync • Security • Access token renewal
- 28. Challenges • Technical concerns • Testing • Less code will be tested • Test in isolation • Integration testing is hard • Maintenance • Less code to maintain • Less code to understand • Extensibility • New feature, new MS
- 29. When to use MS ? Time to market Extensibility Replicability Scalability
- 30. Thank You