8 ms·

I have been doing microservices for 4 years now and I can tell you something: do not go there. The tools are simply not there. Although I am working on one pla

I have been doing microservices for 4 years now and I can tell you something: do not go there. The tools are simply not there. Although I am working on one platform like that right now (see https://github.com/1backend/1backend https://github.com/1backend/1backend) the reason I started it was more the fact that I could not easily deploy a custom tiny service and call it easily. We have solved both problem with 1Backend: launching a new service is as easy as creating a git repo on GitHub, and calling them is just like calling a library with the autogenerated clients. That being said, until a project like 1Backend matures, anyone who starts their startup on a microservices architecture instead of a simple monolitic one is out of their skull.* I have personally watched millions and millions of dollars burnt on building on such platform while our competitor (Uber) became one of the biggest unicorns the world has ever seen. Don't be that startup! We managed to screw it up with 100+ million dollars in funding, which was (is) extremely exceptional in Europe. Of course the tech was only part of the reason for failure, still: there are better way of spending money than chasing bugs across hundreds of services and building instrumentation. *Edit: this sentence of mine was very unfortunately worded and said the exact opposite of what I meant. Hopefully the tons of upvotes I got was because that the upvoters correctly inferred from the context that I advice you to start with a monolith, and not with microservices. Thanks.

je42 9y ago
it depends on your reasons. - if you need to scale the number of teams working on the same product you need to introduce microservices to make the teams work independently from each other. - if you need to scale the (monolith) service and it is too expensive to just scale it n times. microservices can help because you can scale each microservice independently. - that's said the overhead is real. There have been quite a few publications and advocates (like Randy Shoup) that staying monolith is fine until you have pain that a microservice architecture can ease.
- friendly_chap 9y ago
  Exactly! I think we completely agree. All those reasons are very fine ones - but it's still a dangerous move to go microservice style. You have to know what you are doing, and in our buzzword driven industry that's not the case usually. Little insidious time wasters will creep into your work flow and they will lurk there eat away dollars and you won't even notice. I constantly switch back and forth between working on monolithic and microservice apps and for the majority of companies sticking to a monolith until the pain points you mentioned become unbearable is the good call. Even then, just break down your apps to bigger sized services, and stop when the pain goes away. Microservices is a catchy name but if anything micro is the poison there.
  - je42 9y ago
    yeah good to point to make it explicit. splitting to smaller (but not micro) is a very good transition, that might already help.
  - afpx 9y ago
    Given that I have been part of a team that independently invented micro-services, and that since knowing that, I’ve met several other people who have done similarly, it can’t imagine that it’s all that hard. To me, it was just a natural evolution. What do you consider as the most important things that people are do wrong? Also, could you enumerate the time-wasters? Off hand, besides occasionally having to re-consolidate the architecture, I can’t think of many. It would be good to know how much the time-wasters cost in contrast to the alternatives.
- marcosdumay 9y ago
  > if you need to scale the number of teams working on the same product You can do that by several different ways. Overall, if one wants a "one size fits all" answer to how to break code into teams, it is by breaking the code into libraries, not services. Services are a niche tech here, to be considered when the others won't suffice. > if you need to scale the (monolith) service and it is too expensive to just scale it n times. Again, nearly every time this happens, the correct answer is to refactor the monolith so replicating it scales. Services are only for those cases where this won't suffice. I don't think I disagree with how you think. But I do think your comment is easily misunderstood and harmful without those qualifiers.
  - je42 9y ago
    1) Agreed, the split into libraries can be fine. At some point, you want teams to deploy independently of other teams. 2) agreed ! thanks for adding the qualifiers !
  - philwelch 9y ago
    I’ve seen the library approach in practice. It is works to a certain point, but it isn’t too long until having a single deployable[1] artifact becomes as much of a bottleneck as having a single codebase, if not more. Taking this approach makes it harder to do other things that are just as important, such as continuous delivery, empowering development teams to take ownership of operational excellence, or even ship updates in a reliable and timely fashion. Most of the hatred towards microservices is probably better directed at REST, which is a good paradigm for serving documents to web browsers but is overcomplicated for microservices. RPC is a good alternative, and gRPC is a good implementation of it. [1] My phone autocorrected this to “deplorable”, which is also a good adjective for a monolithic web application that contains lots of libraries and is only deployable as one artifact.
  - imtringued 9y ago
    A service can be deployed independently from other services. If you release a new version 1.1.0 of a library you have to update and redeploy all applications that use this library.
  - 9y ago
