Why our team cancelled our move to microservices

Practically every technology decision has pros and cons.<p>I think that if you can&#x27;t think of a good reason <i>not</i> to use some technology, then you don&#x27;t understand the technology well enough yet and you shouldn&#x27;t try to use it in production yet. It may be what you need, but thinking that &quot;everything must switch to this&quot; is usually a huge warning signal that cargo cult engineering is happening instead of real engineering.

&gt; We have approximately 12 developers spread across 2 feature teams and a support team.<p>If I were consulting for this company, I would have told them to stop right there, microservices are probably not for them. Unless you build from the start for microservices on something like AWS lambda, doing with such a small team would be really hard.<p>And as they eventually discovered, a lot of unnecessary overhead for such a small team.

Microservices shift complexity from code to operations - microservices don&#x27;t remove complexity - they spread it wider, making the whole more complex.

Monolith vs microservice is not a dichotomy, it&#x27;s a spectrum (as it is with so many other things). Individual microservices can still become monolith-y and become responsible for doing a Lot of Things (TM).<p>That being said, the biggest hurdle in a re-architecture project like this is usually in the &quot;n=1 -&gt; n=2&quot; stage, and &quot;n=2 -&gt; n=5&quot; is a lot easier: once you add service #2, you learn how to set up telemetry, permissions, billing&#x2F;chargeback, alerting, etc. The next few are just repeating the same process.

The term &quot;Monolith&quot; was devised by people who wanted to brand microservices as newer and superior.<p>It&#x27;s almost as if in order to succeed these days you need to discredit and disparage your competition rather than simply having a better product, and that&#x27;s why I don&#x27;t buy into buzz words at all.<p>If it&#x27;s not broken, don&#x27;t fix it... Microservices are relatively new and unproven. The way the world has rushed to dive into microservice infrastructure only highlights reckless spending and waste that is characteristic of overpriced goods and high taxes that are constantly in turn thrust upon us, as consumers.<p>Microservice architecture is also inherently designed to lock a customer into very specific tools that make future migration to any other platform a very costly decision in most cases... Thereby locking a customer into platform-specific dependency. Microservices architecture also introduces the ability for providers to charge for each specific service as a utility... Instead of being charged for one single server annually, on microservices you can be charged for many individual components that run your app independently, and when usage skyrockets, it&#x27;s a sticker shock that you can only stop by going offline.<p>We have also seen enough failures and pain points within microservice and even cloud architectures over the past two years alone to raise questions about whether or not it it indeed a better solution.<p>We need to stop disparaging traditional (non-cloud) hosting and solutions that aren&#x27;t obsolete at all in this manner, and focus on what works, what is secure, and what is cost effective in order to stay sustainable into the future.<p>The more we allow marketing minds to take control of our IT decisions over reasonable technical minds, the more costly it will be to us all over time, no matter what salary we make. Bog tech firms will hate me for saying this, but any human in the chain can tell that reckless drive for weak&#x2F;vulnerable&#x2F;costly&#x2F;and over-complex IT solutions cannot be sustained as a viable long-term business sales strategy anyway.

Going from a monolith to a micro-service setup is essentially my idea of a Christian hell. Swirling depths of pain and uncertainty interspersed with screaming and urgency. There is no rest. No one knows when it will end.<p>I think this is because our monoliths are so complicated they hide away our technical debt like monstrous Jack-In-The-Boxes. When you start breaking it into chunks all of these issues come exploding out of them. Suddenly huge bugs that no one noticed or cared about are showing up in testing. Old libraries that sat dormant wake from their crypts to harass and torture junior developers. Forgotten binaries whose source code was lost with the changeover from ancient source control software to GIT starts showing up security issues in VeraCode.<p>Really, a well coded monolith is just a bunch of micro-services on the same server communicating through memory. In reality it&#x27;s more of a Lich who&#x27;s eyes shine with the light of the tortured souls of fallen QA testers and developers.

