10 ms·

Why our team cancelled our move to microservices

• rydgel 5y ago
  Why would you consider microservices if you are only 12 developers?
  • tored 5y ago
    It can sometimes make sense even that small, like if team has different geographical locations and/or time zones. And that I think how you should approach micro services, to solve an organizational problem, not use it for solving a technical problem.
  • bhuber 5y ago
    Most of the conversation so far has focused on the development benefits of microservices (decoupling deployments, less coordination between teams, etc). Small teams don't really have this problem, but there are other benefits to microservices. One of the biggest is scaling heterogeneous compute resources. Suppose, for example, your webapp backend has to do some very expensive ML GPU processing for 1% of your incoming traffic. If you deploy your backend as a monolith, every single one of your backend nodes has to be an expensive GPU node, and as your normal traffic increases, you have to scale using GPU nodes regardless of whether you actually need more GPU compute power for your ML traffic. If you instead deploy the ML logic as a separate service, it can be hosted on GPU nodes, while the rest of your logic is hosted on much cheaper regular compute nodes, and both can be scaled separately. Availability is another good example. Suppose you have some API endpoints that are both far more compute intensive than the rest of your app, but also less essential. If you deploy these as a separate service, a traffic surge to the expensive endpoints will slow them down due to resource starvation (at least until autoscaling catches up), but the rest of your app will be unaffected.
    • jeremyjh 5y ago
      So sure, maybe make the ML model a separate service, but you don't really have the same driver for other services; state-less server processes tend to need the same type of resources only in different amounts, and you don't really gain anything by splitting your work load based on the words used in your domain description. Real-world monoliths often do have some supporting services or partner services that they interact with. That doesn't mean you need a "micro-service architecture" in order to scale your workload.
    • midrus 5y ago
      Well, no. You can deploy the same monolith to two different clusters with different resource configurations. In fact, this is what you usually do with "worker" nodes that do background jobs. And you can always have feature flags/environment variables to disable everything you don't need in a given cluster.
      • bhuber 5y ago
        I'm not saying you have to use microservices to solve these problems, just that they are potential reasons why you might want to, even with a small team of developers. I would also argue that if you're deploying the same codebase in two different places and having it execute completely different code paths, you're effectively running two separate services. Whether or not you decide to deploy a bunch of dead code (i.e. the parts of your monolith that belong to the "service" running on the other cluster) along with them doesn't change how they logically interact.
  • FridgeSeal 5y ago
    Because the team might already be comfortable working in that way? Because certain parts of the application might require specialised implementations and very natural lines of separation fall out? I’m in a team of 4 and the few API’s we expose would be considered microservices. We did that because it was easiest and fastest for us to build and maintain and the features we provide were all quite distinct.
• tored 5y ago
  I wish more languages had an abstraction layer above namespaces, classes & interfaces, something like Java modules, to help organize a large monolith. Instead of creating isolation over an network interface we add an abstraction to achieve it.
• kirse 5y ago
  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. Actor systems are a natural fit for this eventual de-coupling. What starts as a simple actor w/ a mailbox can eventually grow to a standalone REST service with minimal headache in architectural refactoring.
• mykowebhn 5y ago
  > 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. I had always assumed that it was the other way around. Good to be made aware of the alternative.
• notyourday 5y ago
  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? Congratulations, you have micro services! 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.
• contextfree 5y ago
  I'm not speaking from experience here, but it seems like rather than "moving to a microservices architecture" it would perhaps be better to think more in terms of "splitting out specific functionality X into an independently deployable and hostable service, which should alleviate the specific problem Y that we've been experiencing due to their being too closely coupled" and if there are no obvious X and Y then maybe the "monolith" is fine?
  • wpietri 5y ago
    For sure. Find a problem first, then look at solutions. Try one out, see if it helps. If not, try a different solution. Man-with-a-hammer syndrome is dangerous.
• mavu 5y ago
  Answer: "Because your team is smart and doesn't follow every hype as it happens."
• midrus 5y ago
  Microservices and SPAs are to me in the same category of "things we do because it is fun" rather than because the business will take any benefit out of it. The amount of effort wasted is just not worth it in 90% of the cases.
• nurettin 5y ago
  > A benefit of microservices is that each team can be responsible for releasing their services independently and without coordination with other teams. Sounds almost sarcastic. How do you deliver API changes without alerting other teams?
  • willcipriano 5y ago
    I'd guess that 90-95% of tickets do not alter a existing API in a non-backwards compatible way
  • jeffbee 5y ago
    Don't ever change APIs. It's pretty simple. I don't know why the monolith people believe this is such a gotcha. If you really need to change the API, give the new API another name. You may choose to think of this as "versioned APIs", if you want, but "versioned" and "renamed" are the same thing.
  • no_wizard 5y ago
    Proper deprecation procedures. you can document how you uniformly deprecate and remove APIs. This is a strength of using something like OpenAPI for documentation, or GraphQL, for instance. It is then the responsibility of a consumer to deal with these deprecation(s). On the most basic level you could also do versioning, though its not my recommendation Document and set expectations accordingly. I've done this move before breaking apart a monolith into separate micro services and this is key. Spending more time on good documentation is generally a good idea regardless. I'm assuming we're not talking about public facing APIs. That's a situation where versioning might make a lot more sense.
  • linuxdude314 5y ago
    Do you not version APIs you design? When engineering an API meant for consumption by disparate services it’s imperative to provide back words compatibility. This is pretty basic stuff anyone designing a serious API should be taking into account.
    • nurettin 5y ago
• fdgsdfogijq 5y ago
  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).
  • winternett 5y ago
    A size 20 shoe is better for a large foot... But not better for a size 15 or size 10 foot. Saying Microservices are better is the same as me saying "a size 20 shoe is better than any other shoe"... for everyone. It's not a viable statement in any use case, except for people with size 20 feet. The business need is what determines the solution necessary.
    • fdgsdfogijq 5y ago
      I know its not a catch all. But more often than I would like to admit they bring simplicity and reduce complexity. The more I develop software, the less I can stomach monoliths running on some big server. The other day I was considering deploying an MVP I have written on Django, and instead just ripped it apart and pushed the pieces into their own seperate lambdas. Deploying some monolith API like that was nerve wrecking, updates are, the blast radius is higher, and the composability of components is easier with smaller microservices.
  • shuntress 5y ago
    I think the catch is that "Services" are typically the scope at which encapsulation should stop. They don't need to be "Micro".
    • pc86 5y ago
      This is just arguing over the service boundary definition and not the architecture. There are multiple comments here trying to differentiate between a "service" and a "microservice" which seems like a fools errand to me.
• winternett 5y ago
  The term "Monolith" was devised by people who wanted to brand microservices as newer and superior. It'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's why I don't buy into buzz words at all. If it's not broken, don'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. 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's a sticker shock that you can only stop by going offline. 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. We need to stop disparaging traditional (non-cloud) hosting and solutions that aren'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. 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/vulnerable/costly/and over-complex IT solutions cannot be sustained as a viable long-term business sales strategy anyway.
  • dpark 5y ago
    > that's why I don't buy into buzz words at all. Clearly you do, because this is mostly nonsense driven by your knee jerk reaction to “microservices”. Very little you’ve written here is substantive. It’s all emotional appeal covering ignorance. > If it's not broken, don't fix it... But it is broken. Engineers often experience significant pain from monoliths so they look for a solution. They often also experience significant pain from microservices so the pendulum returns. Hopefully during all of this we learn enough that at least some pain is reduced, whether we land on microservices or monoliths or hybrid solutions. > We need to stop disparaging … and focus on what works Here I agree. Focus on what works and stop engaging in low value attacks on solutions that clearly work for some. > The more we allow marketing minds to take control of our IT decisions… What “marketing minds” are making decisions about service architecture? This seems like an imaginary issue.
• rodorgas 5y ago
  Is there any way to read without login?
  • quickthrower2 5y ago
    https://pastebin.com/BcA7r18x https://pastebin.com/BcA7r18x
  • f0xtrot 5y ago
    edit: nvm; its not the full article. Found it on outline[.]com https://outline.com/Leznmz https://outline.com/Leznmz
    • rodorgas 5y ago
      Isn’t it cropped on the first paragraph for you?
• glintik 5y ago
  "Microservices had been sold to us as the ideal architectural for perhaps a year now." When he learn that there is no ideal architectural in software? )
• luhego 5y ago
  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/departments. In that scenario, each team/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't see the benefit.
• f0xtrot 5y ago
  Article is from 2019.
