8 ms·

If you don't have a product yet or the parameters could change quickly with new business insight, you need to be able to change it fast. With microservices you

If you don't have a product yet or the parameters could change quickly with new business insight, you need to be able to change it fast. With microservices you will be spending half your time figuring out orchestration, building data flows that people can understand, and doing ops. Last startup I was in delayed their launch date for >6 months because of their architecture. Way too many people think they need it, but a load balanced monolith can take you from 0 income to able to hire more engineers.

eropple 9y ago
I do devops. I consult for startups. And while it would make me a lot more money in the short term to fuel their microservice-first, sparkly-architecture aspirations, this is exactly the approach I take when I pour some water on that. Your Big Ugly Monolith will get you where you're trying to go if anything will. You don't need services, you don't need microservices, you don't need some bloggable-as-heck Kubernetes setup with pet sets holding your billionty different datastores--you need a webserver and one data store and maybe a cache, eventually. You grow from there. Where I do push, though (and this often surprises people because "what does a devops person know about code architecture"--the answer is "a lot, both from writing it and seeing it badly written"), is hard demands of app statelessness and an encouragement of business logic internals that are functional in nature, with I/O, wireups, etc. handled at the outer edges of the application. Functional-core-imperative-shell lends itself to decomposition later if you need services (and I say "need services" because the size of the set of companies that "need microservices" is within epsilon of zero)--you replace RPC with a network layer because you built your app with clean, bright-line divisions. Rule of thumb: if you have two "service" talking to the same set of data in the same general-purpose datastore (i.e., not pub-sub, not opposite ends of a job queue), they're the same service.
- taurath 9y ago
  Couldn't agree more - inheritance chains and heavily stateful instruction environments are the number one blocker to eventually decoupling a monolith. The "enterprise" code style is absolutely what you need to avoid in a startup.
  - srtjstjsj 9y ago
    what is "enterprise" code style?
  - quickben 9y ago
    If you avoid what you listed in actual software, you'll be left with a mess they will take years and tons of money to fix.
    - beat 9y ago
      Yes, but if you don't avoid it, you might never get off the ground to the point where you have years of time and tons of money in the first place.
      - deleted 9y ago
        [deleted]
      - quickben 9y ago
        I guess it depends on the viewpoint. Yours sounds valid. Mine comes from the occasional fixing people's messes. But I agree with you, some product is better than no product in most cases.
        beat 9y ago
        I have a lot of career experience dealing with legacy software. I feel that pain intensely. But still... a working product with bugs and flaws is better than a not-working product that is elegantly built. Or half-built.
  - JBReefer 9y ago
    Absolutely agreed, where Enterprise === "making a profit"
- Animats 9y ago
  Rule of thumb: if you have two "service" talking to the same set of data in the same general-purpose datastore (i.e., not pub-sub, not opposite ends of a job queue), they're the same service. Why? The whole point of a general-purpose database is to allow multiple applications to use the same data. Consider an online ordering system for merchandise. There's an service for checking product availability. There's a service for building a shopping cart. There's checkout and payment, the only one that faces the outside world that needs high security. There's customer order tracking. On the back end, there are various services which deal with fulfillment, shipping, accounting, and reordering. There may also be customer-relationship systems which can read order data for marketing purposes. Each of those functions can be worked on independently.
  - sbov 9y ago
    A huge point of microservices is to create code that is independent of eachother. Your database backend is tightly coupling what should be completely independent services. Microservices were designed to scale your engineering departments just as much (if not more than) your performance. You are throwing away the major point of why microservices were created in the first place when you do what you're doing: so teams in large organizations can do independent releases. That you cannot see this as a major benefit makes me think microservices are a poor choice for your use case.
    - eternalban 9y ago
      > You are throwing away the major point of why microservices were created in the first place when you do what you're doing: so teams in large organizations can do independent releases. Let's ammend this: so teams in large organizations +{that lack both a coherent architecture and the ability to devise one} can do independent releases +{by adoptiong the no-architecture architecture}.
      - marcuslager 9y ago
        "teams in large organizations" Could be simplified to just "teams. These days from what I can see teams in organizations with no ability to devise a sane architecture usually take the microservice route. Management loves this new buzzword. To them it means problems go away.
