
Building Microservices: Free Ebook from O’Reilly and NGINX - akoenig
http://nginx.com/blog/building-microservices-free-ebook-oreilly-nginx/
======
rianjs
For what it's worth, this is the first three chapters, not the full e-book.
It's in the fine print.

~~~
chaghalibaghali
It would be good if the mods (or submitter) could change the title to reflect
this, I think that a few people might be upvoting before they actually try to
download the book and realise that it's not the full version.

------
amelius
One of the main problems with breaking up a system into many independent
(micro?)systems is that you can't easily combine two or more systems into a
logical transaction. Or, in other words, it becomes increasingly more
difficult to do things atomically to the complete system.

Is this problem covered?

~~~
msluyter
A concrete example we've faced. A certain operation requires writing data to N
flaky services. You successfully write to N-1 of them, but the Nth fails. Now
what do you do?

If these N things were just database writes to the same DB, transactions would
save you, as you could just rollback. Without that, the answer has to be
handled in code -- do you reverse the previous changes (if possible) by
sending delete events, or leave the system in some sort of half-baked state
and rectify things later via some other process? (I'm interested in hearing of
other options...)

~~~
MichaelGG
On my phone so boo cite. Look up Amazon apologetic computing. They also have a
presentation describing their general distributed approach. The main thing is
that you have a bunch of components that you expect to fail. If they don't get
confirmation, they send another message to the next component. Then, there's a
stateless, unambiguous way to determine which message "wins" in case of
conflict. For instance, an order submits two shipping requests for the same
order. They use, for instance, the highest message ID (a GUID) to avoid
duplicate processing.

It's all very neat, though I'm doing a bad job explaining. Search for Amazon
architectural presentations and hopefully you can find it. It may have been on
James Hamilton's blog, maybe.

------
DanielBMarkham
Related: I'm recording myself code up a new microservices hobby application.
I'm doing the whole thing, from selecting a domain name to services
orchestration (much later, of course). The technology stack is F#, Mono, .NET,
ubuntu, AWS, BASH, Apache. We're talking about architecture, design, user
stories, TDD, philosophical differences between traditional OO coding and FP
coding and more.

It's all free.

If you're interested in more microservices stuff, here's the link to the first
one. Fair warning, though: this isn't professionally produced or slick. It's
just some schmuck (me) programming.

[http://vimeo.com/120136738](http://vimeo.com/120136738)

~~~
CWuestefeld
I'm looking forward to this. We're about to embark on a (probably) .Net-based
microservices project, although we'll probably use C# rather than F#.

One thing I've found is that infrastructure stuff abounds for Java-based
projects, doing much work for the message bus, metrics, and logging. But I
find much less available for .Net, particularly for the latter two. Maybe
you'll find some stuff that'll help me.

~~~
DanielBMarkham
Being old and cantankerous, my feeling is that we've tooled up about 400 times
more than we need for microservices and the cloud -- a good programmer
could/should be able to construct and maintain most small-to-medium-sized
projects without a lot of third-party tools.

As an Agile coach, what I find interesting is conveying the _philosophy of the
work_. I am nowhere near being a code ninja any more, but the way you think
about writing the application is the most important part of doing the work.

But who knows? We'll see.

EDIT: To be a little clearer, message bus? You sure you need a full-bore bus?
Make it work with simple files. Take a look at your volume. If you code it
correctly from the start, adding on new stuff is easy. If you start with lots
of frameworks and such, you can get caught up in complexities that are
orthogonal to your mission. One of the beauties of going full functional is
that it makes you focus on whether the dang thing is working or not. In an OO
environment, many times you get lost in the "wiring" of the construction,
making sure you implement the correct interfaces, paying attention to
Demeter's Law and the rest. The end of the week comes and all you've got is
forty thousand lines of code and 7 new dlls in your build.

~~~
CWuestefeld
I suspect that getting our developers to embrace not only this new
architecture, but also the new paradigm of functional programming is a bridge
too far.

Regarding the "full-bore bus" question, I see it being that way for two
reasons:

1\. Distributed architecture. I _think_ that the way to foster simple
deployment of updates services is making them distinct deployable units, and
the most obvious way to do that is to put each on its own cluster of servers -
although in most cases this is way overkill in scale. And I think that if the
services are on different machines, that pushes away from a really simple
approach like your idea of files, toward something more sophisticated. On the
other hand, perhaps there's a good way to let the services be co-resident by
using docker, which I don't yet know very well.

2\. Capacity. Although most of the system isn't too heavy, I've got a couple
services that are used ubiquitously, and probably do need serious high-
performance. First, the legacy system at peak is handling about 25 product
pricing queries per second (our pricing is customer specific and based on
near-time availability from suppliers). Second, we have not just localization
of text, but customer-specific text, so every bit of text everywhere needs to
come from that customization engine, although I suspect that this may wind up
being addressed more as caches at the UI layer.

~~~
DanielBMarkham
What I should do, once I finish up the basic functionality (which could take a
month or two working part-time), is copy this over to an empty box(es) and
pound the hell out of it; see how much volume it can handle.

My gut tells me the Ubuntu O/S can take quite a bruising. It'd be interesting
to find out. Also there'd be some good lessons in there :)

Remember, the goal of microservices is to completely decouple processing so
that you can completely configure the cloud graph any way you'd like. A
microservices OO construct by definition would have to do a lot of honking
around with the CPU before we got to the "work" part.

Of course what works for one team wouldn't work for another. Fun stuff to play
around with, though.

~~~
CWuestefeld
_A microservices OO construct by definition would have to do a lot of honking
around with the CPU before we got to the "work" part._

No doubt. While I'm enamored with OO myself (having begun my professional life
in the late 80s when it was the thing), I think that anything OO would be
_internal_ to a given service, and the interfaces between services would be
much more conventional, most likely a simply REST approach.

------
tomchristie
Note that the _full_ copy is now available to purchase in both ebook and
hardcopy:
[http://shop.oreilly.com/product/0636920033158.do](http://shop.oreilly.com/product/0636920033158.do)

(No side-interest here, just found it confusing that the page mentioned
"hardcopy expected to be published in May")

~~~
justincormack
Indeed, my copy just arrived.

------
lukasm
Direct link [http://nginx.com/wp-
content/uploads/2015/01/Building_Microse...](http://nginx.com/wp-
content/uploads/2015/01/Building_Microservices_Nginx.pdf)

~~~
josteink
I'm pretty sure the idea behind publishing this free book was gathering leads
and potential customer-data for future marketing.

You know, if it's free, you're the product and all that yadda yadda.

By posting the direct DL link here, you are discouraging similar free offers
in the future. If I were you and I appreciated free offers, I would consider
editing my post.

~~~
hackerboos
Unlikely to garner much favour declaring 'Free Ebook from O’Reilly and NGINX'
and giving away only 3 chapters...

------
josteink
Note: Requires registration and is PDF only. Not mobi or epub.

Still free though. I snatched a copy.

~~~
valevk
But not all chapters?!

~~~
gregd
You would be correct.

------
fermigier
Bait and switch. [http://en.wikipedia.org/wiki/Bait-and-
switch](http://en.wikipedia.org/wiki/Bait-and-switch)

------
definiv
So inbound.

