Coffee As A Service Architecture

Intro

To­day I was in a meet­ing with re­cruiters (yes, re­al­ly) be­cause they want to be bet­ter at tech­ni­cal re­cruit­ing and they had the idea that talk­ing to me would help them (o­h, sweet sum­mer chil­dren).

A nice time was had by all (I hope) and at one point I was asked about what ar­chi­tec­ture was, and more specif­i­cal­ly, about the dif­fer­ence be­tween mi­croser­vices and a mono­lith.

Which I tried to ex­plain us­ing what I had at hand: cof­fee cup­s, sug­ar dis­penser­s, a spoon and so on. It did­n't quite work out but I kept think­ing about it on my way home and ... let's try again.

What is Architecture?

Ar­chi­tec­ture, when it comes to soft­ware, can be de­fined in many ways, but one way I like is to say that ar­chi­tec­ture in­volves:

• What the com­po­nents of your sys­tem are
• How they are done
• How they talk to each oth­er

There is a lot more, but you start with that, and that is more or less enough to ex­plain mono­liths and mi­croser­vices.

The Coffee Service

One thing of mas­sive im­por­tance about sys­tems is that they are meant to do some­thing. They ex­ist for a pur­pose. So, let's sup­pose the pur­pose of our sys­tem is to make cof­fee and put it in a cup.

We can call the cup the "cof­fee clien­t" and what­ev­er we use to make the cof­fee is the "cof­fee sys­tem" or "cof­fee ser­vice"

So, as­sum­ing you have a can full of cofee beans and a cup, how do you make cof­fee?

The Coffee Monolith

This is my very own cof­fee ma­chine. Not on­ly is it mono­lith-shaped, it's func­tion­al­ly mono­lith­ic (it's al­so large enough to de­serve its own table, as you can see).

It has two buck­ets on top. On one you put wa­ter, in the oth­er you put cof­fee bean­s. Then, you put a cup un­der the spig­ot and press a but­ton or two.

It will:

• Grind the beans
• Put the ground cof­fee in the right place and ap­ply the "right" pres­sure
• Heat the wa­ter to the "right" tem­per­a­ture
• Run wa­ter through the cof­fee grounds
• Pour the cof­fee in­to the cup
• Dis­card the grounds in­to a hid­den de­posit

Sounds awe­some, right? It is!

It takes all of 30 sec­onds to go from cof­fee beans to a nice cup of cof­fee! It tastes good!

And it's im­por­tant to keep that in mind. IT IS GREAT.

Mono­lith­s, when they done cor­rect­ly and you are not ex­pect­ing any­thing out of their op­er­at­ing pa­ram­e­ter­s, are awe­some.

The prob­lem with mono­liths is not that they can't be done right, it's that it's hard to do them right, and that even when you do get it right, in our in­dus­try the mean­ing of "right" is not fixed.

So, be­cause the whole point is to ride this anal­o­gy in­to the ground, let's con­sid­er all the things about this awe­some ma­chine.

Flexibility

It grounds the cof­fee. What hap­pens if you want it ground fin­er? Or coarser?

It turns out that if you have the right tool you can ad­just the mil­l's out­put (it's not in the man­u­al).

In a mi­croser­vice-based cof­fe­mak­er I would re­place the grinder.

How about wa­ter tem­per­a­ture?

It has three set­tings. Want any­thing else? No luck.

In a mi­croser­vice-based cof­fee ser­vice I would just use an ad­justable ket­tle.

How about the amount of cof­fee per cup?

It has three set­tings. Want any­thing else? No luck.

In mi­croser­vice-­cofee I would just trans­mit as much cof­fee as I want­ed.

How about chang­ing the bean va­ri­ety be­tween cup­s?

The bean hop­per takes half a pound of bean­s. It's not easy to get them out. So, no.

In mi­croser­vice-­cof­fee heav­en I could have mul­ti­ple hop­pers pro­vid­ing beans of all va­ri­eties and just con­nect to the one I want to­day!

Cup size?

It does two sizes (but you re­pro­gram those sizes)

In mi­croser­vice-­cofee I would just pour as much wa­ter as I liked.

A mono­lith has the flex­i­bil­i­ty its de­sign­ers thought of adding, no more, no less. And chang­ing it is ... not triv­ial.

I could use a vac­u­um clean­er to re­move the beans from the hop­per and change va­ri­eties. I would con­sid­er that a hack. I have al­so done it. I re­gret noth­ing.

Unused Features

It has a thing that lets you set­up a cred­it sys­tem for cof­fee cups I will nev­er use. A milk foamer I use once a week. Why? Be­cause "we may need this and it's hard to add it lat­er, so let's just do it from the be­gin­ning" ground cof­fee.

