This is a small introduction to microservices. you can find the differences between microservices and monolithic applications. You will find the pros and cons of microservices. you will also find the challenges (Business/ technical) that you may face while implementing 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
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.
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
