6 ms·

I'd like to hear some background from the author on his situation(s). Personally my current company is over 100,000 employees. We have a few 100 developers an

I'd like to hear some background from the author on his situation(s). Personally my current company is over 100,000 employees. We have a few 100 developers and many stacks, web apps, mobile apps etc. Our API is essential and is currently a giant monolith written by devs who no longer work here. Splitting API code into repos based on endpoints allows us to have small easy chunks to deal with. It also allows us to drop those into containers and monitor and scale much easier. It also means instead of one API team, other devs can easily pickup a small code base and make changes for their stuff and, submit a PR for the API team. ]] This article seems a bit elementary to have been voted up high on HN to be honest. It failed to acknowledge the true merits of doing microservices properly and the huge gains. Not all code bases are meant for microservices. However, huge monolith API's in general are a very good example where it's a perfect fit.

Retric 10y ago
While breaking up a giant API is reasonable. Microservices are tiny, so you and the author may be talking about different things. What % of your services consist of less than 100 lines of code? 1,000? 10,000? PS: Nanoservices are often used as the negative extreme, but as Microservices have a rather fluid definition people are not always on the same page.
- mabbo 10y ago
  The big advantage of microservices, imho, isn't that their code is small (though that can be true), it's that their domain is small. If it takes 100,000 lines to manage your user logins, then do so, but put it behind a simple API that the rest of the company can use. Now you've freed yourself doubly- everyone else can just trust that logins work, and the team focusing on logins can focus on just that one thing.
  - Retric 10y ago
    The problem is if you need 100,000 lines of code for your login you can probably break that up. EX: Employee login vs. contractor login. So, where you might think microservices others may be thinking of your monolithic login service.
    - Jtsummers 10y ago
      Perhaps the focus should be on how people interact with the services. If everyone interacts with the login service through the same interfaces, then they don't need to know how it breaks out internally or care. If, however, you use it through one set of API features, and I use it through another very disconnected set, then perhaps it's time to break it down further. At the end of the day, though, what does it contain? A list of users, their roles, and access control mechanisms. Does it make sense to have unified logins or multiple sets of logins across your company's services? If the latter, break it down to be run once per other application with specialised selection of features per application. If the former, let the login team handle control of the system and leave it a 100k monolith or break it down as they see fit.
  - awj 10y ago
    If it takes 100k LOC to manage your user logins, I doubt you can really put it behind a "simple" API. You're still going to have intricate details that everyone needs to know, but now you're adding all of the issues of networked communication and (often) allowing teams to use different languages/stacks/etc which prohibit inspection to understand the system they're calling.
    - mabbo 10y ago
      So break that logic up into smaller services yet, again splitting up the domain into smaller pieces. No one said a microservice can't call another microservice! Logins are a bad example because it really shouldn't take 100k lines to handle it, but replace 'logins' with any business domain logic that you need. And honestly, the biggest challenge often is building the simplest API possible without limiting your clients.
- falcolas 10y ago
  Each 100 LOC nanoservice is frequently backed by a 1,000+ LOC framework, so you're not really saving that much on code.
StavrosK 10y ago
Why can't you split up your code into libraries? API doesn't have to mean "HTTP API", you're free to pick a different IPC layer.
- eej71 10y ago
  I think the popular counterpoint has been - microservices _forces_ consideration of a good API because you are now on the network even if its just localhost.
  - falcolas 10y ago
    I'd counter that they also force a lot of additional networked API boilerplate, and all new code is a potential source of bugs. Perhaps it's better to break it into libraries with well defined APIs, and then break those libraries out into services when necessary. Jumping straight to the latter is going to create more room for problems than it solves.
    - dsmithatx 10y ago
      Well we are rebuilding from scratch into micro services as we have the man power and money to do it. Why not just go with libraries? Here are the top five reasons off of the top my head. The current monolith is requires vagrant and doesn't mimick production nearly as well as smaller containers. This design will be easier to understand and with dev turnover that means bringing new devs up to speed faster. This is especially important when working with outside development firms which we do. Deployments and scaling will be much faster. If one endpoint goes down it wont affect others. We are working to ensure one endpoint is not dependent on another. When change is required in a certain part of the application, only the related service can be modified and redeployed. No long-term commitment to a single technology stack
      - tekklloneer 10y ago
        This is like looking into a mirror.
      - 10y ago