• GrumpyNl 5y ago
  There is a big misconception that a monolith has to be fully deployed every time. A well designed monolith can be partially deployed.
  • pc86 5y ago
    How?
    • lemmsjid 5y ago
      The 'monolith' (which I find a silly term but I'll use it here) can expose different parts of itself as services. As long as those services can be versioned and are backwards compatible, you can deploy the monolith using any schedule or notification mechanism you like. If the monolith is composed of modules with a DAG-like dependency structure (e.g. maven projects), then pieces of the monolith can be deployed alongside the dependencies they need.
      • Graffur 5y ago
        I think the problem is there's no popular framework that makes this easy (or is there?)
        • lemmsjid 5y ago
          Depends on the eco system, I've found this straightforward with maven / sbt + GRPC / Akka / Thrift, and then more difficult in environments that don't have baked in concepts of packages and module deployables, but from experience the mention of any of those technologies can start a flamewar of good and bad experiences therein :).
  • Softcadbury 5y ago
    Can you say more about that ? I'm a DotNet developer and I don't see how this could be possible without having several applications
    • 5y ago
• vmception 5y ago
  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
  • cyberge99 5y ago
    I’m skeptical because they’re on IIS in 2022.
  • feoren 5y ago
    Rephrasing: "this person, who is probably solving a very different problem with different design constraints than me, is doing things differently than the handful of ways I have ever seen in my limited career, and is therefore stupid."
    • vmception 5y ago
      if I meant to say that, I would have said that for anybody else passing by, the people still doing things like a LAMP stack on a single compute instances are getting the same user experience issues under load that we solved for over the last decade or so. I’m just not running into people that have looked at a system design tutorial in the last 10 years that thought “ah this is the use case where I can reject all these guidelines because I’m so experienced”
• giaour 5y ago
  > Microservices allow your team to have control over the full stack they require to deliver a feature. 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.
  • beebmam 5y ago
    My experience is the opposite of yours. Teams I've worked with get massive freedom to implement their services with any (reasonable) language + framework: Rust, Python, Java, Go, C++, C#, and so on. Seems like an organizational decision
    • giaour 5y ago
      My experience was mostly at small companies with dedicated ops personnel and in government. I worked with a large number of teams that had been chartered with implementing microservices within government agencies, and every single one of them was told what stack they were going to use, either by agency leadership or by infosec personnel. There was slightly more freedom of choice when I was at AWS, but compliance requirements and tooling support basically strongly encouraged everyone to adopt a standardized stack. All of which is to say, I get that what you're describing is in theory what microservices are supposed to allow, but I have yet to see it actually work that way in practice.
  • yongjik 5y ago
    Honestly, "every team in the same company having full control over what kind of stack they want to use" sounds like a nightmare. Soon you have services running in Python, C++, Java, Go, and node.js, with five different internal libraries talking to MySQL, all slightly incompatible with each other. (Let's hope someone doesn't start up a PostgreSQL server.)
  • scottious 5y ago
    or even worse: the teams DO have full control over their stack and now you have dozens or more different technology stacks at the company and expertise isn't shared between them
• joatmon-snoo 5y ago
  Monolith vs microservice is not a dichotomy, it'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). That being said, the biggest hurdle in a re-architecture project like this is usually in the "n=1 -> n=2" stage, and "n=2 -> n=5" is a lot easier: once you add service #2, you learn how to set up telemetry, permissions, billing/chargeback, alerting, etc. The next few are just repeating the same process.
  • jedberg 5y ago
    I always say n=2 -> n=3 is the hardest step, then n=1 -> n=2. With 1 to 2, you can take a lot of shortcuts with the n's communicating directly. With 3, you have to start formalizing message transmission either through a message bus or a cache or whatever. But once you have n=3, n=3+ is pretty easy as it's mostly edge cases to solve for or geometric scaling problems.
    • joatmon-snoo 5y ago
      It definitely depends on the shortcuts you take! e.g. if you run #1 and #2 with the same identity, you don't have to figure out how to make your ACLs work... but you're also breaking principle of least access :)
• andrewstuart 5y ago
  Microservices shift complexity from code to operations - microservices don't remove complexity - they spread it wider, making the whole more complex.
  • FridgeSeal 5y ago
    It’s about trade offs I think. Monolith can Microservices are so often presented as “x is better than y”, but it should be “which is more applicable for the team size, product and operational concerns”. Monoliths are a great choice for certain team sizes and applications, want stricter isolation and blast-radius between different teams and products and need to scale different things differently? Micro services are probably a better choice.
  • deleted 5y ago
    [deleted]
  • twblalock 5y ago
    The operations needed to keep a large monolith buildable when a lot of different teams work on it are also highly complex, and increase in complexity relative to the number of contributors to the codebase. It becomes a massive coordination problem at scale. Microservices decouple teams, so they can get their work done without stepping on each other's toes.
    • christophilus 5y ago
      Eh. Properly segmented monoliths are just fine. And are probably much simpler to deploy.
    • hw 5y ago
      Until there needs to be a change in the interface. Now you have N other services to deploy to and coordinate
  • ironmagma 5y ago
    Examining behavior in the limit (a la physics) is interesting. Imagine a system where every function call goes out to a separate process. Suddenly you have a lot of processes waiting around to be called. Debugging requires special tools. Profiling becomes a nightmare. Even determining if the system is fully running becomes difficult. What have you gained?
