Hello and thanks in advance.

First I want to provide some context to make answering my question easier.

We are using Google Cloud.

We got to a situation when our needs to be able to deploy updates easily for various parts of application bumped into our monolith architectures limitations. Our app is not super big, but it already has 2 physical services - backend (scope being updated), and caching server which caches data and makes search in a mongo-like way over data from Google Datastore.

We have 2 options here.

• "plugins" - like nanoservices running within same process which are developed in a way that these nanoservices do not know they are on the same process, all they know is a set of "plugins shell API" injected at activation of a nanoservice code. This shell gives the nanoservice access to a database, logging, configuration, routes registration, control events like refresh pages map and some metadata like website root url and root of static content deployed as supply stuff for a service version. Like https://static.server.com/deployments/foo/v2

• standard microservices on kubernetes where same API mentioned exposed to each service via "shell client" package deployed as part of container image.

In short, this is a common "infrastructure vs library" dilemma, often mentioned in articles about microservices i read.

For library approach I have some vision already on how to implement all that including hot modules replacement without stopping server but the more i read about kubernetes the stronger I feel that I am inventing kubernetes (or similar) wheel.

How I imagine that:

1) there is a router service which is single service exposed outside from the cluster. When a page is requested, and this service attached to the load balancer we already have as backend. It will handle authentication/authorization of outside requests, and pick the page to be rendered or API endpoint to be invoked. When a page requested, the related template is loaded, and data for pre-rendering is picked by calling related endpoint exposed by module service. When public API endpoint is picked, the matching service endpoint is called. There are few services, including:

• caching service (that service which deployed now at separate servers group, and what
• updates service, which process the module services version switch and provides API to do so via some UI for admins.
• modules services (one per modules). Each module exposes endpoints for providing preloaded pages data, endpoint to give list of pages routes to be registered, API endpoints implementations, and endpoint to list exposed API routes to be invoked through router service.
• router service which process external requests and dispatch them across other services when appropriate using cached routes map, updated in case if one of internal services broadcasts pages map refresh event, e. g. updates service.

What is stopping me from starting to use kubernetes right away is the lack of knowledge about how to implement the following scenarios:

1) only 1 microservice must be exposed outside cluster, the "routing service".

2) reuse builtin services discovery etc to communicate with services within cluster like caching server.

3) Cluster's router service would be attached to cloud load balancer we already have as a backend.