Service Weaver, Monolithic or Microservice?

Everyone was in love with microservices, which was the simple way to fix every issue on planet Earth. Everything was ready for that: lambdas, cloud functions, EKS, GKE, Kubernetes, and many other tools and components appeared on the market to implement microservices everywhere.

But reality is not like dreams, and when everyone started to deploy microservices, they began to discover all the issues.

When you end up with a huge number of components, interconnections are a nightmare.

When you want to update a common library, it could end in total chaos.

Code is independent, and sometimes parameters to interconnect are not known.

APIs could end in a crazy mess.

So, what is the solution? Back to monolithic environments? Code everything in Ruby? No idea, but at least since March 2023, we have had a new option from Google. This is a library called Service Weaver and allows us to write, build, and deploy distributed applications in the same repo.

The idea is simple. You write your code in Go as a simple monolithic module, and a set of deployers will allow you to deploy in different microservices, on your machine, or even in a GKE cluster; okay, I wasn’t able to make this part work.

Let's start with our example.

First, we install wget, which will be needed later to download Go. This installation will take a while, so let’s speed up. Now we download the Go tar file. And now we can unpack the tar file in /usr/local/go. We export the new PATH to use the binary.

Now is when we need to install the library with go install. Everything is working fine, but in the end, we will see that there is an issue with sqlite3. I tried to install sqlite3 with Go, with and without a version and failed, and the only way to make it work was by executing go install from Service Weaver's git code. Now our go install works fine.

When we try to execute, the weaver command fails, but in this case, the solution is simple: export the PATH. Now weaver works, and we can create our hello folder and our Go module where our code will be executed.

After that, we create our main.go file, where we will include an init, a listener, and the query we will show.

Now we can execute go mod tidy and go run. Now our web server is up and running, and to test it, we sent it to the background, and with curl, we checked that everything was fine. We kill the process, and after this simple example, let’s jump to something more complex.

We are going to create a file called reverser.go that is going to reverse the strings. In the file, we add our code that, as we can see, will reverse the output. The next step is in the main.go file. We need to remove the previous output and make a call to our reverser module.

With weaver generate and go run, our app starts, and now if we move to the background and execute curl, we can see that the output is reversed. Now after we start again because we killed it by mistake, we can run weaver single status and see all the components, listeners, and the app. Cool.

The last example is the multiprocessor. We are going to execute every component in a different process. To do that, we need to create a tool file that describes the process. After that, we need to execute go build, now weaver multi deploy weaver.toml and what will happen is the same as before, but this time we can see two different processes, one per component.

If we send it to the background as always and execute curl to the URL, we will have the same output, but when we run weaver multi-status, we can see that every component has a different PID, and if you remember, before, it was only one PID.

I hope that you enjoy this and we will work to try to make the GKE component work because at least the documentation promises that automatically every component goes to a different pod.

Here' the same article in video form for your convenience: