6 ms·

The alternative to Microservices would be to get better at building boundaries in your application before resorting to creating physical boundaries to interact

The alternative to Microservices would be to get better at building boundaries in your application before resorting to creating physical boundaries to interact with code. There are a lot of approaches to this. I've explored these ideas with Obvious Architecture (http://retromocha.com/obvious/ http://retromocha.com/obvious/) and the talk I gave at MWRC 2015 on Message Oriented Programming (http://brianknapp.me/message-oriented-programming/ http://brianknapp.me/message-oriented-programming/). I think the big lesson is that the Erlang stuff was WAY ahead of its time and it already solved a lot of the problems of large networked systems decades ago. Now that we are all building networked systems, we are relearning the same lessons telcos did a long time ago.

jedberg 11y ago
But then you lose a lot of the benefits of microservices, namely the scalability and reliability of being able to manage deployments seperately.
- EdSharkey 11y ago
  YAGNI?
  - jedberg 11y ago
    Absolutely, if there is an additional cost to doing it. But if it's an either or, why not build it right the first time?
    - EdSharkey 11y ago
      YAGNI!
      - jedberg 11y ago
        I don't think you understand what YAGNI means.
        EdSharkey 11y ago
        It sounds like YOU don't understand what YAGNI means to us developers, though. In the context of our little conversation here, Microservices is not an either-or choice. There's quite a penalty you take to productivity/agility/cost with a Microservices architecture just like there was with SOA. It's not free, even if you believe it is "right". Take a look at this: http://martinfowler.com/bliki/MicroservicePremium.html http://martinfowler.com/bliki/MicroservicePremium.html So, YAGNI certainly does apply here, and I do toss the acronym around lightly on purpose because that is the blunt response we programmers need to hear and give WAY more often. You ain't gonna need it!!! Architecture astronauts are everywhere and they are mostly a-holes that create chaos for the rank-and-file. You want hell? Ok, go smash your head against the wall implementing another BDFL's pipe dream. We developers are most to blame in this and we need to cut it out with all the fun meta-work we like to create for ourselves. Run a tight ship, be professional, deliver precisely the product that our customers ask for with no extra bells or whistles. When you have Mt. Everest size workloads like Netflix has, and you need maximum isolation and monitoring and deployment flexibility then, yeah, you're in another league and Microservices is a really awesome approach. I'm guessing you're in my league though, so, I'm doing you a favor here, you can thank me later: YAGNI.
- programminggeek 11y ago
  I don't think it's an either or situation. If you have internal app services, it should be easy to break that/expose that as an external service.
- eloff 11y ago
  But if your project is still small, with a small team you likely don't need that yet. However, if your going to start with a monolith with the intent of going to microservices you had better have strong architectural discipline in the team. Otherwise, with no physical barrier to prevent it, developers are going to fall prey to the temptation of taking shortcuts and reaching across module boundaries, out making chatty APIs that can't be made distributed in a practical manner.
  - jedberg 11y ago
    Even with a small project and small team, it's nice to be able to scale up just the part that is overloaded. Especially if you're on a small budget. And I was working on the premise that you are already doing microservices, so presumably you are already taking the overhead hit.
MrBuddyCasino 11y ago
This. I know that quote has been overused already, but: "Almost all the successful microservice stories have started with a monolith that got too big and was broken up. 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." http://martinfowler.com/bliki/MonolithFirst.html http://martinfowler.com/bliki/MonolithFirst.html Also good: https://rclayton.silvrback.com/failing-at-microservices https://rclayton.silvrback.com/failing-at-microservices
- justicezyx 11y ago
  It's not a microservice success story, it's a software system success story. microservice is just the way the system evolves.
- malexw 11y ago
  It's a good quote, and a sentiment that I've seen echoed by CTOs and VP Engs who actually are running or are currently migrating their companies to microservices. That said, I feel the quote should be: "As of 2015, almost all successful microservice stories..." As the tooling and knowledge around microservices builds up over the next few years, I could imagine a world where starting with microservices makes sense. For a new company, the flexibility you get with microservices to try new tech and throw out failed experiments could result in much faster iterations, helping to nail the product-market fit.
  - bradleybuda 11y ago
    Totally disagree. The advantage of monolith-first isn't that monoliths are easier than microservices (though they might be). The advantage is that early in a project's lifetime, you don't yet know the boundaries between services. Worse, guessing those boundaries incorrectly is more expensive than a monolith. Breaking a monolith into services is difficult, but it's much hard to "rebalance" microservices once your product grows and you realize you have gotten the interface wrong. The monolith stage is important because it helps you figure out what the hell you're building. Establishing service boundaries overly early risks getting you "stuck" in the wrong architecture.
