19 ms·

Monolith First (2015)

• BillinghamJ 6y ago
  > I feel that you shouldn't start with microservices unless you have reasonable experience of building a microservices system in the team Well, yeah... obviously. That's not the same thing as it being bad to start with microservices generally. I just don't agree with this at all. The designer of the architecture clearly does need to know how to design service-based architectures and needs to have a very strong understanding of the business domain to draw reasonable initial boundaries. These are not unusual traits when starting a company as a technical founder.
  • bobthebuilders 6y ago
    Conway's Law is king
  • gilfoyle 6y ago
    > These are not unusual traits when starting a company as a technical founder. Its actually not unusual to have technical cofounders who have no prior software engineering work experience.
    • xmprt 6y ago
      I see two categories of technical founders. 1. The people who have many years of experience building a highly specialized application using domain knowledge gained at their previous job. 2. The new CS grad right out of college who had big dreams, a lot of time, and high risk tolerance. Unclear as to whether they're starting up the company because they failed to get a job elsewhere or because they think they're about to build the next Facebook.
      • BillinghamJ 6y ago
        I'm definitely not in either of those camps, more mid-senior level experience with highly specialised domain knowledge in a completely unrelated field (neuro/QEEG feedback training before, now fintech/insurance)
  • marcus_holmes 6y ago
    What if those boundaries change because an initial assumption turns out to be wrong? In a monolith, no biggy. With microservices, huge pain. Moving to microservices is something you do to optimise scability, but it comes with costs. A major cost is the reduction in flexibility. Starting a new not-very-well-understood thing needs massive flexibility.
    • BillinghamJ 6y ago
      I think we've found in many situations that the microservice boundaries make it easier to change things. We were pretty careful in making fairly conservative choices initially though, and split some of the bigger systems up more over time.
• foreigner 6y ago
  I'm embarrassed to say that I recently built microservices first, and am now kicking myself as I merge them back in to a monolith.
  • spectramax 6y ago
    You can still build a "monolith" but in a very modular way. Can't scale independently like microservices, but what if you don't need scale! Compile times are higher but what if you don't need to compile that much code! One error can bring down all "monolith services" but what if your app is not that big! I'd wager, something like 90% of software projects in companies can just get by with monoliths. You know...there are monoliths that are well architected, and then there are monoliths that are developed for job security.
    • xxs 6y ago
      >Can't scale independently like microservices, but what if you don't need scale! What do you mean? Aside from deployed codebase, I don't quite see it - if you need memory, allocate - start small/empty for any datastructure. If managed/gc setup delallocating is inherent, so no special case about freeing memory. Don't create unnecessary threads - but even then dormant threads are very cheap nowadays. There you go - it scales vertically nicely, make sure the application can scale horizontally (say, partitioning by user) and you have all the benefits with close to no drawbacks
      • spectramax 6y ago
        You're actually right. Just don't call the portions of the app and you can horizontally scale too.
      • irshadc 6y ago
        We had very similar settings where our codebase was built modular but deployed as monolith. At once we wanted to scale just the Queue processor module out of. We did deploy complete monolith and only enabled Queue processor on other machine. It did add up to extra memory & disk usage. But in the end it helped our team to deploy without going through microservice architecture.
• ser0 6y ago
  A more common scenario I see is that people start with a monolith that ends up inheriting all the conceptual debt that accumulates as a project evolves. All this debt builds up a great desire for change in the maintaining team. A champion will rise with a clean architecture and design in microservice form that addresses all high visibility pain points, attributing forecasted benefits to the perceived strengths of microservices. The team buys into the pitch and looks forwards to a happily-ever-after ending. The reality though is that the team now has multiple problems, which include: - Addressing conceptual debt that hasn't gone away. - Discovering and migrating what the legacy system got right, which is often not documented and not obvious. - Dealing with the overheads of microservices that were not advertised and not prominent at a proof-of-concept scale. - Ensuring business continuity while this piece of work goes on. I would propose alternative is to fix your monolith first. If the team can't rewrite their ball of mud as a new monolith, then what are the chances of successfully rewriting and changing architecture? Once there is a good, well functioning monolith, shift a subset of responsibility that can be delegated to a dedicated team - the key point is to respect Conway's law - and either create a microservice from it or build a new independent monolith service, which aligns more to service oriented architecture than microservices.
  • zimpenfish 6y ago
    Another issue I've seen is that people push all the problems onto the monolith even if they're external - one place had a Perl monolith (which was bad, sure) but their main issue was an overloaded database which could have been addressed with moving some queries out of the (awful homegrown) ORM and using e.g. signed session cookies instead of every request causing a session table hit.
  • Chyzwar 6y ago
    There is one approach Fowler suggested is SacrificialArchitecture. You build your monolith quickly, get to market fit and once you understand service boundaries you move to microservices. Personally I would like to try Umbrella Projects[1]. You can design it as microservices but deploy and build as monolith. Overhead is lower, and it is easier to figure out right services when in one codebase. It can be easy implemented in other lang/frameworks as well. [1] https://elixirschool.com/en/lessons/advanced/umbrella-projects/ https://elixirschool.com/en/lessons/advanced/umbrella-projec...
• aryehof 6y ago
  Surely a radical viewpoint against the (current) state of the art in software architecture? Why swim against a tide of industry “best practice” that says ... ... Lets make our application into many communicating distributed applications. Where the boundaries lie is unclear, but everyone says this is the way to produce an application (I mean applications), so this must be the way to go.
• Cthulhu_ 6y ago
  I've worked in two major microservices environments. The one was a new application where everything was sloppily wired together via REST APIs and the code itself was written in Scala. A massively weird conflict there where the devs wanted a challenge on a code level but nobody wanted to think about the bigger picture. The other was an attempted rebuild of an existing .NET application to a Java microservices / service bus system. I think there was no reason for a rebuild and a thorough cleanup would have worked. If that one did not move to the microservices system, the people calling the shots would not have a leg to stand on because the new system would not be significantly better, and it would take years to reach feature and integration parity.
• wwww4all 6y ago
  Monoliths are solution in search of problems. Micro services are solution in search of problems. Generally, focus on solving the problems first. Can the problem be solved by some static rendering of data? Monolith is better solution. Does the problem require constant data updates from many sources and dynamic rendering of data changes? Micro services and reactive architecture are better solutions. There’s no one size fits all solution. The better software engineers recognizes the pros and cons of many architecture patterns and mix match portions that make sense for the solution, given schedule, engineering resources, and budget.
  • monsieurbanana 6y ago
    I don't understand what you mean by "static rendering" vs "dynamic rendering", but I suspect I wouldn't agree on that. Monolith vs microservice IMO depends more on team size/structure, stage of the project (POC/beta/stable/etc.), how well defined the specs are, … Rather than the nature of the problem itself.
• ngngngng 6y ago
  With this in mind, if I were to start a new project today (using Go, which is all I use anymore). I would segment my code inside of a monolith using interfaces. This would incur a very slight initial cost in the organization of the codebase prior to building. As your usage goes up and the need to scale parts of it increases, you could swap these interfaces out little by little by reimplementing the interface to contact your new external microservice. I've worked at several companies where microservices were necessary, and I can't believe how clunky they are to work with. I feel like in 2021 I should be able to write a monolith that is capable of horizontally scaling parts of itself.
  • pjmlp 6y ago
    Yep, that is the right approach, modular code.
  • domano 6y ago
    I don't see a lot of cost associated with the duck typing-ish approach go takes with interfaces. Instead of passing an implementation directly (or even having it in the first place) you can develop with an interface from the get go. Makes for easier tests too. In my experience the cost is lower if you write code the way you described (and you don't need to plan ahead as much)
  • rollulus 6y ago
    Exactly with this vision I started beginning of 2020 our Go monolithic backend. Currently, one year later with a few people developing it, it's working very well. And thank god I resisted and pushed back against people who were advocating to split off parts into AWS lambdas, misguided by confusing "physical" separation for logic separation. And regarding the cost you mention, I don't think there is any. Yes, the components only know each other via their interfaces, not their concrete types. Yes, you need to define these interfaces. But that's in essence plain old school dependency injection. You'd do that anyway for testing, right?
  • b-pixel 6y ago
    This is the way. Interfaces for modularity and leveraging nested packages within the monolith to keep code decoupled and organized.
• mstipetic 6y ago
  I keep saying this every time this topic comes up, have a look at elixir/erlang. The OTP library gives some great reusable patterns (and elixir project is adding new ones[1]) out of the box. You're basically developing a single codebase microservice project which feels like a monolith. You can spread out on multiple machines easily if you need to, the introspection tooling is better than anything you can buy right now, it's amazing. Things can get tricky if you need to spread out to hundreds of machines, but 99%+ of projects wont get to that scale. [1] https://elixir-lang.org/blog/2016/07/14/announcing-genstage/ https://elixir-lang.org/blog/2016/07/14/announcing-genstage/
  • jC6fhrfHRLM9b3 6y ago
    Neat, but nobody uses Elixir.
  • why_Mr_Anderson 6y ago
    And Erlang runtime) is used in massive telephone switches, famously AXD301 which is claimed to have uptime percentage of 99.9999999% over 20 years.
    • ramchip 6y ago
      It's unfortunate that this number stills gets thrown around: https://stackoverflow.com/a/26447543 https://stackoverflow.com/a/26447543
    • TimTheTinker 6y ago
      Experiences with the AXD301 suggest that “five nines” availability, downtime for software upgrades included, is a more realistic assessment. For nonstop operations, you need multiple computers, redundant power supplies, multiple network interfaces and reliable networks, cooling systems that never fail, and cables that system administrators cannot trip over, not to mention engineers who are well practiced in their maintenance skills. Considering that this target has been achieved at a fraction of the effort that would have been needed in a conventional programming language, it is still something to be very proud of. - from Erlang Programming by Simon Thompson, Chapter 1
• trabant00 6y ago
  I see services (not micro) as an organizational solution more than a technical one. Multiple teams working on the same service tend to have coordination problems. From this perspective starting with a monolith as you start with one team seems natural. Now the trend of breaking things up for the sake of it - going micro - seems to benefit the cloud, consultancy and solution providers more than anybody else. Orchestrating infrastructure, deployments, dependencies, monitoring, logging, etc, goes from "scp .tar.gz" to rocket science fast as the number of services grows to tens and hundreds. In the end the only way to truly simplify a product's development and maintenance is to reduce its scope. Moving complexity from inside the code to the pipelines solves nothing.
  • pjc50 6y ago
    Yes, that's the "Conway's Law" argument; microservices exist to replicate the team structure in the code, not the other way round.
• akavel 6y ago
  (2015) I am very interested in what he could add now.
• ivanb 6y ago
  There is no replacement for discipline. If you cannot structure your modules well, what makes you think that your microservice spaghetti would look better?
  • tappio 6y ago
    In my opinion it will become unusable and unmaintainable faster with microservice spaghetti. With monolith you can get by with bad design longer. But anyways, everything boils down to good structure as you said.
  • Cthulhu_ 6y ago
    It's a means to shift the problem to Someone Else; I've got my codebase, it is mine and it is perfect. Integrating with it is someone else's problem.
• deleted 6y ago
  [deleted]
• forgingahead 6y ago
  Your first and biggest problem when you start a technology startup is lack of customers and revenue. Do everything that gets you to the first customers and first revenue, and do everything that helps you find a repeatable & mechanical distribution strategy to reach more customers and more revenue. Then and only then should you even consider paying back your technical debt. Monolith first always until you have the cash to do otherwise, and even then only if your app desperately needs it.
• hayst4ck 6y ago
  If you imagine a monolith as a service that: takes a request -> deserializes it/unpacks it to a function call -> sets up the context of the function call (is the user logged in etc) -> calls the business logic function with the appropriate context and request parameters -> eventually sends requests to downstream servers/data stores to manipulate state -> handles errors/success -> formats a response and returns it The main problem I've seen in monoliths is that there is no separation/layering between unraveling a requests context, running the business logic, making the downstream requests, and generating a response. Breaking things down into simplified conceptual components I think there is a: request, request_context, request_handler, business_logic, downstream_client, business_response, full_response What is the correct behavior? return request_handler(request): request -> request_context; business_response = business_logic(request_context, request): downstream_client(); downstream_client(); business_response -> full_response; return full_response; business_response = request_handler(request_context, request): return business_logic(request_context, request): downstream_client(); downstream_client(); business_response -> full_response; return full_response; request -> request_context; business_response = request_handler(request_context, request, downstream_client): return business_logic(request_context, request, downstream_client): downstream_client(); downstream_client(); business_response -> full_response; return full_response; something else? In most monoliths you will see all forms of behavior and that is the primary problem with monoliths. Invoke any client anywhere. Determine the requests context anywhere. Put business logic anywhere. Format a response anywhere. Handle errors in 20 different ways in 20 different places. Determine the request is a 403 in business logic, rather than server logic? All of a sudden your business logic knows about your server implementation. Instantiate a client to talk to your database inside of your business logic? All of a sudden your business logic is probably manipulating server state (such as invoking threads, or invoking new metrics collection clients). The point at which a particular request is handed off to the request specific business logic is the most important border in production.
  • tappio 6y ago
    I guess it all boils down to building software with modular structure rather than mixing business logic all around. I personally think that it is easier to isolate business logic with microservice structure, but you can also make a huge mess. You can also make really good modular monolith, where business logic and state is where it belongs and not spread everywhere.
