From a Ruby monolith to microservices in Go

Rewriting a monolithic platform as a set of microservices will almost always result in improvements from every perspective. You&#x27;re replacing legacy code with new, cruft-free code; you&#x27;re de-coupling parts of the system; you&#x27;re building a more scalable design.<p>For example, if you&#x27;re in the situation where you&#x27;ve gone from 12GB to 5MB of memory consumption, then you have a design issue and not a language one. That&#x27;s not Ruby&#x27;s fault.<p>We are also in the process of converting several monoliths into a microservice-driven system, but we are doing so with Ruby. It remains great language to use for building web apps, and I suspect some of the push back against it is caused by a dislike of the cliché giant Rails monolith that we&#x27;ve all come across, with hundreds of gem dependencies and so on. Rubby and Rails have a habit of encouraging such bad designs primarily through ease of use, but it&#x27;s hard to see that as a problem with Ruby.<p>Go is a good tool for doing the same, and single-binary deployment is pretty magic. I&#x27;m sure it&#x27;ll be supported for ages, so if you want to re-tool to use that then go for it! But Ruby&#x27;s a viable option too, and it&#x27;s important not to place blame for bad app design in the wrong place.

Many folks in this thread are expressing that it&#x27;s the OP&#x27;s fault and not Ruby&#x27;s.<p>The OP made his post as objective as possible, politely written and nobody is loosing his face, neither Ruby as a language nor the Ruby community. But people are still resentful and fire back.<p>I believe it&#x27;s not a discussion about Ruby anymore, its strengths, its weaknesses and wether Ruby still fits in 2015—no it&#x27;s the fear of people that their core competence might be less worth in future. That all the time and energy they invested all the years into one language might be not a good investment anymore. The fear that better tech will replace their tech and that they have to start at zero again.<p>I know I am going to be heavily downvoted for this post. Before you downvote just think a second again why you&#x27;ll downvote me.

Ruby is the new Java everyone is bashing. Go is the new Ruby everyone is hyping.<p>If you replace every mention of Ruby with Java, and every mention of Go with Ruby in the comments on HN, then you&#x27;ve invented a time machine to go back 10 years.<p>And if you do this with C, welcome to 1995.

So many wrongs and confounding variables that I don&#x27;t even know where to begin but I&#x27;ll try anyway.<p>1) Ruby is a complex language: Ruby is quite simple. Everything is an object, every method call is a message send that follows the exact same protocol of dispatch. Also, completely irrelevant to the main thrust of the article.<p>2) Memory consumption and speed: Can&#x27;t really refute anything since by their own admission they were running a monolithic system.<p>3) Concurrency: Plenty of options. I like celluloid personally and if you switch to JRuby then you can do all sorts of other stuff as well with automatically managed thread pools.<p>4) Backcompat: Ruby is not an enterprise ecosystem. Some people call that speed and agility. In their case they really should have gone with Java since they are basically serving an enterprise customer. This is not a knock on Java. I think the language and its ecosystem is by design made for stuff like this.<p>5) PDF generation: I&#x27;m guessing the Ruby code was calling some C library to do the rendering and they swapped out all of it for Go. I don&#x27;t know what library Go is using to render PDFs if it is the same library then there is something interesting happening here. If it is a different library then they are comparing apples and oranges and there&#x27;s nothing to see here.<p>6) Alert service: Completely bound by I&#x2F;O so doesn&#x27;t matter what language you use. Bad design for keeping many processes around because you only need to spin them up during spikey times which can be easily handled with better engineering. Also eventmachine and celluloid for the worker internals would have been another option so again they didn&#x27;t do their research.<p>7) Gradebook service: No idea again. Thin on details so nothing to refute really.<p>8) Deployment: Sure. Why not. Single binary is easier or JRuby and a single jar which is just as easy.<p>In conclusion, they re-wrote everything and I&#x27;m sure removed a lot of cruft in the process and called it a victory for Go. In a year or so they&#x27;re going to run into similar issues and Go is not going to save them because from what I read all I saw was bad engineers blaming their tools.

