Ok, I have listened to Test Pyramid, indeed, there is plenty of content around this concept. Roughly, the test pyramid concept asserts that the first layer of test, Unit, is cheaper, faster, and has the desired confidence property [1,2,3]. As we climb the pyramid through Integrated and End2End (E2E) tests, in the benefit of completeness, these three properties are compromised more and more. Other properties related to the test pyramid are automation and coverage as well as correctness — the property that is asserted when the system under test is correct with respect to its specification.

A pyramid is a…

Let us start recalling the conclusion of the last conversation [1]. IT phenomena as cloud, “…-as-a-service”, and microservices, which carry on distributed computing, require reliability engineering since the complexity of systems continues to grow. By the same token, “failures are a given, and everything will eventually fail over time” a quote by Werner Vogels (VP & CTO Amazon).

Therefore, Site-Reliability Engineering (SRE), an acronym defined by Google, emphasizes the necessity of reliability concerns and requirements, in particular, fault tolerance, which is the capacity of a given system to tolerate failures and continue to function. Nonetheless, a sine qua non condition…

Of course, you have heard about Site Reliability Engineering (SRE), an acronym introduced by Google. The aim of this text is to dissect the acronym using a seesaw (an old-school kindergarten toy) as a conceptual model. Nonetheless, instead of going from kindergarten to middle school, as usual, this text applies the other way around.

Middle School

Let us start with a brief history of reliability engineering. One can argue that statistics and mass production were the enablers in the rise of reliability engineering [1], concomitantly, many reliability issues occurred in World War II due to the unreliability of electronic equipment and the…

A didactical way to define a concept is starting by what it is not. Therefore, in Section 1, the focus is on what is not an “architecture for agility”. In Section 2, a case, inspired by a true story, is discussed to clarify what we would call an “architecture for anti-agility”. Section 3 defines the concept hopefully.

  1. What is not “architecture for agility”?

As always in the technology information, there are too many buzzwords around a given abstract concept, so “architecture for agility” is another case. Recall the concept “architecture for agility ” is related to the ability of a…

Once upon a time, a queen possessed a magic mirror, which she asked every morning, “Magic mirror on the wall, who is the fairest one of all?” The mirror always told the queen that she was the fairest. One day, when the queen asked her mirror, it told her that Snow White was the fairest. — Brothers Grimm

Back in the 1960s, Conway [1] shared the following cornerstone question: is there any predictable relationship between the architecture of an organization and a product that the organization designs in response to a given set of functional requirements?

In fact, Conway introduced…

Everyone makes mistakes. The wise are not people who never make mistakes, but those who forgive themselves and learn from their mistakes.” — Ajahn Brahm (theoretical physicist, author, and Buddhist monk)

In this second part, we return to the endeavor of providing, perhaps, for wise people, a shortcut to “learn from their mistakes” when applying the microservice pattern (if shortcuts exist at all). The first part was focused on the applicational design mistakes [1], whereas this second and final part is focused on architectural mistakes.

Indeed, a given system that applies the microservice pattern is a distributed system by definition…

Source: https://en.wikipedia.org/wiki/Ajahn_Brahm

Everyone makes mistakes. The wise are not people who never make mistakes, but those who forgive themselves and learn from their mistakes.” — Ajahn Brahm (theoretical physicist, author, and Buddhist monk)

Nowadays, the microservice pattern [1] is a hot topic, which has a tremendous influence on all sorts of software engineering programs and projects. Nevertheless, through the last two years, there has been a noticeable backlash against microservices [2]. …

Assume that is in place a tool for the management of containerized applications across multiple hosts (e.g., Kubernetes, OpenShift, Docker Swarm, Apache Mesos) and that applications are composed of containerized processes as defined by the Twelve-Factor App.

Still according to the Twelve-Factor App [1], such containerized processes can be horizontally scaled up and down as needed since they are stateless and share-nothing. Consequently, any data that needs to persist must be stored in a stateful store. …

Nowadays, microservice pattern [1] is a hot topic, which has a tremendous influence in all sort of software engineering projects. In projects that deal with state (some sort of store — data store, event store, etc…), invariably, microservice pattern leads to a multitude of fine-grained services following the database per service pattern [2]. Once these fine-grained services are established, they pose the challenging of implementing queries that need to retrieve distributed data, which in turn leads to the Command Query Responsibility Segregation (CQRS) pattern [3]. …

Alessandro Gerlinger Romero

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store