4 ms·

Microservices advice for web and mobile backends?

4 points by malloryerik 10y ago

I'm thinking as a lone dev, currently using Clojure/Script. But microservices, probably on AWS, have great appeal. Pitfalls? Book recommendations? War stories?

CyberFonic 10y ago
I'm a lone dev too. I've been using microservices with Google App Engine. By using some templates and some conventions I find it easy to create modular back-ends. Basically I design using fairly detailed use cases and data model. Then each scenario in the use cases is implemented as a microservice. This approach makes single responsibility design rather easy. As business requirements evolve, the updated use cases lead to changes and additions. All rather neat and easy.
- malloryerik 10y ago
  Interesting, and nice to hear that at least for one lone dev it isn't overwhelming. Do you find that Google App Engine has advantages over AWS in this case?
PaulHoule 10y ago
The real advantage of microservices is being able to scale different parts independently. The way we do it in Java is to logically partition services, and it turns out that some of them are so small they fit in the same address space as the server process and it just not worth breaking them out, particularly when one of our goals is to be the service that is done loading before your finger has even hit the stopwatch to start timing the 15 second load of the other guys. (Who are doomed because they use shiny front-end technology) There is one "service" that runs out of process on the same physical server, and then two "services" that run on other machines, one of them is an authentication server hosted at Stormpath, the other one is a DynamoDB. We rebuild the primary and supporting databases each day on a second cloud server, connect it to Stormpath and Dynamo, then nuke the old server once it passes int tests. You need to have a strategy for ser/deser that requires close to zero effort when you need to change things. Frankly I think it is stupid stupid stupid to replicate code any more than you need to. I worked at a place where "on principle" they wanted to have the code be decoupled so every team would hand-code ser/deser logic which meant that it took two weeks or more to make a small change that would ripple through the system and introduce more bugs. Lotsa consequences of that such as "have a schema", "generate code" and "don't module module A in Rust, and module B in Go, and module C in Shiny3" or you are doomed. It feels so good to have competitors that are doomed.
- malloryerik 10y ago
  Hahah, thanks. Flexibility (w/ scaling and structure), fine-tuned performance, these are totally the things that draw me in. Taking note of what you've written.
- deleted 10y ago
  [deleted]
emidln 10y ago
If you follow typical Clojure usage recommendations (avoid global state), you can often get started with a fat prototype that is trivial to slice up as your ideas become more clear. As a lone developer, I would recommend not making your nREPL and generic dev experience harder than it has to be.
- malloryerik 10y ago
  I guess you're saying, stay monolithic, but with an eye to modularity later when it makes more sense. Might be wise advice.
  - emidln 10y ago
    Sorta. I'd advocate for separating the deployment story (which might be simple or might be something complicated like microservices) from the development story (needing to add :checkouts to your lein project and/or manage multiple nREPLs is a real headache). The way most libraries get written, you end up with a namespace or two that matters. If you have three conceptually independent services, put them in separate namespaces like foo.bar, foo.baz, and foo.quux. If you later find the project is too large to manage, you can just move directories containing namespaces. Until then, you can use facilities in leiningen or boot to spit out multiple jars, or a single jar that can run multiple services (perhaps based on flags you invoke or a class you load). Further, until you need to have separate services, I'd probably just load all of them in the same process. Through all of this, your development story is much nicer, and there are fewer git repos to reason about. If you really do think you'll eventually need different git repos for your services, you might consider prefixing commit messages based on the logical service they relate to, so that you can migrate the history easily later on in an organized and linear way.

4 points by malloryerik 10y ago

I'm thinking as a lone dev, currently using Clojure/Script. But microservices, probably on AWS, have great appeal. Pitfalls? Book recommendations? War stories?

CyberFonic 10y ago

I'm a lone dev too. I've been using microservices with Google App Engine. By using some templates and some conventions I find it easy to create modular back-ends. Basically I design using fairly detailed use cases and data model. Then each scenario in the use cases is implemented as a microservice. This approach makes single responsibility design rather easy. As business requirements evolve, the updated use cases lead to changes and additions. All rather neat and easy.

malloryerik 10y ago
Interesting, and nice to hear that at least for one lone dev it isn't overwhelming. Do you find that Google App Engine has advantages over AWS in this case?

PaulHoule 10y ago

The real advantage of microservices is being able to scale different parts independently. The way we do it in Java is to logically partition services, and it turns out that some of them are so small they fit in the same address space as the server process and it just not worth breaking them out, particularly when one of our goals is to be the service that is done loading before your finger has even hit the stopwatch to start timing the 15 second load of the other guys. (Who are doomed because they use shiny front-end technology) There is one "service" that runs out of process on the same physical server, and then two "services" that run on other machines, one of them is an authentication server hosted at Stormpath, the other one is a DynamoDB. We rebuild the primary and supporting databases each day on a second cloud server, connect it to Stormpath and Dynamo, then nuke the old server once it passes int tests. You need to have a strategy for ser/deser that requires close to zero effort when you need to change things. Frankly I think it is stupid stupid stupid to replicate code any more than you need to. I worked at a place where "on principle" they wanted to have the code be decoupled so every team would hand-code ser/deser logic which meant that it took two weeks or more to make a small change that would ripple through the system and introduce more bugs. Lotsa consequences of that such as "have a schema", "generate code" and "don't module module A in Rust, and module B in Go, and module C in Shiny3" or you are doomed. It feels so good to have competitors that are doomed.

malloryerik 10y ago
Hahah, thanks. Flexibility (w/ scaling and structure), fine-tuned performance, these are totally the things that draw me in. Taking note of what you've written.
deleted 10y ago
[deleted]

emidln 10y ago

If you follow typical Clojure usage recommendations (avoid global state), you can often get started with a fat prototype that is trivial to slice up as your ideas become more clear. As a lone developer, I would recommend not making your nREPL and generic dev experience harder than it has to be.

malloryerik 10y ago
I guess you're saying, stay monolithic, but with an eye to modularity later when it makes more sense. Might be wise advice.
- emidln 10y ago
  Sorta. I'd advocate for separating the deployment story (which might be simple or might be something complicated like microservices) from the development story (needing to add :checkouts to your lein project and/or manage multiple nREPLs is a real headache). The way most libraries get written, you end up with a namespace or two that matters. If you have three conceptually independent services, put them in separate namespaces like foo.bar, foo.baz, and foo.quux. If you later find the project is too large to manage, you can just move directories containing namespaces. Until then, you can use facilities in leiningen or boot to spit out multiple jars, or a single jar that can run multiple services (perhaps based on flags you invoke or a class you load). Further, until you need to have separate services, I'd probably just load all of them in the same process. Through all of this, your development story is much nicer, and there are fewer git repos to reason about. If you really do think you'll eventually need different git repos for your services, you might consider prefixing commit messages based on the logical service they relate to, so that you can migrate the history easily later on in an organized and linear way.