Challenges when designing a new application

Arthur Pym — Wed, 20 Apr 2022 23:11:03 +0000

You have to choose the move that feels right sometimes; that’s what intuition is.
— Magnus Carlsen, Chess World Champion

I’ve been thinking about the multiple challenges we face when designing a greenfield project. There’re many things we have to analyze and define. In the end, we’ll need the correct combination of architecture, language programming, database, infrastructure, and so on. This is really difficult because several options exist, and a new one appears all the time with promising benefits and unclear drawbacks. Additionally, the combination depends on the business context and the team. In any case, we don’t need the perfect setup because it could be too time-consuming and too complicated. As we all know, a low time to market is essential when starting a project. Instead, we must have a good enough combination that allows us to maintain a healthy balance.

Almost everyone knows about chess and has played it for some time. The rules are quite simple, although the possibilities are enormous. After both players move, 400 possible board setups exist. After the second pair of turns, there are 197,742 possible games, and after three moves, 121 million. What makes it even more challenging is that sometimes a simple change in a position could transform a winning move into a completely losing one. So it’s impossible for a human to calculate all the variations. That’s why strong chess players have to develop good intuition and pattern recognition to make a good move in a decent amount of time. As in system design, a good enough decision is fine and desirable.

The limits of my language mean the limits of my world.
— Ludwig Wittgenstein, Tractatus Logico-Philosophicus (1922)

When Martin Klepmann reviewed the different data models in his fascinating book, he cited this very interesting quote. I think it’s a great analogy to show us that any decision involves trade-offs. There’s no such a thing as a silver bullet. For instance, the data model limits how we can read, write and update the data, but it allows us to organize and query it in a particular way that might be useful. Deciding on the correct kind of model for an application is crucial to avoid future problems in terms of performance and complexity of implementation. The same applies to each technical decision we make.

There’re a lot of possibilities for every aspect of our system. You don’t have to be an expert on each of them, but it’s important to know the main categories. We can mention the relational and non-relational models for databases or microservices and monoliths for architectures. These categories could be further divided, depending on the detail we need. Ultimately, these are all tools to have in our bag when the time to design a new system comes. Last but not least, keep in mind that these decisions are not immutable. We must revisit them along the way.

This was originally posted by me in medium

When to use Microservices

Arthur Pym — Sun, 26 Sep 2021 01:38:44 +0000

Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest.

The familiar software project, at least as seen by the nontechnical manager, has something of this character… But, we see no silver bullet.

Frederick Brooks

During the last decade, Microservices have been very popular. It seems that a lot of people believe they will solve each of the issues in their applications. They indeed provide several benefits, but you have to carefully analyze their pros and cons to unleash their full potential. In other words, Microservices are great, but only if you know when they make sense.

In general, every technology decision has multiple trade-offs. There’s no such a thing as a perfect solution. Almost always, you have to conform with a good enough one. Which one should be? Well, that’s one of the hardest things about developing and designing information systems. For instance, Microservices add a lot of complexity to your system to improve scalability, agility and robustness.

Bear in mind that Microservices are just a way to achieve your goals. Before adopting them, you should consider alternatives that could be less expensive in terms of costs or/and time. If you finally decide to migrate your system to Microservices, you must constantly monitor what is happening and see if you are accomplishing your goals.

I recently read a couple of books about this topic, such as Microservices Patterns by Chris Richardson and Monolith to Microservices by Sam Newman. These are great books with many considerations to keep in mind when implementing Microservices. In particular, Sam Newman wrote about a few things to consider before deciding to adopt this architecture. I find them very interesting, so let’s see what he thinks about it.

Three questions before adopting Microservices

What are you hoping to achieve ?
Have you considered alternatives to using microservices?
How will you know if the transition is working.

Reasons to adopt Microservices

Improve team autonomy
Reduce time to market
Scale cost-effectively for load
Improve robustness
Scale the number of developers
Embrace new technology

Reasons to not do it

Unclear domain
Startups
Customer-Installed and managed software
Not having a good reason

DEV Community: Arthur Pym

Challenges when designing a new application

When to use Microservices

Three questions before adopting Microservices

Reasons to adopt Microservices

Reasons to not do it