
Microservices advice for web and mobile backends? - malloryerik
I&#x27;m thinking as a lone dev, currently using Clojure&#x2F;Script. But microservices, probably on AWS, have great appeal.<p>Pitfalls? Book recommendations? War stories?
======
PaulHoule
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
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.

------
CyberFonic
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
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?

------
emidln
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
I guess you're saying, stay monolithic, but with an eye to modularity later
when it makes more sense. Might be wise advice.

~~~
emidln
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.