- 0x445442 9y ago
  Yeah, I've not seen much in the way of definitions about what the bounds of a "micro" service are or how much scope each one includes. It sounds like you're saying that a single micro service maps to a team. Do you think each team should manage many micro services and how many do you think each team should manage? I'm generally interested but having been the guy on dev teams to handle most of the configuration management stuff I've not really been willing to listen to micro service advocates. Depending on runtime environments/architectures the CM costs sound prohibitive at best.
  - foobarian 9y ago
    One per team sounds about right, unless there are some components that don't fit together in the same runtime (e.g. a data lookup with a little business logic might not fit with a module sending out emails). That said libraries go a long way to reduce the dependency graph and prevent developers from creating unnecessary edges by randomly autocompleting code.
    - daotoad 9y ago
      IME we had multiple services for each team. But we were in the process of carving several mutually incompatible whales into common, shared services, YMMV. So we had one team maintaining each whale, and our senior engineers would collaborate to identify pieces that could be cut from each and replaced with a common service. If the innards of one whale matched our service better than the others, that whale's team got to write the service. Eventually all the teams would port their products to the new, resulting service. This meant, for example, that my team, had our whale, an audio transcoding service, an automated transcription service, a post-phone-call messaging service, and several data integrations. If you need a whole team to do nothing but maintain a service, it seems to me like you built it to do too much.
    - dreamfactored 9y ago
      So you would hard couple your architecture to your current org structure?
      - 9y ago
- abraae 9y ago
  Or microservices are strongly indicated if you are in a SaaS industry as we are (HR software), where individual customers want choice over the components making up their own stack.
  - hodgesrm 9y ago
    This is perhaps off-topic but why would you let your SaaS customers dictate the composition of the stack? This seems to obviate one of the major benefits for customers, namely that they don't sweat the details.
    - abraae 9y ago
      Very relevant. The nature of software for managing humans is that it's very fuzzy, fashion/tend driven, diverse. E.g a recent trend is for companies to try and reduce the number of undesirable applicants they get for jobs (since in a big e.g retailer, saying no to a candidate is likely also saying no to a customer). So customer now needs to inject an e.g culture fit quiz into the candidate experience, which only unlocks the apply button once the candidate has "passed". This kind of tweaking and evolvement is not possible within a monolith, so good APIs allowing vendors of the customer's choice to inject functionality are essential. That functionality can then be injected in the form of a small app that does one thing and does it well, has it's own database, i.e has many of the characteristics of what people think of as microservices.
      - icebraining 9y ago
        I don't think it's helpful to conflate "microservices" with "dynamically-loaded code". Many, many programs have a plugin system that can completely alter their behavior while having all the characteristics of a monolith - single process, function calls rather than a message bus, central control of flow rather than decentralized, etc.
        abraae 9y ago
        Well, this can be a fruitless discussion without a shared understanding of what a microservice is. To Martin Fowler: > In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. Assembling HR ecosystems from separate apps certainly meets all of the points above.
- D_Guidi 9y ago
  > quite a few publications "Monolith First", Martin Fowler
  - je42 9y ago
    also this: https://www.slideshare.net/RandyShoup/goto-aarhus2014-enterprisearchitecturemicroservices https://www.slideshare.net/RandyShoup/goto-aarhus2014-enterp...
