[
https://issues.apache.org/jira/browse/ATLAS-3736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Eckman updated ATLAS-3736:
----------------------------------
Description:
Microservices are an increasingly important and pervasive part of modern
architectures. By definition, a microservice’s APIs provide the only access to
a dataset—the schema of the underlying RDBMS, NoSQL db, etc is not exposed.
Therefore, it would be nice if Atlas enabled microservices to be discovered
along with other dataset types. The microservice typedef would include the
top-level endpoint, plus each of its API resources (GETs, POSTs, PUTs,
DELETEs), with their URI, parameters, JSON request and response objects, and
http response messages (200: Success, 404: Not Found, etc).
One might ask, why put this metadata into Atlas when it can already be
searched in a Swagger/OpenAPI repository? Three main reasons: 1) microservice
metadata can be searched along with all other enterprise datasets to find a
complete set of datasets of interest for, say, a cross-silo data science
investigation; 2) we can express lineage between microservices and other
datasets that either feed the db underlying the microservice or serve as
historical repositories for transactional microservices (eg S3 datalakes); 3)
we can express semantic relationships between microservices, eg the marketing
contact microservice contains a location id as a “FK” that is the “PK” of the
location microservice.
more to come...
was:
Microservices are an increasingly important and pervasive part of modern
architectures. By definition, a microservice’s APIs provide the only access to
a dataset—the schema of the underlying RDBMS, NoSQL db, etc is not exposed.
Therefore, it would be nice if Atlas enabled microservices to be discovered
along with other dataset types. The microservice typedef would include the
top-level endpoint, plus each of its API resources (GETs, POSTs, PUTs,
DELETEs), with their URI, parameters, JSON request and response objects, and
http response messages (200: Success, 404: Not Found, etc).
One might ask, why put this metadata into Atlas when it can already be
searched in a Swagger/OpenAPI repository? Three main reasons: 1) microservice
metadata can be searched along with all other enterprise datasets to find a
complete set of datasets of interest for, say, a cross-silo data science
investigation; 2) we can express lineage between microservices and other
datasets that either feed the db underlying the microservice or serve as
historical repositories for transactional microservices (eg S3 datalakes); 3)
we can express semantic relationships between microservices, eg the marketing
contact microservice contains a location id as a “FK” that is the “PK” of the
location microservice.
*** more to come ***
> Atlas typedef for microservices
> -------------------------------
>
> Key: ATLAS-3736
> URL: https://issues.apache.org/jira/browse/ATLAS-3736
> Project: Atlas
> Issue Type: New Feature
> Reporter: Barbara Eckman
> Assignee: Barbara Eckman
> Priority: Major
>
> Microservices are an increasingly important and pervasive part of modern
> architectures. By definition, a microservice’s APIs provide the only access
> to a dataset—the schema of the underlying RDBMS, NoSQL db, etc is not
> exposed. Therefore, it would be nice if Atlas enabled microservices to be
> discovered along with other dataset types. The microservice typedef would
> include the top-level endpoint, plus each of its API resources (GETs, POSTs,
> PUTs, DELETEs), with their URI, parameters, JSON request and response
> objects, and http response messages (200: Success, 404: Not Found, etc).
> One might ask, why put this metadata into Atlas when it can already be
> searched in a Swagger/OpenAPI repository? Three main reasons: 1)
> microservice metadata can be searched along with all other enterprise
> datasets to find a complete set of datasets of interest for, say, a
> cross-silo data science investigation; 2) we can express lineage between
> microservices and other datasets that either feed the db underlying the
> microservice or serve as historical repositories for transactional
> microservices (eg S3 datalakes); 3) we can express semantic relationships
> between microservices, eg the marketing contact microservice contains a
> location id as a “FK” that is the “PK” of the location microservice.
> more to come...
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
