5 ms·

I think that with the rise in popularity of functions as a service (lambda, gcf, azure), we are heading more and more towards nanoservices. Small services are

I think that with the rise in popularity of functions as a service (lambda, gcf, azure), we are heading more and more towards nanoservices. Small services are easier to develop with several teams, in my opinion. Each team knows what to input, and output. They can do whatever in between as long as these two contracts are respected. But the overlooking of all these moving pieces changing at different paces is tough. And the smaller the services get, the harder it will become. Not a size fits all, clearly!

deleted 8y ago
[deleted]
xj9 8y ago
> Reusable Reproducible Composable Software https://github.com/fractalide/fractalide/ https://github.com/fractalide/fractalide/
madamelic 8y ago
>I think that with the rise in popularity of functions as a service (lambda, gcf, azure), we are heading more and more towards nanoservices. There are some pretty big asterisks next to running "nanoservices". Mostly how expensive they actually are to run at large scale and the weird caveats that can happen due to them not always being up. And I wouldn't advocate for "always-up nanoservices". The basic answer to both "nanoservices" and microservices is do what you think is right but don't go too far. There are good reasons to make a nanoservice and good reasons not to, same with microservices.