jtmarmon 9y ago
Thanks for being so candid. I made the same mistake at my startup when given the chance to start greenfield due to a pivot. I ate my pride and switched back to a monolith after realizing I was spending more time doing devops than I was coding.
- friendly_chap 9y ago
  You are welcome. I believe you 100% made the right call. And yeah, the cost of devops is massive: you have to automate everything! If you have a monolith or two you can easily do one off tasks manually and forget about them forever, with microservices it's all about automation.
  - akulbe 9y ago
    Isn't there a sense in which automation, for the sake of creating something more predictable/repeatable/maintainable, is a good thing though?
    - jtmarmon 9y ago
      predictable repeatable and maintainable are all great and important things. But micro services makes everything you do less predictable repeatable and maintainable. You must automate many more things with micro services to achieve the same level of predictable repeatable and maintainable as you have with a monolith. There are many possible benefits of microservices, few of which outweigh the massive costs for many (dare I say most) startups.
bsiemon 9y ago
I disagree. Companies that start with a monolith then face an exceptionally difficult task of 'moving to micro services' because they need that architecture to support team growth. This task amounts to replacing the engine of a running car. I agree in general the tools are lacking but if you use AWS,GCP, or w/e you get a huge boost on the tooling.
- cookiecaper 9y ago
  >This task amounts to replacing the engine of a running car. I hate this phraseology, and IMO it's a telltale sign of a new or inexperienced professional developer (another variation: "replace jet engine while in flight"). All non-greenfield development forbids breaking the existing system in order to make changes. This is a daunting responsibility, but it's inherent and assumed, so only college kids who have never had to maintain a running system before talk about it like it's noteworthy. If someone needs a microservice architecture to support team growth, it just means they don't know how to manage a team, and have to let every dev or pair of devs have their own little kingdom.
- staticassertion 9y ago
  Yes, I can definitely attest to this. For all of the people saying "start with a monolith", having started with a Monolith I can tell you to start with microservices. Even if they all live on the same box, even if they live in the same process, build your software from the start with microservice architecture in mind (eg: understand your boundaries, develop against them - if you can't break a component behind a boundary into a separate process trivially, it's a bad component).
  - HatchedLake721 9y ago
    That’s called modular architecture and has nothing to do with microservices.
    - staticassertion 9y ago
      Microservices encompasses quite a lot, including designing where your module/service boundaries lie. The same ideas exist in many different places (DDD).
olalonde 9y ago
> I have personally watched millions and millions of dollars burnt on building on such platform while our competitor (Uber) became one of the biggest unicorns the world has ever seen. Funny that you picked this example given that Uber itself is known for heavily using and popularising microservices: http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html http://highscalability.com/blog/2016/10/12/lessons-learned-f....
- oblio 9y ago
  Yeah, but didn't Uber do it because they were going for a huge headcount increase? They went from 50 engineers to 2000 in a year or so and they were facing all sorts of non tech issues such as shipping the org chart, engineer recruiting limitations (i.e. easier to recruit 2000 devs knowing any language than just 2000 Java devs), etc. I don't think you can apply the lessons from a startup burning billions per year in many other places...
  - Benjammer 9y ago
    The Uber cargo cult is real.
jpswade 9y ago
Your system seems to be a platform for running Functions as a service (FAAS) not microservices...
ex_amazon_sde 9y ago
Most buzzword chasers end up implementing a distributed monolith. Services work well when you have one or two services per team, the problem space is divided in the right places and the teams provide a service to each others, not code. When you see more services than developers it's often a bad sign.
- ebiester 9y ago
  ...with one caveat: How long has the system been in place? We have services that were built and are in the background because they are effectively finished (for now.) An example would be a service that handles a third party integration. It might get a commit a month once it's built. From my limited perspective, I look at two warning signs: Do changes require changes to more than two services on a regular basis? Ideally, the majority of changes are limited to one service. If you're propagating changes up a stack, it is going to be a slow change. (The whole point of microservices is that once set up, you can move faster, right?)
  - daotoad 9y ago
    Yes. IME, once a service is dialed in, it should need little maintenance. That's how my team was able to handle responsibility for 5+ services on top of our slowly carved up monolith. If your microservice code is significantly harder to manage than your monolith, you've factored it wrong. Which means you shouldn't find yourself constantly working on 6 or 7 different services at once. If so, try a different decomposition. Saying one team per service is like saying "a team should only handle one or two classes".