blauditore 10y ago
The article's author description points to a startup company with a handful of devs, so it's quite likely that they indeed wouldn't gain much from microservices. But large companies with large code bases are a whole different story, and what works well for the former might be unfeasible for the latter.
- mikeryan 10y ago
  So as a small company or startup the upside of microservices is the architecture lends itself well to the use of third party services. Using Auth0 for user auth is awesome for not having to right a ton of user management boilerplate. Content ful for CMS capabilities gives you a content management system and UI. Firebase for DB and push services, Amazon SNS for notifications. A lot of early prototyping and startup tasks can be done gluing together third party services while you focus on core product offering. You can always pull back services as you outgrow these. I think this use case is one of the huge reasons microservice architectures have been so popular.
  - bmh100 10y ago
    The author addresses building internal software as monolith vs. microservices, not the use of others' services as part of one's monolith/microservice.
- StabbyCutyou 10y ago
  This is more of the intended audience (earlier startups or smaller groups of devs), but I could have done a better job spelling that out.
deleted 10y ago
[deleted]
StabbyCutyou 10y ago
Hi, original author here! Quickly, on the "elementary" nature of the post, this was adapted from a lightning talk I gave, and so it was sort of designed to be a very quick introduction into the problem space. Also this was meant to be (and this is my own fault for maybe not more carefully spelling this out) aimed at people just starting out with a new project or endeavor, as a warning that "just sprinkling some microservices on it" is not a magical panacea for scalability or good software design. Thanks for taking the time to read and comment!
Johnny555 10y ago
A company of 100,000 with 100 developers does not make high level architectural decisions from a blog (at least, it should not). If you read the article and can't identify exactly why the issues he raised don't apply to your organization's architecture, then it probably does apply to you. The author did address your situation and said to use microservices: “When you’re ready as an engineering organization.” But for most smaller companies, the issues raised by the article are significant -- One company I worked at tried to do microservices and found that doing distributed transactions across multiple microservices was causing much more complexity than the microservices saved. Doing nested/recursive transactions and rollbacks across multiple services was causing multiple problems - especially in deadlock detection/avoidance. They eventually moved much of the code to a more monolithic service.
nasmorn 10y ago
I would say that he fact that you have 100s of developers changes a lot. But I see micro services pushed as the default approach even for startups with 4 guys in a room.
nasmorn 10y ago
I would say that he fact that you have 100s of developers changes a lot. But I see micro services pushed as the default approach even for startups with 4 guys in a room.
collyw 10y ago
You will have smaller easier chunks of code to deal with, but far more complex deployment and testing.

Retric 10y ago

While breaking up a giant API is reasonable. Microservices are tiny, so you and the author may be talking about different things. What % of your services consist of less than 100 lines of code? 1,000? 10,000? PS: Nanoservices are often used as the negative extreme, but as Microservices have a rather fluid definition people are not always on the same page.

mabbo 10y ago
The big advantage of microservices, imho, isn't that their code is small (though that can be true), it's that their domain is small. If it takes 100,000 lines to manage your user logins, then do so, but put it behind a simple API that the rest of the company can use. Now you've freed yourself doubly- everyone else can just trust that logins work, and the team focusing on logins can focus on just that one thing.
- Retric 10y ago
  The problem is if you need 100,000 lines of code for your login you can probably break that up. EX: Employee login vs. contractor login. So, where you might think microservices others may be thinking of your monolithic login service.
  - Jtsummers 10y ago
    Perhaps the focus should be on how people interact with the services. If everyone interacts with the login service through the same interfaces, then they don't need to know how it breaks out internally or care. If, however, you use it through one set of API features, and I use it through another very disconnected set, then perhaps it's time to break it down further. At the end of the day, though, what does it contain? A list of users, their roles, and access control mechanisms. Does it make sense to have unified logins or multiple sets of logins across your company's services? If the latter, break it down to be run once per other application with specialised selection of features per application. If the former, let the login team handle control of the system and leave it a 100k monolith or break it down as they see fit.
