7 ms·

Yes, a thousand times yes! Microservices are yet another tool in the box but they shouldn't be used on everything. And it makes no frigging sense for a startup

by song 11y ago

Yes, a thousand times yes! Microservices are yet another tool in the box but they shouldn't be used on everything. And it makes no frigging sense for a startup or any new project to start with microservices... The main advantage of microservices are in scaling and in reducing complexity of a big system but those advantages only make sense when you have enough traffic so that you have to scale or when your system has become complex enough to warrant microservices. When first starting development, the most important thing is speed of development to get feedback from users as soon as possible. It's much faster to develop a clean, well optimized monolith than to spend a lot of time developing a whole bunch of micro services. And while thinking in term of microservices will help you to better conceptualize your software architecture, at this stage, you don't have all the informations needed to have a clear idea of what the final architecture will be and you'll often end up with microservices that are divided in suboptimal ways causing a lot of pain.

petard 11y ago
> And it makes no frigging sense for a startup or any new project to start with microservices... Doesn't that really depend on what the startup is doing? If your goal is a SaaS platform things might be different. > ..you'll often end up with microservices that are divided in suboptimal ways causing a lot of pain. Or one large monolith that is a mess. Really doesn't matter if you go with monolith or microservice architecture, you can screw up both ways.
worldadventurer 11y ago
Martin Fowler wrote a great post "MonolithFirst" [1] just a few months ago. Quoting him: 1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up 2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. [1] http://martinfowler.com/bliki/MonolithFirst.html http://martinfowler.com/bliki/MonolithFirst.html
- debacle 11y ago
  That's somewhat disingenuous. Historically all software has been "monolith first" and has only adopted an SOA out of need. The microservice mindset is relatively new, and we're not really going to see it mature for another year or few.
  - nthj 11y ago
    If the argument we're going with is “well, microservices-first is relatively new so we won't know for another year or 3 if this is a mature route to take, but everyone's trying it anyway so let's do that", there is NO WAY I can or want to sell microservices-first to stakeholders.
    - debacle 11y ago
      That's not really what I meant. There's a massive survivorship bias with monolithic architectures.
  - mring33621 11y ago
    "relatively new"? I've seen lots of places use little http endpoints for discrete tasks. Whether the endpoint lives inside a shared container or has its own embedded server is an implementation detail.
iofj 11y ago
The article didn't even mention a lot of drawbacks : Changing anything means changing half a dozen programs. Potentially in different languages. Building any new feature into the program means you get to "walk the dependency tree", making sure no serialized stuff from a new version gets sent to an old version. Good luck with circular dependencies. Related: deleting a field ... never going to happen. We're talking years of planning. Any field added ... ever ... has to be taken along for the ride for years. Oh and don't even think about deleting the code that interprets and supports the field for the same reason. Also related: best of luck with the interactions between "oh we're not going to do that after all, sorry about asking you to already push that and update the database" and the "we really need to do this next thing right now" features. And the Constant serialization overhead. People go overboard with this microservice crap and the result is that 99% of your program's cpu time is used putting objects to json and back (which is very expensive due to constant alloc'ing), and you have 10-100 times the normal memory overhead. Microservices should be like optimization : build your program without using them and then figure out where they'd make sense. yes I know, you can sort-of avoid it these days with cap'n proto and flatbuffers
- mdpopescu 11y ago
  deleting a field ... never going to happen This is true for ANY class you release. I'm not even talking about a service API: if you published a class, and it gets used, you should never delete or change fields in it. You might get away with adding fields to it, depending on various factors. This is just the OCP; why is it a surprise?
  - ed_blackburn 11y ago
    Depends. Things are rarely in absolutes :) If you serialise / deserialise you are probably coupled to an underlying type. Modify it instead of extending it and you have pain. If you parse the raw message, or serialise into a hash, or dynamic type then you have one place to make amends (your parser). Taking things further you can version your messages and map them to versions of parsers, as such you'd never violate OCP (or at least simply mitigate). Granted all of which is additional complexity compared to your stereotypical ball of mud / monolith that'll let you refactor field name changes etc to your hearts content. Obviously ball of mud approach has draw backs too...
deleted 11y ago
[deleted]
hyperpallium 11y ago
I think you're right, but scales will shift in a surprising way; also, it's possible to refactor to microservices bit by bit (not all at once). (1) Easy scaling allow for worse coding (and therefore quicker developement). For "webscale" you're right, and if you can run it all on a single cheap server, then no need to worry about it - small servers are so cheap, the cost per month is insignificant relative to, say, ramen cost per month. But what if you write your app incredibly inefficiently? Perhaps because you develop it quickly; you're not highly skilled (or not even a "developer"); it's difficult to optimise. It's very slow, seconds per request. That's fine for getting started, but you need to scale it far before it gets to "webscale". You could just upgrade to a better server; but at some point, the costs becomes prohibitive. The key thing about microservices is that they should be cheaper (because vendors can better utilise capacity; and customers only buy what they need, when they need it). (2). You don't have to architect the whole project for microservices from the get go. e.g. If there's a single resource-heavy function, factor it out into a microservice. Your main code becomes super cheap to host; the microservice only uses expensive resources as needed: when and if it runs. === At the moment, microservices are a pain to set up and manage. But with tools, it will become very easy to factor out a module into a microservice. That is, assuming that code is already a separate module - microservices aren't magic pixie dust!

