Kartones Blog

Most developers will be familiar with the acronym ACID, which stands for Atomicity, Consistency, Isolation & Durability regarding database transactions. ACID is well known and applicable for single database instances, but cannot be uphold for distributed transactions. Regarding the CAP theorem, it chooses Consistency and Partition tolerance. Building an application with ACID capabilities mostly requires just wrapping critical paths under transactions and properly configuring the isolation level of the database system.

With the NoSQL movement appeared another acronym, BASE: Basically Available, Soft state, Eventual consistency. It provides the Availability and Partition Tolerance from CAP, but eventual consistency requires deeper architectural and even product changes in any system (e.g. your clients can see stale or transitional data, or fail to see recently created data units).

Today while reading about distributed systems and consistency I came across a third acronym, CALM. Apart from the obvious jokes around "keep CALM and ...", while far from easy as the article "Keeping CALM: When Distributed Consistency Is Easy" implies, it is interesting regarding two key points:

• It proposes that "A problem has a consistent, coordination-free distributed implementation if and only if it is monotonic". By reasoning about program outcomes, rather than mutations to storage, and avoiding linearity and ordering, theoretically we can build software that doesn't needs to coordinate at all (with the concept of "confluence" to a final correct result).
• It observes that "Coordination-freeness is equivalent to availability under partition", thereby fulfilling all 3 CAP properties for those cases where problems are monotonic.

So, if we found a solution to distributed agreement, why is not so known? Where's the catch? Well, non-linearity and confluent operations are very hard to implement with imperative languages, they are more apt for functional programming. Up to the point that the theorem authors created the Bloom programming language, with the purpose of build distributed systems software. So here the cost of implementation is as huge as probably requiring a full rewrite of parts of the system (and of course in a functional paradigm).

I left on purpose well-known consensus protocols like 2PC, Two-Phase Commit, and the Paxos family, because they bet strongly on agreement mechanics to achieve CAP, while BASE and CALM propose and/or provide approaches that that "skip" or workaround consensus.

But I wanted to mention CALM also because the ACM article represents an interesting journey on traditional distributed systems problems, with examples using familiar scenarios like a distributed shopping cart. I'd like to keep at hand a list of terms and a few notes about the topic, so this small post does the job.

2020-11-02

I recently came across FIRE: Financial Independence, Retire Early, got interested and reading about it found some misleads and not-so-true claims, not in the theory but in posts and articles about "success stories", and wanted to dump my thoughts on the subject.

Most definitions (sample) include the two critical pillars that support this movement: savings and investment. FIRE is about earning money, then spending part of it to somehow have passive income source(s), so that you don't need to work. To not actively work at least.

And precisely in the "passive" adjective is where I see the problem, because seems to be either confused or just switched with self-employment (probably to click-bait, because profiting from blog posts or related books is an income source too 😉). Let me showcase two examples:

a) Stock Investing: If you invest passively, you contract an investor, a fund or any similar broker that deals with your assets and generates you income. If you actively choose the stock, what to buy, when to sell, check markets, etc., then that's actual work, it's active work. You became a small stock trader.

b) Real state renting: If you invest passively, you buy a house (or more), then contract someone to handle the management (repairs, finding tenants, etc.) for a fee. If you're the one in charge of any problem/repair, even if it's just calling the insurance company, then it's not passive, it's an active job (a property management services company of one). This is easy to notice if you get more work each property you add, if it's passive shouldn't have any effect other than regarding money.

Yes, I've read there are variants of FIRE in which you keep a part-job, but then that's not early retirement, it's partial retirement.

Until recently I had for a few years a small property that I rented and, while it mostly required low attention, when there were issues it did require time and effort, and sometimes totally understand why there exists services that handle these scenarios and wonder if should have taken that path. I didn't just because overall was easy to handle and near my home.

This is just my subjective interpretation, but few things in life are really free.

Freedom to spend your time while earning income usually has a cost, often in the form of somebody taking care of some assets, ensuring an income and dealing with any issue that might happen.

2020-11-01

Review

Title: The Economics Book - Big Ideas Simply Explained (Audiobook format)

Author(s): Dorling Kindersley Ltd (DK)

Continuing with non-technical leaning, I just finished another DK audiobook, this one about economics. Similarly to The Business Book from the same editorial, in around 16 hours of we'll be given a historical tour of economics presenting multiple economic models, theories and ideas (according to the description, around 100 of the those).

Some of the topics we'll learn about are: monopolies, oligopolies, competition, markets, predatory marketing (and other types), economic bubbles, inflation and employment, economic models, rationality, crisis, how banks work and what "bank runs" are... And, as you might imagine, some are not trivial, while others feel simple to understand once properly explained.

Another quite interesting title, of course not a deep dive but neither shallow, probably a good starting point to then focus on the models that appeal. Of course considering that I have no clue about the topic, so I might be wrong, but I felt I learned a lot.

2020-10-18

Imagine the following scenario. You and a colleague have written an architecture proposal to implement Contract Testing into the system, so most services can benefit from it. You've built a working proof of concept, all using internal frameworks, protocols and the existing messaging system, because you don't like reinventing the wheel but when you're already driving a custom-made car, you think it's if not better at least less friction-inducing to use existing building blocks instead of introducing new tools into an already complex system.

