How I upgraded from go-Micro V2 to Micro V3

[camba1]

I upgraded my sample application from go-micro v2 to Micro v3. While It is not a production app, but it may provide some context on the steps to upgrade. You can find the original v2 app here and the v3 app here.

Upgrading the code

In general terms, this is what I did to upgrade the application:

1.- install the newer version of the micro protobuf generator and then regenerate the proto files normally

go get github.com/micro/micro/v3/cmd/protoc-gen-micro

2.- Update the imports in the code. The biggest change here is that the functionality in github.com/micro/go-micro/v2 is now under github.com/micro/micro/v3/service

3.- For core services like setting up a broker, you no longer use options for initialization ( service.Options().Broker), but instead import github.com/micro/micro/v3/service/broker and use it with broker.DefaultBroker

4.- Instantiating the server is now done with:

service := microServ.New(
   microServ.Name(serviceName),
)

(microServ is an alias for github.com/micro/micro/v3/service)

While in V2, it used to be :

service := micro.NewService(
 micro.Name(serviceName),
)

5.- Since Micro does not use plug-ins, I needed to review my code. In my project, I use NATS as a broker and Redis as a store for caching.

NATS:

Since NATS is also the default broker in Micro, it just worked out of the box (I provide the address to my NATS instance in the Environment variables)

Redis:

For Redis to work as a store, I brought the old plugin code into my project as a new package and hooked it up to work as a Micro store in the main function:

microStore.DefaultStore = globalCache.NewStore(microStore.Nodes(glCacheAddress))

glCache.Store = microStore.DefaultStore

where:

microStore is an alias for github.com/micro/micro/v3/service/store

globalCache is the package that holds the old Redis plugin (which I modified to use Redis v8 instead V7)

glCacheAddress is the address to my Redis instance

glCache is a struct that holds an instance of the micro store (github.com/micro/micro/v3/service/store)

Note: Before setting up Redis to run in V3, I had commented out the references to Redis and I was gladly surprised that the app ran properly using the default store instead.

6.- While doted service names like are still supported when running locally or in docker, they are not supported in K8s. Since I do want to run in K8s, I dropped the dotted names and replaced it just simple names (e.g.: moved goTemp.api.user to user)

Running the app

While the application upgrade was mostly straight forward, the biggest change was the mindset change on how to run run the in V3 vs V2.

In V2, I was running everything on my Mac with docker-compose up in dev and eventually pushing to K8s using my own K8s manifests.

In V3, Micro runs all the services. This means that while I still do docker-compose up for bringing up my DBs, Redis and Nats, the services are run by Micro:

1.- Locally, I use micro run to build, and run each of the services.
2.- With Docker, I mount a volume with the code and then use micro run inside the micro/micro container. I guess one could also use something like docker exec <microContainerName> micro run <addressToServiceGitRepo>instead of using volumes.
3.- In K8s, I still use my own manifests to bring up the DBs, NATS and Redis, but to run Micro I deployed the Micro Helm chart. I then used port-forwarding to enable micro run to interact with the Helm chart.

When running in K8s, micro run automatically deploys the micro-services as pods and sets up the necessary network to be able to communicate with the micro-services using the API gateway. At that point you can access the app either by port-forwarding to the proper port in the api gateway or by creating an ingress (which is what I did).