• ivanb 6y ago
  Now that Fowler himself wrote about it I hope that the masses follow. Next I hope that the trend of going vertical-first comes back. Mr Fowler, could you please write an article on vertical-first scaling?
  • richbradshaw 6y ago
    The article is from 2015, so doesn't look like this had much impact!
  • typescriptfan1 6y ago
    Lack of engineering talent + accessibility of the cloud + buzz words got us here. Looking forward to the end of this cycle. This is somewhat reminiscent of the abuse of higher level languages and the mindset computers are so powerful there's no need to think too hard. However, the consequences are no longer limited to a slow and buggy program but many slow and buggy programs and a large AWS bill too!
• jC6fhrfHRLM9b3 6y ago
  MonolithForever (tm)
• optimalsolver 6y ago
  Was hoping for something 2001-related.
• harperlee 6y ago
  In my main side project what I've done is separate different conceptual components in clojure libraries that I then import into my main program (clojure enables you to seamlessly require a private github repo as a library). This way you get most of the benefits of separating a codebase (such as testing different things, leaving code that barely works in the repo, pointing to older versions of part of the monolith, smaller repos, etc.) whilst integration between modules is a one-liner, so I don´t need microservices, servers, information transformation, etc. There's even the possibility to dynamically add library requirements with add-lib, an experimental tools.deps functionality.
  • heuroci 6y ago
    This is an excellent approach that I wish was more well known/common. We use this first before going to a complete service, which becomes easier anyway once you have a few libraries that had been in use and tested by then. Works great for our clojure code and other languages.
• ThouYS 6y ago
  This is the never ending cycle of "too much order" - "too much chaos". It takes a lot of experience to be able to judge how much chaos you want. That is all.. experience. I don't think any theoretical theory can tell you how much or how little is right
• ecmascript 6y ago
  I worked on a project that was a monolith. A team was placed to rewrite it to microservices and shortly after I quit that job. About a year after that I ate lunch with a ex-colleague that told me they were still working on that rewrite. Looking at the page now it looks like the monolith is still running as far as I can see, about 5 years later. I guess they gave up. :)
  • woutr_be 6y ago
    Was the rewrite to microservices really the problem here? I’ve worked on a few such projects too, where we decided to rewrite the application, but it never ended up replacing the old existing one. Technology was never the issue in all these.
    • ecmascript 6y ago
      Most likely not, the new guys were phd-types that was ultra smart but did nothing except have meetings. I think they were over-engineering it completely which made it impossible to deliver something of value. However, I think that is often the case of a microservices architecture.
      • woutr_be 6y ago
        > Most likely not, the new guys were phd-types that was ultra smart but did nothing except have meetings. There's your problem, regardless of architecture, it would most likely have been over-engineered anyway.
• sublimefire 6y ago
  The fact that we talk about it raises some questions. Surely it depends on the problem at hand. There are multiple companies solving various issues and those are either global or local, well defined or ambiguous. There is no one approach as it depends on where you stand at the moment as well. Another problem is developers themselves as they are incentivized to push for "over-engineering" as it'll make their CVs look better.
• ernopp 6y ago
  He can write all the posts about software engineering practices he wants his server is still down right now :)
• a_imho 6y ago
  Gall's law.
• Yuioup 6y ago
  Thank you, Martin.
• alexmingoia 6y ago
  The question isn't microservices or monolith. The question is: What problem are we solving, and what's the most efficient way to solve it? Requirements should dictate architecture. Data should dictate the model. Avoid unnecessary work. Be mindful of over-engineering.
• yagodragon 6y ago
  I recently got introduced to the Laravel framework in php. I think it's probably the best implementation of a monolith web framework right now. Php is very simple if you come from c/java and the framework provides you with so much functionality out of the box.
• vemv 6y ago
  Modular First. You start out as technically a monolith, but that is prepared at all times to be decomposed into services, if and when the need arises. It's nothing too fancy - can be simply another name for Hexagonal Architecture, functional-core-imperative-shell, etc.
• lmilcin 6y ago
  Hahaha. I have been saying the same for years but have either been punished by my managers or mercilessly downvoted on HN. Somehow mentioning that microservices might not be perfect solution in every case triggers a lot of people. I have actually helped save at least one project in a huge bank which got rolled from 140 services into one. The team got also scaled down to third of its size but was able to work on this monolithic application way more efficiently. Also reliability, which was huge issue before the change, improved dramatically. When I joined, I have observed 6 consecutive failed deployments. Each took entire week to prepare and entire weekend to execute (with something like 40 people on bridge call). When I left I have observed 50 consecutive successful deployments, each requiring 1h to prepare (basically meeting to discuss and approve the change) and 2h of a single engineer to prepare and execute using automation. Most projects absolutely don't need microservices. Breaking anything apart brings inefficiencies of having to manage multiple things. Your people now spend time managing applications rather than writing actual business logic. You have to have really mature process to bring those inefficiencies down. If you want to "do microservices" you have to precisely know what kind of benefits you are after. Because the benefits better be higher than the costs or you are just sabotaging your project. There are actually ways to manage huge monolithic application that don't require each team to have their own repository, ci/cd, binary, etc. How do you think things like Excel or PhotoShop have been developed? It is certainly too large for a single team to handle.
  • Mandatum 6y ago
    I think my biggest gripe with orgs that adopt microservices is they don't build out any of the testing, CI/CD, monitoring and debugging workflows to support it. It goes from shitty, slow monolithic application that super-pro can debug in a few minutes to.. Slow, shitty disparate services that are managed by different teams who don't share anything, suddenly you've got a Cuckoo's Egg situation where 1 guy needs to get access to all the things to find out what the fuck is happening. Or you just accept it's shitty and slow, and pay a consultancy to rebuild it in New Thing 2.0 in 8 years when accounting forget about the last 3 rebuilds.
    • lmilcin 6y ago
• mathgenius 6y ago
  I take this same philosophy at all levels of my code. It's like the big bang: start out with a dense hot lump of code and as it grows and cools off things break apart into subunits and become more organized, documented, standalone, etc.
• vergessenmir 6y ago
  The main takeaway for me is clean modularity in a system with strong decoupling, the modules can be in a single application boundary (a monolith) or across multiple (services or microservices). The design challenge becomes making sure that your modules can execute within the monolith or across services. The work to be done can be on a thread level or process level. The interfaces or contracts should be the same from the developers point of view. The execution of the work is delegated to a separate framework that can flip between thread and process models transparently without extra code. This is how I approached my last microservices project. It could be built as one massive monolith or deployed as several microservices. You could could compose or decompose depending on how much resources where needed for the work. I fail to understand why techniques around these approaches aren't talked about in detail. They have some degree of difficulty in implementation but are very achievable and the upsides are definitely worth it.
  • mongol 6y ago
    There should be a name for it. If a name is established so people can talk about it easier, it would make a big difference. This is a kind of design pattern, although not an object-oriented pattern.
  • mattacular 6y ago
    Could you elaborate on the framework you mentioned for flipping between process and thread models? That sounds interesting. Was it released or just used internally for some projects?
  • chrisvalleybay 6y ago
    This definitely sounds like an interesting approach. I think however defining these modules and the interfaces between them is the hard part. Part of this work is defining the bounded contexts and what should go where. If I understand DDD correctly this shouldn't be done by «tech» in isolation. It's something that's done by tech, business and design together. This is hard to do in the beginning – and I would argue that it should not be done in the beginning. When starting out you've just got a set of hypothesis about the market, how the market wants to be adressed and in which way you can have any turnover doing it. This isn't the point when one should be defining detailed bounded contexts, but should instead just be experimenting with different ways to get market fit. Edit: typo
