Skip to main content

Microservices architecture and design patterns

Microservices Architecture and Design patterns

Available in doc link as well which have better formatting: Microservices architecture and design patterns
  1. What are microservices?
           In short, the microservice architectural style is an approach to 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. These
services are built around business capabilities and independently deployable by fully automated deployment machinery.
There is a bare minimum of centralized management of these services, which may be written in different programming languages
and use different data storage technologies.
           -- James Lewis and Martin Fowler
  1. Scoping microservices
    1. Domain-driven-design
    1. Ubiquitous language
    1. Bounded context
  1. API-based microservices
    1. API architectural styles
      1. REST (Pragmatic REST)
      2. HATEOS (True REST)
      3. SOAP
      4. RPC









    1. API architectural patterns
      1. Façade Pattern
      1. Proxy Pattern
      1. Stateless service pattern
  1. Async microservices
    1. Why async microservices?
      1. Fire and Forget Interactions
      2. Long running jobs
      3. Decoupled client and services
      4. Better user experience
    2. Event based
      1. Competing Worker Pattern
Subscribers compete for message (Eg. Rabbit MQ Direct Exchange)




      1. Fanout Pattern
Multiple consumers get the message (Eg. Rabbit MQ Fanout Exchange)
    1. Async API calls















  1. Microservices Composition Pattern
Used to compose microservices together.
    1. Broker
    1. Aggregate
    1. Chained
    1. Proxy
    1. Branch





  1. Data consistency across the microservices
    1. Two-phase commit








    1. Saga pattern
    1. Eventual Consistency
  1. Split monolithic databases across microservices
    1. Data First vs. Function first


    1. Patterns for DB design
      1. Event driven (Event-Carried State Transfer)
              This pattern shows up when you want to update clients of a system in such a way that they don't need to contact
the source system in order to do further work. A source system might fire off events whenever a customer changes
their details with events that contain details of the data that changed. A recipient can then update its own copy of
customer data with the changes, so that it never needs to talk to the main customer system in order to do its work in the future.
      1. Event sourcing
             The core idea of event sourcing is that whenever we make a change to the state of a system, we record that state change as
an event, and we can confidently rebuild the system state by reprocessing the events at any time in the future. The event store
becomes the principal source of truth, and the system state is purely derived from it. The best example of this is a version-control
system. The log of all the commits is the event store and the working copy of the source tree is the system state.


      1. CQRS






      1. Greenfield database approach
      1. Brownfield migration approach


  1. Make microservices more resilient
    1. Patterns and approaches
      1. Timeout
             Minimises’ the risk for exhausting all the threads in a thread pool and stops from system to go down.




      1. Circuit breaker
      1. Retry
      1. Bulkhead
Ex. Separating resources


Ex. Isolating microservices


Ex. Redundancy using load balancers and message brokers


  1. Microservices backward compatibility
Request Header versioning:
Request path versioning:




  1. Centralized Logging
Centralized logging considerations:


How to achieve consistent logging format?
Logging levels:
Transaction transparency:


  1. Microservices configurations
    1. Deployment servers
    1. Eternalized configurations
    1. Configuration management tools
Chef Overview:
Puppet Overview:


    1. Containers
  1. Microservices registration and discovery
    1. Client side discovery
Example:
    1. Server side discovery












    1. Service registration
Self-registration:
Third-party registration:






    1. Tools
  1. Monitoring Microservices
    1. Monitoring key metrics
    1. Monitoring SLA metrics
    1. Dashboards
    1. Alerting and monitoring
    1. Defining thresholds for alerts
    1. Microservices monitoring pattern


Comments

Post a Comment

Popular posts from this blog

Pivotal Cloud Foundry Developer Certification - Managed and User-Provided Services

1. What is a service? Can you name some examples? Services are cloud native apps dependencies. Consider S ervice as a factory that delivers service instances. Two types: 1. Managed services Cloud Foundry offers a marketplace of services, from which users can provision reserved resources on-demand. Examples of resources services provide include databases on a shared or dedicated server, or accounts on a SaaS application.  Example: my-sql, rabbitmq, redis etc... 2. User provided services User provided services provides the metadata to connect to the system outside the cloud. These services are not available in market place. This are custom services i.e. connecting to your own external DB or any other service outside the cloud i.e. erp etc.. Command to list the service instances in your space: cf services To see details of particular service cf service SERVICE_INSTANCE_NAME What is the “marketplace”? Does it show all services?  The Pivotal Cloud F...
7 comments
Read more

Pivotal Cloud Foundry Developer Certification - Cloud Foundry Architecture

Can you name the main components running inside Cloud Foundry? Do you know what  each of them does? Main components are: Router :  routes incoming traffic to cloud controller or the hosted application in diego cell. It periodically queries the Diego bulletin board system to determine which cells and containers each application currently runs on. Using this router recomputes new routing table based on IP addresses of each cell VM and the host side port number for the cell's container. Oauth2 Server(UAA) and Login server work together to provide the identity management. Cloud controller and Diego brain: CC is responsible for application life-cycle and deployment. It directs the diego brain through CC Bridge component to coordinate individual Diego cells to stage and run applications. CC also maintains record of orgs, spaces, user roles and services. nsync : recieves the message from CC when user scales an app. It writes number of instances into a desiredLRP s...
7 comments
Read more

Pivotal Cloud Foundry Developer Certification - Cloud Foundry Overview - Concepts

Cloud Foundry Concepts Cloud Foundry is the cloud native platform or PaaS i.e. Platform-as-a-service infrastructure which is basically PCF(Runtime & Middleware) + IaaS, where you just manage your application and data. Below diagram will help understanding it more. Deploying an application in IaaS vs PaaS IaaS deployment: 1. Provision a VM 2. Install application runtime 3. Deploy application 4. Configure load balancer 5. Configure SSL termination 6. Configure Service connectivity 7. Configure Firewall PaaS deployment: 1. cf push (CLI command), which will push your application and you do not need to take care of IaaS deployment steps. Scaling an application in IaaS vs PaaS IaaS: Same steps as deployment PaaS: cf scale Cloud Foundry is the open source platform that you can deploy to run your apps on your own computing infrastructure, or deploy on IaaS like AWS, vSphere, or OpenStack. How cloud foundry works CF has subsystems that perform speciali...
3 comments
Read more