Skip to content

Commit d4357e4

Browse files
sicoylesicoyle
authored
Proposal: Extend service invocation to non-Dapr endpoints (#20)
* docs: add inital proposal details Signed-off-by: Samantha Coyle <[email protected]> * fix: update per pr feedback Signed-off-by: Samantha Coyle <[email protected]> * style: rm naming redundancy Signed-off-by: Samantha Coyle <[email protected]> * fix: add ex yaml + address feedback Signed-off-by: Samantha Coyle <[email protected]> * refactor: pick http specific CRD approach Signed-off-by: Samantha Coyle <[email protected]> --------- Signed-off-by: Samantha Coyle <[email protected]>
1 parent f946492 commit d4357e4

File tree

1 file changed

+158
-0
lines changed

1 file changed

+158
-0
lines changed

‎0006-B-external-service-invocation.md‎

Lines changed: 158 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,158 @@
1+
# External Service Invocation
2+
3+
* Author(s): Samantha Coyle (@sicoyle)
4+
* State: Ready for Implementation
5+
* Updated: 04/06/2023
6+
7+
## Overview
8+
9+
This is a design proposal for the requested [external service invocation feature](https://github.com/dapr/dapr/issues/4549).
10+
11+
The goal of this feature enhancement is to provide developers with a way to invoke any service of their choosing,
12+
using the existing building blocks provided by Dapr.
13+
14+
## Background
15+
16+
### Motivation
17+
We want Dapr users to be able to invoke external,
18+
non-Daprized services with ease and flexibility.
19+
20+
### Goals
21+
Implement a change into `dapr/dapr` that facilities a seamless Dapr UX to allow for external service invocation using existing building blocks and feature sets.
22+
23+
### Current Shortfalls
24+
Currently, we have the service invocation API that allows for Dapr users to use the invoke API on the Dapr instance.
25+
This provides many features as part of the service invocation building block such as HTTP & gPRC service invocation,
26+
service-to-service security, resiliency, observability, access control, namespace scoping, load balancing, and service discovery.
27+
However, the current implementation does not allow for external service invocations - which is a real bummer for many Dapr users.
28+
29+
To remind everyone of the work around many Dapr users use, there is the HTTP binding.
30+
Dapr users can create an HTTP binding with their external URL specified,
31+
but this approach has many downfalls that yield a less-than-desirable developer experience.
32+
33+
For additional background information,
34+
please refer to the [external service invocation feature request](https://github.com/dapr/dapr/issues/4549).
35+
36+
## Related Items
37+
38+
### Related proposals
39+
40+
Formalizing the proposal here from [this issue](https://github.com/dapr/dapr/issues/4549).
41+
42+
## Expectations and alternatives
43+
44+
* What is in scope for this proposal?
45+
Feature enhancement to enable external service invocation
46+
using the existing service invocation building block allowing service communication using HTTP protocol.
47+
48+
* What is deliberately *not* in scope?
49+
gRPC invocation as well as additional authentication, to include OAuth2,
50+
is not within scope of this initial proposal and implementation.
51+
52+
53+
* What alternatives have been considered, and why do they not solve the problem?
54+
1. Expanding the existing HTTP Binding.
55+
2. Creation of another HTTP Binding explicitly dedicated to external service invocation keeping in mind the current pain points.
56+
57+
Moving forward with the alternative approaches goes against the motivation and goal of this proposal,
58+
as Dapr users would be missing crucial service invocation features,
59+
be restricted on numerous avenues,
60+
and be forced to continue abiding by an awkwardly clunky workaround.
61+
Additional pros/cons may be found in the [linked issue's discussion](https://github.com/dapr/dapr/issues/4549#issuecomment-1414841151).
62+
63+
* Are there any trade-offs being made? (space for time, for example)
64+
N/A
65+
66+
* What advantages / disadvantages does this proposal have?
67+
This proposal allows service invocation to be enabled for non-Dapr endpoints.
68+
69+
Pros:
70+
- Extends existing service invocation implementation.
71+
- Same feel as current user invocation process.
72+
- Can leverage existing service invocation features like resiliency, security practices, observability.
73+
- Leveraging a new CRD would keep our CRD setup less cluttered and easier to adjust and add to moving forward.
74+
- With a new CRD you can add/rm endpoints programmatically via kubectl.
75+
- Allows for user overrides such as base URL and related request information at invocation time.
76+
77+
Cons:
78+
- Creation of an additional CRD, thus increasing the duplication of boilerplate code for its setup.
79+
- Need to know external base URL ahead of time to configure, but that may not always be easy for end users.
80+
- Would need to change the Dapr Operator to notify on edits for external endpoints.
81+
82+
## Implementation Details
83+
84+
### Design
85+
86+
How will this work, technically?
87+
88+
Allow configuration of pieces needed for external service invocation through creation of new CRD titled `ExternalHTTPEndpoint`.
89+
It is HTTP specific in it's `Kind`.
90+
This has benefits in being obvious upfront that it supports only `http`,
91+
and makes it to where we do not need `spec.allowed.protocols`.
92+
However, it would have the drawback of needing additional CRDs in the future for supporting other protocols such as `gRPC`.
93+
The sample `yaml` file snippet below represents the proposed configuration.
94+
95+
```
96+
apiVersion: dapr.io/v1alpha1
97+
kind: ExternalHTTPEndpoint
98+
metadata:
99+
name: externalserviceinvocation
100+
spec:
101+
allowed:
102+
- name: github
103+
baseUrl: "github.com"
104+
headers:
105+
- "Accept-Language": "en-US"
106+
metadata:
107+
- name: mymetadata
108+
secretKeyRef:
109+
name: my-secret
110+
key: mymetadataSecret
111+
auth:
112+
secretStore: my-secretstore
113+
```
114+
115+
Implementation for external service invocation will sit alongside the existing service invocation building block implementation with API changes to support external invocation.
116+
117+
User facing changes include overriding the URL when calling Dapr for service invocation.
118+
Users will use the existing service invocation API, but instead of using an app ID,
119+
they can use an external URL and optionally overwrite fields at the time of invocation.
120+
121+
122+
### Feature lifecycle outline
123+
124+
* Expectations
125+
This feature will be enabled after Dapr v1.11 release.
126+
127+
* Compatability guarantees
128+
This feature is fully compatible with the existing service invocation API.
129+
130+
* Deprecation / co-existence with existing functionality
131+
This feature will require support for external service invocations that will sit alongside and make changes to expand the existing service invocation API.
132+
133+
* Feature flags
134+
N/A
135+
136+
### Acceptance Criteria
137+
138+
How will success be measured?
139+
140+
* Performance targets
141+
N/A
142+
143+
* Compabitility requirements
144+
This feature will need to be fully compatible with existing service invocation API.
145+
146+
* Metrics
147+
Existing service invocation tracing and metrics capabilities when calling external enpoints will be fully functional.
148+
149+
## Completion Checklist
150+
151+
What changes or actions are required to make this proposal complete?
152+
153+
* Code changes
154+
* Secret resolution
155+
* Tests added (e2e, unit)
156+
* SDK changes (if needed)
157+
* Documentation
158+

0 commit comments

Comments
 (0)