hodgesrm 9y ago
I don't disagree with your point but it seems to beg the question of how to design a monolith so that it can be split into parts later on.
- dreamfactored 9y ago
  If the domain boundaries don't become self-evident perhaps there's nothing to break off in any case?
adamcharnock 9y ago
As this is a discussion about the microservice/monolithic dichotomy, I'm going to do a little self promotion. I'm working on a project called Lightbus which I'm hoping will find a use for applications which sit somewhere between microservice & monolithic: http://lightbus.org http://lightbus.org https://github.com/adamcharnock/lightbus https://github.com/adamcharnock/lightbus I'm aware that this has all been done before to an extent, so I'm trying not to reinvent the wheel and learn from the past. Advice, critique, or encouragement is very welcome indeed.
cookiecaper 9y ago
The fad of "microservices" is a disaster start-to-finish. Don't be fooled into believing that microservices are popular based on technical merit. As the parent noted, this will just make things harder by trying to micro-ize a startup. Microservices are a thing primarily for their political convenience and dynamic, and they're just dressed up as a technical thing. [Sideline: most of our technical fads are this way. Err on the side of "letting developers feel important and special while requiring as little effort as possible". Cloud servers are this way because it makes Unix greybeards transparent, and the brogrammer won't have to feel inadequate next to him/her, OR worry about esoteric command-line incantations. Document databases are this way for the same reasons, but replace esoteric command-line incantations with esoteric SQL aggregates (or any useful schema development at all, actually) and greybeards with DBAs. Rinse and repeat for every major development fad.] Microservices are popular due to Conway's Law [0]. They give an out to people who would rather avoid the difficulties of interfacing, deliberating, and collaborating with other people in their organization. They don't have to decide on a common language, they don't have to decide on a common style, they don't have to do anything; they can go run amok, treating the company codebase as their personal playground, under cover of "super cool new-wavy best practices". "Google is doing it. You want to be like Google, right?" There are potential good designs that would qualify as "microservice architectures", but I've seen them only rarely. What I see more often is what I like to call "brittle-services": dozens of tiny, fragile, interdependent units that are virtually impossible to debug, instrument, or reason about cohesively. At $DAY_JOB, we have tons of these; if one service starts to slack off, there is a giant waterfall -- ahem -- of failures that cascades across everything else. The software has been structured this way for purely political reasons, even though no one would be willing to admit it. Like everything else important, good software design boils down to designers with substantial experience, good judgment, and the authority and respect to see their designs faithfully implemented. Unfortunately for the hoi polloi, it can't be generalized into a formula or paradigm like "use microservices", but it seems in any field, there are many posers eager to try. [0] https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
- staticassertion 9y ago
  I'm sorry that at your day job you deal with poorly built software, but that doesn't sound like an argument against microservices. Cascading failures are one of the first things you should have dealt with in your design (and eventually they would become a benefit since your failures have nice boundaries, and are explicit in your code). You sound extremely bitter, and extremely pompous with your "all the other devs are just dumb, I'm the only one who can see through the hype" attitude; especially your comment about younger developers. > good software design boils down to designers with substantial experience, good judgment, and the authority and respect to see their designs faithfully implemented. Like this - projecting much? Microservice architecture is a tool. It isn't a replacement for you or your job. It isn't a replacement for communication. There is a recognition that Conway's law is a serious problem in orgs as they scale - microservices (in part) attempt to deal with this. There are many other benefits. It makes things like DDD easier, since your domains and services can be tied closely together. It makes scaling at a finer grained level easier - a problem a lot of companies may run into as they scale from a few customers to many. I've certainly run into this problem at a company that was moving from distributed monoliths to microservices. It has downsides - a more complicated rollout / deployment structure, less shared knowledge of services, and others. Acting like it's only hype or just 'those darn young devs' makes you sound really silly, especially as someone who's seen Microservices both fail miserably and turn things around completely (in a positive way) for companies. You say it comes down to experienced developers making good decisions - can you not see that Microservices are designed to help with that? The way you break apart your services, their domains, the 'bounded context', etc is all a tool to help you build things well.
forgotpassagan 9y ago
I agree. Microservices have no tooling and a shitload of overhead. After working on such a project I think microservices are an anti-pattern. After a certain point you have to maintain state across service boundaries and all hell breaks loose. By spitting up your application you basically throw away everything a database gives you as far as ordering and atomicity. And you end up building a giant distributed database yourself. Stay away from microservices. I've seen people try to make it work multiple times, the overhead for failure scenarios, lack of distributed transactions, and eventual consistency multiply the size of the codebase
da02 9y ago
Have you written more on the failed microservices design your startup worked on? Like how the services communicated with one another and the protocols used?

je42 9y ago

it depends on your reasons. - if you need to scale the number of teams working on the same product you need to introduce microservices to make the teams work independently from each other. - if you need to scale the (monolith) service and it is too expensive to just scale it n times. microservices can help because you can scale each microservice independently. - that's said the overhead is real. There have been quite a few publications and advocates (like Randy Shoup) that staying monolith is fine until you have pain that a microservice architecture can ease.

friendly_chap 9y ago
Exactly! I think we completely agree. All those reasons are very fine ones - but it's still a dangerous move to go microservice style. You have to know what you are doing, and in our buzzword driven industry that's not the case usually. Little insidious time wasters will creep into your work flow and they will lurk there eat away dollars and you won't even notice. I constantly switch back and forth between working on monolithic and microservice apps and for the majority of companies sticking to a monolith until the pain points you mentioned become unbearable is the good call. Even then, just break down your apps to bigger sized services, and stop when the pain goes away. Microservices is a catchy name but if anything micro is the poison there.
- je42 9y ago
  yeah good to point to make it explicit. splitting to smaller (but not micro) is a very good transition, that might already help.
- afpx 9y ago
  Given that I have been part of a team that independently invented micro-services, and that since knowing that, I’ve met several other people who have done similarly, it can’t imagine that it’s all that hard. To me, it was just a natural evolution. What do you consider as the most important things that people are do wrong? Also, could you enumerate the time-wasters? Off hand, besides occasionally having to re-consolidate the architecture, I can’t think of many. It would be good to know how much the time-wasters cost in contrast to the alternatives.
marcosdumay 9y ago
> if you need to scale the number of teams working on the same product You can do that by several different ways. Overall, if one wants a "one size fits all" answer to how to break code into teams, it is by breaking the code into libraries, not services. Services are a niche tech here, to be considered when the others won't suffice. > if you need to scale the (monolith) service and it is too expensive to just scale it n times. Again, nearly every time this happens, the correct answer is to refactor the monolith so replicating it scales. Services are only for those cases where this won't suffice. I don't think I disagree with how you think. But I do think your comment is easily misunderstood and harmful without those qualifiers.
- je42 9y ago
  1) Agreed, the split into libraries can be fine. At some point, you want teams to deploy independently of other teams. 2) agreed ! thanks for adding the qualifiers !