• celticninja 6y ago
  To make microservies you just first build a monolith
• hendry 6y ago
  hah, I made a video on the same vibe. https://www.youtube.com/watch?v=clagrT5BC7g https://www.youtube.com/watch?v=clagrT5BC7g Martin is definitely ahead of the curve, or perhaps I'm behind.
• itsthecourier 6y ago
  I saw the internals of an international company service, 40 microservices for a really simple business. Competitor releases 1 monolith. International company was wasting 6x the clouding hosting costs. And using 30+ engineers. Competitor, 6 engineers. Competitor successfully completed the project and is releasing features faster. Microservices should only be used when necessary, just as antibiotics.
• thinkingemote 6y ago
  If starting from scratch, lets say a startup, it's still true that the vast majority of all software projects fail. Therefore optimising things prematurely is not a good use of time or money.
• ilitirit 6y ago
  There's another issue - sometimes people choose to migrate to microservices because the monolith "can't be scaled" or "is too slow" or whatever. Where often the case is just that the monolith was written poorly. But the team doesn't realise this and they and up copying the same poor design and technical processes that lead to the initial problems to the microservice refactor. Now they have the same problems with potentially higher complexity. A problem I've seen on the project I'm working on is that the team seems to want to do conflate orthogonal issues from a design and technical perspective. "We're going to microservices because the monolith is slow and horrible. We're going to use CQRS to alleviate pressure on the repositories. We're going to use Event Sourcing because it works nicely with CQRS." Question: "Why are we Event Sourcing this simple CRUD process?" Answer: "Because we are moving from the Monolith to Microservices".
• je42 6y ago
  > It takes a lot, perhaps too much, discipline to build a monolith in a sufficiently modular way that it can be broken down into microservices easily. have seen that happening. importing modules from all over the place to get a new feature out in the monolith. also, note this happened with rapid on boarding, the code-review culture was not strong enough to prevent this. so the timing of the change from monolith to micro-service is critical, in order to get rid of it. otherwise, chances are high you got a monolith and microservices to take care of.
• marsven_42 6y ago
  If you design for testability and use proper dependency injection your "monolith" will already be "ready" for micro services.
