In November 2020 AWS had a major outage, which started with their Kinesis service, having a cascading failure over some services. Several articles and analyses of the outage, including the official note from AWS. This blog post reflects the outage, but rather focus on the technical aspects, I will deep dive into the social ones, namely mental models.

I’m grateful to learn from my daughter. Be able to see how the brain develops and picks up new concepts, skills and words. Nowadays, I enjoy to sit down and watch her play. As a parent, I also need to help her to achieve her autonomy: emotionally, mentally and physically. It is the job, and my wife and I are navigating through it. There is not a guide on how to parent, and we discuss what is working and what is not working. Sometimes is just not the time for a new skill, other times our daughter doesn’t develop an interest for a particular activity. Well, we are all different, and that is what makes the world colourful!

Context Map was the first visualisation for the Bounded Context pattern from Domain-Driven Design. In a nutshell, it is a map of the different Bounded Contexts and their relationships. I tend to create a Context Map during or after a Big Picture EventStorming. Changing perspectives can be helpful, to challenge assumptions and get the best of different techniques.

However, sometimes it is hard to reach a consensus on the Context Map. I often operate in brownfield projects, with large organisations. Although people agree with the different bounded contexts, it is a process that takes time, and most significant energy. Which can lead to fatigue towards the method, and at the same time raises exciting patterns in the behaviours. But this blog post is not about emergent behaviour. 🙂

Chaos Engineering is a practice that has its roots at Netflix. It born from the challenges of moving their workloads from the data centre to the cloud; the transient nature of the cloud affected the way that they build and operate a system at scale. The initial project was called Chaos Monkey, and it has almost 10 years.

Since then the community grew, fueled by Netflix practitioners. Today there are commercial and open-source tools, and we can see more initiatives in different communities. The technical practices had matured, and the knowledge started to spread in the IT world.

However, it is deemed perceived as a technical practice. Can we leverage Chaos Engineering as a management practice?

Team Topologies is the work of Matthew Skelton and Manuel Pais, and I use it as part of my job. From a sociotechnical perspective, a team-first approach is paramount for any organisation and helps to decrease the accidental complexity. As such, I’m often asked “How can we operate in DevOps?” or “How can I have a reliable service to deliver value to my customer?”.

Read more →

The most important learning during my career is that the act of creating software is a team effort. We can be a one-person team, but there is someone else involved; at least someone to use it.

Read more →

Did the title tease you? Great, job is done! Today I will tell you my story about Integration Tests; it came after another knowledge share lunch with my pal Kenny.

By this definition an Integration Test is

(…) the phase in software testing in which individual software modules are combined and tested as a group. Integration testing is conducted to evaluate the compliance of a system or component with specified functional requirements. It occurs after unit testing and before validation testing. Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready forsystem testing.

Sounds pretty waterfall, right? It is! also, the implementation approaches that I observed creates huge dependencies between teams, coupling the software release process.

Read more →

There are 2 systems in any company that are critical: the payroll system, and the CI/CD system. Why? You may ask…
If the payroll system doesn’t work, people will leave the company and the company (may) face legal problems; the CI/CD system is the gateway to production. If it is down and there is a bug in production, it will affect your business; loss of revenue, loss of customers, loss of money, just to name a few.

Usually, I find these problems regarding the CI/CD tooling:

• Poor Software Lifecycle Management, with outdated software, containing critical vulnerabilities
• Ancient capabilities in the build agents. In extreme cases, frameworks and tools that are no longer supported by the vendors
• Drifting agents. It means that teams had to do some sorcery to get the software build
• Lack of proper isolation between different builds. It means that a build could access to another build files
• Lead teams to upgrade or install a new framework
• Outdated and strict rules mandated by a operations team. Usually from people that outdated heuristics on how software should be developed

Read more →

Today Serverless is a thing. Although everyone can write a blog post about how Serverless run on servers, I share the same visions as Mathias Verraes:

If you want to tweet or blog about how serverless actually runs on servers, let me save you some time: Nobody thinks that serverless doesn't run on servers. Nobody. You're just taking cheap shots at a catchy name.

— Mathias Verraes (@mathiasverraes) May 12, 2018

Given that, I decided to share my developer experience building, testing and deploying AWS Lambda functions in the .NET world. Not a “Hello World” example, but rather a real-world scenario, where some services integrate with each other. Since a Serverless function is a tiny piece of code in a much larger process, how can I test the flow on my development machine?

Read more →