<story><title>The End of Microservices</title><url>http://lightstep.com/blog/the-end-of-microservices/</url></story><parent_chain><item><author>lobster_johnson</author><text>I see several people criticize microservices here. We&amp;#x27;ve been doing it for about 6 years and are extremely happy with it.&lt;p&gt;A core principle which a lot of people and articles ignore, though, is &lt;i&gt;reusability&lt;/i&gt;. I bring this up on HN every time there&amp;#x27;s a discussion about microservices, yet I&amp;#x27;ve never seen any discussion about it.&lt;p&gt;Essentially, you build out the backend to act as a library for your front end. So we have login, storage, analytics, reporting, logging, data integrations, various forms of messaging, business-structural stuff, etc. etc. all bundled up as separate services. The front ends just use these services to build a coherent product. The front end is the monolith: The microservices are the cloud.&lt;p&gt;For example, let&amp;#x27;s say I wanted to create a new product called &amp;quot;Hacker News&amp;quot;. I&amp;#x27;d use our storage service to store links and comments. I&amp;#x27;d use the login service to let users log in. I&amp;#x27;d use our messaging service to send notifications about things like verifying your email or send password resets. I&amp;#x27;d use our analytics backend to emit events for reporting. And so on. I could easily build the whole thing without writing a single line of backend code, and without setting up a new cluster, because every backend service has been designed with multitenancy from the start.&lt;p&gt;This ability to piggyback on a platform of services where I think the real utility of microservices lies. Everything else — fine-grained scalability, smaller surface for tests, language-independence, swappable implementations, etc. etc. — are secondary to that.</text></item></parent_chain><comment><author>lmm</author><text>Separate pieces of functionality into small reusable libraries? Great. Enforce separation of each library&amp;#x27;s internals from each other one? Great. Ensure each database is owned by one and only one service? Great.&lt;p&gt;Invoke those services via RPC-over-HTTP? Why???</text></comment>
<story><title>The End of Microservices</title><url>http://lightstep.com/blog/the-end-of-microservices/</url></story><parent_chain><item><author>lobster_johnson</author><text>I see several people criticize microservices here. We&amp;#x27;ve been doing it for about 6 years and are extremely happy with it.&lt;p&gt;A core principle which a lot of people and articles ignore, though, is &lt;i&gt;reusability&lt;/i&gt;. I bring this up on HN every time there&amp;#x27;s a discussion about microservices, yet I&amp;#x27;ve never seen any discussion about it.&lt;p&gt;Essentially, you build out the backend to act as a library for your front end. So we have login, storage, analytics, reporting, logging, data integrations, various forms of messaging, business-structural stuff, etc. etc. all bundled up as separate services. The front ends just use these services to build a coherent product. The front end is the monolith: The microservices are the cloud.&lt;p&gt;For example, let&amp;#x27;s say I wanted to create a new product called &amp;quot;Hacker News&amp;quot;. I&amp;#x27;d use our storage service to store links and comments. I&amp;#x27;d use the login service to let users log in. I&amp;#x27;d use our messaging service to send notifications about things like verifying your email or send password resets. I&amp;#x27;d use our analytics backend to emit events for reporting. And so on. I could easily build the whole thing without writing a single line of backend code, and without setting up a new cluster, because every backend service has been designed with multitenancy from the start.&lt;p&gt;This ability to piggyback on a platform of services where I think the real utility of microservices lies. Everything else — fine-grained scalability, smaller surface for tests, language-independence, swappable implementations, etc. etc. — are secondary to that.</text></item></parent_chain><comment><author>pjmlp</author><text>I have been doing it since the early 90&amp;#x27;s.&lt;p&gt;It is called unit, module, package, library.&lt;p&gt;No need to put some network layer, with its own set of problems, between method&amp;#x2F;function calls.</text></comment>