7 ms·

> 2 - Monoliths still make sense in many contexts Yes and I'd argue it makes sense in most contexts for small startups. Also, Monolith is sometimes synonymous

• mathgorges 5y ago
  Hard agree. If you aren't familiar, I find The App Continuum [1] to be fantastic for structuring these kind of conversations with my teams :D [1]: https://www.appcontinuum.io/ https://www.appcontinuum.io/
• nicoburns 5y ago
  > If code is kept organized, it can be split into microservices when/if the need arises. You can even just run multiple copies of the monolith with feature flags to enable/disable different parts of the code.
  • cheradenine_uk 5y ago
    I know, right? It's also perfectly possible to split those things up, and to have them share the same database. This causes microservice extremists' heads to pop off..
    • withinboredom 5y ago
      We do this at work with multiple entry points. New engineers sometimes don’t even know it exists until the 6th month when they eventually run into shenanigans.
      • cheradenine_uk 5y ago
        Hehe "shenanigans" ;-) The truth is, most things can be made to work - though there are various trade-offs ("shenanigans") involved. e.g: In my current project, there's a bit that loads large-ish files, parses/converts the data, and loads them (order of tens of thousands of rwos) into SQL tables. For reasons that best escape me - since after the files are parsed the entire dataset is _literally_ in memory, instead of doing a bulk sql update there- and then, thousands of messages are enqueued to be consumed by a practically unlimited number of lambda functions that then... bomb out as the SQL database hits it's connection limit and keels over. I guess those shenanigans have better buzzword compliance!
        • withinboredom 5y ago
          Sounds like one of my favorite shenanigans when the stakeholders tell you it needs to handle billions, so you engineer it that way. Reality: it needs to handle thousands. Sounds like you got the reverse shenanigans.
          • nicoburns 5y ago
            Except that there's only one database, you it wouldn't even billions. In fact, I suspect it will handle significantly less load than a batched model will. I've been able to get 100x speedups by batching SQL queries.
            • withinboredom 5y ago
              I miss the days of just one database sometimes… Batching is the way to go, 100%. Remove the network as much as you possibly can.
        • toomanydoubts 5y ago
          You should really put a connection manager in between your lambda functions and database, like HAProxy or AWS RDS Proxy. (still, that doesn't change the fact the code is badly designed)
    • WJW 5y ago
      It's possible, but also a really poor idea. The whole point of microservices is to separate concerns. Reintegrating those concerns through the database is an excellent way to run into problems. Changes to the database schema will alter how all the services that touch it work, and now you have to manage schema migrations across multiple services and probably multiple teams. So much nicer to expose a documented and versioned API (and/or published event stream), so that the consumers of data your service manages have some flexibility at which moment to migrate to the new schema.
  • what_is_orcas 5y ago
    > You can even just run multiple copies of the monolith with feature flags to enable/disable different parts of the code. I can't tell if this is facetious. I hope it is.
    • SkyBelow 5y ago
      Facetious. Everyone knows your feature flags can be determined based on user properties so you can have each user having a custom experience in a single version of the monolith.
    • mlazos 5y ago
      When reading it, it sounds bad, but it’s actually what a lot of big companies do.
    • nicoburns 5y ago
      Why? It's really not very different to having several microservices in a monorepo.
• deleted 5y ago
  [deleted]
• TameAntelope 5y ago
  Organized as in... kept in different repos? People live/die on this hill and it makes no sense. One or many repos, it's just an organizational question, not some Super Serious Big Decision. I work at a small, early stage startup and I'm about to create a new repo for our Slack bot. I'm going to use the Docker image another of our repos generates as the base Docker image for this new repo, and it's going to be just fine.
  • lolinder 5y ago
    Organized as in everything lives in the same deployment unit (and therefore most likely in the same repo) but with clearly defined module boundaries. If you've got separate docker images, you have separate services. OP is saying that most startups that think they need to split out their code into independent services actually just need to organize their single service better. > One or many repos, it's just an organizational question, not some Super Serious Big Decision. When people talk about monoliths they're not usually talking about repo structure, they're talking about deployment structure. One or many repos is just an arbitrary organizational question. One or many services is a really big deal: It's the difference between running a distributed system and not.
    • TameAntelope 5y ago
      "one or many services" is also not a Really Big Deal. You can have a few services that do a category of things and not even sniff microservices architecture. It's not a boolean, it's a spectrum, and where precisely you land on that spectrum is not as important if you're actually focused on getting work done.
      • lolinder 5y ago
        It's a spectrum, yes, and adding an extra service might be the right move, especially if they are well and truly independent (don't interact with each other). But it's still a significant architectural decision to go for a distributed system, much more so than whether you split your services into separate repos or go for a monorepo. Getting work done is important, but it's not an excuse to avoid thinking through the long-term implications of your decisions. If you shrug and say "it's just one more service" every time you're tempted to add a new docker image, you'll not just end up with microservices, you'll end up with poorly planned microservices.
