3 ms·

I agree overuse of almost everything is bad. Currently, I am working with one another seasoned architect, who is very proponent of Microservices and AWS lambda

by gagan2020 9y ago

I agree overuse of almost everything is bad. Currently, I am working with one another seasoned architect, who is very proponent of Microservices and AWS lambda on same lines as mentioned in the article. My discussion with whom has always articulated that let's do traditional portion(user management, permissions, payments, etc) in a traditional way (we are using Django so in that) and whatever tasks we have, lets do them in a microservices way. In a traditional sense, we are implementing a system in Django that will be deployed to AWS lambda via Zappa or SAM. All, the traditional task-queue tasks will be separate microservices (lambda). So, We are implementing fusion and I personally see future in that.

mrweasel 9y ago
>I agree overuse of almost everything is bad. One of our customers are developing a service, which in turn consist of four minor services. They are completely separate services, one provide the core functionality and the rest a supporting tools, but the core can run without them. To me that's a completely reasonable seperation, and it allows multiple teams to work in parallel. One of the "services" above however consist of 10 to 15 smaller services, all of which are communicating via http. The idea as I understand it is that these are small components that can be reused in other projects, if needed. What I don't understand is why these aren't just made into library that can be reused, rather than having them as micro-services. This project is an example of where microservices is done both right and wrong.
- gagan2020 9y ago
  That's why what I am trying is seems more right. Those task-queue tasks, we anyway put to queue and then access it through workers. They usually, do computation/IO intensive work or sending out email or notifications, etc. So, its logical to deploy those as separate to aws lambda kind of service to decrease total service turn around time.
StavrosK 9y ago
For what it's worth, this random internet commenter agrees with you. I especially wouldn't put Lambda on anything mission-critical so early.
- gagan2020 9y ago
  Our architecture is more resilient than what you think. With using Django on lambda, we could also deploy that code to machines. So, we are safe there. Other components will be just functions that could be deployed to Docker with any queue as necessary. So, its calculated risk to leverage the Lambda's benefits of no DevOps, scalability and lower pricing (initially).

mrweasel 9y ago

>I agree overuse of almost everything is bad. One of our customers are developing a service, which in turn consist of four minor services. They are completely separate services, one provide the core functionality and the rest a supporting tools, but the core can run without them. To me that's a completely reasonable seperation, and it allows multiple teams to work in parallel. One of the "services" above however consist of 10 to 15 smaller services, all of which are communicating via http. The idea as I understand it is that these are small components that can be reused in other projects, if needed. What I don't understand is why these aren't just made into library that can be reused, rather than having them as micro-services. This project is an example of where microservices is done both right and wrong.

gagan2020 9y ago
That's why what I am trying is seems more right. Those task-queue tasks, we anyway put to queue and then access it through workers. They usually, do computation/IO intensive work or sending out email or notifications, etc. So, its logical to deploy those as separate to aws lambda kind of service to decrease total service turn around time.

StavrosK 9y ago

For what it's worth, this random internet commenter agrees with you. I especially wouldn't put Lambda on anything mission-critical so early.

gagan2020 9y ago
Our architecture is more resilient than what you think. With using Django on lambda, we could also deploy that code to machines. So, we are safe there. Other components will be just functions that could be deployed to Docker with any queue as necessary. So, its calculated risk to leverage the Lambda's benefits of no DevOps, scalability and lower pricing (initially).