- philwelch 9y ago
  I’ve seen the library approach in practice. It is works to a certain point, but it isn’t too long until having a single deployable[1] artifact becomes as much of a bottleneck as having a single codebase, if not more. Taking this approach makes it harder to do other things that are just as important, such as continuous delivery, empowering development teams to take ownership of operational excellence, or even ship updates in a reliable and timely fashion. Most of the hatred towards microservices is probably better directed at REST, which is a good paradigm for serving documents to web browsers but is overcomplicated for microservices. RPC is a good alternative, and gRPC is a good implementation of it. [1] My phone autocorrected this to “deplorable”, which is also a good adjective for a monolithic web application that contains lots of libraries and is only deployable as one artifact.
- imtringued 9y ago
  A service can be deployed independently from other services. If you release a new version 1.1.0 of a library you have to update and redeploy all applications that use this library.
- 9y ago
0x445442 9y ago
Yeah, I've not seen much in the way of definitions about what the bounds of a "micro" service are or how much scope each one includes. It sounds like you're saying that a single micro service maps to a team. Do you think each team should manage many micro services and how many do you think each team should manage? I'm generally interested but having been the guy on dev teams to handle most of the configuration management stuff I've not really been willing to listen to micro service advocates. Depending on runtime environments/architectures the CM costs sound prohibitive at best.
- foobarian 9y ago
  One per team sounds about right, unless there are some components that don't fit together in the same runtime (e.g. a data lookup with a little business logic might not fit with a module sending out emails). That said libraries go a long way to reduce the dependency graph and prevent developers from creating unnecessary edges by randomly autocompleting code.
  - daotoad 9y ago
    IME we had multiple services for each team. But we were in the process of carving several mutually incompatible whales into common, shared services, YMMV. So we had one team maintaining each whale, and our senior engineers would collaborate to identify pieces that could be cut from each and replaced with a common service. If the innards of one whale matched our service better than the others, that whale's team got to write the service. Eventually all the teams would port their products to the new, resulting service. This meant, for example, that my team, had our whale, an audio transcoding service, an automated transcription service, a post-phone-call messaging service, and several data integrations. If you need a whole team to do nothing but maintain a service, it seems to me like you built it to do too much.
  - dreamfactored 9y ago
    So you would hard couple your architecture to your current org structure?
    - 9y ago
abraae 9y ago
Or microservices are strongly indicated if you are in a SaaS industry as we are (HR software), where individual customers want choice over the components making up their own stack.
- hodgesrm 9y ago
  This is perhaps off-topic but why would you let your SaaS customers dictate the composition of the stack? This seems to obviate one of the major benefits for customers, namely that they don't sweat the details.
  - abraae 9y ago
    Very relevant. The nature of software for managing humans is that it's very fuzzy, fashion/tend driven, diverse. E.g a recent trend is for companies to try and reduce the number of undesirable applicants they get for jobs (since in a big e.g retailer, saying no to a candidate is likely also saying no to a customer). So customer now needs to inject an e.g culture fit quiz into the candidate experience, which only unlocks the apply button once the candidate has "passed". This kind of tweaking and evolvement is not possible within a monolith, so good APIs allowing vendors of the customer's choice to inject functionality are essential. That functionality can then be injected in the form of a small app that does one thing and does it well, has it's own database, i.e has many of the characteristics of what people think of as microservices.
    - icebraining 9y ago
      I don't think it's helpful to conflate "microservices" with "dynamically-loaded code". Many, many programs have a plugin system that can completely alter their behavior while having all the characteristics of a monolith - single process, function calls rather than a message bus, central control of flow rather than decentralized, etc.
      - abraae 9y ago
        Well, this can be a fruitless discussion without a shared understanding of what a microservice is. To Martin Fowler: > In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. Assembling HR ecosystems from separate apps certainly meets all of the points above.
D_Guidi 9y ago
> quite a few publications "Monolith First", Martin Fowler
- je42 9y ago
  also this: https://www.slideshare.net/RandyShoup/goto-aarhus2014-enterprisearchitecturemicroservices https://www.slideshare.net/RandyShoup/goto-aarhus2014-enterp...

jtmarmon 9y ago

Thanks for being so candid. I made the same mistake at my startup when given the chance to start greenfield due to a pivot. I ate my pride and switched back to a monolith after realizing I was spending more time doing devops than I was coding.

friendly_chap 9y ago
You are welcome. I believe you 100% made the right call. And yeah, the cost of devops is massive: you have to automate everything! If you have a monolith or two you can easily do one off tasks manually and forget about them forever, with microservices it's all about automation.
- akulbe 9y ago
  Isn't there a sense in which automation, for the sake of creating something more predictable/repeatable/maintainable, is a good thing though?
  - jtmarmon 9y ago
    predictable repeatable and maintainable are all great and important things. But micro services makes everything you do less predictable repeatable and maintainable. You must automate many more things with micro services to achieve the same level of predictable repeatable and maintainable as you have with a monolith. There are many possible benefits of microservices, few of which outweigh the massive costs for many (dare I say most) startups.

bsiemon 9y ago