• jmull 5y ago
  I’d put it this way: keeping things organized is something you need to do in any system when there is enough complexity, whether it’s expressed as microservices or a monolith or any other way (this isn’t even specific to computer systems, of course).
• MangoCoffee 5y ago
  IT is like the fashion industry. every few years, you get a new shiny new tech or old tech with new bottle and for some reason what work for Google. we must use it for our organization regardless if it make sense or not.
  • duxup 5y ago
    I think it is partly because it is shiny new ... but also sometimes it seems promising, you have to try to really figure out what works about it, and then you understand it better and its use case is more nuanced.
    • mywittyname 5y ago
      I think it's mostly because the new tech Solves-A-Problem-That-I-Recognize, and developers mislead themselves into thinking the new tech is does everything old tech does, plus this, and they downplay the trade-offs being made (or they aren't experienced enough to recognize the tradeoffs).
      • duxup 5y ago
        I'm not even sure they need to assume. So much programming is by organizational design task by task problem solving that people get lead into making one off decisions and really don't have time to explore otherwise.
      • mbesto 5y ago
        Or even more simply: These solutions are often solved in environments that are running at a scale not most companies operate at, BUT think they will, so they invest in them early for future, potential, needs. It's no surprise many of the core contributors / founders comes from Facebook/Google/etc.
  • giancarlostoro 5y ago
    I mean look at the rise of things like Hotwire. We are seeing developers go away from JSON everything to let me just send an HTML partial over the wire instead, that and things like Phoenix Liveview: let me send what needs to be changed in the DOM as a websocket message and save on data. I don't mind the idea for a SPA for a big social media type of site, but for ordinary sites, I feel like it's overkill in most cases. If you enjoy it and it works best with your team and workflow I'm not trying to knock on you. I just prefer not to add more layers and points of failure to my web application.
• ladyattis 5y ago
  Often I think this means teaching people how to make services large enough to do their job and small enough that you can replace it within a couple hours worth of a work for a junior developer (a senior developer should be able to do the same work within an hour or less depending on their familiarity with the language and build system).
• kodah 5y ago
  The problem isn't that building clean monoliths is hard but rather that building messy monoliths in tempting. Microservices, in most patterns, or even SOA will put more-than-arbitrary separation between code and databases. Without that more-than-arbitrary boundary then code gets spoiled because it's easy to import the other services library directly, it's easy to make that DB call yourself rather than route it through another controller, etc...
  • cseleborg 5y ago
    Isn't it equally hard, if not harder, to maintain a neat, well organized microservices architecture?
    • kodah 5y ago
      If you're in a monorepo then you're replicating the constraints a monolithic architecture applies, so yes, I could see that happening. Edit: Inadvertently, this is why I also like to call these things "patterns" rather than architecture. Architecture being the idea, and pattern how you implement it.
    • somat 5y ago
      Isn't the whole point of microservices is that it does not need a neat, well organized architecture. Not saying it's true, but when you cut through the marketing bs that's the claim.
  • Juliate 5y ago
    Depends in which stage you are, but if you are still figuring out what to build, or how to build it, fast-built messy monoliths are the least of your problems. Once things are validated, opportunities compound to rewrite "properly" (^Wtemporarily) things around or aside the monolith.
    • mirekrusin 5y ago
      Exactly, in any moderately sized corporation new functionality will be rewritten several times, sometimes deprecated/reshuffled completely and crystalized after some time – that is good moment to start thinking about extracting things. Changes on the service boundaries are much more expensive than internal changes.
• AtNightWeCode 5y ago
  I do not see why a startup would not go with microservices today. It is a nice way of separating concerns. The knowledge on how to do this in a good way is out there. It allows for smaller isolated changes, feature focused development and much shorter time to production. Just build services that are not too small, avoid dependency hell between services and never build platforms.
  • rajin444 5y ago
    You introduce a lot of complexity when you change the boundaries. Straight to microservices is almost always premature optimization. You'll know pretty quick when it is needed.
    • AtNightWeCode 5y ago
      The boundary complexity is always present. When you want to tackle that problem is another concern. Horizontal dependencies can destroy any system no matter if it within a database or between services. A lot of monoliths reach end-of-life because everything is glued together. I even worked with partners that have systems where each database table is dependent on a single table in the database. It failed. A design doomed to fail from start.
  • zanellato19 5y ago
    It makes everything more complicated. Deployment is more complicated, changes can be more complicated, performance is more complicated. Its a great way of splitting up teams, but when you are a startup and have a single team for a long time, why would they do this? > Just build services that are not too small, avoid dependency hell between services and never build platforms. This is basically "code without bugs and you will be alright". Avoiding dependency hell is difficult, sizing up the services at the perfect size is also difficult as hell. Everything is a lot more difficult. Microservices can be amazing, I'm not saying they aren't, but acting they are just better than monoliths is not seeing difficulties where there are many.
  • lolinder 5y ago
    Microservices are a solution to organizational problems, not to technical ones. They mean accepting increased technical complexity (your system is now distributed) in exchange for decreased organizational complexity (your teams can now deploy independently from each other, can safely make database schema changes, etc). Going with microservices from day 1 will initially mean that you have one team maintaining many services. They have to deploy them separately. If you're doing it "right" you have separate databases per service. None of that is useful for a team that's just starting out. If you want separation of concerns, the language's module system and a bit of discipline will get most teams as far as they need without introducing distributed computing into the equation.