• pythux 5y ago
  > 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. Maybe redesigning the architecture of the product just because there is time vs. there is a pain point/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. Edit: typo
  • LASR 5y ago
    Exactly. Microservices can solve for some problems, eg: scaling infrastructure in a non-uniform manner or scaling development velocity non-uniformly across many teams. But there are also tons of other ways to solve these problems. The mistake is in assuming that you need microservices to do x, without really critically thinking about what is actually stoping you from having x right now. The move to microservices (or any similar kind of rewrite efforts) should be undertaken only when it's painfully obvious that it's needed.
• jedberg 5y ago
  > We have approximately 12 developers spread across 2 feature teams and a support team. 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. And as they eventually discovered, a lot of unnecessary overhead for such a small team.
  • jeremyjh 5y ago
    Yeah, honestly this should be the entire content of the article. Not only do they only have two small teams but they all overlap completely anyway. There is no reason even a significantly larger org - say 40+ people in 8-10 teams cannot work effectively in a single repository and monolith architecture. Beyond that there are certain growing pains and if you don't effectively manage those then I could see how you end up going with micro-services. Beyond scaling a large development org the primary benefits of micro-services accrue to consultants who bill by the hour.
  • wpietri 5y ago
    One of the questions I like asking developer pals is what ratio their company has between engineers and services/deployable units. Anybody reading this care to share? For me, that number says a lot more about the day-to-day life of devs than the microservices vs monolith label does.
    • edude03 5y ago
      We are currently between 3-7 services per dev depending on how you count (~40 services developed in house, ~70 if you include third party micro services we run) It would likely be insurmountable if not for using kubernetes, we choice the idiomatic options (gke/GitHub actions/Argo/Prometheus/etc) so starting with micro services wasn’t too bad
      • WatchDog 5y ago
        Wow, that sounds like an utter nightmare.
• dvt 5y ago
  A few points I'd like to make: 1. You can't "migrate" to microservices from a monolith. This is an architectural decision that is made early on. What "migrating" 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't believe me? See this quote: > 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. Once something is built as "one thing," you can't really easily take it apart into "many things." 2. Microservices does not 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. 3. Microservices are "antifragile," to use a Talebian term. So I think that this paragraph is actually incorrect: > This uncertainty made creating microservices more fraught, as we couldn’t predict what new links would pop up, even in the short term. A microservice is way easier to change (again, if designed properly), than a huge app that shares state all over the place. 4. What's the point here? It seems like the decision was hasty and predictably a waste of time. Any CTO/architect/tech lead worth his or her salt would've said this is a bad idea to begin with.
  • edude03 5y ago
    > Microservices does not 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. You don’t need to use kubernetes but I strongly believe it’s the best choice if you’re not using FaaS. If you pick nomad or bare vms you’ll spend a lot of your time building a framework to deploy/monitor/network/configure etc your services whereas kubernetes has “sane” defaults for all of these That said - you should use managed kubernetes and not deploy it from scratch
• kgeist 5y ago
  Just last week I found an interesting and unexpected (for me) advantage of microservices. We have two monoliths written in different stacks/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'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't package it into a library because clients have different stacks.
  • deleted 5y ago
    [deleted]
• Ostrogodsky 5y ago
  Medium? Nah
• tomc1985 5y ago
  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
• misterbwong 5y ago
  The real problem in monolithic codebases isn't that it's large and needs to be separated- it's that the pieces are logically coupled. Microservices force you into separation but do not force decoupling.
• shroompasta 5y ago
  Their architecture didn't provide any clear boundaries to be sufficient for microservices, however that isn't the case for many medium to larger sized projects. (By the way, just because there's still quite a bit of coupling between services, doesn't mean there aren't clear boundaries - Microservices can communicate with one another all the time and still be justified in being decoupled) There isn't an absolute answer to monolith vs microservices - It depends case by case. Instagram was built using Django and I'm unsure of ig'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'm sure it would suffice for many other projects. However, still, it's not a this or that as many of the comments here would seemingly imply - Again, it's HEAVILY dependent on the case.
• foxyv 5y ago
  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. 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. Really, a well coded monolith is just a bunch of micro-services on the same server communicating through memory. In reality it's more of a Lich who's eyes shine with the light of the tortured souls of fallen QA testers and developers.
  • dasil003 5y ago
    Agreed, however I've experienced something worse: trying to refactor domain models across an SOA that was poorly factored to begin with, and then layered 10k eng-years of incremental feature development driven by a fractured product team with short average tenures.
    • foxyv 5y ago
      Sounds like a second circle. Jeeze, my condolences.
  • JetAlone 5y ago
    This is poetry.
• jpalomaki 5y ago
  Some perspective from Netflix. Around 10k employees [1] (could not find how many are working with software), more that 1000 microservices [2]. 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. 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 [1] https://www.macrotrends.net/stocks/charts/NFLX/netflix/number-of-employees https://www.macrotrends.net/stocks/charts/NFLX/netflix/numbe... [2] https://www.cloudzero.com/blog/netflix-aws?hs_amp=true https://www.cloudzero.com/blog/netflix-aws?hs_amp=true
• fleddr 5y ago
  An example to show you how easily the idea of "boundaries" breaks down... 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. 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. So it'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. It's terrible UX. Slow and jumpy. 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'm sure that might be an anti pattern. What is the best solution isn'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't care because data and services are not products. Furthermore, when designing these boundaries you absolutely can not foresee how they're going to be used. As such, it is incredibly common that for an app/web developer, the API fails to meet needs. It doesn'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. There'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. A boundary is not a feature. A boundary is a problem. It makes everything inefficient, slow and complex. I'm not closed minded, there'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.
• noway421 5y ago
  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 "products" that each individual team builds and then the rest of organization dogfoods, then sure. But if there's a single underlying dependency, that won't work. If there're complex interdependencies, it won't work (as nicely). If you have a small team, it won't work. If requirements frequently change, it won't work. Ultimately works well if you have something very high scale with enduring set of requirements.
• kgeist 5y ago
  We have a hybrid model: modular monolith + microservices. It has worked well so far. The core of the product is found in the monolith. We use bounded contexts ("modular monolith") 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. As for microservices, we usually use them for: 1) critical infrastructure which needs to be fast and scalable (for example, the auth service) 2) isolated helper services, for example a service which allows to integrate with third-party platforms 3) isolated features/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's a product of its own, it's developed separately with its own codebase, and integrated into the monolith So I think it's a false dichotomy that you either have a monolith, or microservices. You can use both, they can complement each other.
  • nchi3 5y ago
    > We use bounded contexts ("modular monolith") with strictly separated concerns. >because the logic between modules is too intertwined and coupled. That doesn't sound very modular? If your bounded contexts are intertwined, I don't think they can be considered bounded contexts. A modular monolith would only communicate between contexts through well-defined and non-leaky APIs, and that's the opposite of intertwined.
    • kgeist 5y ago
      They only communicate through well-defined APIs, and there's a rule that cross-context API calls can only happen in the anti-corruption layer (we use a tool to check it at build time). What I meant by intertwined (maybe a wrong word, I'm not a native speaker): 1) there's a lot of data/logic dependency between the contexts (i.e. a context in its operation depends on N other contexts), although we at least disallow circular references; it's unfortunately dictated by business rules and I'd like to see contexts to be more isolated and self-contained. Some can say that if a change in the requirements requires to change many contexts at once, maybe it's one fat context after all - and they may be right, but we enjoy the current modularization effort, one big fat module would be far less manageable for us. 2) there're occurrences of temporal coupling; there are synchronous operations that spawn several contexts, with a lot of data flowing back and forth Now, it's easier to manage it in a monolith, in the same process, because: 1) there are no network trips back and forth in case of complex operations with a lot of data 2) no retry logic in case of network connectivity issues 3) DB connections/locks and other in-memory structures can be reused 4) same codebase, so easier to reason about Microservices require more care and more complex solutions: 1) distributed transactions are hard 2) eventual consistency is hard 3) the idiom "DB per microservice" makes managing the infrastructure harder 4) deployment is harder (if you have changes in several related contexts, there's only 1 deployment in the monolith as opposed to N deployments of microservices) 5) you have to manage different codebases/repos, can't see the whole picture 6) you have to defend against network connectivity issues, microservice unavailability etc. 7) debugging is harder, you can't just step into another microservice like you do with in-memory modules 8) new devs need to be taught all that The list can go on and on. So we don't try to make all our modules/contexts into microservices just because we like microservices, we have to substantiate a move to a microservice with proof that it will make development/scalability easier for us, and that the advantages outweigh the disadvantages.
