Comments by "" (@ContinuousDelivery) on "Monolith vs Microservices" video.

  1. It’s the most common approach that I see in most of my clients. May be a self-selecting group I suppose.
    3
  2. Please do!
    3
  3. Can be a good idea, but they need to be independently deployable, and that means independently testable. That is changes to these services, don't force change on the users of the service. I have a recent video that talks about that, not just from a microservices perspective, but from a platform view: https://youtu.be/_zH7TIXcjEs
    2
  4. Yes, in that case the most efficient way to organise things is to have a single (not necessarily gigantic) repo for both services. As I said, the real question is what do you have to test before changes anywhere, in either of these services, are safe to release? The real answer given your scenario is both services. For microservices it is generally preferable to duplicate behaviour than share code between services, to retain their independence, and keep them de-coupled, unless the code that they are sharing is another, decoupled, microservice. The downsides of monorepo are that you need to work harder to get results fast enough, and that it can result in poor or inexperienced teams to ignore coupling within the repo (this is true of microservices too but they suffer more when it happens). Even in a mono repo you still want good, modular design.
    2
  5. sorry, only kindle/e-reader or paperback, at the moment.
    2
  6. Thank you for your support!
    2
  7. We have an announcement on that soon 🤫
    2
  8. I don't think "microservices suck" but they are a lot more complicated than monoliths, so if you can't build and manage a monolith well, you aren't ready for microservcies. The problem is that people think microservices are easier, when they are not. Microservices are the most scalable approach to SW dev, but that comes at a cost.
    2
  9. Glad it was helpful!
    1
  10. I've worked out a deal with the t-shirt providers for a discount for CD viewers - https://bit.ly/3FVX3tP *Remember to use the discount code: ContinuousDelivery
    1
  11. I think that you start with a false alternative, it is not "microservice or corporate repo", it is "align your repo boundaries with deployable things". So mostly I'd have a repo per system, and the test for "deployable things" is "do I need to test this with anything else before I release it?". If not you are good, if you do, then you are dealing with more complexity than you need to. In my experience coupling is a MUCH bigger problem than lack of re-use. Of course we want to architect systems so that there are cannonical versions of some behaviours, I am a big fan of service oriented design, key to the strategy of microservices is to reduce coupling, and as soon as you share code you increase coupling. This means that it is always a dance. There is no single simple answer, and my experience for the past few years is that virtually every client company that I have worked with are struggling to cope with too much coupling between things that they think of as microservices, when they are really coupled-modules. I don't advise mono repos for everything, but I at the moment I see many more people struggling because of multi-repos than because of mono repos. It is more complex than either one of these solutions which is why I like the "independently deployable unit" as a guide. That doesn't rule-out sharing code, but when you do, you protect those boundaries where you share in some of the ways that I mentioned.
    1
  12. Mostly what I mean is not necessarily one repostory for all your systems, but one repository per deployable unit of software. You can parallelise the deployment. For the bigger systems that I worked on, we'd usually have a distributed, service-based, architecture and deployment would be carried out with each part being deployed in parallel with the others, but coordinated so that the release was between the previous version of the whole distributed system to the new version of the whole distributed system. Actually, the size of the repo doesn't really matter much unless it causes problems - you certainly don't want to be downloading 84Tb a day! But if your tools only work on deltas, then knowing that all 84Tb of stuff DEFINITIVELY works together is a useful think to know.
    1
  13. 😉 Thanks for the suggestion.
    1
  14. 💯
    1
  15. Glad it was helpful!
    1
  16. 😂😂😂 If you're interested, I've worked out a deal with the t-shirt providers for a discount for CD viewers - https://bit.ly/3FVX3tP *Remember to use the discount code: ContinuousDelivery
    1
  17. Monorepo means one repo, multi repo means many. You are right to say one or many for what. What the video attempts to explain is that it should be for the scope of evaluation necessary to release a change into production - a single deployable unit of software. The advice in the video is to organise your repos based on the releasability of your software. You should be able to release the contents of a repo without testing it with anything else first.
    1
  18. I've worked out a deal with the t-shirt providers for a discount for CD viewers - https://bit.ly/3FVX3tP *Remember to use the discount code: ContinuousDelivery
    1
  19. For me it is all about scope of evaluation. If your mini-services, from which you construct "independently deployable services" are all in one repo, and all evaluated in the same pipeline prior to release, then yes, I think that is the most efficient way to organise things. If each of your mini-services is in a separate repo, and then you test them all together when composed as an "independently deployable service" or even worse "your mini services are used in multiple 'independently deployable service" then IMO you have an inefficient distributed monolith, either at the level of each of your "independently deployable services" or in the second, worst, case at the level of your whole system which is coupled through the re-use of the mini-services. if your mini services are in separate repos, the question is, what do you have to test after changing a mini service?
    1
  20. I've worked out a deal with the t-shirt providers for a discount for CD viewers - https://bit.ly/3FVX3tP *Remember to use the discount code: ContinuousDelivery
    1
  21. Sure, and you can do that with contract testing, which is what I usually recommend, but I still think that the real test is "can you release your service without testing it with others first?" if not it is not microservices, it is coupled-modules with all the costs associated with that.
    1