- awj 10y ago
  If it takes 100k LOC to manage your user logins, I doubt you can really put it behind a "simple" API. You're still going to have intricate details that everyone needs to know, but now you're adding all of the issues of networked communication and (often) allowing teams to use different languages/stacks/etc which prohibit inspection to understand the system they're calling.
  - mabbo 10y ago
    So break that logic up into smaller services yet, again splitting up the domain into smaller pieces. No one said a microservice can't call another microservice! Logins are a bad example because it really shouldn't take 100k lines to handle it, but replace 'logins' with any business domain logic that you need. And honestly, the biggest challenge often is building the simplest API possible without limiting your clients.
falcolas 10y ago
Each 100 LOC nanoservice is frequently backed by a 1,000+ LOC framework, so you're not really saving that much on code.

StavrosK 10y ago

Why can't you split up your code into libraries? API doesn't have to mean "HTTP API", you're free to pick a different IPC layer.

eej71 10y ago
I think the popular counterpoint has been - microservices _forces_ consideration of a good API because you are now on the network even if its just localhost.
- falcolas 10y ago
  I'd counter that they also force a lot of additional networked API boilerplate, and all new code is a potential source of bugs. Perhaps it's better to break it into libraries with well defined APIs, and then break those libraries out into services when necessary. Jumping straight to the latter is going to create more room for problems than it solves.
  - dsmithatx 10y ago
    Well we are rebuilding from scratch into micro services as we have the man power and money to do it. Why not just go with libraries? Here are the top five reasons off of the top my head. The current monolith is requires vagrant and doesn't mimick production nearly as well as smaller containers. This design will be easier to understand and with dev turnover that means bringing new devs up to speed faster. This is especially important when working with outside development firms which we do. Deployments and scaling will be much faster. If one endpoint goes down it wont affect others. We are working to ensure one endpoint is not dependent on another. When change is required in a certain part of the application, only the related service can be modified and redeployed. No long-term commitment to a single technology stack
    - tekklloneer 10y ago
      This is like looking into a mirror.
    - 10y ago

blauditore 10y ago

The article's author description points to a startup company with a handful of devs, so it's quite likely that they indeed wouldn't gain much from microservices. But large companies with large code bases are a whole different story, and what works well for the former might be unfeasible for the latter.

mikeryan 10y ago
So as a small company or startup the upside of microservices is the architecture lends itself well to the use of third party services. Using Auth0 for user auth is awesome for not having to right a ton of user management boilerplate. Content ful for CMS capabilities gives you a content management system and UI. Firebase for DB and push services, Amazon SNS for notifications. A lot of early prototyping and startup tasks can be done gluing together third party services while you focus on core product offering. You can always pull back services as you outgrow these. I think this use case is one of the huge reasons microservice architectures have been so popular.
- bmh100 10y ago
  The author addresses building internal software as monolith vs. microservices, not the use of others' services as part of one's monolith/microservice.
StabbyCutyou 10y ago
This is more of the intended audience (earlier startups or smaller groups of devs), but I could have done a better job spelling that out.

deleted 10y ago

[deleted]

StabbyCutyou 10y ago

Hi, original author here! Quickly, on the "elementary" nature of the post, this was adapted from a lightning talk I gave, and so it was sort of designed to be a very quick introduction into the problem space. Also this was meant to be (and this is my own fault for maybe not more carefully spelling this out) aimed at people just starting out with a new project or endeavor, as a warning that "just sprinkling some microservices on it" is not a magical panacea for scalability or good software design. Thanks for taking the time to read and comment!

Johnny555 10y ago

A company of 100,000 with 100 developers does not make high level architectural decisions from a blog (at least, it should not). If you read the article and can't identify exactly why the issues he raised don't apply to your organization's architecture, then it probably does apply to you. The author did address your situation and said to use microservices: “When you’re ready as an engineering organization.” But for most smaller companies, the issues raised by the article are significant -- One company I worked at tried to do microservices and found that doing distributed transactions across multiple microservices was causing much more complexity than the microservices saved. Doing nested/recursive transactions and rollbacks across multiple services was causing multiple problems - especially in deadlock detection/avoidance. They eventually moved much of the code to a more monolithic service.

nasmorn 10y ago

I would say that he fact that you have 100s of developers changes a lot. But I see micro services pushed as the default approach even for startups with 4 guys in a room.

nasmorn 10y ago

I would say that he fact that you have 100s of developers changes a lot. But I see micro services pushed as the default approach even for startups with 4 guys in a room.

collyw 10y ago

You will have smaller easier chunks of code to deal with, but far more complex deployment and testing.