5 ms·

I see a lot of places that seem to either think that: 1. Microservices will let them ship things faster or 2. It's microservices everywhere or nothing Micros

• Tobani 6y ago
  At my current place of work we have 1 monolith and 2 "Micro-Serivces" Working in the monolith is fine, but running tests is slow because it is a giant rails app that is 7+ years old. There is 1 "microservice" that does its thing and the few people who need to interact with it like it. the second microservice was created, deployed and abandoned. Now people want to move it into the core monolith. It is a distinct unit of functionality that doesn't really have any overlap with the core app. I'm going through and adding all of the tooling to this project because it enables us to solve a certain class of problem (Report generation) that the monolith can't do very well for a couple of reasons. Articles like this have fueled the fire to re-combine it but the pain points have nothing to do with this particular service being separate.
  • JamesBarney 6y ago
    If it's working well why change it? If your co-workers argument is just "microservices bad" then obviously they are making a mistake. But in the general I've seen far more frequent inappropriate splitting of monoliths than inappropriate combining of microservices. (this is honestly the first time I've heard of it.)
    • chrisan 6y ago
      I mean you admit it yourself, far too often the splitting off is inappropriate. Normally an inappropriate microsservices is a net negative over all that costs you money in the long run. Just because its working doesn't mean it is efficient. My last two "assimilations" where because one microservice was written in Java. The original guy left and no one (around the company) likes to touch Java (or pretend they don't know/do it) which means it was alaways me who had to update it. It was a very small service, likely why he thought small = micro! but it was about 3 hours of work in the monolith. Now anyone can update/contribute to it and not bug me every time The other was a microservice that only served the monolith. New features required the monolith to be updated in order to realize the new features.
      • JamesBarney 6y ago
        Makes total sense.
    • Tobani 6y ago
      Honestly it doesn't work well now as a developer. It is about a week worth of work away from being a great developer experience. They'll come around. Honestly every time I have split out a separate service it is because the current state of affairs is bad and there is a distinct need. Those handful of things have been rock solid and needed very little attention, but it has been a last resort.
