4 ms·

After reading about microservices, I feel like it's a great idea if you have a large team and a lot of resources, but that's not really explicitly stated (altho

After reading about microservices, I feel like it's a great idea if you have a large team and a lot of resources, but that's not really explicitly stated (although it's nice this article features drawbacks). I feel like there's a ton of hype but nobody is saying "Don't do this if you don't have a 30-person team!" Separating everything out into little APIs all with their own datastores that all talk to each other sounds great, but I would not to do this on a three person team. Just give me an old fashioned monolithic API, a large database, and then I can spend 80% of my time programming and 20% on maintenance. One app is hard enough to run, why consciously choose to run 10 of them if you don't have the capacity? I don't think microservices are a bad idea at all...I love the architecture. But the hype makes it hard to see that this architecture probably isn't for you unless you have the capacity for it.

mountaineer 11y ago
That is a pretty accurate read on it I think. Fowler's been discussing similar data and findings from their research [1]. [1] http://martinfowler.com/articles/microservice-trade-offs.html http://martinfowler.com/articles/microservice-trade-offs.htm...
johns 11y ago
If you're interested in our experience on starting on microservices from scratch with only 2 people, I gave a talk on it: http://www.infoq.com/presentations/queues-proxy-microservices-automation http://www.infoq.com/presentations/queues-proxy-microservice... I agree they're not for every team, but it definitely allowed us to move, grow and scale faster than other dev environments I've worked in.
- orthecreedence 11y ago
  Thanks, sounds really interesting. I'm bookmarking it for later (having a long day at work). Would love to hear how you achieved this with a smaller team.
- levelist_com 11y ago
  Great talk. This may be a silly question; however, how do you handle authentication between the main app and the services? Im in the middle of building a sizable application but have begun offloading some of the tasks to microservices, for many of the same reasons you gave. I currently use OAuth2 to authenticate to the main API, but dont really want to add additional overhead by having to authenticate to each service as its needed.
  - levelist_com 11y ago
    perhaps JSON Web tokens between main API and microservice where both have a shared secret?
viksit 11y ago
Actually, I'd say the microservices architecture has helped in a complex project that I'm working on right now. Consider the following that need to be done here. - A main library that needs to load up a few gigs of data in memory - A process that communicates with a queue of messages coming in - A process that interfaces with mobile app (port x) - A process that interfaces with a different kind of app (port y) The goal is - every incoming message needs to go through to the main library and back to the app via the queue. Monolith option - main.cc which contains all this, takes a while to start, can't queue up incoming messages till everything starts up and loads in memory, et al. Even using threads and whatnot. Now with microservices, - I can build a service that exposes my big-data-load library through a port. This can be loaded and restarted at will. - Queue is running as a separate process. Messages queue when main lib is down and processed later. - Server A and server b run separately - A bug in one won't crash all the others - I can manage each service independently (run them via supervisor or whatnot) - Scaling it is easy - I can deploy each service behind load balancers, on different machines in the future without ever needing to change anything but the urls in a config file - Monitoring - I have latencies for each service available via haproxy and the like. My 2c.

mountaineer 11y ago

That is a pretty accurate read on it I think. Fowler's been discussing similar data and findings from their research [1]. [1] http://martinfowler.com/articles/microservice-trade-offs.html http://martinfowler.com/articles/microservice-trade-offs.htm...

johns 11y ago

If you're interested in our experience on starting on microservices from scratch with only 2 people, I gave a talk on it: http://www.infoq.com/presentations/queues-proxy-microservices-automation http://www.infoq.com/presentations/queues-proxy-microservice... I agree they're not for every team, but it definitely allowed us to move, grow and scale faster than other dev environments I've worked in.

orthecreedence 11y ago
Thanks, sounds really interesting. I'm bookmarking it for later (having a long day at work). Would love to hear how you achieved this with a smaller team.
levelist_com 11y ago
Great talk. This may be a silly question; however, how do you handle authentication between the main app and the services? Im in the middle of building a sizable application but have begun offloading some of the tasks to microservices, for many of the same reasons you gave. I currently use OAuth2 to authenticate to the main API, but dont really want to add additional overhead by having to authenticate to each service as its needed.
- levelist_com 11y ago
  perhaps JSON Web tokens between main API and microservice where both have a shared secret?

viksit 11y ago

Actually, I'd say the microservices architecture has helped in a complex project that I'm working on right now. Consider the following that need to be done here. - A main library that needs to load up a few gigs of data in memory - A process that communicates with a queue of messages coming in - A process that interfaces with mobile app (port x) - A process that interfaces with a different kind of app (port y) The goal is - every incoming message needs to go through to the main library and back to the app via the queue. Monolith option - main.cc which contains all this, takes a while to start, can't queue up incoming messages till everything starts up and loads in memory, et al. Even using threads and whatnot. Now with microservices, - I can build a service that exposes my big-data-load library through a port. This can be loaded and restarted at will. - Queue is running as a separate process. Messages queue when main lib is down and processed later. - Server A and server b run separately - A bug in one won't crash all the others - I can manage each service independently (run them via supervisor or whatnot) - Scaling it is easy - I can deploy each service behind load balancers, on different machines in the future without ever needing to change anything but the urls in a config file - Monitoring - I have latencies for each service available via haproxy and the like. My 2c.