Microservices

Microservices

What are Microservices?

• What are Microservices - microservices.io
• Microservices - martinFowler.com
• What is Microservices? - SmartBear
• What are Microservices? - RedHat
• The What, Why, and How of a Microservices Architecture
• What are Microservices? Code Examples, Best Practices, Tutorials and More
• Microservices - Spring.io
• Microservices - IBM
• Microservices Architectures: What They Are and Why You Should Use Them

Decomposition patterns

• Decompose by business capability
• Decompose by subdomain

Sub Domains

• Records Management (Document Repository)
• User Management (Users/Roles/Permissions)
• Workflow (Customizable Workflow)
• Master Data Management (Contract/Opportunity etc.)

Steps

1. Use app credential to get/create/update/remove records instead of user credential in records management
2. Abstract record entities with relationship with actual records (record unique key and uri)
3. Abstract master entities relationship with record entities. e.g. Contract, Opportunity.
4. Create customizable workflow for specific master entity. e.g. specific type of Contract.
5. Create users with assigned roles (generic for specific type of master entity) and permissions (for specific record)

Architecture Styles

• Microservices Architecture
• Event-Driven Architecture

Microservices

Benefits:

• Agility. Because microservices are deployed independently, it's easier to manage bug fixes and feature releases.
• Small, focused teams. A microservice should be small enough that a single feature team can build, test, and deploy it. Small team sizes promote greater agility.
• Small code base. In a monolithic application, there is a tendency over time for code dependencies to become tangled Adding a new feature requires touching code in a lot of places. By not sharing code or data stores, a microservices architecture minimizes dependencies, and that makes it easier to add new features.
• Mix of technologies. Teams can pick the technology that best fits their service, using a mix of technology stacks as appropriate.
• Fault isolation. If an individual microservice becomes unavailable, it won't disrupt the entire application, as long as any upstream microservices are designed to handle faults correctly (for example, by implementing circuit breaking).
• Scalability. Services can be scaled independently, letting you scale out subsystems that require more resources, without scaling out the entire application.
• Data isolation. It is much easier to perform schema updates, because only a single microservice is affected.

Microservices on AWS

• Container - Amazon Elastic Container Service (ECS)
• Serverless - AWS Lambda
• Other
  • API Gateway pattern - Amazon API Gateway
  • Caching - Amazon ElastiCache Redis
  • Messaging - Amazon Simple Queue Service (SQS)
  • Pub/Sub - Amazon Simple Notification Service (SNS)
  • NoSQL - Amazon DynamoDB

Input -> Lambda -> DynamoDB -> Batch Job -> Database

---

AWS Microservices

Microservices on AWS

Monolithic vs. Microservices Architecture

Cloud Services

• Compute
  • Containers
    • Amazon Elastic Container Service (ECS)
  • Serverless
    • AWS Lambda
• Storage & Databases
  • Caching
    • Amazon ElastiCache
  • Object Storage
    • Amazon S3
  • NoSQL Databases
    • Amazon DynamoDB
  • Relational Databases
    • Amazon RDS
    • Amazon Aurora
• Networking
  • Service Discovery
    • AWS Cloud Map
  • Service Mesh
    • AWS App Mesh
  • Elastic Load Balancing
    • Application Load Balancer
    • Network Load Balancer
  • API Proxy
    • Amazon API Gateway
  • DNS
    • Amazon Route 53
• Messaging
  • Message Publishing & Subscription
    • Amazon Simple Notification Service (Amazon SNS)
  • Message Queuing
    • Amazon Simple Queue Service (Amazon SQS)
• Logging and Monitoring
  • API Monitoring
    • AWS CloudTail
  • Application and Resource Monitoring
    • Amazon CloudWatch
  • Distributed Tracing
    • AWS X-Ray
• DevOps
  • Container Image Repository
    • Amazon Elastic Container Registry (Amazon ECR)
  • Continuous Delivery
    • AWS Developer Tools

---

MMR Microservices Expectations

• Individual compute
• Individual deployment
• Scalable
• Small team
• Decoupling
• Free tech selection
• No impact to existing apps

AWS Microservcies

• Container
• Serverless

MMR Integration Patterns

Source	Target	Method
Upstream App	MMR	Read
Upstream App	MMR	Write
MMR	Downstream App	Read
MMR	Downstream App	Write

---

Implementing Microservices on AWS (Web)

Implementing Microservices on AWS (PDF)

AWS Cloud Map service discovery for serverless applications

Guide to Implementing Microservices On AWS [With Examples]

