Architecture Weekly Issue #51. Articles, books, and playlists on architecture and related topics. Split by sections, highlighted with complexity: 🀟 means hardcore, πŸ‘·β€β™‚οΈ is technically applicable right away,  🍼 - is an introduction to the topic or an overview. Now in telegram as well.

WARNING πŸ‡ΊπŸ‡¦

It's already been 326 days since Russia's crazy, brutal and unjustified war against Ukraine. We condemn this war and want it to stop ASAP. We continue this newsletter so you can advance your skill and help the millions of Ukrainian people in any way possible. If you want to help directly, visit this fund.

Video

https://www.youtube.com/watch?v=iZ4A6PuYORU

Highlights

Should architects code? 🍼

The common problem for architects is closing themselves up in an ivory tower - getting far from the actual code, making abstract decisions and imposing them on a team. This is a recognized antipattern, but the discussion is about the remedy. Gregor Hohpe wrote an article explaining how lines of code written by an architect do not bring much value; but the insights in the process do. So instead of coding you might be doing debugging instead. Follow Gregor on the new post in the Architect Elevator.

Debugging Architects
Whether architects must code or not has been much debated. Why not try debugging?

6 steps to autoscaling on Kubernetes πŸ‘·β€β™‚οΈ

Everybody wants a performant, yet cost-efficient solution with any container orchestrator. Although Kubernetes can definitely give you that with autoscaling, just enabling Horizontal Pod Autoscaler won't cut it. You need to better understand your workload, performance baseline and some nuances about autoscaling like rightsizing the pods and performance baselines - like how many users a pod can handle before degradation occurs. This and actually many more in the Perficient Blog - a fascinating read indeed.

6 Steps to successful autoscaling on Kubernetes - Perficient Blogs
In this article I’m showing the 6 steps to implement a successful autoscaling strategy on Kubernetes using KEDA

The Art of Writing Amazing REST APIs 🍼

Every second API on the Internet is a REST API. But many of them are poorly designed: they are inconsistent, they have bad errors and they hard to understand. Joe Ebertz wrote a good, long blog post what to keep in mind when you design a REST API. I think she also could have included some advice on the API versioning, but it can done as a separate article indeed.

The Art of Writing Amazing REST APIs
When writing APIs, REST (short for representational state transfer) is considered the standard. And yet, REST itself isn’t actually a …

Follow-Up

Multi-region deployment with AWS Whitepaper πŸ‘·β€β™‚οΈ

How many availability 9s you need for your application? If it's 99.99%, it will be nearly impossible to satisfy within a single cloud region. This week AWS published a guide how to understand if you need a multi-region deployment, why you need to think about failover, data consistency and operations. Grab it here!

#aws #resilience #cloud Β 

Introduction to IaaC on AWS 🍼

Continuiung AWS topic in this newsletter and the history of IaaC in previous one, I am sharing an introduction to the Iaac. This is a light article which covers the history of deployment and 4 different approaches: manual, scripted, declarative and component based.

Infrastructure as Code on AWS - An Introduction
This post gives you an introduction to infrastructure as code on AWS. We show you the history and which different types of IaC exist.

#aws #cloud #iaac

Data Ingestion challenges 🍼

Tons of data nowadays is a norm - user requests, telemetry, IoT, business analytics and many more. The question which still is open how to process it efficiently. Grab a small article on how to do it and what challenges you are going to face.

How to Simplify Data Ingestion [Business Guide]
A guide to data ingestion and how to simplify it for business operations.

Modules, not microservices 🍼

Microservices promised us velocity, granularity, low coupling, quality and many more. But what we found were problems of distributed systems. In the short article Ted Neward reasoning that we wanted was actually modules with clear boundaries. Examples inside.

You Want Modules, Not Microservices
Dissecting why everybody keeps talking about microservices.

#microservice #modularity

Troubleshooting Kafka for 2000 microservices 🀟

As an illustration of a problem with microservices, check out an article from Wix. The backbone of the product is tons of microservices communication through Kafka. And debugging a particular problem just reported from production could take long time. Then they introduced a lot of helpful tools like sidecars for request tracing, consumer lag monitoring and many more. Follow the article for details. Β 

Troubleshooting Kafka for 2000 Microservices at Wix
5 Monitoring features and remediation tools used by Wix’s 2000 microservices to debug and fix Kafka related production issues

#kafka #microservice #observability

Real-time integration of PostgreSQL and Kafka 🀟

If you need to put data to several locations, like the database, index and some other storage the first idea which comes to a mind is to do a write right-away to those systems. Although being simple solution, it also bring a problem with consistency - what would do if a write to one of those system fails? Confluent blog suggests to write to the DB first, then capture the change with Kafka and connect it to the target location. Enjoy a nice article with bottled water analogy.

Bottled Water: Real-time integration of PostgreSQL and Kafka | Confluent
Confluent is building the foundational platform for data in motion so any organization can innovate and win in a digital-first world.

#kafka

Distributed State 🀟

Can't leave you without a paper to read. This time it's about distributed state. The paper covers the benefits of distributed state, but states that those are potential benefits and are hardly achieved due to consistency problems and performance drawbacks.

How databases store data on disk? 🀟

This week I publicly shared the video on how the dbs store data on disk in the form of files, pages and how to handle variable-size data. Checkout the video!

Like the newsletter? Wanna receive new content earlier, than everybody else? Consider helping to run it at Patreon or Boosty. The funds go to pay for the hosting and some software like a Camo Studio license. Patrons and Boosty subscribers of a certain level also get access to a private Architecture Community and of course every supporter gets early access. Big thanks to Nikita, Anatoly, Oleksandr, Dima, Pavel B, Pavel, Robert, Roman, Iyri, Andrey, Lidia, Vladimir, August and Roman for already supporting the newsletter. Join them as well!