A few points I&#x27;d like to make:<p>1. You can&#x27;t &quot;migrate&quot; to microservices from a monolith. This is an architectural decision that is made early on. What &quot;migrating&quot; means here is re-building. Interestingly, migrating from microservices to a monolith is actually much more viable, and often times just means stick everything on one box and talk through function calls or IPC or something instead of HTTP. Don&#x27;t believe me? See this quote:<p>&gt; The only ways we could break down our monolith meant that implementing a standard ‘feature’ would involve updating multiple microservices at the same time. Having each feature requiring different combinations of microservices prevented any microservice from being owned by a single team.<p>Once something is built as &quot;one thing,&quot; you can&#x27;t really easily take it apart into &quot;many things.&quot;<p>2. Microservices does <i>not</i> mean Kubernetes. The idea that to properly implement microservices, you need to set up a k8s cluster and hire 5 devops guys that keep it running is just flat-out wrong.<p>3. Microservices are &quot;antifragile,&quot; to use a Talebian term. So I think that this paragraph is actually incorrect:<p>&gt; This uncertainty made creating microservices more fraught, as we couldn’t predict what new links would pop up, even in the short term.<p>A microservice is way easier to change (again, if designed properly), than a huge app that shares state all over the place.<p>4. What&#x27;s the point here? It seems like the decision was hasty and predictably a waste of time. Any CTO&#x2F;architect&#x2F;tech lead worth his or her salt would&#x27;ve said this is a bad idea to begin with.

&gt; A benefit of microservices is that each team can be responsible for releasing their services independently and without coordination with other teams.<p>Sounds almost sarcastic. How do you deliver API changes without alerting other teams?

Their architecture didn&#x27;t provide any clear boundaries to be sufficient for microservices, however that isn&#x27;t the case for many medium to larger sized projects.<p>(By the way, just because there&#x27;s still quite a bit of coupling between services, doesn&#x27;t mean there aren&#x27;t clear boundaries - Microservices can communicate with one another all the time and still be justified in being decoupled)<p>There isn&#x27;t an absolute answer to monolith vs microservices - It depends case by case.<p>Instagram was built using Django and I&#x27;m unsure of ig&#x27;s architecture today, but it remained monolithic for a very long time (at least till late 2019), and if that architecture sufficed for Instagram, I&#x27;m sure it would suffice for many other projects.<p>However, still, it&#x27;s not a this or that as many of the comments here would seemingly imply - Again, it&#x27;s HEAVILY dependent on the case.

&gt; Microservices allow your team to have control over the full stack they require to deliver a feature.<p>This is honestly pretty rare, at least in my experience. What I have seen is that organizations will buy in to the microservices hype, then dictate to their teams what stacks, deployment paradigms, etc. (sometimes even down to the sprint cadence) are acceptable.

I think that moving a monolith to a microservices architecture is only justified if the organization size is large enough, so there are different business teams&#x2F;departments. In that scenario, each team&#x2F;department will own a microservice and this will speed up the development on each team. Still, every time there is a change in any microservice API, that will require coordination. For a small company(12 developers), I can&#x27;t see the benefit.

We have a hybrid model: modular monolith + microservices. It has worked well so far.<p>The core of the product is found in the monolith. We use bounded contexts (&quot;modular monolith&quot;) with strictly separated concerns. There are no immediate plans to split the core into microservices (unless absolutely necessary) because the logic between modules is too intertwined and coupled. Splitting the core into microservices would overcomplicate everything for us, and the performance would suffer.<p>As for microservices, we usually use them for:<p>1) critical infrastructure which needs to be fast and scalable (for example, the auth service)<p>2) isolated helper services, for example a service which allows to integrate with third-party platforms<p>3) isolated features&#x2F;products which minimally interact with the rest of the system; for example, we have an optional feature which shares the UI with the rest of the application, and uses some of its data, but ultimately it&#x27;s a product of its own, it&#x27;s developed separately with its own codebase, and integrated into the monolith<p>So I think it&#x27;s a false dichotomy that you either have a monolith, or microservices. You can use both, they can complement each other.

Just last week I found an interesting and unexpected (for me) advantage of microservices. We have two monoliths written in different stacks&#x2F;frameworks, and developed by different departments. Monolith #1 is being split into microservices, we already have around 20 microservices. Monolith #2 kind of lags behind, and there are certain problems that they encountered, which are already solved in one of the microservices split from monolith #1. The solution I came up with is to simply reuse the microservice from monolith #1 in monolith #2 (the service is isolated and self-contained so it doesn&#x27;t care who uses it). I found it to be a rather elegant and simple solution for cases when you want to reuse an implementation but can&#x27;t package it into a library because clients have different stacks.