- tnolet 9y ago
  This is exactly what happened / is happening at my former employer. Already 2 years of work, team of 5 engineers, Kubernetes, dozens of microservices. Lot's of time wasted on CI/CD, orchestration, monitoring, refactoring. Live date? Probably somewhere next year. It was sad to watch. 100% resume-based development.
  - avip 9y ago
    RDD is 2010. It's called blog-driven development now (BDD)
  - ebiester 9y ago
    I agree with the rest of this, but CI isn't hard on a monolith, and it's well worth it. (CD is a tradeoff. If you understand why it's important for you, it might be worth it, but does add complexity.)
- Turbots 9y ago
  Exactly. Make a monolith first, but do it with clean code and with twelve factor apps in mind. That's why I love using Spring Boot.
staofbur 9y ago
I'd argue it's cheaper scaling out the monolith or introducing isolated functional silos and scaling them out than even bothering migrating everything to microservices. Also you certainly can't port a complex monolith to microservices; you have to start again. We're quite happily able to shift 15,000 requests/sec from over 2000 http endpoints with a monolith and our kit is at ~20% capacity. Need more? Slice up a silo some more. Key aspect when you design the monolith is not building a spaghetti monster. If X doesn't need to talk to Y, put a wall there (package level)
- eropple 9y ago
  > Also you certainly can't port a complex monolith to microservices Upvoted you, but I disagree with a little. "Microservices" tend to pathological cases, but you 100% can segment a monolithic apps into services. Each module in your application has an interface. Behind that interface, replace it with network calls that fulfill the interface's contracts. (If your monolith doesn't have sections that encapsulate work--well...kinda did it to yourself, but that IME is rare.)
  - staofbur 9y ago
    You can, hence my comment about silos. The interface is rarely well defined enough to be able to abstract it over a network boundary from experience. One of the things I see in a lot of monoliths is leaky abstractions and they are really difficult to reign in. We tend to go for throwing related web front and and API endpoints into the same ball of mud silo and back end that directly with the storage and cache services. We scale those silos up and partition across tenants too. I think a couple of the silos are around the 1 million LoC size now as well.
    - eropple 9y ago
      Fair enough. In places where I've had to deal with that, I was in the code review seat ahead of time and was generally able to go "no no no, let's not do that"--but I can see how stuff can decay.
sanderjd 9y ago
I've experienced the opposite: you get traction with a monolith, and when its time to expand and scale, you find yourself with a massive kludge that makes it hard and slow to make progress. Which is not at all to say that you're wrong - a long delay in the capability to release something can definitely be an earlier and more severe death knell than friction when trying to grow. For me personally, I like to see all of: tools that aim to make it easier to modularize from the start, tools that aim to make it easier to modularize an incumbent monolith, and tools that make monoliths work better themselves. I think all of these solve real problems for different teams at different stages of growth and facing different trade offs.
- dasil003 9y ago
  Sure, but if you build microservices from the start, you die before you get traction because refactoring takes too long while you are finding product-market fit. The right way to do it is to write a modular monolith and maintain a loose plan on how to break it up later. Admittedly this is difficult in SV's youth-obsessed culture where "senior" devs have 5 years experience, and staying at a company long enough to understand the long-term repercussions of architectural choices is seen as a black mark on your resume, but on the bright side languages like Elixir/Erlang help you do the right thing more naturally than more traditional languages.
  - sanderjd 9y ago
    The point of my comment is that I both agree with all that and like to see people working on the problem of making it work better to start with microservices if that's what your team thinks is best for your project. It's not a law of the universe that microservices must result in death. It's a tooling problem. I don't think the tools are quite there yet, but they've improved a lot in the past few years. I think that's a good thing and look forward to even more improvement in the future.
  - NathanKP 9y ago
    > because refactoring takes too long In my experience refactoring microservices only takes a long time if the microservices are badly done, just like refactoring a monolith only takes a long time if the monolith is a horrible piece of spaghetti code. If refactoring requires modifying multiple microservices then the microservice boundaries and contracts were badly designed at the start. When you have practice drawing boundaries well then refactoring with microservices becomes very fast, as you only have to modify the code of one service and redeploy it. I think too many microservice enthusiasts have a tendency to claim monoliths always turn into spaghetti code, and monolith enthusiasts claim microservices are always slower and hard to refactor. This is just a sign that neither group of architecture fans knows how to do the other architecture properly, because its possible to build microservices fast and refactor them quickly just like its possible to build a monolith that is clean and scalable.
BurningFrog 9y ago
I think the "micro" part of the name is really unfortunate for "microservices". "Micro" means "one millionth", so it's easy to get the impression that you should have at least thousands of "microservices". In reality, if each of your microservices don't fill up at least dozens of heavily loaded servers, you're better off with a monolith architecture.
heisenbit 9y ago
There is one area where I feel it makes sense to consider going into a micro-services direction from the beginning: User Accounts. It is clearly re-usable, can increase security and while more effort it is not so costly.
brightball 9y ago
That's actually one of the biggest perks of Elixir IMO. You can a monolith that's basically already separated into microservices.

eropple 9y ago

I do devops. I consult for startups. And while it would make me a lot more money in the short term to fuel their microservice-first, sparkly-architecture aspirations, this is exactly the approach I take when I pour some water on that. Your Big Ugly Monolith will get you where you're trying to go if anything will. You don't need services, you don't need microservices, you don't need some bloggable-as-heck Kubernetes setup with pet sets holding your billionty different datastores--you need a webserver and one data store and maybe a cache, eventually. You grow from there. Where I do push, though (and this often surprises people because "what does a devops person know about code architecture"--the answer is "a lot, both from writing it and seeing it badly written"), is hard demands of app statelessness and an encouragement of business logic internals that are functional in nature, with I/O, wireups, etc. handled at the outer edges of the application. Functional-core-imperative-shell lends itself to decomposition later if you need services (and I say "need services" because the size of the set of companies that "need microservices" is within epsilon of zero)--you replace RPC with a network layer because you built your app with clean, bright-line divisions. Rule of thumb: if you have two "service" talking to the same set of data in the same general-purpose datastore (i.e., not pub-sub, not opposite ends of a job queue), they're the same service.

taurath 9y ago
Couldn't agree more - inheritance chains and heavily stateful instruction environments are the number one blocker to eventually decoupling a monolith. The "enterprise" code style is absolutely what you need to avoid in a startup.
- srtjstjsj 9y ago
  what is "enterprise" code style?
- quickben 9y ago
  If you avoid what you listed in actual software, you'll be left with a mess they will take years and tons of money to fix.
  - beat 9y ago
    Yes, but if you don't avoid it, you might never get off the ground to the point where you have years of time and tons of money in the first place.
    - deleted 9y ago
      [deleted]
    - quickben 9y ago
      I guess it depends on the viewpoint. Yours sounds valid. Mine comes from the occasional fixing people's messes. But I agree with you, some product is better than no product in most cases.
      - beat 9y ago
        I have a lot of career experience dealing with legacy software. I feel that pain intensely. But still... a working product with bugs and flaws is better than a not-working product that is elegantly built. Or half-built.
- JBReefer 9y ago
  Absolutely agreed, where Enterprise === "making a profit"
Animats 9y ago
Rule of thumb: if you have two "service" talking to the same set of data in the same general-purpose datastore (i.e., not pub-sub, not opposite ends of a job queue), they're the same service. Why? The whole point of a general-purpose database is to allow multiple applications to use the same data. Consider an online ordering system for merchandise. There's an service for checking product availability. There's a service for building a shopping cart. There's checkout and payment, the only one that faces the outside world that needs high security. There's customer order tracking. On the back end, there are various services which deal with fulfillment, shipping, accounting, and reordering. There may also be customer-relationship systems which can read order data for marketing purposes. Each of those functions can be worked on independently.
- sbov 9y ago
  A huge point of microservices is to create code that is independent of eachother. Your database backend is tightly coupling what should be completely independent services. Microservices were designed to scale your engineering departments just as much (if not more than) your performance. You are throwing away the major point of why microservices were created in the first place when you do what you're doing: so teams in large organizations can do independent releases. That you cannot see this as a major benefit makes me think microservices are a poor choice for your use case.
  - eternalban 9y ago
    > You are throwing away the major point of why microservices were created in the first place when you do what you're doing: so teams in large organizations can do independent releases. Let's ammend this: so teams in large organizations +{that lack both a coherent architecture and the ability to devise one} can do independent releases +{by adoptiong the no-architecture architecture}.
    - marcuslager 9y ago
      "teams in large organizations" Could be simplified to just "teams. These days from what I can see teams in organizations with no ability to devise a sane architecture usually take the microservice route. Management loves this new buzzword. To them it means problems go away.
tnolet 9y ago
This is exactly what happened / is happening at my former employer. Already 2 years of work, team of 5 engineers, Kubernetes, dozens of microservices. Lot's of time wasted on CI/CD, orchestration, monitoring, refactoring. Live date? Probably somewhere next year. It was sad to watch. 100% resume-based development.
- avip 9y ago
  RDD is 2010. It's called blog-driven development now (BDD)
- ebiester 9y ago
  I agree with the rest of this, but CI isn't hard on a monolith, and it's well worth it. (CD is a tradeoff. If you understand why it's important for you, it might be worth it, but does add complexity.)
Turbots 9y ago
Exactly. Make a monolith first, but do it with clean code and with twelve factor apps in mind. That's why I love using Spring Boot.

staofbur 9y ago

I'd argue it's cheaper scaling out the monolith or introducing isolated functional silos and scaling them out than even bothering migrating everything to microservices. Also you certainly can't port a complex monolith to microservices; you have to start again. We're quite happily able to shift 15,000 requests/sec from over 2000 http endpoints with a monolith and our kit is at ~20% capacity. Need more? Slice up a silo some more. Key aspect when you design the monolith is not building a spaghetti monster. If X doesn't need to talk to Y, put a wall there (package level)

eropple 9y ago
> Also you certainly can't port a complex monolith to microservices Upvoted you, but I disagree with a little. "Microservices" tend to pathological cases, but you 100% can segment a monolithic apps into services. Each module in your application has an interface. Behind that interface, replace it with network calls that fulfill the interface's contracts. (If your monolith doesn't have sections that encapsulate work--well...kinda did it to yourself, but that IME is rare.)
- staofbur 9y ago
  You can, hence my comment about silos. The interface is rarely well defined enough to be able to abstract it over a network boundary from experience. One of the things I see in a lot of monoliths is leaky abstractions and they are really difficult to reign in. We tend to go for throwing related web front and and API endpoints into the same ball of mud silo and back end that directly with the storage and cache services. We scale those silos up and partition across tenants too. I think a couple of the silos are around the 1 million LoC size now as well.
  - eropple 9y ago
    Fair enough. In places where I've had to deal with that, I was in the code review seat ahead of time and was generally able to go "no no no, let's not do that"--but I can see how stuff can decay.

sanderjd 9y ago

I've experienced the opposite: you get traction with a monolith, and when its time to expand and scale, you find yourself with a massive kludge that makes it hard and slow to make progress. Which is not at all to say that you're wrong - a long delay in the capability to release something can definitely be an earlier and more severe death knell than friction when trying to grow. For me personally, I like to see all of: tools that aim to make it easier to modularize from the start, tools that aim to make it easier to modularize an incumbent monolith, and tools that make monoliths work better themselves. I think all of these solve real problems for different teams at different stages of growth and facing different trade offs.

dasil003 9y ago
Sure, but if you build microservices from the start, you die before you get traction because refactoring takes too long while you are finding product-market fit. The right way to do it is to write a modular monolith and maintain a loose plan on how to break it up later. Admittedly this is difficult in SV's youth-obsessed culture where "senior" devs have 5 years experience, and staying at a company long enough to understand the long-term repercussions of architectural choices is seen as a black mark on your resume, but on the bright side languages like Elixir/Erlang help you do the right thing more naturally than more traditional languages.
- sanderjd 9y ago
  The point of my comment is that I both agree with all that and like to see people working on the problem of making it work better to start with microservices if that's what your team thinks is best for your project. It's not a law of the universe that microservices must result in death. It's a tooling problem. I don't think the tools are quite there yet, but they've improved a lot in the past few years. I think that's a good thing and look forward to even more improvement in the future.
- NathanKP 9y ago
  > because refactoring takes too long In my experience refactoring microservices only takes a long time if the microservices are badly done, just like refactoring a monolith only takes a long time if the monolith is a horrible piece of spaghetti code. If refactoring requires modifying multiple microservices then the microservice boundaries and contracts were badly designed at the start. When you have practice drawing boundaries well then refactoring with microservices becomes very fast, as you only have to modify the code of one service and redeploy it. I think too many microservice enthusiasts have a tendency to claim monoliths always turn into spaghetti code, and monolith enthusiasts claim microservices are always slower and hard to refactor. This is just a sign that neither group of architecture fans knows how to do the other architecture properly, because its possible to build microservices fast and refactor them quickly just like its possible to build a monolith that is clean and scalable.

BurningFrog 9y ago

I think the "micro" part of the name is really unfortunate for "microservices". "Micro" means "one millionth", so it's easy to get the impression that you should have at least thousands of "microservices". In reality, if each of your microservices don't fill up at least dozens of heavily loaded servers, you're better off with a monolith architecture.

heisenbit 9y ago

There is one area where I feel it makes sense to consider going into a micro-services direction from the beginning: User Accounts. It is clearly re-usable, can increase security and while more effort it is not so costly.

brightball 9y ago

That's actually one of the biggest perks of Elixir IMO. You can a monolith that's basically already separated into microservices.