Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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.


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.


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.


YAGNI?


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?


YAGNI!


I don't think you understand what YAGNI means.


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

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: