As companies embrace microservices and serverless / lambda based architectures, the catalog of services and endpoints internally available is growing rapidly. The holy grail of microservices was always many small independent teams operating freely, spinning up new services, releasing and iterating with ease.
However, services — and therefore the teams that publish them — must work together to generate value. Each new service that appears provides functionality for others to consume —requiring developers to write integration code, fetching data and performing actions.
These integrations are often brittle & time consuming, and as new versions emerge, existing integration code must be upgraded to match. This requires co-ordination and planning, leading to lingering deprecated API’s that can’t be removed until all teams are upgraded.
Tooling has emerged which assists with parts of this — Service Discovery platforms like Eureka and Consul provide a live address book of where services are deployed. Swagger / OpenAPI have helped provide living documentation of what functions services can perform, and what inputs they need to do so. And tools like GraphQL and JSON-LD have emerged to encourage developers to think of their data as a graph of connected entities.
However, while these tools aid in improving discoverability and reducing boilerplate, they all still depend on developers reading the docs, and connecting the services manually. Even though your “User” service has a Swagger API, and is registered with service discovery, existing tooling is unable to know when it needs a “User”, how to leverage existing data, and then invoke your service. This is where Vyne comes in.
Vyne borrows from and builds upon these technologies, focusing on enabling autonomous integration between services.
Vyne — Automated, adaptive integration
Vyne has a simple, expressive API, that lets you express integrations as you would naturally: “Given [something I know], discover [something else]”
Vyne then leverages services & their metadata to find a way to perform your integration task.
Vyne knows about the services that are deployed across your enterprise — it knows what services exist, how to invoke them, and what functionality they provide. It can construct request objects, discover missing input values from other services, and use services to transform data between formats. Vyne is agnostic to the underlying protocols — JSON over REST / SOAP / gRPC / Protobufs are all covered. Support for streaming and async interactions is on the roadmap too.
And, as the underlying services evolve and upgrade their API’s, Vyne automatically adapts it’s solution to suit — no developer cycles required. This means that changes to services are much less likely to be breaking, reducing the friction & co-ordination required in release cycles, and allowing developers to focus on releasing functionality, rather than maintaining deprecated API’s.
Vyne leads to code that is both dramatically simpler, and signficiantly more resilliant to change. The following two pieces of code perform the same task — manually, and then on the right, with Vyne. The difference is clear.
In addition, Vyne has some powerful developer and monitoring tooling, to help visualise what solutions Vyne is using for integration tasks.
The below diagram, which was generated from the Vyne developer app — shows the solution from a Bank trade compliance app, where Vyne was used to discover a JurisdictionRuleResponse for a given trade. Vyne needed to construct a specific request object — and to do so, needed to discover two additional values — A ClientJurisdiction and TraderJurisdiction.
Where can I get it?
Vyne is still in it’s early stages. The first mileston release — 0.1, is coming soon, which provides an MVP of basic functionality. There’s an exciting roadmap of functionality planned out, on the way to a 1.0 release.
If you’re interested in leveraging Vyne to reduce the pain of integration, I’d love to hear from you — drop me a line at firstname.lastname@example.org.