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.
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.
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.
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.
#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.
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.
#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. Β
#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.
#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!