Old Guy @ The Terminal Ep 2: Python Sucks!
Episodio 2! Oh yeah!
Esta es una charla relámpago que dí en la PyCon Argentina de 2018, es cortita y sencilla, ojalá les guste!
Episodio 2! Oh yeah!
Esta es una charla relámpago que dí en la PyCon Argentina de 2018, es cortita y sencilla, ojalá les guste!
Este es el primer (y por ahora único, obviamente) episodio de un nuevo canal de video llamado "Old Guy @ The Terminal" en el que muestro algunas cositas de Linux, programación, como se relacionan cosas actuales con cosas viejas y veremos qué más a medida que se me ocurran temas.
Nunca había hecho algo parecido, así que no sean muy duros conmigo ;-)
En este episodio vemos qué es una terminal, como se hace un programa para terminal y una terminal para el programa, porque por qué no.
En algún momento va a haber una versión en inglés (tal vez).
El código: en GitHub
Today I was in a meeting with recruiters (yes, really) because they want to be better at technical recruiting and they had the idea that talking to me would help them (oh, sweet summer children).
A nice time was had by all (I hope) and at one point I was asked about what architecture was, and more specifically, about the difference between microservices and a monolith.
Which I tried to explain using what I had at hand: coffee cups, sugar dispensers, a spoon and so on. It didn't quite work out but I kept thinking about it on my way home and ... let's try again.
Architecture, when it comes to software, can be defined in many ways, but one way I like is to say that architecture involves:
There is a lot more, but you start with that, and that is more or less enough to explain monoliths and microservices.
One thing of massive importance about systems is that they are meant to do something. They exist for a purpose. So, let's suppose the purpose of our system is to make coffee and put it in a cup.
We can call the cup the "coffee client" and whatever we use to make the coffee is the "coffee system" or "coffee service"
So, assuming you have a can full of cofee beans and a cup, how do you make coffee?
This is my very own coffee machine. Not only is it monolith-shaped, it's functionally monolithic (it's also large enough to deserve its own table, as you can see).
It has two buckets on top. On one you put water, in the other you put coffee beans. Then, you put a cup under the spigot and press a button or two.
It will:
Sounds awesome, right? It is!
It takes all of 30 seconds to go from coffee beans to a nice cup of coffee! It tastes good!
And it's important to keep that in mind. IT IS GREAT.
Monoliths, when they done correctly and you are not expecting anything out of their operating parameters, are awesome.
The problem with monoliths 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 industry the meaning of "right" is not fixed.
So, because the whole point is to ride this analogy into the ground, let's consider all the things about this awesome machine.
It grounds the coffee. What happens if you want it ground finer? Or coarser?
It turns out that if you have the right tool you can adjust the mill's output (it's not in the manual).
In a microservice-based coffemaker I would replace the grinder.
How about water temperature?
It has three settings. Want anything else? No luck.
In a microservice-based coffee service I would just use an adjustable kettle.
How about the amount of coffee per cup?
It has three settings. Want anything else? No luck.
In microservice-cofee I would just transmit as much coffee as I wanted.
How about changing the bean variety between cups?
The bean hopper takes half a pound of beans. It's not easy to get them out. So, no.
In microservice-coffee heaven I could have multiple hoppers providing beans of all varieties and just connect to the one I want today!
Cup size?
It does two sizes (but you reprogram those sizes)
In microservice-cofee I would just pour as much water as I liked.
A monolith has the flexibility its designers thought of adding, no more, no less. And changing it is ... not trivial.
I could use a vacuum cleaner to remove the beans from the hopper and change varieties. I would consider that a hack. I have also done it. I regret nothing.
It has a thing that lets you setup a credit system for coffee cups I will never use. A milk foamer I use once a week. Why? Because "we may need this and it's hard to add it later, so let's just do it from the beginning" ground coffee.
Sometimes yes, it's useful (capuccino!) but sometimes it's just something I paid for and will never use (coffee credits!)
In a microservice architecture I would just get a new milk foamer, use both for a while and then keep using the one I like.
How do I add a better foaming thingie?
By buying one and putting it in the table.
How do I add a more flexible coffee grinder?
I can't because this machine is incompatible with pre-ground coffee. There is a newer, more expensive model that can take that but this one? You need to throw it away.
Modifying a monolithic system is difficult because the pieces are tightly coupled. I can't use a separate grinder because the system requires the coffee grounds to arrive via a specific internal duct at a specific point in the coffee-making cycle, there is just no way to insert my grind-o-matic-3000 in there without a saw and duct tape.
In a modular system I would unplug the grinder and insert a compatible-but-different grinder, in a microservice architecture I would just use whatever grinder and put the coffee grounds in a message and have the next piece in the system pick it from there.
This coffee machine is expensive. It's much more expensive than buying a grinder, a coffee machine a kettle and a milk foamer.
What it provides in exchange for the extra money (and reduced flexibility and so on) is performance. I don't boil water, I don't grind coffee, I don't pour, I just press a damned button and enjoy coffee.
You can buy pre-ground coffee and effectively outsource that part of the process to some external provider.
I can't! I am doomed to ground my own coffee forever.
I have a lubrication schedule, or else my expensive machine will break.
I have to disinfect the coffee ground bin or else it will have maggots.
I have to empty the water waste tray before it overflows.
I have to have a thing to dump the bits of dirty water it uses to clean itself when it turns on/off.
I have to buy special acid to periodically remove scale from its innards or it will stop working. That costs actual money and takes half an hour.
I need to cleanup coffee crud from all the internal springs, levers and thingies every couple of weeks.
Now, you, readers with normal coffee making things? How is your coffee machine maintenance routine? What, you don't have one? Thought so.
So, that's why nowadays most people prefer to pay the performance penalty of a microservice architecture instead of using an awesome monolith.
This is not exhaustive, there is still separation of concerns, encapsulation, rigidity of contracts and a lot more, but it should be convincing enough without being dogmatic :-)
I wrote a git tutorial for those who don't know git where I tried to explain how to use Git for version control on your local machine.
Of course those of you who know about these things already know that half the fun of git is not using it locally, but using a server that can centralize the develpment and allow collaboration.
Well, good news! I just wrote the chapter where I cover that part!
Read and let me know what you think:
I want to learn new languages. But new as in "new to me", not new as in "created last week". So I decided to play with the grandaddy of all cool languages, LISP. Created in 1958, it's even older than I, which is good because it's experienced.
One "problem" with LISP is that there are a million LISPs. You can use Scheme or Common Lisp, or Emacs' Lisp, or a bazillion others. I wanted something simple so it was supposed to be Scheme... but a few days ago I ran into something called Picolisp and it sounded so cool.