by song 11y ago

petard 11y ago

> And it makes no frigging sense for a startup or any new project to start with microservices... Doesn't that really depend on what the startup is doing? If your goal is a SaaS platform things might be different. > ..you'll often end up with microservices that are divided in suboptimal ways causing a lot of pain. Or one large monolith that is a mess. Really doesn't matter if you go with monolith or microservice architecture, you can screw up both ways.

worldadventurer 11y ago

Martin Fowler wrote a great post "MonolithFirst" [1] just a few months ago. Quoting him: 1. Almost all the successful microservice stories have started with a monolith that got too big and was broken up 2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. [1] http://martinfowler.com/bliki/MonolithFirst.html http://martinfowler.com/bliki/MonolithFirst.html

debacle 11y ago
That's somewhat disingenuous. Historically all software has been "monolith first" and has only adopted an SOA out of need. The microservice mindset is relatively new, and we're not really going to see it mature for another year or few.
- nthj 11y ago
  If the argument we're going with is “well, microservices-first is relatively new so we won't know for another year or 3 if this is a mature route to take, but everyone's trying it anyway so let's do that", there is NO WAY I can or want to sell microservices-first to stakeholders.
  - debacle 11y ago
    That's not really what I meant. There's a massive survivorship bias with monolithic architectures.
- mring33621 11y ago
  "relatively new"? I've seen lots of places use little http endpoints for discrete tasks. Whether the endpoint lives inside a shared container or has its own embedded server is an implementation detail.

iofj 11y ago

The article didn't even mention a lot of drawbacks : Changing anything means changing half a dozen programs. Potentially in different languages. Building any new feature into the program means you get to "walk the dependency tree", making sure no serialized stuff from a new version gets sent to an old version. Good luck with circular dependencies. Related: deleting a field ... never going to happen. We're talking years of planning. Any field added ... ever ... has to be taken along for the ride for years. Oh and don't even think about deleting the code that interprets and supports the field for the same reason. Also related: best of luck with the interactions between "oh we're not going to do that after all, sorry about asking you to already push that and update the database" and the "we really need to do this next thing right now" features. And the Constant serialization overhead. People go overboard with this microservice crap and the result is that 99% of your program's cpu time is used putting objects to json and back (which is very expensive due to constant alloc'ing), and you have 10-100 times the normal memory overhead. Microservices should be like optimization : build your program without using them and then figure out where they'd make sense. yes I know, you can sort-of avoid it these days with cap'n proto and flatbuffers

mdpopescu 11y ago
deleting a field ... never going to happen This is true for ANY class you release. I'm not even talking about a service API: if you published a class, and it gets used, you should never delete or change fields in it. You might get away with adding fields to it, depending on various factors. This is just the OCP; why is it a surprise?
- ed_blackburn 11y ago
  Depends. Things are rarely in absolutes :) If you serialise / deserialise you are probably coupled to an underlying type. Modify it instead of extending it and you have pain. If you parse the raw message, or serialise into a hash, or dynamic type then you have one place to make amends (your parser). Taking things further you can version your messages and map them to versions of parsers, as such you'd never violate OCP (or at least simply mitigate). Granted all of which is additional complexity compared to your stereotypical ball of mud / monolith that'll let you refactor field name changes etc to your hearts content. Obviously ball of mud approach has draw backs too...

deleted 11y ago

[deleted]

hyperpallium 11y ago

I think you're right, but scales will shift in a surprising way; also, it's possible to refactor to microservices bit by bit (not all at once). (1) Easy scaling allow for worse coding (and therefore quicker developement). For "webscale" you're right, and if you can run it all on a single cheap server, then no need to worry about it - small servers are so cheap, the cost per month is insignificant relative to, say, ramen cost per month. But what if you write your app incredibly inefficiently? Perhaps because you develop it quickly; you're not highly skilled (or not even a "developer"); it's difficult to optimise. It's very slow, seconds per request. That's fine for getting started, but you need to scale it far before it gets to "webscale". You could just upgrade to a better server; but at some point, the costs becomes prohibitive. The key thing about microservices is that they should be cheaper (because vendors can better utilise capacity; and customers only buy what they need, when they need it). (2). You don't have to architect the whole project for microservices from the get go. e.g. If there's a single resource-heavy function, factor it out into a microservice. Your main code becomes super cheap to host; the microservice only uses expensive resources as needed: when and if it runs. === At the moment, microservices are a pain to set up and manage. But with tools, it will become very easy to factor out a module into a microservice. That is, assuming that code is already a separate module - microservices aren't magic pixie dust!