Service connectivity inside and outside the mesh using AWS App Mesh (EC2/Fargate)

Implementing Microservices on AWS

Contents

• Abstract
• Introduction
• Simple Microservices Architecture on AWS
  • User Interface
  • Microservices
  • Data Store
• Reducing Operational Complexity
  • API Implementation
  • Serverless Microservices
  • Deploying Lambda-Based Applications
• Distributed Systems Components
  • Service Discovery
  • Distributed Data Management
  • Asynchronous Communication and Lightweight Messaging
  • Distributed Monitoring
  • Chattiness
  • Auditing
• Conclusion
• Contributors
• Document Revisions

There are three common patterns that we observe when our customers build microservices: API driven, event driven, and data streaming.

Microservices architectures are not a completely new approach to software engineering, but rather a combination of various successful and proven concepts such as:

• Agile software development
• Service-oriented architectures
• API-first design
• Continuous Integration/Continuous Delivery (CI/CD)

---

• The Era of Microservices and Cloud Computing
  
  

SOA, Service Oriented Architecture

XaaS, Everything as a Service

IaaS, Infrastructure as a Service

PaaS, Platform as a Service

SaaS, Software as a Service

• Selecting the Right Database for Your Microservices

Microservices

• Decoupling of services
• Data store autonomy
• Miniaturized development
• Testing setup
• Facilitate faster time-to-market
  
  

How to choose the right data store for your miceroservices?

• Performance
  1. Read performance
     
     operations-per-second
     
     how fast you can run queries
     
     how fast you can retrieve results
     
     how well you organize and index data
  2. Write performance
     
     operations-per-second
  3. Latency
  4. Resource efficiency
  5. Provisioning efficiency
• Reliability
• Data modeling

For read/write operations-per-second

• Very high — Greater than one million
• High — Between 500,000 and one million
• Moderate — Between 10,000 and 500,000
• Low — Less than 10,000

For latency

• Low — Less than one millisecond
• Moderate — one to 10 milliseconds
• High — Greater than 10 milliseconds

Data Modeling Requirements

Nature of Data

1. Transient data

2. Ephemeral data

3. Operational data

4. Transactional data

Vendor	Service Domain	Product Certification	Status	Current Availability
AWS	Database Services	ElastiCache	--	GA 1.0

• How to choose a database for your microservices

• Choosing the Right Databases for Microservices

• Pattern: Shared Databse

• Pattern: Saga

• The FTGO application and the Database per service pattern

• Pattern: Database per Service