• hardwaresofton 6y ago
  > The second issue with starting with microservices is that they only work well if you come up with good, stable boundaries between the services - which is essentially the task of drawing up the right set of BoundedContexts. > The logical way is to design a monolith carefully, paying attention to modularity within the software, both at the API boundaries and how the data is stored. Do this well, and it's a relatively simple matter to make the shift to microservices. This is the big take-away to me -- for a long while now I've seen this whole monoliths-vs-microservices debate as a red herring. Whether your conduit is functions in shared virtual address space, HTTP or a Kafka topic the real problem is designing the right contracts, protocols and interface boundaries. There's obviously an operational difference in latencies and deployment difficulty (i.e. deploying 5 separate apps versus 1) but deep down the architectural bits don't get any easier to do correctly, they just get easier to cover up (and don't sink your deployment/performance/etc) when you do them badly when there's less latency. What we're witnessing is a dearth of architectural skill -- which isn't completely unreasonable because 99% of developers (no matter the inflated title you carry) are not geniuses. We have collectively stumbled upon decent guidelines/theories (single responsibility, etc), but just don't have the skill and/or discipline to make them work. This is like discovering how to build the next generation of bridge, but not being able to manage the resulting complexity. I think the only way I can make the point stick is by building a bundle of libraries (ok, you could call it a framework) that takes away this distinction -- the perfect DDD library that just takes your logic (think free monads/effect systems in the haskell sense) and gives you everything else, including a way to bundle services together into the same "monolith" at deployment time. The biggest problem is that the only language I can think of which has the expressive power to pull this off and build bullet-proof codebases is Haskell. It'd be a hell of a yak shave and more recently I've committed to not spending all my time shaving yaks. Another hot take if you liked the one above -- Domain Driven Design is the most useful design for modern software development. The gang of 4 book can be reduced to roughly a few pages of patterns (which you would have come across yourself, though you can argue not everyone would), and outside of that is basically a porn mag for Enterprise Java (tm) developers.
• p5v 6y ago
  my TL;DR of the entire article: > Although the evidence is sparse, I feel that you shouldn't start with microservices unless you have *reasonable experience of building a microservices system* in the team.
• ChrisMarshallNY 6y ago
  I tend to take a “hybrid” approach. I believe in modular architectures, as I think they result in much better quality, but the design needs to be a “whole system” design, with the layers/modules derived from the aggregate. Once that is done, I work on each module as a standalone project, with its own lifecycle. I’m also careful not to break things up “too much.” Not everything needs to be a standalone module.
• franklampard 6y ago
  ......
• known 6y ago
  Reminds me https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deb...
• kfk 6y ago
  From my experience the issue with monoliths is organizational and cultural first, then technical (maybe). Monoliths are usually managed by 1 team (IT for instance). This 1 team has never had to collaborate with other teams on building/configuring/improving the monolith. Centralizing things works well for stability but it is horrible for innovation. For instance, ERPs like SAP are monoliths, how do you inject, say, an AI algo to improve productivity on managing invoices into it? That team pushing for that AI is probably super close to accounting but probably far from the SAP IT team. The SAP IT team is incentivized on stability while the accounting one on productivity, how do you resolve the conflict? How do you work together and collaborate? I am sure microservices have many issues, but they make these conversations not just easier but necessary. I think this is the biggest advantage of microservices.
• JulB 6y ago
  Here is interesting comparison of Microservices vs Monolith https://www.n-ix.com/microservices-vs-monolith-which-architecture-best-choice-your-business/ https://www.n-ix.com/microservices-vs-monolith-which-archite...
• FpUser 6y ago
  I always use monolith when building my servers. Only split microservices part when it is really required. Particular example: I've built native C++ server that does some complex computations in some business domains. When this monolith exposes generic JSON RPC based API where agents (human or software) can connect and do various tasks: admin, business rules design and configuration, client management, report design etc. etc. based on permission sets. Now actual business client came. They have their own communication API and want integration with our server and of course being "customer is a king" they want communications tailored to their API. I was warned that this customer is one of many more that company is signing deals with. Not gonna put Acme specific code into main server. This is where microservice part comes. Just wrote a small agent that mediates between client API and ours. Not much work at all. Come another client I can add more specific parts to this new microservice, or give it to other team to build their own based on first one as a template. Physical scalability - I do not worry about. We re not Google and will never be due to nature of the business. Still main server can execute many 1000s of requests/s sustainably on my laptop (thank you C++). Put it on some real server grade hardware and forget about all that horizontal scalability. Big savings.
• notthegov2 6y ago
  Brilliant article Martin and brilliant discussion Hacker News. This is why this forum is still the best.
• jiggawatts 6y ago
  Not even just microservices. Even just unnecessary layers or tiers. I'm working on a project right now trying to spin up the infrastructure in the public cloud for a simple application that some bored architecture astronaut decided would be better if it had an "API tier". No specific reason. It should just have tiers. Like a cake. Did you know Azure's App Service PaaS offering introduces up to 8-15ms of latency for HTTPS API calls? I know that now. Believe, me I know that all too well. To put things in perspective, back in the days I cut my teeth writing "4K demos" that would be added to zip files on dialup bulletin boards. In those days, I carefully weighed the pros and cons of each function call, because the overheads of pushing those registers onto the stack felt unnecessarily heavyweight for something that's used only once or maybe twice. These days, in the era of 5 GHz CPUs with dozens of cores, developers are perfectly happy to accept RPC call overheads comparable to mechanical drive seek times. I can hear the crunching noises now...
• throwaway4good 6y ago
  Martin. The archicture astronaut. Finally returning to earth. Landing the same spot where he took off. But wiser ...
  • heuroci 6y ago
    I was thinking the same thing. Funny how full circles come about in this industry sometimes isn't it ;)
  • notfed 6y ago
    Keep in mind this article was written in 2015.
    • xxs 6y ago
      As long as they are books to sell and conferences to present at, it's all cool and dandy.
    • throwaway4good 6y ago
      Martin has been a character in "enterprise architecture" for a long long time. He has been the inspiration for many convoluted systems. Actually I think he coined the term with his patterns of ... books.
  • deckard1 6y ago
    I was wondering why I was agreeing with this article. It's the most un-Fowler thing I've read from him.
• kumarkeshav 6y ago
  hey, i have just launched our app and trying to get early feedbacks so if you guys give it a try and give some feedback, it would be awesome. https://getorionapp.com https://getorionapp.com
• pc86 6y ago
  We are in the middle of the first production-scale deployment of a greenfield microservice-based application now and there are certainly a lot of pain points. On the flip side, I've been a part of about half a dozen extremely successful strangler migrations[0], some of which were downright easy even with a complicated business domain. I often wonder if we would have been better off deploying a monolith in half the time and immediately starting a strangler migration once the rate of business changes slows down. I've become more and more convinced over the past decade that Monolith First + Strangler Migration is most stable, safest way to deliver mid-sized software projects. [0] https://microservices.io/patterns/refactoring/strangler-application.html https://microservices.io/patterns/refactoring/strangler-appl...
• jaygray0919 6y ago
  We started with flask(https://flask.palletsprojects.com/en/1.1.x/ https://flask.palletsprojects.com/en/1.1.x/) and never looked back. It enables pure, iterative, incremental development.
• darkstar_16 6y ago
  There is no one size fits all solution here. In my experience it is sometimes good to start (conceptually) as a monolith and then divide the service into Microservices, eventually. Also depends on the maturity and experience of the team handling the services because micro services do like a different temperament both to develop and to manage. I'm not from the camp that believes in creating services for every single thing - It's the same camp that believes in starting with distributed databases and then moving in the same direction. I believe in PostgreSQL everything and then moving to distributed only if the application demands ... Wait did I just start another war in here !
• tekmaven 6y ago
  Microservices are hard. Monoliths are hard too. Focus on the product and the customer, build what they need. Architecture is a means to make a successful product.
  • punkdata 6y ago
    Agreed and I'll add that the architecture must evolve into its most efficient form in tandem with the success of the product.
• heuroci 6y ago
  Architecting systems is a dance around tradeoffs: What weight do you you assign to each of the 'ilities'. Some products/services are inherently complex. For those, complexity can not be destroyed.Just transformed from one form to another. I agree that there in many cases people jump on the micro services architecture too soon, without first developing a mature understanding of the domains involved in the application as well as data flow and state transitions. Some years ago I was involved in re-architecting a monolith. This was a team that cherished testing, had modules and layers in the monolith , swore by DRY and so on. There were a few problems: * Adding features was an expensive exercise. For all the layers in place, the abstractions and interfaces were evolved over 5 years and not necessarily with enough design upfront. * Performance was poor: The monolithic architecture was not necessarily to blame here, but rather using a document oriented data store and doing all the marshalling/unmarshalling in the application code. The reasoning was that 'we can store anything. we can interpret it any way we like'. In practice, the code was re-inventing what relational databases were designed for. I proposed and designed a micro services architecture with the team. I had done that sort of thing a few times even before they were called micro services. There were a few advantages: * The product team had the freedom to re-think the value proposition, the packaging, the features. It was critical for the business in order to remain competitive. * The development team could organize in small sub teams with natural affinity to the subdomains they had more experience/expertise in. * Each domain could progress at the pace that fits, with versioned APIs ensuring compatibility. Not necessarily a unique micro service success prerequisite. One can argue versioning APIs is a good best practices even for internal APIs but the reality is that versioning internal APIs is often less prioritized or addressed to begin with. There are technical pros and cons for monolith/MS. Additional data that can augment this decision is the org structure , the teams dynamic and the skillsets available. In the case of that project, the team had excellent discipline around testing and CI/CD. Of course there are challenges. Integration testing becomes de-facto impossible locally. Debugging is not super difficult with the right logging, but still harder. One challenge I saw with that project and other projects that adopt microservices is that the way of thinking switch to 'ok so this should be a new service'. I think this is a dangerous mindset, because it trivializes the overhead of what introducing a new service means. I have developed some patterns that I call hybrid architecture patterns, and they have served me well. One thing to consider when deciding what road to take, is how does the presentation layer interact with the micro services. When it is possible to map the presentation to a domain or a small subset of the domains, the micro services approach suffers less from the cons. A monolithic presentation ---> Micro services backend could severely reduce benefits. 2 good references here: 'Pattern oriented software architectures' 'Evaluating software architecture'
• JebusAustralia 6y ago
  Please donate ethereum to this address as I am being kept hostage by a psychopath called Satoshi Nakamoto. He has scattered all of my personal information and economical research all over youtube, cnbc, techcrunch, the local mainstream media in the netherlands. https://ibb.co/74qYknK https://ibb.co/74qYknK
• caust1c 6y ago
  I'm surprised that he doesn't mention the Monorepo + Microservice approach. I've found that most of the pain, confusion and bugs when dealing with microservice architectures has to do with the basic overhead of repo management, not the actual microservices themselves. If you have a monorepo, and you make a change to a schema (backwards compatible or not, intentional or not), it's a lot easier to catch that quickly with a test rather than having a build pipeline pull in dozens of repos to do integration tests.
  • mlthoughts2018 6y ago
    The article doesn’t have any connection to monorepo / polyrepo axis. You can use either repo structure for a monolith application, or use either repo structure for separated microservices. The article is just not related to repo structure in any way.
    • k__ 6y ago
      I'd say, that's the problem with that article.
      • mlthoughts2018 6y ago
        That wouldn’t make sense, given that repo structure truly is unrelated in any way to the distinctions between monolith applications vs microservices.
        • k__ 6y ago
          But it is. If you have multiple services in one repo it's much easier to work on each of them.
          • mlthoughts2018 6y ago
            No, it is not easier. Working on them across multiple repos is just as easy. In either case you write dev tools to apply changes across units. If the units are repos, it adds no additional complexity.
• ibraheemdev 6y ago
  [2015]
• kpmah 6y ago
  The main problem I have with the 'monolith first' advice is that it implies 'microservices later'. It feels like people have forgotten how to build good, simple, modular code.
• 100-xyz 6y ago
  I work for a small company that uses microservices architecture. The product is simple where a user registers, enters preferences, selects from courses and submits a form. A monolith would be doable with 5 good engineers. Instead we have about 50 engineers+QA releasing bug filled code. The company's design philosophy is based more on what is fashionable that what is suitable.
  • dboreham 6y ago
    > we have about 50 engineers The plan worked.
    • sk5t 6y ago
      Clearly something is working if you've got 50 engineers turning out bug-filled code and systems, and yet the business keeps on living.
      • 0xbadcafebee 6y ago
        > and yet the business keeps on living Sure, they just change the business plan. Move into as many new markets as possible, focus more on new sales than maintaining customers, ship more features/products than you can maintain, etc. If the company gets twice as big but revenue/growth remains the same, that's a sinking ship.
  • lucideer 6y ago
    Anec-contra-data: I worked for a while at a small startup, initially as the sole developer and eventually growing to 3. We had an architecture I would describe as at least being "microservices-esque": a single large "monolithic" backend service, with a number of smaller consumer services, webapps, UIs. The distinction between microservices and monoliths may be debatable but I believe monoliths as described by Martin Fowler typically involve your primary service logic and your UI coexisting. I've found that splitting these at least is usually fruitful. I think this approach is sometimes called "fan-out", though I've seen that term used to describe other different things too; namely the opposite where there's a single monolithic UI layer fanning out to many micro upstreams. TL;DR: Fowler's opening 2 bullet points seem likely to be a false dichotomy as he's force-classifying all architectures into two buckets.
• jjjeii3 6y ago
  I heard so many horror stories that some company tried to break up a large monolith to microservices and after X years of working on it, they give up. For example, in monolith you can use transactions and change millions of rows. If something goes wrong, the entire transaction will be rolled back. If you use microservices, you can only use transactions within a single service.
• idlemind 6y ago
  Article is from 2015. Should this be added to the title?
• vonwoodson 6y ago
  Micro services is a networked/cloud buzzword for The Unix Philosophy. Doing “one job and doing it well” implies, though, that you know what that job is, what the right tool is, and that you know how to do it well. Another word for “monolith” could easily be “prototype” for the sake of this article. If only we all had the time and money to do real software engineering, amirite? But, time and time again I’ve been proven out that “the hack becomes the solution” and that we’re not going to go back and “fix” working code.
• sigmaml 6y ago
  If we were to ignore the mechanism part of microservices, we could say that qmail and postfix have a microservices architecture. Both of them have fared much better than monilithic Sendmail. And, their track records for resilience and reliability are very encouraging too. There exist other ways of designing 'microservices' that are not necessarily conventional monoliths!
• matijash 6y ago
  I like the "peeling off" strategy - starting with the monolith and adding microservices from the edges. I've been working on something that tries to make starting with a monolith in React/Node.js relatively easy. Still don't have much of the "peeling" support but that is something we're looking to add: https://github.com/wasp-lang/wasp https://github.com/wasp-lang/wasp
• hcarvalhoalves 6y ago
  IMO this is an unnecessary dichotomy that we're currently forced to deal with, because we don't yet have a good solution for programming the "cloud" the same way you program a for a single computer, and that ends up leaking into all the consequent decisions of modularisation, performance, code management, deployment, team organisation, etc. (My holy grail would be programming for distributed environments as if you had one giant single-thread computer, and function calls could arbitrarily happen over IO or not, then concerns would boil down to code organisation first. I believe Erlang's OTP model or the way some features of Google Cloud Platform are organised gets us closer to this ideal, but we're not quite there yet.)
  • matijash 6y ago
    This is a great summary of the problem, upvoted.
  • haskellandchill 6y ago
    Have you seen Unison language? They are positioned as a solution to what you are describing.
  • ryanelfman 6y ago
    Sorta the purpose of the Actor model but that has other complexities.
  • ex_amazon_sde 6y ago
    > programming for distributed environments as if you had one giant single-thread computer, and function calls could arbitrarily happen over IO or not Ex-Amazon SDE here. Message-passing libs like 0mq tried to push this idea. They never became very popular internally because passing data between green threads vs OS threads vs processes vs hosts vs datacenters is never the same thing. Latencies, bandwidths and probability of loss are incredibly different. Also the variance of such dimensions. (Not to mention security and legal requirements) Furthermore, you cannot have LARGE applications autonomously move across networks without risks of cascading failures due to bottlenecks taking down whole datacenters. Often you want to control how your application behaves on a network. This is also a reason why OTP (in Erlang or implemented in other languages) is not popular internally.
• deleted 6y ago
  [deleted]
• bernawil 6y ago
  But how monolithic were our monoliths anyway? Take your bog-standard ecommerce solution, built with a LAMP stack. Okay, we've got a php process. Let's put our business logic there. Okay, I need a database. With current cloud practices, that's probably going to be deployed in a different machine. We've got our business logic service and our datastore separated by a network bound from the get go. Okay this is not very performant, I need to cache some data. Let's add a redis instance in our cloud provider. I guess this we'll be our cache service. Okay we need to do full-text search, let's add an elasticsearch cluster through our cloud provider. Okay I need to store users. We can built that into our business logic core, of course, but screw that. We are using Auth0. I guess our "user service" is distributed now. Okay, my php process can't keep up with all this requests, let's scale this horizontally by deploying multiple php processes behind a load balancer! Okay, now I need to do some batch processing after hours. I could add a cron job for that, but I don't want to deal with everything needed for retrying/reprocessing/failure handling plus now that it's a multi-instance deployment it's not even clear which process should do this! Let's put this work in a Lambda from our cloud provider. So until now, we had a star architecture where everything talked to our business core. But adding this lambda that will talk directly to other services without consulting the core we've lost that. Now, stripping out the business core into its constituent parts doesn't sound so strange, does it?
  • luhn 6y ago
    Yeah, that's a terrible idea, so don't do something like that. You don't need to break up your monolith to run cronjobs. My setup: I have async worker running alongside my application. Same codebase, same environment, same monolith, just instead of accepting HTTP requests it pops tasks off a queue. The framework handles retrying/reprocessing/failure. To run cron tasks, I have CloudWatch Events -> SNS -> HTTP endpoint in the monolith which pushes the cron task into the queue. And this isn't some unusual setup. This is something that people have been dealing with for a very long time, long before Lambda came into existence. Most web frameworks have async tasks built-in or an integration with a framework that can do async tasks.
    • morelisp 6y ago
• bob1029 6y ago
  We did the journey both ways: Monolith -> Microservices -> Monolith The first monolith was so bad that microservices made sense at that point in time. The current monolith is an exemplar of why we do not use microservices anymore. Everything about not fucking with wire protocols or distributed anything is 100x more productive than the alternatives. Deciding you need to split your code base up into perfectly-isolated little boxes tells me you probably have a development team full of children who cannot work together on a cohesive software architecture that everyone can agree upon.
• vijaybritto 6y ago
  I have worked on both types of applications and what he says is very true. The startup which failed to launch because of difficulties in getting the architecture and infrastructure right. It was around 2014 and the company company eventually ran out money and more importantly missed the time frame. The second product was a massive enterprise product that had 100s of members working on it on any given day. The product was written in Java as a monolith. It was slow to develop and a pain to work on. But it worked and the product succeeded. People complained that it was slow and they were right. So they decided to break it up into multiple services. First was a pdf report generation service which I wrote in node.js. Then more and more services were added and other other modules were ported as node apps or separate java apps. In the end it was around 12 services and all of them worked well. The monolith was still there but it's fast enough and users were happy. That's a lesson I'll never forget and have understood that time and velocity are far more important for a product to succeed!
• nojvek 6y ago
  Most common architecture for SAAS apps is a frontend served from cdn + frontends served by app stores, an api server behind app load balancer (e.g nginx), a database cluster, and a bunch of async long lived cron jobs + on demand jobs. In that architecture you don’t need that many Microservices. The api server is prolly the most important bit and can be served as a monolith. Many 10B+ companies use this architecture. It works well and does the job. Mono/Microservices is really about separation of concerns. Separation of concerns mostly around what you want to deploy as a unit, redundancy and what should be scaled as a unit. Agree with author. Start with one chunk, and split when you feel the pain and need that separation of concern. Fewer pieces are easier to reason about.
  • arwhatever 6y ago
    I’ve seen Separation of Concerns used as a “killer argument” in many a planning meeting, but reminder it needs to be weighed against the cost of being (un)able to test and validate the entire system atomically.
• jillesvangurp 6y ago
  One issue with any form of modularization is that dependency cycles are not desirable and have the side effect of creating a need for ever more modules. The reason is that any dependency cycle can be trivially broken by adding another module. You get dependency cycles when two dependent services need the same thing and you lack a good place to put that thing. You start with modules A and B. Then B need something that A has and then A needs something that B has. You can't do it without introducing a dependency cycle. So, you introduce C with the new thing. And A and B depend on C but B still also depends on A. And so on. True weather you do Corba, COM, SOAP, Web RPC, OSGi, Gradle modules, etc. The only difference is the overhead of creating those modules is different and has varying levels of ceremony, management needs, etc. Also refactoring the module structure gets more complicated with some of these. And that's important because an organically grown architecture inevitably needs refactoring. And that tends to be a lot more tedious once you have micro services. And inevitably you will need to refactor. Unless you did waterfall perfectly and got the architecture and modularization right in one go. Hint: you won't. Finally, the same kind of design principles you use for structuring your code (e.g. SOLID, keeping things cohesive, maximizing cohesiveness, Demeter's law, etc.) also applies to module design. Services with lots of outgoing dependencies are a problem. Services that do too much (low cohesiveness are a problem). Services that skip layers are a problem. The solutions are the same: refactor and change the design. Except that's harder with micro-services. That's why Martin Fowler is right. Start with a monolith. Nothing wrong with those and should not stop you practicing good design. Using microservices actually makes it harder to do so. So, don't introduce microservices until you have to for a good technical or organizational reason (i.e. Conway's law can be a thing). But don't do it for the wrong reason of it being the hip thing to do.
  • runeks 6y ago
    How does a monolith solve dependency cycles, assuming you don’t put all your code in the same module?
    • jillesvangurp 6y ago
      It doesn't but it simplifies moving stuff around. I use an IDE and can rename at will. With microservice, it's rename. Commit, wait for the thing to build and deploy, open a different project fix all the names, etc. That requires a lot of coordination and is also risky if you get it wrong. With a monolith, you change everything, create 1 commit. And after that passes CI/CD it can be live in minutes.