I disagree. Companies that start with a monolith then face an exceptionally difficult task of 'moving to micro services' because they need that architecture to support team growth. This task amounts to replacing the engine of a running car. I agree in general the tools are lacking but if you use AWS,GCP, or w/e you get a huge boost on the tooling.

cookiecaper 9y ago
>This task amounts to replacing the engine of a running car. I hate this phraseology, and IMO it's a telltale sign of a new or inexperienced professional developer (another variation: "replace jet engine while in flight"). All non-greenfield development forbids breaking the existing system in order to make changes. This is a daunting responsibility, but it's inherent and assumed, so only college kids who have never had to maintain a running system before talk about it like it's noteworthy. If someone needs a microservice architecture to support team growth, it just means they don't know how to manage a team, and have to let every dev or pair of devs have their own little kingdom.
staticassertion 9y ago
Yes, I can definitely attest to this. For all of the people saying "start with a monolith", having started with a Monolith I can tell you to start with microservices. Even if they all live on the same box, even if they live in the same process, build your software from the start with microservice architecture in mind (eg: understand your boundaries, develop against them - if you can't break a component behind a boundary into a separate process trivially, it's a bad component).
- HatchedLake721 9y ago
  That’s called modular architecture and has nothing to do with microservices.
  - staticassertion 9y ago
    Microservices encompasses quite a lot, including designing where your module/service boundaries lie. The same ideas exist in many different places (DDD).

olalonde 9y ago

> I have personally watched millions and millions of dollars burnt on building on such platform while our competitor (Uber) became one of the biggest unicorns the world has ever seen. Funny that you picked this example given that Uber itself is known for heavily using and popularising microservices: http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html http://highscalability.com/blog/2016/10/12/lessons-learned-f....

oblio 9y ago
Yeah, but didn't Uber do it because they were going for a huge headcount increase? They went from 50 engineers to 2000 in a year or so and they were facing all sorts of non tech issues such as shipping the org chart, engineer recruiting limitations (i.e. easier to recruit 2000 devs knowing any language than just 2000 Java devs), etc. I don't think you can apply the lessons from a startup burning billions per year in many other places...
- Benjammer 9y ago
  The Uber cargo cult is real.

jpswade 9y ago

Your system seems to be a platform for running Functions as a service (FAAS) not microservices...

ex_amazon_sde 9y ago

Most buzzword chasers end up implementing a distributed monolith. Services work well when you have one or two services per team, the problem space is divided in the right places and the teams provide a service to each others, not code. When you see more services than developers it's often a bad sign.

ebiester 9y ago
...with one caveat: How long has the system been in place? We have services that were built and are in the background because they are effectively finished (for now.) An example would be a service that handles a third party integration. It might get a commit a month once it's built. From my limited perspective, I look at two warning signs: Do changes require changes to more than two services on a regular basis? Ideally, the majority of changes are limited to one service. If you're propagating changes up a stack, it is going to be a slow change. (The whole point of microservices is that once set up, you can move faster, right?)
- daotoad 9y ago
  Yes. IME, once a service is dialed in, it should need little maintenance. That's how my team was able to handle responsibility for 5+ services on top of our slowly carved up monolith. If your microservice code is significantly harder to manage than your monolith, you've factored it wrong. Which means you shouldn't find yourself constantly working on 6 or 7 different services at once. If so, try a different decomposition. Saying one team per service is like saying "a team should only handle one or two classes".

hodgesrm 9y ago

I don't disagree with your point but it seems to beg the question of how to design a monolith so that it can be split into parts later on.

dreamfactored 9y ago
If the domain boundaries don't become self-evident perhaps there's nothing to break off in any case?

adamcharnock 9y ago

As this is a discussion about the microservice/monolithic dichotomy, I'm going to do a little self promotion. I'm working on a project called Lightbus which I'm hoping will find a use for applications which sit somewhere between microservice & monolithic: http://lightbus.org http://lightbus.org https://github.com/adamcharnock/lightbus https://github.com/adamcharnock/lightbus I'm aware that this has all been done before to an extent, so I'm trying not to reinvent the wheel and learn from the past. Advice, critique, or encouragement is very welcome indeed.