[Choosing the Right Database for Microservices Solutions](file:///C:/Users/chikun.cui/Downloads/MMateev-SQLSat823Israel-Choosing-the-Right-Database-for-Microservices-Solutions.pdf)

Effective Microservices: 10 Best Practices

10 Microservices Best Practices for the Optimal Architecture Design

Adopting Microservices at Netflix: Lessons for Architectural Design

Creating Cross Tab Queries and Pivot Tables in SQL

SQL Server Cross Join

Crosstab queries using PIVOT in SQL Server

Use SQL Server to Create a Cross Tab Query

SQL Server Hardware Performance Tuning

How Monitoring Query Performance Can Help You Save SQL Memory Usage

Ten Common Database Design Mistakes

SQL Server database design best practices and tips for DBAs

Best Practice - An Introduction To Domain-Driven Design

martinFowler.com tagged by: domain driven design

---

AWS Microservices

• Compute
  • Containers - Amazon Elastic Container Service
  • Serverless - AWS Lambda

Cloud Product Catalog

Vendor	Service Domain	Product	Certification Status	Current Availability
AWS	Compute Services	Elastic Container Service (ECS)	Blueprint In Progress 1.0	Not Available
AWS	Compute Services	Lambda	--	GA1.0

---

Azure Microservices

• Microservices Approches
  • Service Fabric
  • Azure Kubernetes Service (AKS)
  • Azure Functions
  • API Management

Cloud Product Catalog

Vendor	Service Domain	Product	Certification Status	Current Availability
Azure	Compute Services	Service Fabric Clusters	--	Beta 1.0
Azure	Compute Services	Function Apps	--	GA 1.0
Azure	Enterprise Integration	API Management Services	--	GA 1.0

---

GCP Microservices

• Google App Engine
• Google Kubernetes Engine (GKE)

Cloud Product Catalog

Vendor	Service Domain	Product	Certification Status	Current Availability
GCP	Compute Services	Google Kubernetes Engine (GKE)	--	GA 2.0
GCP	App Services	App Engine	--	Beta 2.0

---

MMR Technical Pain Points

• Performance Issues
  
  High volume of data updates have impact on MMR performance.
• Data Gap on Opportunity data
  
  Opportunity Data in MMR are from Sales ODS with 24 to 48 hours of delay from source application (MMS). If the Opportunity is not yet available in MMR, users would not be able to perform Opportunity submissions.
  
  Moreover, Sales ODS does not deliver updates for Opportunities that are not active in the current fiscal year. This impacts company code mapping for AIL reports.
• Security Model
  
  Security Implementation in MMR is very granular.
• Vendor Limitations and Product Maintenance
  
  Requires VM with desktop experience (does not support CORE). App teams need to raise exception requests
  
  since the vendor does not support cloud native offerings yet.Time to upgrade product version would take 3-6 months.
• Data Replication
  
  MMR Data (both metadata and actual documents) are now replicated on other apps like SEAL and ALICE (like everything).

---

• Microservices.io
  • Pattern: Microservice Architecture

What are microservices?

Microservices - also known as the microservice architecture - is an architectural style that structures an application as a collection of services that are:

• Highly maintainable and testable
• Loosely coupled
• Independently deployable
• Organized around business capabilities
• Owned by a small team

The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications. It also enables an organization to evolve its technology stack.

The pattern language is your guide

The microservice architecture is not a silver bullet. It has several drawbacks. Moreover, when using this architecture there are numerous issues that you must address.

The microservice architecture pattern language is a collection of patterns for applying the microservice architecture. It has two goals:

1. The pattern language enables you to decide whether microservices are a good fit for your application.
2. The pattern language enables you to use the microservice architecture successfully.

A good starting point is the Monolithic Architecture pattern, which is the traditional architectural style that is still a good choice for many applications. It does, however, have numerous limitations and issues and so a better choice for large/complex applications is the Microservice architecture pattern.

Avoid the potholes

Thinking of migrating to the microservice architecture? If so, you should look at this presentation about the potholes in the road from monolithic hell and read this series of blog posts about anti-patterns and how to avoid them.

Assess your architecture

If you have built an application with the microservice architecture then take a look at the Microservices Assessment Platform. The platform assesses what you have built and identifies what needs to be improved. It reduce architectural and organizational risk and maximizes the benefits of the microservice architecture.

• Microservices - Wikipedia
• Microservices - MartinFowler.com
• The What, Why and How of a Microservices Architecture

---

• .NET Microservices Architecture Guidance
  • Microservices & Docker containers
  • Microservices architecture e-book .NET Microservices: Architecture for Containerized .NET Applications
  • DevOps for containerized apps e-book Containerized Docker Application Lifecycle with Microsoft Platform and Tools
  • Modernizing existing .NET apps e-book Modernize existing .NET applications with Azure cloud and Windows Containers
• Microservices with .NET

---

• Microservice Architecture Assessment Platform

1. Key software delivery outcomes
2. General architecture
3. Inter-service communication
4. Deployment and Reliability
5. Obervability
6. Externalized configuration
7. Supporting infrastructure
8. Libraries and frameworks
9. Documentation
10. Organization and process

---

1. Key software delivery outcomes
2. Service design
   
   A service is an independently deployable, loosely coupled, component with well-defined and focussed responsibilities.
   1. Is the service an independently deployable/executable component?
   2. Does the service implement a business capability?
   3. Does the service have a single responsibility?
   4. Is a service’s datastore private to that service?
   5. Does the service use reliable mechanism, such as sagas, to maintain data consistency across services?
   6. Is the service built using a supported technology stack?
   7. Is the service built using a supported microservice chassis?
3. Externalized configuration
4. Inter-service communication
   
   Services must communicate securely using IPC mechanisms that allow the API to evolve. In addition, a service that uses RPC must use a service discovery mechanism.
   1. Does the service use language neutral communication mechanisms?
   2. Is the service’s API secured?
   3. Do the communication mechanisms support API evolution?
   4. Does the service use service discovery to locate its (REST/RPC) dependencies?
   5. If the application uses client-side registration, Does the service register itself?
5. Service reliability
6. Deployment/Release
7. Observability
8. Documentation
9. Automated testing
10. Organization and process

---

Microsoft Microservices Architecture

API Gateway

演化路线

1 - 所有容器都在一台机器上使用不同端口利用Nginx映射

2 - 部分容器在单独的机器上，UI使用静态对象

https://github.com/Microsoft/Yams