• 0xbadcafebee 6y ago
  "Monolith vs microservices" is a bit like "Fullsize SUV vs multiple sedans". They are used differently, so you should pick that which fits your purposes. And the idea that you have to do one or the other is a bit ridiculous. I've seen plenty of businesses that organically landed on a mix of monolith and microservice and things in between. Don't get caught up in formalism.
• Shicholas 6y ago
  Monoliths are even easier to manage in 2021 because of workspace dependency management (e.g. yarn workspaces, cargo workspaces) etc. You can have your cake (microservices built as separate packages) and eat it too (a monorepo workspace w/ all your code).
• soheil 6y ago
  A lot of people are saying microservices are great if you do it right. What they miss is they require a whole bunch more people than a monolith to operate, they ignore the cost of adding those people. Really it's like comparing apples and oranges, sure if you have the resources and the headcount to have 37 and a half teams each owning only one piece of your app in a competent way go for that architecture, but if not then stop advocating for a unicorn that only large companies with big budgets can benefit from and preaching it to startups that are struggling to get off the ground as if that should be the industry norm.
• RcouF1uZ4gsC 6y ago
  > But even experienced architects working in familiar domains have great difficulty getting boundaries right at the beginning. By building a monolith first, you can figure out what the right boundaries are, before a microservices design brushes a layer of treacle over them. I think this is one of the most important points. Often it takes time to figure out what the right boundaries are. Very rarely do you get it right a priori.
