5 ms·

One of the big ones: For a small startup, granular microservices are often very premature, and will slow you down rather than speed you up.

by bpicolo 10y ago

swsieber 10y ago
This should get more emphasis. Microservices do require more overhead. Additionally, they require you to be familiar enough with you business logic to know where you boundaries lie - changing abstraction boundaries is much harder with microservices than with a monolith. I think that while they are great for scaling, they are a lot harder to use to successfully get off the ground (though I'm betting that there are places that have successfully done so)
- ben_jones 10y ago
  You also have to know how to "do" microservices. Whether it's incorporating message queues like RabbitMQ, protocols like gRPC, etc., it's very hard to get right the first time by winging it without previous experience. Redesigning microservices after is a PITA.
  - mcginleyr1 10y ago
    100% agree. Your path is based on your teams experience and capabilities, not trends.
vojant 10y ago
That really depends on the startup, and sometimes starting with micro-services helps with hiring - In our case thanks to starting with micro-services we hired developers knowing different programming languages and they can work together on the project by exposing end-points/consumers. Of course I wouldn't recommend doing that for everyone but in our use-case we had to start with distributed system anyway due to quite complicated domain.
- bpicolo 10y ago
  Even with microservices, I wouldn't recommend changing languages between the bunch without a very good reason. You -will- build up infrastructure and packages that are language and stack specific: monitoring, logging, helpers, etc. that take a lot of time to reinvent. If you're switching languages/stacks just for funsies, you're going to make services more difficult to maintain over time (and just generally slow down development) As far as languages go, pick one. When you hit a problem that absolutely cannot be reasonably solved under the specifications you care about, consider a different one for that service. Apart from that, there's little value, and lots of overhead, in moving. Getting to write that one Haskell microservice is sure a romantic idea, until that employee leaves and nobody knows Haskell anymore, and suddenly the service is dysfunctional because dependencies have changed. (For non-mission-critical funsies, sure, use whatever, though non-mission-critical apps tend to have a knack for becoming very important for workflows, hah)
  - vojant 10y ago
    That's a good comment and of course there is a list of approved stacks (not random list of languages) and we try to think about future. Hiring people wasn't our only reason and we had technical reasons to go with micro-services and multiple languages, but it was nice perk.
romanovcode 10y ago
Not to mention longer development time.
gotchange 10y ago
I totally agree that one should start with a monolith and when he feels confident that all bases were covered in the codebase, he can begin to worry about breaking up the monolith into microservices. This growth journey makes more sense than starting out the door working on your microservices before business logic as this is like putting the cart before the horse.
- ProblemFactory 10y ago
  Even then, I have a feeling that people jump too quickly from a "messy monolith" to microservices. Instead, people should start splitting up the monolith into sensible modules and libraries. Instead of a "user accounts microservice", start with a "user accounts library" with a well-documented API that stays in the main codebase and is deployed as part of the rest of the app.
bsder 10y ago
Sometimes. Having nice hard boundaries that you can't just penetrate can aid and abet you in debugging. It also probably helps you with respect to managing security. As in most things, good judgement is key.
jlebrech 10y ago
write the MVP in Rails or Django and scale things that need scaling later. you can scale the base app by giving it more hardware, but when you have to batch process lots of stuff then think of services (most of the time you can just split that to another server).
- bpicolo 10y ago
  > most of the time you can just split that to another server Yeah. A starting monolith, some cronnish way to run batches, and some way to listen to queues goes a long way.
- enraged_camel 10y ago
  >>write the MVP in Rails or Django and scale things that need scaling later. There's a new alternative: write it in Elixir/Phoenix. You'll get the same productivity benefits with none of the performance trade-offs. Elixir apps are reliable and concurrent by default, and the Phoenix framework has none of the "magic" that Rails has, making it very developer-friendly. :) This isn't to say that Elixir/Phoenix are perfect. The ecosystem isn't as mature as that of Ruby/Rails, so finding answers to questions can take a bit longer. But that is changing quite quickly.
  - bpicolo 10y ago
    This is one where opinions are widespread and mostly the choice doesn't matter so much, hah. Fwiw, I've been pretty intrigued by the idea of dotnet on linux lately (integrates with postgresql and everything). dotnet isn't exactly hip, but C# is fast and it's mature (and has some pretty dope functionalish features. You can run F# if you want to, too). Planning to try how well this works in practice soon. There are things I like a lot about Elixir, but also plenty that I'm not quite a fan of.
  - draw_down 10y ago
    What's really important in this context is building something quickly. That's why GP mentioned Rails and Django; they come with many things either built in or built by community, so you can focus on building your first version quickly. To the extent that is true with other tools or frameworks, sure, go for it.
curun1r 10y ago
The "how" really matters when deciding between microservices and a monolith. For instance, pumping out a bunch of Lambda/API Gateway web endpoints that back a static site served out of S3 or some other static hosting service would qualify as a microservices approach and yet is a huge time saver during the experimentation phase. No worrying about ops, monitoring or anything else off the list of overhead issues that isn't building your product. But if Microservices means configuring servers/clusters, service discovery and such, it actually adds to your overhead list and you're right that it will slow you down. To my mind, services like Lambda are perfect for startups. In addition to scaling down, costing nothing when unused and allowing rapid iteration with zero operational concerns, they largely scale up and, in the unlikely event that the startup is wildly successful, they'll handle almost any load you throw at them until you've had time to re-engineer the backend to be more economical for the increased load.
- davidlee1435 10y ago
  I'm currently in the experimentation phase and I find FaaS to be a blessing. I'm currently using Google Cloud Functions since I hooked the initial app (which has a real-time messaging component) to Firebase and it's saved so much time wrt overhead.
- tedmiston 10y ago
  Serverless microservices, some call these nanoservices / functions as a service / microservices as a service, like AWS Lambda are definitely a distinct lighter weight category because you're not managing apps or servers to support them.
tedmiston 10y ago
I've experienced this one firsthand as well. Microservices sound ideal at first because it's easy to not see that the brunt of the effort is not writing the first version but monitoring, maintaining, and handling when some go down. By using microservices one introduces additional edge cases that don't exist in a "monolith". Quotations around monolith because I believe startups use it with some exaggeration. For example, a Django project of ~10k LoC might be composed of 15 separate Django apps behind one API and I don't see this as monolithic.

One of the big ones: For a small startup, granular microservices are often very premature, and will slow you down rather than speed you up.

by bpicolo 10y ago

One of the big ones: For a small startup, granular microservices are often very premature, and will slow you down rather than speed you up.

swsieber 10y ago

This should get more emphasis. Microservices do require more overhead. Additionally, they require you to be familiar enough with you business logic to know where you boundaries lie - changing abstraction boundaries is much harder with microservices than with a monolith. I think that while they are great for scaling, they are a lot harder to use to successfully get off the ground (though I'm betting that there are places that have successfully done so)

ben_jones 10y ago
You also have to know how to "do" microservices. Whether it's incorporating message queues like RabbitMQ, protocols like gRPC, etc., it's very hard to get right the first time by winging it without previous experience. Redesigning microservices after is a PITA.
- mcginleyr1 10y ago
  100% agree. Your path is based on your teams experience and capabilities, not trends.

vojant 10y ago

That really depends on the startup, and sometimes starting with micro-services helps with hiring - In our case thanks to starting with micro-services we hired developers knowing different programming languages and they can work together on the project by exposing end-points/consumers. Of course I wouldn't recommend doing that for everyone but in our use-case we had to start with distributed system anyway due to quite complicated domain.

bpicolo 10y ago
Even with microservices, I wouldn't recommend changing languages between the bunch without a very good reason. You -will- build up infrastructure and packages that are language and stack specific: monitoring, logging, helpers, etc. that take a lot of time to reinvent. If you're switching languages/stacks just for funsies, you're going to make services more difficult to maintain over time (and just generally slow down development) As far as languages go, pick one. When you hit a problem that absolutely cannot be reasonably solved under the specifications you care about, consider a different one for that service. Apart from that, there's little value, and lots of overhead, in moving. Getting to write that one Haskell microservice is sure a romantic idea, until that employee leaves and nobody knows Haskell anymore, and suddenly the service is dysfunctional because dependencies have changed. (For non-mission-critical funsies, sure, use whatever, though non-mission-critical apps tend to have a knack for becoming very important for workflows, hah)
- vojant 10y ago
  That's a good comment and of course there is a list of approved stacks (not random list of languages) and we try to think about future. Hiring people wasn't our only reason and we had technical reasons to go with micro-services and multiple languages, but it was nice perk.

romanovcode 10y ago

Not to mention longer development time.

gotchange 10y ago

I totally agree that one should start with a monolith and when he feels confident that all bases were covered in the codebase, he can begin to worry about breaking up the monolith into microservices. This growth journey makes more sense than starting out the door working on your microservices before business logic as this is like putting the cart before the horse.

ProblemFactory 10y ago
Even then, I have a feeling that people jump too quickly from a "messy monolith" to microservices. Instead, people should start splitting up the monolith into sensible modules and libraries. Instead of a "user accounts microservice", start with a "user accounts library" with a well-documented API that stays in the main codebase and is deployed as part of the rest of the app.

bsder 10y ago

Sometimes. Having nice hard boundaries that you can't just penetrate can aid and abet you in debugging. It also probably helps you with respect to managing security. As in most things, good judgement is key.

jlebrech 10y ago

write the MVP in Rails or Django and scale things that need scaling later. you can scale the base app by giving it more hardware, but when you have to batch process lots of stuff then think of services (most of the time you can just split that to another server).

bpicolo 10y ago
> most of the time you can just split that to another server Yeah. A starting monolith, some cronnish way to run batches, and some way to listen to queues goes a long way.
enraged_camel 10y ago
>>write the MVP in Rails or Django and scale things that need scaling later. There's a new alternative: write it in Elixir/Phoenix. You'll get the same productivity benefits with none of the performance trade-offs. Elixir apps are reliable and concurrent by default, and the Phoenix framework has none of the "magic" that Rails has, making it very developer-friendly. :) This isn't to say that Elixir/Phoenix are perfect. The ecosystem isn't as mature as that of Ruby/Rails, so finding answers to questions can take a bit longer. But that is changing quite quickly.
- bpicolo 10y ago
  This is one where opinions are widespread and mostly the choice doesn't matter so much, hah. Fwiw, I've been pretty intrigued by the idea of dotnet on linux lately (integrates with postgresql and everything). dotnet isn't exactly hip, but C# is fast and it's mature (and has some pretty dope functionalish features. You can run F# if you want to, too). Planning to try how well this works in practice soon. There are things I like a lot about Elixir, but also plenty that I'm not quite a fan of.
- draw_down 10y ago
  What's really important in this context is building something quickly. That's why GP mentioned Rails and Django; they come with many things either built in or built by community, so you can focus on building your first version quickly. To the extent that is true with other tools or frameworks, sure, go for it.

curun1r 10y ago

The "how" really matters when deciding between microservices and a monolith. For instance, pumping out a bunch of Lambda/API Gateway web endpoints that back a static site served out of S3 or some other static hosting service would qualify as a microservices approach and yet is a huge time saver during the experimentation phase. No worrying about ops, monitoring or anything else off the list of overhead issues that isn't building your product. But if Microservices means configuring servers/clusters, service discovery and such, it actually adds to your overhead list and you're right that it will slow you down. To my mind, services like Lambda are perfect for startups. In addition to scaling down, costing nothing when unused and allowing rapid iteration with zero operational concerns, they largely scale up and, in the unlikely event that the startup is wildly successful, they'll handle almost any load you throw at them until you've had time to re-engineer the backend to be more economical for the increased load.

davidlee1435 10y ago
I'm currently in the experimentation phase and I find FaaS to be a blessing. I'm currently using Google Cloud Functions since I hooked the initial app (which has a real-time messaging component) to Firebase and it's saved so much time wrt overhead.
tedmiston 10y ago
Serverless microservices, some call these nanoservices / functions as a service / microservices as a service, like AWS Lambda are definitely a distinct lighter weight category because you're not managing apps or servers to support them.

tedmiston 10y ago

I've experienced this one firsthand as well. Microservices sound ideal at first because it's easy to not see that the brunt of the effort is not writing the first version but monitoring, maintaining, and handling when some go down. By using microservices one introduces additional edge cases that don't exist in a "monolith". Quotations around monolith because I believe startups use it with some exaggeration. For example, a Django project of ~10k LoC might be composed of 15 separate Django apps behind one API and I don't see this as monolithic.