There is a big misconception that a monolith has to be fully deployed every time. A well designed monolith can be partially deployed.

I think many microservice implementations are more complex than necessary but I also am extremely skeptical of someone’s competence if the database is on the same compute instance as everything else

&gt; Recently our development team had a small break in our feature delivery schedule. Technical leadership decided that this time would be best spent splitting our monolithic architecture into microservices.<p>Maybe redesigning the architecture of the product just because there is time vs. there is a pain point&#x2F;problem that needs solving is already a red flag. In this context it feels like “micro services” was a hammer looking for a nail, and they had no such nail.<p>Edit: typo

I always start with a monolith while keeping microservices in mind. Have clear communication boundaries, avoid shared state as much as possible, consider asynchronous and parallel processing needs, etc.<p>Actor systems are a natural fit for this eventual de-coupling. What starts as a simple actor w&#x2F; a mailbox can eventually grow to a standalone REST service with minimal headache in architectural refactoring.

Do you have an auth service that does not do API? Does your API ask the auth rather than reaching into the auth table to see who is authorized? When you send an email, do you do it inline or do you trigger a push to a queue with separate worker(s)? Does your externally accessible API talk to internal services using a predefined protocol rather than reaching directly into a database?<p>Congratulations, you have micro services!<p>As someone who have driven the migration from a monolith (just set environment variables and magically the same codebase becomes auth, notifications, workers, web and API and the same codebase reaches into every single database and talks to every single service) into micro services because a simple features were taking months to implement, I can confidently say that even today, in 2022, an average organization does not have the tooling or the team to do a monolith. Monolith is a cargo cult. Break stuff into an digestable chunks, externalize your own internal libraries if they are shared, version the interfaces and stop worrying about microservice complexities.

Some perspective from Netflix. Around 10k employees [1] (could not find how many are working with software), more that 1000 microservices [2].<p>The second article also provides some insight to the services. Those make sense for me - they truly sound like independent, relatively large pieces of software. Not like “LoginService” type of things you sometimes see.<p>Few examples: 1)Create a main menu list of movies 2)Determine your subscription status to provide content relevant to that subscription tier 3)Use your watch history to recommend videos you may like<p>[1] <a href="https:&#x2F;&#x2F;www.macrotrends.net&#x2F;stocks&#x2F;charts&#x2F;NFLX&#x2F;netflix&#x2F;number-of-employees" rel="nofollow">https:&#x2F;&#x2F;www.macrotrends.net&#x2F;stocks&#x2F;charts&#x2F;NFLX&#x2F;netflix&#x2F;numbe...</a> [2] <a href="https:&#x2F;&#x2F;www.cloudzero.com&#x2F;blog&#x2F;netflix-aws?hs_amp=true" rel="nofollow">https:&#x2F;&#x2F;www.cloudzero.com&#x2F;blog&#x2F;netflix-aws?hs_amp=true</a>

My team built an application using a multiple not so well thought out microservices, and it ended up creating a lot of unnecessary maintenance and complexity and has been a long term pain. I wish we had just built within a single service.<p>But, my company split out a much older, larger monolith over many years into separate services with clear ownership across a variety of teams. This has been a huge benefit, coming from clear ownership, API boundaries, and separation of concerns.<p>So neither monolith or microservices are a clear winner. It depends on context. An easy litmus test, IMO, is that a single dev team will get little to no benefit from managing many microservices, but a company scale problem will get a lot of benefit from having each team manage and deal with an independent service.

From what I gather microservices architecture works in a large enough organization where there are enough teams to manage each individual microservice. If your business logic allows for nicely isolated modules, which can almost act as separate &quot;products&quot; that each individual team builds and then the rest of organization dogfoods, then sure. But if there&#x27;s a single underlying dependency, that won&#x27;t work. If there&#x27;re complex interdependencies, it won&#x27;t work (as nicely). If you have a small team, it won&#x27;t work. If requirements frequently change, it won&#x27;t work.<p>Ultimately works well if you have something very high scale with enduring set of requirements.