• anticristi 6y ago
  I'm wondering if "microservices" hasn't lost it's initial meaning. To me, an application composed of the "core", a message queue and a database server already qualifies as "microservices". I know which parts are "delicate" and which parts are "kill-at-will". That is what I care about at a very high level, not having a separate codebase for every single HTTP route.
• _sohan 6y ago
  Microservices primarily solve a team scaling problem. Then comes technical.
  • spaetzleesser 6y ago
    The question is from what team size on microservices make things easier. I bet the number is much bigger than what people think.
• atleta 6y ago
  I, like many others, have been saying this for years. Too bad I didn't see this link before, it would have helped convincing a few people in the past. Now, fortunately, it doesn't seem that much of a heresy to say that monoliths (or SOA) is the right architecture a lot of the time (maybe most of the time). I remember, a little more than 4 years ago I was brought on to save a product launch for a startup. They were, as far as I can remember, already creating the 2nd iteration/rewrite of their MVP with the first one never released and just few months short of doing their first release one of their developers started to convince everyone that the code base was a pile of crap and that they need to rebuild the whole thing is microservices. Because there is no other way around. The system was built in PHP and the otherwise smart and motivated developer wanted to rebuild it as a set of JS microservices. He almost managed to convince the management, including the devlopment lead and the rest of the team. And it wasn't easy to convince him that that would have been a pretty dumb move and that it wouldn't have just taken a few more months, just because creating a 'user service' with a mongo backend was something he could pull of in his spare time. Then I realized that there is something inherent in these kind of situations. Some people come around stating that a new piece of technology (or other knowledge) is better and then suddenly the rest of the world is somehow on the defense. Because they know something the rest don't so how could you prove them wrong? Not easy. And funny enough, this is actually a classic case of the shifting of the burden of proof fallacy.