• namelessoracle 5y ago
  Monolith almost sounds cool to me. To be honest. 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. He looked at me like i was insane when i said a monolith would work better for them.
• julienb_sea 5y ago
  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. 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. 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.
• mindcrime 5y ago
  Microservice architecture isn't "better". Monoliths aren't "better". Because the whole idea of "better" 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 "better" but not by enough of a margin to care about. It's the oldest cliche in the book, but one that this industry seems to hate with a passion: "Pick the right tool for the job." Sadly, in our world, the received wisdom sometimes seems to be "Use the newest, shiniest, most hyped tool that is what everyone is talking about."
• dwheeler 5y ago
  Practically every technology decision has pros and cons. I think that if you can't think of a good reason not to use some technology, then you don't understand the technology well enough yet and you shouldn't try to use it in production yet. It may be what you need, but thinking that "everything must switch to this" is usually a huge warning signal that cargo cult engineering is happening instead of real engineering.
  • brunellus 5y ago
    This point is reminiscent of the Chesterton’s Fence concept discussed on HN recently
    • dwheeler 5y ago
      I completely agree, good point! Historically Chesterton's Fence is that you shouldn't remove something until you understand why it's there, but we should probably broaden the lesson to cover change of any kind. Something like, "Don't remove anything until you understand why it's there, and don't use something new until you understand under what conditions that new thing is better (vs. when it isn't)." I'm not against change, but I do hate the endless cargo cults.
  • netfl0 5y ago
    Fashion has H&M Tech has HN
• tetsuhamu 5y ago
  The #1 reason to split your serving architecture into microservices is that your application can't fit in 1 server's memory. If your application fits in 1 server, you have a choice, otherwise you don't. If your application can't fit in 1 server and you can't split it up, you have to refactor so it can. If you can'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. Clustered applications are unavoidable.
• mdavis6890 5y ago
  "What were we trying to achieve again?" 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's going to be a big waste of time.
• lamontcg 5y ago
  > We have approximately 12 developers spread across 2 feature teams and a support team. 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.
• indymike 5y ago
  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. 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. 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?
• tentacleuno 5y ago
  > 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. Wouldn'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't really understand this argument.
  • wafer-bw 5y ago
    Perhaps the language/stack they were using wasn't condusive to this but honestly I can't think of one where this would be a problem they couldn't solve with a module/package the performs the essential business logic piece.
  • staticassertion 5y ago
    Or moved into its own microservice and then RPC'd to from those other services. But yeah.
  • phphphphp 5y ago
    I have a very strong objection to this line of thinking. Effective use of microservices depends upon a strong, meaningful boundary between the services and that boundary should be business driven, not code driven. As soon as you start dealing in packages of code[1], there’s no longer a meaningful boundary between your services, instead the boundary is completely arbitrary and each service becomes a microservice in name only. If every microservice knows about the business logic for generating basket prices, whether the code comes from a package or not, you no longer have microservices… you have a lot of monoliths. I joined a company that did this and it was one of my worst experiences as a software engineer, I would never recommend it. [1] specifically packages containing business logic. Packages containing functionality for cross-service communication etc. are very reasonable.
    • tentacleuno 5y ago
      > As soon as you start dealing in packages of code[1], there’s no longer a meaningful boundary between your services, instead the boundary is completely arbitrary and each service becomes a microservice in name only. While this sounds very radical (to me at least), I mostly understand how you've come to this conclusion. Obviously "just one package" is going to lead to further complexities down the line, and perhaps many more packages than that. Perhaps a dedicated microservice for this piece of business logic would be better, as you suggested.
• r00tanon 5y ago
  As with all architectural patterns there are tradeoffs. Microservices for one thing are not functions. Granularity is an important concern. A DDD approach up front will help with granularity. 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. Definitely a game of scale and not for small organizations. 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. That said, all shops are not Netflix or AWS...
• Tarucho 5y ago
  The problem is in the hype. 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/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. SOA came to aid in this case by putting a common integration pattern between the interested parts. 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. Basically: if you don´t have problems of scale (domain, technical or people related) going microservices first is probably not granted.