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
- Use app credential to get/create/update/remove records instead of user credential in records management
- Abstract record entities with relationship with actual records (record unique key and uri)
- Abstract master entities relationship with record entities. e.g. Contract, Opportunity.
- Create customizable workflow for specific master entity. e.g. specific type of Contract.
- 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
- Containers
- Storage & Databases
- Caching
- Amazon ElastiCache
- Object Storage
- Amazon S3
- NoSQL Databases
- Amazon DynamoDB
- Relational Databases
- Amazon RDS
- Amazon Aurora
- Caching
- 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
- Service Discovery
- Messaging
- Message Publishing & Subscription
- Amazon Simple Notification Service (Amazon SNS)
- Message Queuing
- Amazon Simple Queue Service (Amazon SQS)
- Message Publishing & Subscription
- Logging and Monitoring
- API Monitoring
- AWS CloudTail
- Application and Resource Monitoring
- Amazon CloudWatch
- Distributed Tracing
- AWS X-Ray
- API Monitoring
- DevOps
- Container Image Repository
- Amazon Elastic Container Registry (Amazon ECR)
- Continuous Delivery
- AWS Developer Tools
- Container Image Repository
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)
SOA, Service Oriented Architecture
XaaS, Everything as a Service
IaaS, Infrastructure as a Service
PaaS, Platform as a Service
SaaS, Software as a Service
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
- Read performance
operations-per-second
how fast you can run queries
how fast you can retrieve results
how well you organize and index data - Write performance
operations-per-second - Latency
- Resource efficiency
- Provisioning efficiency
- Read performance
- 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
-
Transient data
-
Ephemeral data
-
Operational data
-
Transactional data
| Vendor | Service Domain | Product Certification | Status | Current Availability |
|---|---|---|---|---|
| AWS | Database Services | ElastiCache | -- | GA 1.0 |
[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
- Compute
- Containers - Amazon Elastic Container Service
- Serverless - AWS Lambda
| 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 |
- Microservices Approches
- Service Fabric
- Azure Kubernetes Service (AKS)
- Azure Functions
- API Management
| 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 |
- Google App Engine
- Google Kubernetes Engine (GKE)
| 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).
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:
- The pattern language enables you to decide whether microservices are a good fit for your application.
- 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
- Key software delivery outcomes
- General architecture
- Inter-service communication
- Deployment and Reliability
- Obervability
- Externalized configuration
- Supporting infrastructure
- Libraries and frameworks
- Documentation
- Organization and process
- Key software delivery outcomes
- Service design
A service is an independently deployable, loosely coupled, component with well-defined and focussed responsibilities.- Is the service an independently deployable/executable component?
- Does the service implement a business capability?
- Does the service have a single responsibility?
- Is a service’s datastore private to that service?
- Does the service use reliable mechanism, such as sagas, to maintain data consistency across services?
- Is the service built using a supported technology stack?
- Is the service built using a supported microservice chassis?
- Externalized configuration
- 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.- Does the service use language neutral communication mechanisms?
- Is the service’s API secured?
- Do the communication mechanisms support API evolution?
- Does the service use service discovery to locate its (REST/RPC) dependencies?
- If the application uses client-side registration, Does the service register itself?
- Service reliability
- Deployment/Release
- Observability
- Documentation
- Automated testing
- Organization and process
Microsoft Microservices Architecture
API Gateway
演化路线
1 - 所有容器都在一台机器上使用不同端口利用Nginx映射
2 - 部分容器在单独的机器上，UI使用静态对象