cookiecaper 9y ago

The fad of "microservices" is a disaster start-to-finish. Don't be fooled into believing that microservices are popular based on technical merit. As the parent noted, this will just make things harder by trying to micro-ize a startup. Microservices are a thing primarily for their political convenience and dynamic, and they're just dressed up as a technical thing. [Sideline: most of our technical fads are this way. Err on the side of "letting developers feel important and special while requiring as little effort as possible". Cloud servers are this way because it makes Unix greybeards transparent, and the brogrammer won't have to feel inadequate next to him/her, OR worry about esoteric command-line incantations. Document databases are this way for the same reasons, but replace esoteric command-line incantations with esoteric SQL aggregates (or any useful schema development at all, actually) and greybeards with DBAs. Rinse and repeat for every major development fad.] Microservices are popular due to Conway's Law [0]. They give an out to people who would rather avoid the difficulties of interfacing, deliberating, and collaborating with other people in their organization. They don't have to decide on a common language, they don't have to decide on a common style, they don't have to do anything; they can go run amok, treating the company codebase as their personal playground, under cover of "super cool new-wavy best practices". "Google is doing it. You want to be like Google, right?" There are potential good designs that would qualify as "microservice architectures", but I've seen them only rarely. What I see more often is what I like to call "brittle-services": dozens of tiny, fragile, interdependent units that are virtually impossible to debug, instrument, or reason about cohesively. At $DAY_JOB, we have tons of these; if one service starts to slack off, there is a giant waterfall -- ahem -- of failures that cascades across everything else. The software has been structured this way for purely political reasons, even though no one would be willing to admit it. Like everything else important, good software design boils down to designers with substantial experience, good judgment, and the authority and respect to see their designs faithfully implemented. Unfortunately for the hoi polloi, it can't be generalized into a formula or paradigm like "use microservices", but it seems in any field, there are many posers eager to try. [0] https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law

staticassertion 9y ago
I'm sorry that at your day job you deal with poorly built software, but that doesn't sound like an argument against microservices. Cascading failures are one of the first things you should have dealt with in your design (and eventually they would become a benefit since your failures have nice boundaries, and are explicit in your code). You sound extremely bitter, and extremely pompous with your "all the other devs are just dumb, I'm the only one who can see through the hype" attitude; especially your comment about younger developers. > good software design boils down to designers with substantial experience, good judgment, and the authority and respect to see their designs faithfully implemented. Like this - projecting much? Microservice architecture is a tool. It isn't a replacement for you or your job. It isn't a replacement for communication. There is a recognition that Conway's law is a serious problem in orgs as they scale - microservices (in part) attempt to deal with this. There are many other benefits. It makes things like DDD easier, since your domains and services can be tied closely together. It makes scaling at a finer grained level easier - a problem a lot of companies may run into as they scale from a few customers to many. I've certainly run into this problem at a company that was moving from distributed monoliths to microservices. It has downsides - a more complicated rollout / deployment structure, less shared knowledge of services, and others. Acting like it's only hype or just 'those darn young devs' makes you sound really silly, especially as someone who's seen Microservices both fail miserably and turn things around completely (in a positive way) for companies. You say it comes down to experienced developers making good decisions - can you not see that Microservices are designed to help with that? The way you break apart your services, their domains, the 'bounded context', etc is all a tool to help you build things well.

forgotpassagan 9y ago

I agree. Microservices have no tooling and a shitload of overhead. After working on such a project I think microservices are an anti-pattern. After a certain point you have to maintain state across service boundaries and all hell breaks loose. By spitting up your application you basically throw away everything a database gives you as far as ordering and atomicity. And you end up building a giant distributed database yourself. Stay away from microservices. I've seen people try to make it work multiple times, the overhead for failure scenarios, lack of distributed transactions, and eventual consistency multiply the size of the codebase

da02 9y ago

Have you written more on the failed microservices design your startup worked on? Like how the services communicated with one another and the protocols used?