Some­times yes, it's use­ful (ca­puc­ci­no!) but some­times it's just some­thing I paid for and will nev­er use (cof­fee cred­it­s!)

In a mi­croser­vice ar­chi­tec­ture I would just get a new milk foamer, use both for a while and then keep us­ing the one I like.

Hard to Improve

How do I add a bet­ter foam­ing thingie?

By buy­ing one and putting it in the ta­ble.

How do I add a more flex­i­ble cof­fee grinder?

I can't be­cause this ma­chine is in­com­pat­i­ble with pre-­ground cof­fee. There is a new­er, more ex­pen­sive mod­el that can take that but this one? You need to throw it away.

Mod­i­fy­ing a mono­lith­ic sys­tem is dif­fi­cult be­cause the pieces are tight­ly cou­pled. I can't use a sep­a­rate grinder be­cause the sys­tem re­quires the cof­fee grounds to ar­rive via a spe­cif­ic in­ter­nal duct at a spe­cif­ic point in the cof­fee-­mak­ing cy­cle, there is just no way to in­sert my grind-o-­mat­ic-3000 in there with­out a saw and duct tape.

In a mod­u­lar sys­tem I would un­plug the grinder and in­sert a com­pat­i­ble-but-d­if­fer­ent grinder, in a mi­croser­vice ar­chi­tec­ture I would just use what­ev­er grinder and put the cof­fee grounds in a mes­sage and have the next piece in the sys­tem pick it from there.

Expensive

This cof­fee ma­chine is ex­pen­sive. It's much more ex­pen­sive than buy­ing a grinder, a cof­fee ma­chine a ket­tle and a milk foamer.

What it pro­vides in ex­change for the ex­tra mon­ey (and re­duced flex­i­bil­i­ty and so on) is per­for­mance. I don't boil wa­ter, I don't grind cof­fee, I don't pour, I just press a damned but­ton and en­joy cof­fee.

Outsourcing

You can buy pre-­ground cof­fee and ef­fec­tive­ly out­source that part of the process to some ex­ter­nal provider.

I can't! I am doomed to ground my own cof­fee for­ev­er.

Maintenance

I have a lu­bri­ca­tion sched­ule, or else my ex­pen­sive ma­chine will break.

I have to dis­in­fect the cof­fee ground bin or else it will have mag­got­s.

I have to emp­ty the wa­ter waste tray be­fore it over­flows.

I have to have a thing to dump the bits of dirty wa­ter it us­es to clean it­self when it turns on/of­f.

I have to buy spe­cial acid to pe­ri­od­i­cal­ly re­move scale from its in­nards or it will stop work­ing. That costs ac­tu­al mon­ey and takes half an hour.

I need to cleanup cof­fee crud from all the in­ter­nal springs, levers and thin­gies ev­ery cou­ple of week­s.

Now, you, read­ers with nor­mal cof­fee mak­ing things? How is your cof­fee ma­chine main­te­nance rou­tine? What, you don't have one? Thought so.

Conclusion

So, that's why nowa­days most peo­ple pre­fer to pay the per­for­mance penal­ty of a mi­croser­vice ar­chi­tec­ture in­stead of us­ing an awe­some mono­lith.

This is not ex­haus­tive, there is still sep­a­ra­tion of con­cern­s, en­cap­su­la­tion, rigid­i­ty of con­tracts and a lot more, but it should be con­vinc­ing enough with­out be­ing dog­mat­ic :-)

I have, in­ter­mi­tent­ly, for the past few month­s, been writ­ing a book. You can see it here and I am fair­ly hap­py with how it's go­ing.

I am not so hap­py with the tool­ing.

When I start­ed writ­ing it, I did­n't want to write a tool, I just want­ed to write a book. So, I looked for "things to make a book out of mark­down" and found a few, in­clud­ing md­Book and git­book and tried them both, then de­cid­ed to go with git­book be­cause it seemed more de­vel­ope­d.

But, you know how this work­s. Things start­ed drift­ing.

One ini­tial ob­sta­cle was that I want­ed the code in the book to come from the ac­tu­al work­ing code, not be a copy. I al­so want­ed to "ex­e­cute" the chap­ters and make the out­put of the chap­ter's code part of the chap­ter itelf.

I found a nice tool for this called pyLit­er­ate which... I end­ed up ex­tend­ing to al­low for things such as "in­clude this piece of code from that file but do not ex­e­cute it" and what­ev­er, and in­te­grat­ing it in­to git­book in­volved ... a lot of Make­files.

And then wen the out­put ap­peared in git­Book ... I re­al­ly did­n't like how syn­tax high­light­ing worked. I want­ed pret­ti­er and specif­i­cal­ly to be able to high­light some lines, and to have line num­bers match­ing the file con­tents and not start­ing from 1 ... and I end­ed up writ­ing a Git­book Ex­ten­sion

