osm
docs
osm | docs | |
---|---|---|
7 | 6 | |
2,586 | 987 | |
- | -0.1% | |
8.9 | 9.7 | |
10 months ago | 7 days ago | |
Go | HTML | |
Apache License 2.0 | Creative Commons Attribution 4.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
osm
-
Service Mesh Considerations
If you'd like to go a bit deeper into service mesh technology, be sure to check out the resources listed below then head over to the Open Service Mesh with Azure Kubernetes Service lab to get hands-on and see a service mesh in action! Open Service Mesh is an open-source, lightweight service mesh that is easy to install and operate, so I encourage you to take it for a spin 🚀
-
osm-edge: Using access control policies to access services with the service mesh
osm-edge forked from Open Service Mesh is a lightweight, extensible, cloud-native, SMI-compatible service mesh built purposely for Edge computing. osm-edge uses lightweight programmable proxy Pipy as a sidecar proxy.
-
Benchmarking osm and osm-edge data planes
osm-edge is built on top of Open Service Mesh (OSM) v1.1.0 codebase and is a lightweight service mesh for resource-sensitive cloud environments and edge computing scenarios. It uses osm as the control plane and Pipy as the data plane and features high performance, low resources, simplicity, ease of use, scalability, and compatibility (x86/arm64 support).
-
Announcing osm-edge 1.1: ARM support and more
osm-edge is a fork of open service mesh and we will strive to keep this fork in sync with its upstream and propose back major changes and/or feature proposals to upstream for broader benefits of the community. Both OSM and osm-edge are hosted on Github. If you have any feature request, question, or comment, we’d love to have you join the rapidly-growing community via Github Issues, Pull Requests, or osm slack channel!
-
Need to create a simple POC to prove that mTLS is being used for service to service communication in AKS with Open Service Mesh
Link: https://github.com/openservicemesh/osm/issues/4840
-
Azure Weekly Updates - 21st May 2022 - Part 2
Azure Arc-enabled Kubernetes allows us to attach and configure Kubernetes clusters running anywhere. Open Service Mesh (OSM) is a lightweight, extensible, Cloud Native service mesh that allows users to uniformly manage, secure, and get out-of-the-box observability features for highly dynamic microservice environments. The Open Service Mesh (OSM) extension is a managed service mesh for Arc-enabled Kubernetes clusters that is lightweight and extensible.
-
Pull Requests Like a PRO: Tips to Make High-Quality Pull Requests
Pull Request template from the Open Service Mesh project
docs
-
Picking an architecture
I agree with the general sentiment here that you should try to keep things simple as long as possible. In addition to that, try to use frameworks such as Dapr, that allow you to postpone certain architectural decisions. Since Dapr runs everywhere where Kubernetes runs, it doesn't really matter which cloud provider you pick. Also, when it comes to pub/sub brokers, state stores, or secret stores, when using Dapr components you can easily swap those out.
-
Mechanism for managing faulty consumer in asynchronous event broadcast in microservices / modular monolith
I'm mostly familiar with orchestration type sagas, and there I usually include retries when calling services and compensation actions in case calls completely fail. It really helps if you're using a framework, such as Dapr, to do most of the heavy lifting. You can apply resiliency policies to service calls and with the latest version, there's now a Workflow API to orchestrate your services.
-
Service Mesh Considerations
One other option that is worth mentioning is Dapr. Dapr is a microservices building block that developers can use to develop microservices. There is a bit of overlap between Dapr and service meshes and the Dapr team has done a good job of comparing the two here. The biggest takeaway when comparing the two is that Dapr does not provide traffic routing/splitting. So if you need these capabilities, then yes, you will need a service mesh.
-
Virtual Actors : Dapr vs Orleans
There was a similar issue with the code examples to get/set state, so I created a GitHub issue for them.
-
Image Recognition App using GoLang | Tensorflow | WasmEdge | Dapr | Docker
It is an Image Recognition Application made using Go Language, works on a Tensorflow model and it requires Dapr and WasmEdge runtime for execution.
-
Tech Talks: Building Event-Driven Apps with Dapr in Kubernetes
Dapr Docs
What are some alternatives?
istio - Connect, secure, control, and observe services.
dapr-wasm - A template project to demonstrate how to run WebAssembly functions as sidecar microservices in dapr
geo-golang - Go library to access geocoding and reverse geocoding APIs
CAP - Distributed transaction solution in micro-service base on eventually consistency, also an eventbus with Outbox pattern
kuma - 🐻 The multi-zone service mesh for containers, Kubernetes and VMs. Built with Envoy. CNCF Sandbox Project.
Orleans.CosmosDB - Orleans providers for Azure Cosmos DB
pipy - Pipy is a programmable proxy for the cloud, edge and IoT.
jaeger - CNCF Jaeger, a Distributed Tracing Platform
pbf - OpenStreetMap PBF golang parser
dapr - Dapr is a portable, event-driven, runtime for building distributed applications across cloud and edge.
meshery - Meshery, the cloud native manager
cloud-dapr-demo - Demo of Dapr runtime and seamless integration of cloud providers