&gt; We have approximately 12 developers spread across 2 feature teams and a support team.<p>I started work at Amazon in 2001 when they were near the beginning of the transition to microservices. I think they had a couple thousand software developers at that time.

As with all architectural patterns there are tradeoffs. Microservices for one thing are not functions. Granularity is an important concern.<p>A DDD approach up front will help with granularity.<p>The other leg is serverless support. Without that you are stuck with maintaining infrastructure in tandem with all the other considerations, which takes a lot a specialists - lots of engineers.<p>Definitely a game of scale and not for small organizations.<p>However, if scale is the key ingredient for success and the value proposition is based on scale, then this kind of architecture is worth looking at.<p>That said, all shops are not Netflix or AWS...

&gt; Because we couldn’t isolate any of our services properly, this was going to mean that we would be left with a significant amount of duplication. For example, we identified one particularly complicated and essential piece of business logic that would have to be copy-pasted and maintained across 4 of the planned microservices.<p>Wouldn&#x27;t this piece of business logic be best placed in an import-able module? Then, that module would be imported by those 4 microservices and problem solved ...? I don&#x27;t really understand this argument.

Why would you consider microservices if you are only 12 developers?

I&#x27;m not speaking from experience here, but it seems like rather than &quot;moving to a microservices architecture&quot; it would perhaps be better to think more in terms of &quot;splitting out specific functionality X into an independently deployable and hostable service, which should alleviate the specific problem Y that we&#x27;ve been experiencing due to their being too closely coupled&quot; and if there are no obvious X and Y then maybe the &quot;monolith&quot; is fine?

An example to show you how easily the idea of &quot;boundaries&quot; breaks down...<p>We need to show customers a list of products they registered in a scrollable list. The product registration data is basically a product ID, the user ID and date of registration. It does not contain actual product details.<p>The product registration data is in one database whilst the product details data is in another. Each has their own data store, API and team.<p>So it&#x27;s a classic join problem. To show the customer a list of their registered products including the product name and a thumbnail of it, a call has to be made to get the list of product registrations, plus several dozens of individual calls to get the product details (name, picture), one call for each item.<p>It&#x27;s terrible UX. Slow and jumpy.<p>Yes, I know...a monolith would also struggle with this scenario as the data sources are split for organizational reasons not relevant to discuss here. You might also create a new service that somehow joins these data sources, although I&#x27;m sure that might be an anti pattern.<p>What is the best solution isn&#x27;t really my main point, rather that boundaries are not typically respected, whether it is at data level or at service level. The real world doesn&#x27;t care because data and services are not products. Furthermore, when designing these boundaries you absolutely can not foresee how they&#x27;re going to be used.<p>As such, it is incredibly common that for an app&#x2F;web developer, the API fails to meet needs. It doesn&#x27;t have the data, you get too much of it, or combinations of data are not efficient to get. In my experience, this is the norm, not the exception.<p>There&#x27;s another downside. Now that your services are maintained by autonomous teams, guess what...they really are autonomous. That extra data that you need...sorry, not on our roadmap. Try again in 6 months. Sorry, another team is building a high prio mobile app, their needs come first.<p>A boundary is not a feature. A boundary is a problem. It makes everything inefficient, slow and complex.<p>I&#x27;m not closed minded, there&#x27;s a time and place for micro services but I would consider it a last resort. Only do it when having explored all options to avoid it and when things really are bursting at the seams.

The #1 reason to split your serving architecture into microservices is that your application can&#x27;t fit in 1 server&#x27;s memory.<p>If your application fits in 1 server, you have a choice, otherwise you don&#x27;t.<p>If your application can&#x27;t fit in 1 server and you can&#x27;t split it up, you have to refactor so it can.<p>If you can&#x27;t refactor your application to have isolated domains, aka your domain is so complex it must take up an entire server, you have a serious problem.<p>Clustered applications are unavoidable.

&quot;Microservices had been sold to us as the ideal architectural for perhaps a year now.&quot; When he learn that there is no ideal architectural in software? )

