| Azure function APP | Azure function APP | Azure function APP |
| https://www.youtube.com/watch?v=7gwfINrXqEs&list=PLMWaZteqtEaLRsSynAsaS_aLzDPBUU4CV&index=10 | https://www.youtube.com/watch?v=7gwfINrXqEs&list=PLMWaZteqtEaLRsSynAsaS_aLzDPBUU4CV&index=10 | https://www.youtube.com/watch?v=7gwfINrXqEs&list=PLMWaZteqtEaLRsSynAsaS_aLzDPBUU4CV&index=10 |
| | |
| | |
| https://www.youtube.com/watch?v=8NrO8nHHPDs | |
| SAML | | |
| https://auth0.com/blog/how-saml-authentication-works/ | |
| https://www.componentspace.com/saml-for-asp-net-core | |
| Angular -rxjs | https://angular.io/guide/rx-library | |
| angular-unitest/jasmin | | |
| Microservices | https://blog.clearscale.com/12-factor-approach-for-microservices/ | |
| | |
| https://dzone.com/articles/design-patterns-for-microservices | |
| https://microservices.io/patterns/microservices.html | |
| https://github.com/donnemartin/system-design-primer | |
| | |
| https://owasp.org/www-project-top-ten/ | |
| | |
| | |
| | |
| | |
| Code GReviewuideline | In doing a code review, you should make sure that:
The code is well-designed.
The functionality is good for the users of the code.
Any UI changes are sensible and look good.
Any parallel programming is done safely.
The code isn’t more complex than it needs to be.
The developer isn’t implementing things they might need in the future but don’t know they need now.
Code has appropriate unit tests.
Tests are well-designed.
The developer used clear names for everything.
Comments are clear and useful, and mostly explain why instead of what.
Code is appropriately documented (generally in g3doc).
The code conforms to our style guides.
Make sure to review every line of code you’ve |
| Azzure All design pattern | | |
| 5. Cross-Cutting Concern Patterns
4. Observability Patterns
3. Database Patterns
2. Integration Patterns
1. Decomposition Patterns
a. Decompose by Business Capability
b. Decompose by Subdomain
c. Strangler Pattern
2. Integration Patterns
a. API Gateway Pattern
b. Aggregator Pattern
c. Client-Side UI Composition Pattern
3. Database Patterns
a. Database per Service
b. Shared Database per Service
c. Command Query Responsibility Segregation (CQRS)
d. Saga Pattern
4. Observability Patterns
a. Log Aggregation
b. Performance Metrics
c. Distributed Tracing
d. Health Check
5. Cross-Cutting Concern Patterns
a. External Configuration
b. Service Discovery Pattern
c. Circuit Breaker Pattern
d. Blue-Green Deployment Pattern | |
| What are microservices? | |
| | |
| Microservices are small, independent, and loosely coupled. A single small team of developers can write and maintain a service. | |
| | |
| Each service is a separate codebase, which can be managed by a small development team. | |
| | |
| Services can be deployed independently. A team can update an existing service without rebuilding and redeploying the entire application. | |
| | |
| Services are responsible for persisting their own data or external state. This differs from the traditional model, where a separate data layer handles data persistence. | |
| | |
| Services communicate with each other by using well-defined APIs. Internal implementation details of each service are hidden from other services. | |
| | |
| Supports polyglot programming. For example, services don't need to share the same technology stack, libraries, or frameworks. | |
| | |
| API Gateway | |
| Agility. Because microservices are deployed independently, it's easier to manage bug fixes and feature releases. You can update a service without redeploying the entire application, and roll back an update if something goes wrong. In many traditional applications, if a bug is found in one part of the application, it can block the entire release process. New features may be held up waiting for a bug fix to be integrated, tested, and published. | |
| | |
| 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. Large teams tend be less productive, because communication is slower, management overhead goes up, and agility diminishes. | |
| | |
| 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. Using an orchestrator such as Kubernetes or Service Fabric, you can pack a higher density of services onto a single host, which allows for more efficient utilization of resources. | |
| | |
| Data isolation. It is much easier to perform schema updates, because only a single microservice is affected. In a monolithic application, schema updates can become very challenging, because different parts of the application may all touch the same data, making any alterations to the schema risky. | |
| | |
| API Gateway. The API gateway is the entry point for clients. Instead of calling services directly, clients call the API gateway, which forwards the call to the appropriate services on the back end. | |
| | |
| Advantages of using an API gateway include: | |
| | |
| It decouples clients from services. Services can be versioned or refactored without needing to update all of the clients. | |
| | |
| Services can use messaging protocols that are not web friendly, such as AMQP. | |
| | |
| The API Gateway can perform other cross-cutting functions such as authentication, logging, SSL termination, and load balancing. | |
| | |
| Out-of-the-box policies, like for throttling, caching, transformation, or validation. | |
| | |
| Microservice architecture has become the de facto choice for modern application development. Though it solves certain problems, it is not a silver bullet. It has several drawbacks and when using this architecture, there are numerous issues that must be addressed. This brings about the need to learn common patterns in these problems and solve them with reusable solutions. Thus, design patterns for microservices need to be discussed. Before we dive into the design patterns, we need to understand on what principles microservice architecture has been built: | |
| | |
| Scalability | Scalability |
| Availability | Data isolation. |
| Resiliency(the capacity to recover quickly from difficulties; toughness.
) | Api Gateway |
| Independent, autonomous | Small, focused teams. Small Code base |
| Decentralized governance( standards enable the team to better build and deploy the code that they have created according to their individual governance plans.) | |
| Failure isolation | Fault Isolocation |
| Auto-Provisioning(having the ability to deploy information technology or telecommunications services using predefined automated procedures without requiring human interventions) | Mixed Tech |
| Continuous delivery through DevOps | Agility. |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| Creating Big Systems | |
| 1. All functional and non required to gethers and fixed | |
| 2. Required to clarified with functional | |
| 3.NFR ( scalable , reliable , cap , security(owasp-10) and 12 factor App | |
| 4. then only possible appliable gwon for big and Code quality and FXCop, SonalRCube, MS test | |
| https://12factor.net/ | |
| I. Codebase | |
| One codebase tracked in revision control, many deploys | |
| II. Dependencies | |
| Explicitly declare and isolate dependencies | |
| III. Config | |
| Store config in the environment | |
| IV. Backing services | |
| Treat backing services as attached resources | |
| V. Build, release, run | |
| Strictly separate build and run stages | |
| VI. Processes | |
| Execute the app as one or more stateless processes | |
| VII. Port binding | |
| Export services via port binding | |
| VIII. Concurrency | |
| Scale out via the process model | |
| IX. Disposability | |
| Maximize robustness with fast startup and graceful shutdown | |
| X. Dev/prod parity | |
| Keep development, staging, and production as similar as possible | |
| XI. Logs | |
| Treat logs as event streams | |
| XII. Admin processes | |
| Run admin/management tasks as one-off processes | |
| 1. Codebase | |
| | |
| One codebase tracked in revision control, many deploys | |
| | |
| There is only one codebase per app ─ in microservices architecture, it’s one codebase per service ─ but there can be numerous deploys. A deploy is a running instance of the app. This is usually a production site and one or more staging sites. A copy of an app running in a developer’s local development environment is also considered a deploy. | |
| | |
| The codebase must be the same across all deployments, although different versions may be active in each deploy. For this reason, it’s essential to track the app in a version control system, such as Subversion and Git. | |
| 2. Dependencies | |
| | |
| Explicitly declare and isolate dependencies | |
| | |
| Declare all dependencies precisely via a dependency declaration manifest. Use a dependency isolation tool during execution to ensure that no implicit dependencies enter from the surrounding system. This applies to both production and development. | |
| | |
| Don’t rely on the implicit existence of any system-wide site packages or site tools. While these tools may exist on most systems, there’s no guarantee they’ll exist on the systems where the app runs in the future. Nor is it a sure thing that the version found on a future system will be compatible with the app. | |
| 3. Config | |
| | |
| Store config in the environment | |
| | |
| All configuration data should be stored separately from the code – in the environment as variables and not in the code repository — and read in by the code at runtime. A separate config file makes it easy to update the config values without touching the actual codebase, eliminating the need for redeploying apps when config values are changed. | |
| | |
| The following are some additional best practices to consider: | |
| Use an environment variable for anything that can change at runtime, and for secrets that shouldn’t be committed to a shared repository. | |
| Use non version-controlled .env files for local development. | |
| Keep all .env files in a secure storage system so they’re available to the development teams, but not committed to the code repository being used. | |
| Once an app is deployed to a delivery platform, use the platform’s mechanism for managing environment variables. | |
| | |
| Configs stored as variables are unlikely to be checked into the repository accidentally. Another bonus: then your configs are independent of language and OS. | |
| 4. Backing services | |
| | |
| Treat backing services as attached resources | |
| | |
| Backing services are usually managed locally by the same systems administrators who deploy the app’s runtime. The app may also have services provided and managed by third parties. | |
| | |
| For microservices, anything external to a service is treated as an attached resource. This ensures that every service is completely portable and loosely coupled to the other resources in the system. In addition, the strict separation increases flexibility during development; developers only need to run the services they’re modifying. | |
| 5. Build, release, run | |
| | |
| Strictly separate build and run stages | |
| | |
| Use a continuous integration/continuous delivery (CI/CD) tool to automate builds and support strict separation of build, release, and run stages, Docker images make it easy to separate the build and run stages. Images should be created from every commit and treated as deployment artifacts. | |
| | |
| Start the build process by storing the app in source control and then build out its dependencies. Separating the config information enables you to combine it with the build for the release stage. It’s then ready for the run stage. Each release should have a unique ID. | |
| 6. Processes | |
| | |
| Execute the app as one or more stateless processes | |
| | |
| Ensuring the app is stateless makes it easy to scale a service horizontally by simply adding more instances of that service. Store any stateful data or data that needs to be shared between instances, in a backing service such as a database. The process’ memory space or filesystem can be used as a brief, single-transaction cache. Session state data is a good candidate for a datastore that offers time expiration. | |
| | |
| Never assume that anything cached in memory or on disk will be available on a future request or job. | |
| 7. Port binding | |
| | |
| Export services via port binding | |
| | |
| The app should be completely self-contained and not rely on the runtime injection of a webserver into the execution environment to create a web-facing service. The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port. Nearly any kind of server software can be run via a process binding to a port and awaiting incoming requests. | |
| | |
| To make the port binding factor more useful for microservices, allow access to the persistent data owned by a service only by way of the service’s API. This prevents implicit service contracts between microservices. It also ensures they can’t become tightly coupled. In addition, data isolation allows the developer to choose the type of data store for each service, that best suits its needs. | |
| 8. Concurrency | |
| | |
| Scale-out via the process model | |
| | |
| Supporting concurrency means that different parts of an app can be scaled up to meet the need at hand. When you develop the app to be concurrent, you can spin up new instances to the cloud effortlessly. | |
| | |
| | |
| | |
| Docker and other containerized services provide service concurrency. | |
| 9. Disposability | |
| | |
| Maximize robustness with fast startup and graceful shutdown | |
| | |
| An app’s processes should be disposable so they can be started, stopped, and redeployed quickly with no loss of data. This facilitates fast elastic scaling, rapid deployment of code and config changes, and robustness of production deploys. | |
| | |
| Services deployed in Docker containers do this automatically, as it’s an inherent feature of containers that they can be stopped and started instantly. | |
| | |
| The concept of disposable processes means that an app can die at any time, but it won’t affect the user—the app can be replaced by other apps, or it can start right up again. | |
| | |
| Building disposability into your app ensures that the app shuts down gracefully: it should clean up all utilized resources and shut down smoothly. | |
| | |
| When designed this way, the app comes back up again quickly. Likewise, when processes terminate, they should finish their current request, refuse any incoming request, and exit. | |
| 10. Dev/prod parity | |
| | |
| Keep development, staging, and production as similar as possible | |
| | |
| Continuous deployment requires continuous integration based on matching environments to limit deviation and errors. As such, dev, staging, and production should be as similar as possible. | |
| | |
| Containers work well for this as they enable you to run the exact same execution environment all the way from local development through production. Note: the differences in the underlying data can still cause differences at runtime. | |
| | |
| Don’t use different backing services between development and production, even when adapters theoretically abstract away any differences. Even minor deviations can cause incompatibilities to crop up that can cause code that worked in development or staging to fail in production. | |
| 11. Logs | |
| | |
| Treat logs as event streams | |
| | |
| Stream logs to a chosen location rather than dumping them into a log file. Logs can be directed anywhere. For example, they could be directed to a database in NoSQL, to another service, to a file in a repository, to a log-indexing-and-analysis system, or to a data-warehousing system. | |
| | |
| Use a log-management solution for routing or storing logs. | |
| The process for routing log data needs to be separate from processing log data. Define your logging strategy as part of the architecture standards, so all services generate logs in a similar fashion. | |
| 12. Admin processes | |
| | |
| Run admin/management tasks as one-off processes | |
| | |
| The idea here is to separate administrative tasks from the rest of the app to prevent one-off tasks from causing issues with your running apps. Containers make this easy, as you can spin up a container just to run a task and then shut it down. | |
| | |
| Examples include doing data cleanup, running analytics for a presentation, or turning on and off features for A/B testing. | |
| | |
| Though the admin processes are separate, you must continue to run them in the same environment and against the base code and config of the app itself. Shipping the admin tasks code alongside the app prevents drift. | |
| | |
| Microservice architecture has become the de facto choice for modern application development. Though it solves certain problems, it is not a silver bullet. It has several drawbacks and when using this architecture, there are numerous issues that must be addressed. This brings about the need to learn common patterns in these problems and solve them with reusable solutions. Thus, design patterns for microservices need to be discussed. Before we dive into the design patterns, we need to understand on what principles microservice architecture has been built: | |
| | |
| Scalability | |
| Availability | |
| Resiliency | |
| Independent, autonomous | |
| Decentralized governance | |
| Failure isolation | |
| Auto-Provisioning | |
| Continuous delivery through DevOps | |
| | |
| https://auth0.com/blog/how-saml-authentication-works/ | |
| SAML stands for Security Assertion Markup Language. It is an XML-based open-standard for transferring identity data between two parties: an identity provider (IdP) and a service provider (SP). | |
| | |
| Identity Provider — Performs authentication and passes the user's identity and authorization level to the service provider. | |
| | |
| Service Provider — Trusts the identity provider and authorizes the given user to access the requested resource. | |
| | |
| | |
| | |
| https://jwt.io/introduction | |
| | |
| To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that. | |
| | |
| For example if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way: | |
| | |
| HMACSHA256( | |
| base64UrlEncode(header) + "." + | |
| base64UrlEncode(payload), | |
| secret) | |
| | |
| The signature is used to verify the message wasn't changed along the way, and, in the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is. | |
| | |
| RFI,RFP,RFQ | https://loopio.com/blog/rfi-rfp-rfq/ | |
| | |
| | |
|
|
No comments:
Post a Comment