It works, it is simple (python, git and json), it plugs into the existing services ecosystem and automatically builds the schema definitions of modern services, and with some extra love can theoretically be made almost 100% compatible even with the old legacy ones. Everything seems ready to showcase and proceed to ask for time and resources to make it a real project.

You begin to finally present it at the architecture committee in all it's glory. After five minutes talking about how it's implemented, somebody asks: "I'm sorry... what exactly it's contract testing and what does it add?" 💥

That is the moment when you realize you made a huge mistake... You assumed everybody, being senior roles, had knowledge of the basic pillar: what is contract testing, why is interesting and what problems it solves or aids to ease.

The meeting shifted to some improvised explanation and a brief "next steps", but it felt like the magic of the technical approach was lost, it missed the hype train. Nobody can measure the quicker test development or the added safety net for releasing new service versions without breaking others if they don't know that's a problem and there's a certain way to solve it.

You don't need to go to the other extreme and explain everything like you're a five year old, but you should always include a basic introduction to the topic.

2020-10-04

Remember that old song from the classic Monty Python's film Life of Brian, Always look on the bright side of life? After so many years it's still stuck in my head 😃

2020 is unfolding as either a weird year or directly a bad year to most people, but in my case some relevant events started in 2019, and even I have to go further back to provide enough context.

In 2017 I switched jobs and I was exploring going full-remote, but in the end I went to a small Spanish ticketing company. It got acquired in early 2018 and, suddenly, a ~70 employees company became part of a multinational with +1000 employees. A few months later they also bought a Canadian company, and on January 2019 I asked my manager if there was a way to get transferred to Canada. I was told that at least in 2019 was impossible, as I was one of the two IC5 level engineers in Eventbrite Spain and I was vital for the Madrid office.

After summer 2019, my partner and I realized we really wanted to change, so I came back to my manager and explained the situation; we agreed to explore a transfer to the Vancouver office for early 2020. This was at the beginning of September. After a few internal conversations, waits and approvals in December 2019 I went to Vancouver and got the final approval from that office.

Advancing to March 2020, with all paperwork ready, the house almost empty, and basically everything good to go... COVID-19 hit globally, and specially hard in Spain. At the beginning of the global confinement, as borders closed we couldn't fly to Canada; then, with the forecasting of extended confinements (which in the ticketing business means almost zero income) the transfer got frozen; shortly after, the company laid off half of the workforce, which included the Vancouver office, so the whole transfer idea went away.

While the lay-offs didn't affected me directly, I was contacted by an ex-colleague with an interesting offer, and this time I listened, liked what I was told and took the opportunity.

Having summarized the key points, what initially was a negative outcome has pivoted to a series of changes for the better:

Remote Work

I started to think about becoming full remote around 2017 but didn't in the end. Now, even if currently it's hard to travel to other countries because of the COVID situation, I have the freedom to move anywhere in the world when the time is right. We're also no longer tied to living in a big city in order to "have an interesting job", so we're moving to the North of Spain to enjoy some nature and a colder (and thus, better) weather.

Out of the Comfort Zone

I've switched my day to day development language one more time! How different is working with Java "for real" from the Java you learn at university, and even from books. Java 8+ features, Lombok, Guava, Dagger, JAX-RS... plus GCP services (Pipelines, MapReduce, DataStore, BigQuery...), and the project itself, which is a new area for me. I am so happy to be learning new things almost every day. Combined with keeping working in English, which means I practice it a bit, I am quite satisfied with the decision.

Minimalism

While discussing and afterwards preparing for the transfer we weren't sure if there was going to be a reallocation package or not, so we took a minimalistic approach regarding physical goods. But before that we had already started to walk that path, in early 2019 when we moved outside of the city center. As an example, excluding clothes and my monitor, all my stuff fits in a backpack and a single standard size box [1]. Two laptops, two handheld game consoles, a tablet, a kindle (I keep only one physical book, until I finish reading it), the phone... and mostly just accessories and cables.

It's been a slow and iterative process, and sometimes not easy to apply. For example, I had a collection of boardgames, and quite a few old videogame consoles, but I gifted or sold each and every one of them. And same with printed books and other things that had emotional value but really I wasn't going to use any more.

Reduced Burdens

We had an old car, and last year almost broke; repairing it was expensive but we had to hold on to it for a few more months. Nowadays was due for another round of checks and potential repairs (again all but cheap), so we sold it instead, opting to try the car leasing model. We now only pay a monthly rent and gas, contract gets renewed each few years (and we get the choice of switching to a different vehicle if we want), and even an early cancellation of the leasing would cost significantly less than remaining rent quotas. Similar to that we have removed or simplified other personal and financial obligations. "The less you have, the less you need to worry about".

Built Healthy Habits

I recently wrote about habits and mentioned specific ones I've been shaping, like pomodoros or meditation, but there have been other areas of improvement, like food & health, a bit of sport (at minimum fitness maintenance, but slowly increasing), quality family time, and keeping less hobbies but fully enjoying the ones that remain. I still think days fly away too quickly, but I definitely "do more by doing less".

[1] : Actually I also have two "optional hobbies" boxes, things that if there's space (both physical and regarding my time schedule) I'll ask my family to send me, but else I can live without.

2020-09-01