• gregmac 6y ago
  I've found it most helpful to think in terms of deployments: Each (micro)service effectively gets deployed independently. One implication of this is you need to ensure your APIs are backwards compatible with any other services - even if it's only one service that your team also manages. This also includes databases, if shared by multiple services (which I won't get into, suffice to say congrats, your database schema is now also a crappy API). As soon as you start having concurrent deployment dependencies -- that is, the updates for service a + b both have to be deployed at the same time or things are broken -- you've effectively built a monolith anyway, just with an annoying code layout (eg, spread across multiple repositories). You can use orchestration to tie these deployments together, but this means you're effectively building a monolith with a microservice architecture. Is that really what you want?
  • dpix 6y ago
    Sharing databases across services (micro or not) is generally a pretty bad idea exactly for reasons around versioning. Versioning APIs is a pretty standard way to get around this. If your deployment relies on synchronized service deployments you really dont have independent services at all.
    • danenania 6y ago
      "Sharing databases across services (micro or not) is generally a pretty bad idea" I don't think such a blanket statement is justified. There are plenty of situations where it may make sense to pull out some functionality into its own service--so it can be written in a different language, scaled independently, isolated from failures, or whatever--but where giving that service its own separate database would be serious overkill, complicating ops and introducing potential data integrity issues for no real benefit. "If your deployment relies on synchronized service deployments you really dont have independent services at all." So what? That's really the point: blindly following the Microservices (TM) doctrine is often a mistake. It's better to just solve whatever problem you're facing in the simplest possible way. While that may mean by-the-book microservices with independent databases, in many cases something in between is a better choice.
• eweise 6y ago
  Starting with a monolith could lead to really difficult refactorings unless you structure the code in a way that it can be easily decoupled.
  • dpix 6y ago
    The same argument can be made for building separate services too. Could become very difficult to merge data between two services after you had redundant information being saved across the two because of a bad design up-front.
  • afarrell 6y ago
    I once worked in a monolith that was structured in a way that it could have been easily decoupled. It never was because the codebase was so modular and well-tested that the only time we ever felt the need was when trying to assign ownership to runtime exceptions. https://gocardless.com/blog/getting-started-with-coach/ https://gocardless.com/blog/getting-started-with-coach/ was the framework.
    • mikepurvis 6y ago
      Exception triage often requires examining the stack regardless— even if you have multiple processes, you're still going to have errors bubbling up from your pool of shared library code.
  • stcredzero 6y ago
    Law of Demeter! That idea had a lot of influence from Smalltalk, where the natural way of developing was in a monolith. So tactics like that which are about decoupling by default were a good idea in that context. https://wiki.c2.com/?LawOfDemeter https://wiki.c2.com/?LawOfDemeter
  • JamesBarney 6y ago
    Monolith -> microservices : difficult refactoring Microservices -> monolith : difficult refactoring Microservices with poorly chosen context boundaries -> microservices with well chosen context boundaries: very difficult refactoring.
• stcredzero 6y ago
  As Matt Easton says: "Context!" I think "5 Whys" might be a useful exercise here. Why was building X as a microservice faster? [reason]? Well, why was that? My general rules for this are to always start in a monolith and break things out as they start to fail or break other parts of the codebase, and don't go all in just because you now have one microservice that works well by itself I like this. A key tactic is to always do things, such that one can change one's mind!
• cytzol 6y ago
  This, this, this! It's been said elsewhere in these comments, but the term "micro"-services really do them a disservice, like it's expected that you need to break your application up into little pieces, to eliminate complexity. But many applications are inherently complex, and splitting them up isn't going to get you anywhere. I've been trying to advocate for a "solar system model of services", where you have a big core application in the middle (the sun), surrounded by helper services of various kinds. Your important business logic can be left alone, but the database, other data stores, functions, timers, queues, integrations with third-party systems, one-off jobs, and other things can all stay in orbit. There are benefits that you get from multiple services that you don't get from a monolith: having to rely on service discovery instead of hard-coding addresses or passwords, being unable to assume that the server your code is running on will live forever, and requiring a concrete CI-CD pipeline to get your code up-and-running are all good things to have, no matter your model, so it's important to have a clearly-defined process for them. A service-oriented architecture can give you that — put down the pickaxe, you don't need to split the monolith in two.
  • throwaway894345 6y ago
    Another aspect no one seems to talk about is whether your deployment is monolithic or fragmented. It seems like a lot of the pain of managing microservices comes from designing a coherent CI/CD pipeline, how to share libraries between various microservices, etc. If you have a monorepo, good build tooling, and a good infrastructure as code tool, I think much of that pain goes away, but none of those things are easy and the precise selection and combination of tools depends a lot on your organization (I wouldn't recommend Bazel or Nix--build tools--to a small or medium-sized organization, for example).
    • cgrealy 6y ago
      >> If you have a monorepo, good build tooling, and a good infrastructure as code tool, Yep, and so many organisations ignore these. Especially after a less successful transition to micro-services. "you mean you want to spend more time doing non-customer visible development? You just did that micro services thing a while ago!" "Yes, but to take proper advantage of that we need to invest in the right infrastructure and tooling" "how can I sell that?"
• rhizome 6y ago
  The thing that jumps out to me: there are WAY more page-loading indicators now than there has ever been before. Lots more jumping content, lots more laggy content population, many more elements sliding around...I know "worse is better" is a truism of sorts in technology, but this is ridiculous. What good do any of these architecture decisions make when the experience for the user, the customer, is measurably worse? I mean, aside from not being able to interact with elements of a page before a chain of JavaScript finally gives the all-clear, sites clearly look worse with grayed placeholders and whatnot. There should be a Conway's Corrollary for revenue-oriented choices.
  • deleted 6y ago
    [deleted]
• NomDePlum 6y ago
  That advice of starting with a Monolith has consistently been given by those involved in Microservices since the start. I remember a Fowler article in particular. Unfortunately the "if you only have a hammer everything is a nail" analogy holds true when people start looking at where microservices may fit into an overall system architecture. Their answer is invariably - everywhere! Really small, reusable/shareable and stable domains are the sweet spot for microservices. As you say that is most likely to come from decomposing from a monolith. Microservices can really help with building rich domain components in an overall architecture and removing complexity from other components through delegation to the microservice is my experience. They just don't need to be everywhere. The same problem of over-eagerness is becoming apparent with some of the movement to event-based architectures. People become obsessed acolytes and there is no other way. When in fact they may well be ideal for a portion of your overall system architecture but are unlikely to serve it all well.
• quickthrower2 6y ago
  I'm yet to do micro-services at all at work or outside. I count myself lucky :-).