<story><title>Don&apos;t start with microservices – monoliths are your friend</title><url>https://arnoldgalovics.com/microservices-in-production/</url></story><parent_chain><item><author>jhoelzel</author><text>There is a lot of talk about monoliths vs microservices lately.. I just want to throw into the ring that you can do both at the same time. easily. And noone is going to kill you for it either.&lt;p&gt;maybe we are getting caught up in sematics because its christmas, but &amp;quot;monorepo&amp;#x2F;monolith&amp;#x2F;microservices&amp;#x2F;etc&amp;quot; is -just- the way you organize your code.&lt;p&gt;Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice.&lt;p&gt;Did you write a 150 repo application that can not be deployed seperatly anyway? welp thats a monolith.&lt;p&gt;You can also build a microservice ecosystem without kubernetes on your local network. We have done it for years with virtual machines. Software defined networking just makes things more elegant.&lt;p&gt;So dont stop using microservices because its &amp;quot;hard&amp;quot; or start writing monoliths because its &amp;quot;easy&amp;quot;, because none of that is true in the long run.&lt;p&gt;What is true is that you have a group of people trying to code for a common goal. The way you reach that goal together defines how you organize your code.</text></item></parent_chain><comment><author>sdevonoes</author><text>&amp;gt; Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice.&lt;p&gt;But the 15 lines of Golang are not just 15 lines of Golang in production. You need:&lt;p&gt;- auth? Who can talk to your service? Perhaps ip whitelisting?&lt;p&gt;- monitoring? How do you know if you service is up and running? If it&amp;#x27;s down, you need alerts as well. What if there is a memory problem (because code is not optimal)?&lt;p&gt;- how do you deploy the service? Plain ansible or perhaps k8s? Just scp? Depending on your solution, how do you implement rollbacks?&lt;p&gt;- what about security regarding outdated packages the Go app is using? You need to monitor it as well.&lt;p&gt;And so on. The moment you need to store data that somehow needs to be in sycn with the monolith&amp;#x27;s data, everything gets more complicated.&lt;p&gt;Production stuff is not just about lines of code.</text></comment>
<story><title>Don&apos;t start with microservices – monoliths are your friend</title><url>https://arnoldgalovics.com/microservices-in-production/</url></story><parent_chain><item><author>jhoelzel</author><text>There is a lot of talk about monoliths vs microservices lately.. I just want to throw into the ring that you can do both at the same time. easily. And noone is going to kill you for it either.&lt;p&gt;maybe we are getting caught up in sematics because its christmas, but &amp;quot;monorepo&amp;#x2F;monolith&amp;#x2F;microservices&amp;#x2F;etc&amp;quot; is -just- the way you organize your code.&lt;p&gt;Developing a montolith for years but now you have written a 15 line golang http api that converts pdfs to stardust and put it into on a dedicted server in your office? welp thats a microservice.&lt;p&gt;Did you write a 150 repo application that can not be deployed seperatly anyway? welp thats a monolith.&lt;p&gt;You can also build a microservice ecosystem without kubernetes on your local network. We have done it for years with virtual machines. Software defined networking just makes things more elegant.&lt;p&gt;So dont stop using microservices because its &amp;quot;hard&amp;quot; or start writing monoliths because its &amp;quot;easy&amp;quot;, because none of that is true in the long run.&lt;p&gt;What is true is that you have a group of people trying to code for a common goal. The way you reach that goal together defines how you organize your code.</text></item></parent_chain><comment><author>Pamar</author><text>Maybe it is just me, but I always understood that properly designed microservices have &lt;i&gt;their own specific datastore&lt;/i&gt;, which is &lt;i&gt;not&lt;/i&gt; shared with other microservices even if these all collaborate to the same process.&lt;p&gt;If this is actually (still) true, that means that &amp;quot;the way you organize your code&amp;quot; is a bit simplistic. Your example of an &amp;quot;http api that converts pdfs to ...&amp;quot; is surely a valid example of a microservice, but most business products have to handle much more &amp;quot;state&amp;quot; than those, and this will create further complications which go far beyond &amp;quot;how to organize your code&amp;quot; (and make monoliths more appealing).</text></comment>