• etoykan 6y ago
  I don't understand why people think that microservices are monoliths are 2 only options. https://eng.uber.com/microservice-architecture/ https://eng.uber.com/microservice-architecture/
• deleted 6y ago
  [deleted]
• brokencode 6y ago
  A microservice architecture should mainly be used to solve runtime issues, such as to improve scalability or fault tolerance. Also, it can be useful in order to adopt new languages or frameworks. It is not something that should be used simply to clean up your code. You can refactor your code in any way you see fit within a monolith. Adding a network later in between your modules does not make this task simpler.
• ngc248 6y ago
  A monolith designed using Component Based architecture where each of the components has a well defined service boundary, can easily be split up into a microservices architecture. Each of the components from the monolith making up a subsequent microservice.
• jlengrand 6y ago
  I wonder what would the trend be without the push for the huge megacorps that couldn't do without microservices (MAGA mostly) that decided to start selling their cloud services. Would they have kept them for themselves (including k8s), would microservices be just as fashionable? I'd really like to know the answer, while watching my friends startup of 4 people running they 14 microservices on a k8s cluster.
• highspeedbus 6y ago
  The big curse of microservices is the word "Micro". It should have just the right size, be it big or small.
• deleted 6y ago
  [deleted]
• kingdomcome50 6y ago
  The problem with creating a dichotomy between "monolith" and "microservices" is that... well... it doesn't make any sense. You describe your "microservices" and I'll explain how it's really just a monolith. "So let me get this straight, you have a Billing package and an Ordering package. How are these organized again?" -> "We have a distributed system." "So you you compile them together and deploy them horizontally across many machines? Like a distributed monolith?" -> "No we use microservices. The two packages are compiled and deployed separately so there is no code dependencies between them." "Okay. So if I understand this right, you develop each package separately but they both access the same database?" -> "No no no no! Microservices are not just about code dependency management, they are also about data ownership. Each package is developed and deployed separately and also manages it own database." "Ah, so you have two monoliths?" -> "..." You see the problem is that the above terms are too broad to describe anything meaningful about a system. And usually "monolith" is used to described the dependencies between code whereas "microservices" is used to describe dependencies about data. It turns out there is a lot of overlap. Design and implement your systems according to your use-case and stop worrying about how to label them.
  • rbobby 6y ago
    > "Ah, so you have two monoliths?" Made me snort.
    • a1369209993 6y ago
      Divide and conquer is all well and good, but it often ends up being: A: We have a problem. I know, we'll use divide and conquer! Runs off. B: Uh, that's actually Banach-Tarski^W^Wmicroservices? Wait, come back! later B: Now we have two problems, contorted to fit into a spherical subspace^W^WIO monad, and a dependency on the axiom of choice^W^W^Wasyncio library. A: Wait, why are there monads? This is Javascript! B: There are always monads, it's just a question of whether you type system is overengineered anough to model them.
• 1penny42cents 6y ago
  Monolith First. The point of this idea isn't that it says "monolith"; it's that it includes time as a factor. Too much of our discussion focuses on one state or another, and not on the evolution between states.
• crb002 6y ago
  Using Haskell style IO types - couldn't we lift and shift anything at build time between a network call and a function call? Monolith that could shard at any function boundary into microservices.
• scavenger5 6y ago
  I question the relevance of this with cloud based solutions such as AWS Lambda, where you can spin up a production ready auto-scaled service very quickly; it certainly reduces the cost of ownership and operations. Sure if you are a team of 20 developers working on an app - go monolith. But if you are a 300 person organization launching something from the ground up, I would choose many serverless solutions over a single monolith.
• rudnevr 6y ago
  it's surprising to be _so_ disagree. The value of microservices is to isolate risks and have some manageable entity to reason about, to have an understandable scope of lifecycle, test coverage and relations with other services. The larger the piece, the harder it is to do. Splitting up is normally harder than building up, and often impossible to agree on. Any monolyth I worked on was coupled more than necessary because of regular developer dynamics to use all code available in classpath. I've never even saw a successful monolyth split - you just usually rewrite from scratch, lift-n-shifting pieces here and there.
• sriku 6y ago
  A bit of a shameless plug, but really looking for feedback .. I've been experimenting with Inai [1][2], a framework that can help build modular microservice-like software with similar Dev team independence properties but can independently be built and deployed as a monolith or as separate services operationally. So far, I've had fun building an internal project at much higher speed than I've managed any similar project and had more fun doing it. I feel the idea (which is still nascent) has some merit, but would like to know what folks think. [1] source - https://github.com/Imaginea/Inai https://github.com/Imaginea/Inai [2] blog post describing Inai - https://labs.imaginea.com/inai-rest-in-the-small/ https://labs.imaginea.com/inai-rest-in-the-small/ PS: I've had some difficulty characterising Inai (as you can tell).
• mark_l_watson 6y ago
  Thank you Martin. I have argued against micro services for writing systems (until you really need them) for a while and get real pushback. For me, the issue is that a monolith based on, for example, Apache Tomcat using background work threads let’s me also handle background tasks in one JVM. I have not used this pattern in a long time, but when I did it served me well. I think Java and the JVM are more suitable for this than Python and a web framework. I tried this approach with JRuby one time using background worker threads but I wouldn’t use CRuby.
• mac01021 6y ago
  I just wonder what kind of organization or project faces this kind of decision. I've worked on workflow/crud-type web applications whose computational needs could be met using a single server with a couple of GB of RAM using a single database, indefinitely into the future. I don't see why it would occur to someone to split one of those into multiple services. I've worked on systems for which many such servers were required in order to provide the expected throughput and, in such a case, writing a monolith is really not an option. Is there a significant middle ground?