sbov 11y ago
Reading the article, I'm not sure if that's an alternative so much as a prerequisite. Looking at the monolithic architecture, it just took each feature within the monolith and created it as a microservice. Just because you have a monolith doesn't mean you can't have well thought out features and separations of concern. Before coding, before deciding on architecture, I like to think in these terms. What features make the most sense together? Far apart? It should be a prerequisite of any project, regardless of architecture. If you're building a monolith, each one just goes in a different module or package rather than having its own service.

jedberg 11y ago

But then you lose a lot of the benefits of microservices, namely the scalability and reliability of being able to manage deployments seperately.

EdSharkey 11y ago
YAGNI?
- jedberg 11y ago
  Absolutely, if there is an additional cost to doing it. But if it's an either or, why not build it right the first time?
  - EdSharkey 11y ago
    YAGNI!
    - jedberg 11y ago
      I don't think you understand what YAGNI means.
      - EdSharkey 11y ago
        It sounds like YOU don't understand what YAGNI means to us developers, though. In the context of our little conversation here, Microservices is not an either-or choice. There's quite a penalty you take to productivity/agility/cost with a Microservices architecture just like there was with SOA. It's not free, even if you believe it is "right". Take a look at this: http://martinfowler.com/bliki/MicroservicePremium.html http://martinfowler.com/bliki/MicroservicePremium.html So, YAGNI certainly does apply here, and I do toss the acronym around lightly on purpose because that is the blunt response we programmers need to hear and give WAY more often. You ain't gonna need it!!! Architecture astronauts are everywhere and they are mostly a-holes that create chaos for the rank-and-file. You want hell? Ok, go smash your head against the wall implementing another BDFL's pipe dream. We developers are most to blame in this and we need to cut it out with all the fun meta-work we like to create for ourselves. Run a tight ship, be professional, deliver precisely the product that our customers ask for with no extra bells or whistles. When you have Mt. Everest size workloads like Netflix has, and you need maximum isolation and monitoring and deployment flexibility then, yeah, you're in another league and Microservices is a really awesome approach. I'm guessing you're in my league though, so, I'm doing you a favor here, you can thank me later: YAGNI.
programminggeek 11y ago
I don't think it's an either or situation. If you have internal app services, it should be easy to break that/expose that as an external service.
eloff 11y ago
But if your project is still small, with a small team you likely don't need that yet. However, if your going to start with a monolith with the intent of going to microservices you had better have strong architectural discipline in the team. Otherwise, with no physical barrier to prevent it, developers are going to fall prey to the temptation of taking shortcuts and reaching across module boundaries, out making chatty APIs that can't be made distributed in a practical manner.
- jedberg 11y ago
  Even with a small project and small team, it's nice to be able to scale up just the part that is overloaded. Especially if you're on a small budget. And I was working on the premise that you are already doing microservices, so presumably you are already taking the overhead hit.

MrBuddyCasino 11y ago

This. I know that quote has been overused already, but: "Almost all the successful microservice stories have started with a monolith that got too big and was broken up. 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." http://martinfowler.com/bliki/MonolithFirst.html http://martinfowler.com/bliki/MonolithFirst.html Also good: https://rclayton.silvrback.com/failing-at-microservices https://rclayton.silvrback.com/failing-at-microservices

justicezyx 11y ago
It's not a microservice success story, it's a software system success story. microservice is just the way the system evolves.
malexw 11y ago
It's a good quote, and a sentiment that I've seen echoed by CTOs and VP Engs who actually are running or are currently migrating their companies to microservices. That said, I feel the quote should be: "As of 2015, almost all successful microservice stories..." As the tooling and knowledge around microservices builds up over the next few years, I could imagine a world where starting with microservices makes sense. For a new company, the flexibility you get with microservices to try new tech and throw out failed experiments could result in much faster iterations, helping to nail the product-market fit.
- bradleybuda 11y ago
  Totally disagree. The advantage of monolith-first isn't that monoliths are easier than microservices (though they might be). The advantage is that early in a project's lifetime, you don't yet know the boundaries between services. Worse, guessing those boundaries incorrectly is more expensive than a monolith. Breaking a monolith into services is difficult, but it's much hard to "rebalance" microservices once your product grows and you realize you have gotten the interface wrong. The monolith stage is important because it helps you figure out what the hell you're building. Establishing service boundaries overly early risks getting you "stuck" in the wrong architecture.

sbov 11y ago

Reading the article, I'm not sure if that's an alternative so much as a prerequisite. Looking at the monolithic architecture, it just took each feature within the monolith and created it as a microservice. Just because you have a monolith doesn't mean you can't have well thought out features and separations of concern. Before coding, before deciding on architecture, I like to think in these terms. What features make the most sense together? Far apart? It should be a prerequisite of any project, regardless of architecture. If you're building a monolith, each one just goes in a different module or package rather than having its own service.