And I added sup­port for graphviz in pyLit­er­ate be­cause I want­ed SVG di­a­grams as part of the code and not as sep­a­rate things.

And I wrote and I wrote.

And then life hap­pened and I stopped writ­ing. And when­ev­er I want­ed to start writ­ing again in a new set­up some­thing broke.

• Maybe the git­book ver­sion in­stalled or its de­pen­den­cies had a se­cu­ri­ty is­sue and need­ed up­dat­ing.
• Maybe the up­dat­ed git­book broke my plug­in
• Maybe things just were "of­f" and I had to track it down*

And a cou­ple of days ago, I just got an­gry. And what the hell this is just a lame stat­ic file gen­er­a­tor and I know those suck­er­s.

So, I de­cid­ed to see how much work would it be to reim­ple­men­t, some­what dumb­ly, git­book.

Well, re­al­ly, it's about a day's work (for a low qual­i­ty ver­sion)

• Sup­ports all I want
• Sup­ports plug­ins
• Sup­ports ar­bi­trary mark­down pre­pro­cess­ing
• Sup­ports ar­bi­trary mark­down ren­der­er hack­ing
• Us­es mis­tune for mark­down, which kicks ass
• Us­es jin­ja2 for tem­plates and they are 10x sim­pler than in git­book AND THE OUT­PUT LOOK THE SAME. I mean, there is one tem­plate

I logged the work, which was at a very re­laxed pace over a cou­ple of days here and pub­lished not-git­book in git­lab

I could mi­grate my book to the new toolchain in a day more work, most­ly in­volv­ing im­ple­ment­ing things git­book does­n't do and I am hack­ing via Make­files.

It's sure­ly not ready for any re­al us­age but feel free to poke around and con­tact me if you want to use it.

A long time ago I "wrote a web browser". Those there are some very heavy quotes. You may imag­ine me do­ing air quotes while I write it, may­be?

That's be­cause I did­n't re­al­ly, what I ac­tu­al­ly did was write UI around Qt's we­bkit-based wid­get. It was a fun pro­jec­t, spe­cial­ly be­cause I did it with the ab­surd con­straint of stay­ing be­low 128 lines of code.

And then I did not touch if for six years. But yes­ter­day I did.

commit 0b29b060ab9962a32e671551b0f035764cbeffaa
Author: Roberto Alsina <ralsina@medallia.com>
Date:   Tue Oct 30 12:32:43 2018 -0300

    Initial PySide2 port

commit 831c30d2c7e6b6b2a0a4d5d362ee7bc36493b975
Author: roberto.alsina@gmail.com <roberto.alsina@gmail.com@1bbba601-83ea-880f-26a2-52609c2bd284>
Date:   Fri Jun 1 15:24:46 2012 +0000

    nicer, smaller margins

Six years is a long time. So, nowa­days:

• I pre­fer my code to be for­mat­ted bet­ter
• Python 3 is the thing
• Py­Side is of­fi­cial, so I would rec­om­mend us­ing it in­stead of PyQt
• Qt is now on ver­sion 5 in­stead of 4

So, with those new con­straints in mind, I port­ed De­Vi­cen­zo to the lat­est ev­ery­thing, for­mat­ted the code prop­er­ly us­ing black, and ex­pand­ed by line lim­it to a gen­er­ous 256.

And Here it is ... it's not re­aly use­ful but it is an ex­am­ple of how ex­pres­sive the Python/Qt com­bi­na­tion can be, even while be­ing an ab­surd­ly bad ex­am­ple no­body should fol­low (O­h, the lamb­das!)

A us­er asked in the niko­la-dis­cuss if there was a way to use Niko­la to doc­u­ment APIs. Well, there was­n't and now there is. I took pdoc and wrote a wrap­per as a plug­in for Niko­la.

And now you can just doc­u­ment python mod­ules us­ing it in a cou­ple of min­utes.

Here is the doc­u­men­ta­tion for the re mod­ule from stdlib as an ex­am­ple.

Yes, the out­put is not great, and it needs CSS, and many oth­er fix­es, but it's easy to im­prove now that it's there, as long as there is in­ter­est.

I wrote a git tu­to­ri­al for those who don't know git where I tried to ex­plain how to use Git for ver­sion con­trol on your lo­cal ma­chine.

Of course those of you who know about these things al­ready know that half the fun of git is not us­ing it lo­cal­ly, but us­ing a serv­er that can cen­tral­ize the de­velp­ment and al­low col­lab­o­ra­tion.

Well, good news! I just wrote the chap­ter where I cov­er that part!

Read and let me know what you think:

Git Host­ing