Every time I read something like that, I get the feeling that &quot;Monolith to Microservices&quot; is the pattern and the language doesn&#x27;t matter.<p>At the beginning, a Monolith has huge advantages: easy to deploy, all in one place, smaller operational overhead, easier to manage with unclear requirements.<p>Later, it&#x27;s easier to find out what you can split out and you can learn how to route and manage things piece by piece.

<i>After refactoring the alert feature into a Go microservice, they’ve seen the following improvements<p>The same number of workers (that required 12 GB in Ruby) now requires just 5 MB of memory.</i><p>Not that I don&#x27;t approve of pro-Go articles, but doesn&#x27;t this maybe indicate that something was wrong or inefficient in the Ruby implementation?

Over the last few years, I&#x27;ve tried implementing a few things like this in Go, but the problem I keep running into is the tooling. It&#x27;d be awesome to know which modules they used for things like URL routing and application structure. There seems to be a lot of options with no clear winners.<p>Rails is opinionated, yes, but I&#x27;m generally pretty satisfied with their opinions, and it&#x27;s nice to have a full Batteries-included package.

From the looks of it I assume they are using HTTP&#x2F;1.x as the communication protocol. I&#x27;ve always wondered why most use HTTP for micro-services instead of JSON-RPC (or any other encoding) over a TCP&#x2F;IP socket. What are the benefits?

So a monolith application gets ported to microservices from an interpreter based version of Ruby to a compiled version of Go and the author is surprised about the gains.<p>Why do people keep getting amazed about the performance they get when using native code in their applications instead of a naive interpreter?<p>Not bashing Go, the title could be &quot;From a Ruby monolith to microservices in &lt;pick your language with native compiler available&gt;&quot;.<p>Hey, this could probably even be possible in Ruby, if something like RubyMotion was generally available.

Would someone care the elaborate on the following?: &quot;They use nginx to route requests to either the microservices or the main Ruby app... The Go microservices treat the Ruby application as an API client or upstream proxy, which allows authentication to be simple.&quot;<p>What I read this to mean is that the Ruby app accesses the microservices over HTTP with some kind of token-based authentication. This would make sense if there some form of shared session store which each microservice could validate the token against. What I&#x27;m confused about is how nginx fits into this? Is it routing requests directly from the client to microservices? Or is it a proxy layer in between the Ruby app server and the microservices which allows the Ruby app to forward auth-token information? In the former scenario, would the Ruby app server be pinging the same nginx instance that forwards it requests in the first place?

I&#x27;m trying to decompose a Ruby monolith into microservices, but is it necessary to change languages? For my use case, I&#x27;m less concerned with languages than I am with libraries (AWS library, Sidekiq, Devise, deployment toolchains, etc).

As they say: &quot;Your new boy&#x2F;girlfriend is better because you are better.&quot;

Going from 12GB to 5MB of memory consumption could probably have been achieved through moving the alerting components to a dedicated Ruby (non-Rails) &#x2F; Linux script configured to read their queue.<p>Time taken: 1-2 days.<p>Their high memory consumption was caused by large numbers of unneeded dependencies (e.g. Rails) included in their alerting components. By refactoring so drastically into a separate Go service, they may have squandered tens of thousands of dollars of company&#x2F;investor money in retooling, retraining and learning a new environment. Good for the programmers, toxic for the company.

Ruby enthusiasts seem to get apoplectic at any mention of a posting where someone chooses another language over Ruby. I&#x27;m sure Ruby is just great at what it does, but aren&#x27;t we always talking about the right tool for the job?<p>I don&#x27;t think anyone disagrees that refactoring and evolving the code would have resulted in gains even if they stayed in Ruby. I&#x27;m sure most of us would even agree that if you wrote something, then immediately scrapped it and started over, you might already be able to improve on your original based on some new knowledge you&#x27;ve gained from the experience.<p>When a company does this, they not only learn new things about the language they are converting to, but they are gaining new and valuable insight into the language they already have used. Posts like this are valuable to all of us because they are sharing their experiences; whether you agree with their choices or not.

If you move from Ruby to Go and this works better for you, then choosing Ruby in the first place might - if it was not about a prototype or getting VC money or only found Ruby developers - be a failure on your part.

Companies that invest in rewriting everything from Ruby into Go instead of working on the business model seem to have a lot of money and a secure future and no competition.