Monolith almost sounds cool to me. To be honest.<p>I remember hearing a story (from a person inside said company) about a reasonably sized company with a 2 (really 1) man dev team (they contract for most of their needs) and how excited the company was to move their internal stuff to microservices and off a monolith.<p>He looked at me like i was insane when i said a monolith would work better for them.

&quot;What were we trying to achieve again?&quot;<p>This is the main takeaway here. If you have a problem and think microservices might be a good way to solve it and possibly worth the effort, then go ahead and investigate. But without a clear problem and plausible solution involving MS, it&#x27;s going to be a big waste of time.

&gt; It is useful to bear Conway’s law in mind when considering the shape of your architecture. It states that your software’s architecture grows in a way that mimics how your organization and teams are structured.<p>I had always assumed that it was the other way around. Good to be made aware of the alternative.

The debate about microservices and monoliths are really about valuing consistency of tooling over best tool for the job. Microservices tend to emphasize allowing a developer to use whatever tools services and languages they want to implement a service. We define the input to the service and the output from the service, but little in between. The consistency is in the interfaces between the services - how each service is built can be totally different. Monoliths emphasize consistency of tooling and language across services, so there are fewer tools, fewer things to know to operate and develop the application.<p>You know what? You can totally screw up both architectures, you can have cost overruns, and you can fail to scale. Neither microservices or monoliths are going to make you succeed of fail.<p>The real question is, where do you want to put the consistency? Is that the right way to do it for your app? Can your team maintain and keep building, or is maintenance going to blow you up?

Answer: &quot;Because your team is smart and doesn&#x27;t follow every hype as it happens.&quot;

I wish more languages had an abstraction layer above namespaces, classes &amp; interfaces, something like Java modules, to help organize a large monolith.<p>Instead of creating isolation over an network interface we add an abstraction to achieve it.

Microservices and SPAs are to me in the same category of &quot;things we do because it is fun&quot; rather than because the business will take any benefit out of it.<p>The amount of effort wasted is just not worth it in 90% of the cases.

The real problem in monolithic codebases isn&#x27;t that it&#x27;s large and needs to be separated- it&#x27;s that the pieces are logically coupled. Microservices force you into separation but do not force decoupling.

Microservice architecture isn&#x27;t &quot;better&quot;.<p>Monoliths aren&#x27;t &quot;better&quot;.<p>Because the whole idea of &quot;better&quot; makes absolutely no sense without context. Sometimes microservices are better in a certain context. Sometimes a monolith is better in a different context. And sometimes, one or the other is &quot;better&quot; but <i>not by enough of a margin to care about</i>.<p>It&#x27;s the oldest cliche in the book, but one that this industry seems to hate with a passion: &quot;Pick the right tool for the job.&quot;<p>Sadly, in our world, the received wisdom sometimes seems to be &quot;Use the newest, shiniest, most hyped tool that is what everyone is talking about.&quot;

Salutes go out to the folks who can handle microservices, because they have always been a pain in the ass for me. The world needs more libraries, not services

The problem is in the hype.<p>For example, the tradeoff between centralized and distributed has been taken (mostly informally) by big institutions for years. It´s not possible for a large bank with multiple overlapping domains, hundreds or thousands of dev tems (some of them outsourced&#x2F;offshored) to have all of it´s code in a single repo or a single executable. And not all of it´s applications have the same requirements (technical, scale, etc) either.<p>SOA came to aid in this case by putting a common integration pattern between the interested parts.<p>But at some point the idea was hyped, and even small teams with no diverse technical or scale problems started doing simple backends using full blown distributed systems without reason.<p>Basically: if you don´t have problems of scale (domain, technical or people related) going microservices first is probably not granted.

Article is from 2019.

Is there any way to read without login?

Medium? Nah

It took me a while to accept that microservices are better. Not in every case, but in a surprising number of cases. They really shine when combined with serverless computing. Clear seperation of code by a networking call is the next logical step in the encapsulation principle of object oriented programming. We hide the implementation details and only expose an interface, which creates seperation and forces us to stop sphagetti logic. Microservices are the enxt step in that design pattern, and only with the improvement in container technology and cloud computing has this become achievable (in the sense of there not being so much operations and complexity overhead).