• ar_lan 5y ago
  > If code is kept organized, it can be split into microservices when/if the need arises. You can still keep a client interface, but in the monolith impl you can just have it call code directly instead of transport data over a wire. Then, when/if you separate, the only code changes you need are the transport layer (not necessarily non-trivial, but it's just a single point of code that needs major overhaul). I find usually when people say they are pro/against monolith/micro-services, they are using very overloaded terms. When I hear "anti-microservice" my brain thinks "wow, this person is against code that separates concerns into their own logical buckets - they must love entangled messes of code that take months to make changes in" when usually they are thinking "I'm against severe premature optimization, and rolling out/maintaining orchestration for all 5 of my miniature services when I can really just build this out in a single repository that is able to maintain those concerns for me without duplicating work/effort." Honestly we probably just shouldn't talk about being pro/against any of these patterns dogmatically, and really should talk about the specific issues present in each and when those are worthy trade-offs.
  • cmrdporcupine 5y ago
    'When I hear "anti-microservice" my brain thinks "wow, this person is against code that separates concerns into their own logical buckets' ... Then you're not really listening. Especially in this day and age of cheap machines capable of doing thousands of requests per second and hundreds of thousands of IOPS... almost nobody needs 'microservices'. Hell, I worked at Google and that's not how they solve scaling problems and their scale is bigger than yours... So why does the industry reach for this as a tool? Microservices != separation of concerns or designing for modularity. It's actually a pretty terrible way of designing for that. (Sometimes I feel like if I see another client-side join in my life, blatantly abusing and/or ignoring the presence of a relational database in the stack, I'm going to cut my fingers off with wire snips, throw out all my computers, and leave this industry forever.)
    • ar_lan 5y ago
      You're not really listening, either, as you short-circuited and didn't read the rest of my comment.
• tantaman 5y ago
  > Also, Monolith is sometimes synonymous with tangled spaghetti code but it doesn't have to be Yeah, I hate this false equivalence. When did we start assuming that monoliths couldn't be modular and have clear package boundaries? IMO how you deploy your software (one binary vs many services, all on one box vs distributed) should be an incidental detail that is automated away. You have two packages that are very chatty? Your infra figures this out and deploys them in the same binary. Two packages that rarely talk? Deploy them as separate binaries and maybe even on separate hosts.
  • toomanydoubts 5y ago
    >IMO how you deploy your software (one binary vs many services, all on one box vs distributed) should be an incidental detail that is automated away. >You have two packages that are very chatty? Your infra figures this out and deploys them in the same binary Are there any libs for doing that? Seems to me that that should be pretty complex.
• brightball 5y ago
  > If code is kept organized, it can be split into microservices when/if the need arises. This is my favorite thing about the nature of Elixir actually because it happens automatically. With functional, no-side effects code you ensure that your logic is free from the entanglements that would otherwise complicate the separation. You take one function, you move it somewhere else and it works exactly the same. The ability to cluster BEAM nodes allows you to call that function you just moved by just pointing to the node where it lives and then calling the function. And you'll get the response back just as if it lived in the same place it always did.
• mirekrusin 5y ago
  If you read any respected source, they echo the same thoughts, ie: "For many organizations, the modular monolith can be an excellent choice. If the module boundaries are well defined, it can allow for a high degree of parallel work, while avoiding the challenges of the more distributed microservice architecture by having a much simpler deployment topology. Shopify is a great example of an organization that has used this technique as an alternative to microservice decomposition, and it seems to work really well for that company." "Unfortunately, people have come to view the monolith as something to be avoided—as something inherently problematic. I’ve met multiple people for whom the term monolith is synonymous with legacy. This is a problem. A monolithic architecture is a choice, and a valid one at that. I’d go further and say that in my opinion it is the sensible default choice as an architectural style. In other words, I am looking for a reason to be convinced to use microservices, rather than looking for a reason not to use them." Sam Newman, Building Microservices, 2nd Edition You can see the same thought rephrased by respected people - start with monolith, grow organically from that into services or microservices. It can take years. It may make sense not to do 100% transition ever. Just use common sense, your context etc.
• deleted 5y ago
  [deleted]