O assunto de hoje, como todo mundo já notou, é o DeepSeek-R1 e o estrago que o lançamento dele fez no mercado.
Como todo assunto técnico, tem MUITA desinformação rolando pra população em geral.
Meu objetivo aqui é desmentir um pouco isso. Fio porque vai ter vários links.
🧵
𝗪𝗵𝗮𝘁 𝗜 𝗹𝗲𝗮𝗿𝗻𝗲𝗱 𝗳𝗿𝗼𝗺 𝘁𝗵𝗲 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲: 𝗧𝗵𝗲 𝗛𝗮𝗿𝗱 𝗣𝗮𝗿𝘁𝘀
I recently read the book "𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲: 𝗧𝗵𝗲 𝗛𝗮𝗿𝗱 𝗣𝗮𝗿𝘁𝘀" by Neal Ford, Mark, Richards, Pramod Sadalage & Zhamak Dehghani. The book is mainly related to breaking monolith applications into microservices and could be an excellent companion to the book "Monolith to Microservices," by Sam Newman.
The book emphasizes the step-by-step approach of breaking down monolith, with different patterns for each step, and balancing tradeoffs for those patterns. The book is titled "Hard Parts," yet most of the concepts in the book are familiar.
Here are 𝘁𝗵𝗲 𝘁𝗵𝗶𝗻𝗴𝘀 𝗜 𝗹𝗶𝗸𝗲𝗱 from the book:
1. The most essential architecture skill is how to make decisions and balance trade-ffs
2. Advice on how to do a modern tradeoff analysis:
🔹 Find what parts are entangled together.
🔹 Analyze how they are coupled to one another.
🔹 Assess tradeoffs by determining the impact of change on interdependent systems
3. The main modularity drivers are:
🔹 Speed-to-market, achieved by architectural agility, i.e., the ability to respond quickly to a change.
🔹 Scalability, where the need for more scalability support increased user activity
🔹 Fault tolerance, the ability of an application to fail and continue to operate
4. Breaking down monolith with the two methods:
🔹 Component-based decomposition (if monolith is modular): it applies different refactoring patterns for extracting components to form a distributed architecture in an incremental way
🔹 Tactical forking (if the monolith is a big ball of mud): copy the whole monolith and remove the part not needed
5. Sizing components
🔹 Calculate the total number of statements (with ;) with a given component—the ideal size of 1 to 2 standard deviations from the average component size.
Here are 𝘁𝗵𝗲 𝘁𝗵𝗶𝗻𝗴𝘀 𝗜 𝗺𝗶𝘀𝘀𝗲𝗱 in the book:
1. Although the book is abstract (as expected from architects), it doesn't go into any implementation details or technologies or mention architectural patterns.
2. The book follows Sysops SAGA's fictional story, whereas a real-life example would be more worthwhile. In this way, some things would sound artificial or forced.
3. I need to catch the data, as the book makes many assumptions. As it is not backed with any real-life project (pricing, etc.), we are still determining what metrics we would get.
4. I missed the structured approach. It started well with essential concepts, such as modularity and decomposition, and then twelve immediately into components and pulled apart data. Then, it went to service granularity and reuse patterns and data ownership and access patterns later.
#softwaredesign
I've read 350+ articles in 2023, mostly (300+) technical articles about Engineering & Engineering Management and some about Career, Leadership, Financial Freedom, Psychology & Writing.
Here are My 23 Favorites based on the number of insights I gained from them. They are ranked according to the most influential writers of the year for me.
🧵🧵🧵
Describing System Architecture
When collecting the requirements or when starting the maintenance of a product it is important to define a short list of quality goals. In chapter 1 there is a section dedicated at this.
The quality goals are a sort of cross cutting concept. A quality like "Adequate Performance" can be applied to the UI as well as a REST API.
Here is when a drill down in the Quality Requirements is important to keep them in mind in every aspect where they can be important.
Architects transform quality requirements, which may be unclear or implicit, into explicit and tangible forms through the use of quality scenarios. These scenarios articulate the expected behavior of the system in response to specific stimuli.
Architects primarily focus on two categories of scenarios:
1. Usage Scenarios (or Application Scenarios or Use Case Scenarios):
Usage scenarios delineate the system's real-time response to a particular stimulus. This encompasses not only the system's reaction to user inputs but also scenarios that outline its efficiency or performance characteristics. For instance, an example of a usage scenario could be the system responding to a user's request within one second.
2. Change Scenarios:
Change scenarios capture alterations to the system or its immediate environment. This includes instances where additional functionality is implemented or when there are modifications to requirements related to a specific quality attribute. For example, a change scenario could involve the introduction of new features or adjustments to meet evolving quality attribute requirements.
The quality tree displays quality requirements in the form of a tree with leaves that link to concrete quality scenarios. It can also be in tabular form.
We can represent all the scenarios where a Quality Goal applies. It is a perfect place for a quality check and it can be the base to define any fitting function for both the architecture as well as the product we are describing.
Bookmark and like this post if you found it useful.
Follow me, If you are interested in more Software system architecture topic.
15 articles that can help you get better at important System Design concepts:
[1] How to Scale a Component?
https://t.co/sL0rr7u4lC
[2] Load Balancers (Types, Algorithms, High Availability)
https://t.co/iumQMuUgef
[3] Authentication with JWTs
https://t.co/LJgZ4iAtXg
[4] Database Caching Strategies
https://t.co/oUAmzhh0Ek
[5] Cookies and Sessions
https://t.co/dzZiXewOp4
[6] Microservices Patterns
https://t.co/Fxs4nuHhW3
[7] Types of NoSQL Databases
https://t.co/Qxnudk0g3B
[8] The Secret Trick to High Availability
https://t.co/Qxnudk0g3B
[9] Moving from Monolithic to Microservices
https://t.co/rG7QaUZqxT
[10] How Request Coalescing Works
https://t.co/21HVMvCCoQ
[11] Database Replication under the hood
https://t.co/MiTKoOHpGj
[12] Why Database Replication Lag occurs?
https://t.co/G9MEvyZexC
[13] Problems caused by Replication Lag
https://t.co/leQYSwNERE
[14] How Rate Limiting Works?
https://t.co/aa7ENPVWMd
[15] High Availability Database
https://t.co/jxLzWczasf
Quick Retro! Books I read/re-read in 2023: 70.
My Favorites & The Highest-Density Ones:
-> Engineering/Management:
1- Observability Engineering by @mipsytipsy
2- Scaling People by @chughesjohnson
3- The Leader You Want to Be by @AmyJenSu
4- Confident Career Conversations by @antoinetteog
5- The Staff Engineer's Path by @whereistanya
6- Building a Career in Software by Daniel Heller
7- The Engineering Executive's Primer (still in early-draft/release) by @Lethain
-> Non-Engineering:
1- Outlive by @PeterAttiaMD
2- The Great Work of Your Life by @SCopeAuthor
3- 12 Rules for Life by @jordanbpeterson
4- Memories, Dreams, Reflections by Carl Jung
5- Optionality by @MeadowsRichard
6- How Big Things Get Done by @BentFlyvbjerg
7- Range by @DavidEpstein
More on the thread 👇
79 Resources to read to improve your system design:
High Scalability https://t.co/2FjQGtI7rk
System Design Newsletter https://t.co/EYNa2KP6H2
System Design Primer https://t.co/ujYfKF1EsZ
System Design Course https://t.co/E3RHntdVGZ
Engineering at Meta https://t.co/OjZjWSvF1C
AWS Architecture Blog https://t.co/6a7R85De7d
All Things Distributed https://t.co/O95RpBYN3U
The Netflix Tech Blog https://t.co/yRqJiZtivR
LinkedIn Engineering Blog https://t.co/uuyrTgjJRl
Uber Engineering Blog https://t.co/ZLzTgY81jw
Engineering at Quora https://t.co/emGzeXvYjX
Pinterest Engineering https://t.co/pAKJTBAW1J
Lyft Engineering Blog https://t.co/fTLBQouCMS
Twitter Engineering Blog https://t.co/5jSzIWKKoF
Dropbox Engineering Blog https://t.co/0YAGxIT6bf
Spotify Engineering https://t.co/Y3YBRc72Xq
Github Engineering https://t.co/wTzDAQi41E
Instagram Engineering https://t.co/EehYp4vKLv
Canva Engineering Blog https://t.co/c1H4ji71Jj
Etsy Engineering https://t.co/XIxp4qrexu
https://t.co/gBD3XsWeSa Tech Blog https://t.co/kcr7FPYOCE
Expedia Technology https://t.co/ppAbq7kUiv
The Airbnb Tech Blog https://t.co/a8q3YtZrdJ
Stripe Engineering Blog https://t.co/Cd1LVPX69U
Ebay Tech Blog https://t.co/VF8QCKYmGs
Flickr's Tech Blog https://t.co/w5VM8mq53i
Hubspot Product and Engineering Blog https://t.co/ISFCTojUDe
Zynga Engineering https://t.co/U37CVhxwTL
Yelp Engineering Blog https://t.co/BoslXXaqVq
Heroku Engineering Blog https://t.co/9RJkVlVkuE
Discord Engineering and Design https://t.co/S5dDuKaHsb
Zomato https://t.co/AOSGm5LwdH
Hotstar https://t.co/8xzDPCd344
Swiggy https://t.co/SAnsrx93xZ
Acast Tech https://t.co/xLc1Bni4cd
ASOS Tech Blog https://t.co/A5zsKCDhQT
Shopify Engineering https://t.co/Y0i25GFGy5
Microsoft Tech Blogs https://t.co/UDoOo5P5tU
Engineering at Microsoft https://t.co/reHLmNBHMy
MongoDB Engineering Blog https://t.co/RdSDAmlAnJ
Slack Engineering https://t.co/yD0TfYHx4Q
The rest don't fit in X's post length so you can find them here: https://t.co/AKzXERcA9R
𝗙𝗿𝗲𝗲 𝗯𝗼𝗼𝗸: 𝗢𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴
The book by Charity Majors, Liz Fong-Jones, and George Miranda is about observability in modern distributed systems.
In this book, you will learn:
🔹 𝗧𝗵𝗲 𝘃𝗮𝗹𝘂𝗲 𝗼𝗳 𝗽𝗿𝗮𝗰𝘁𝗶𝗰𝗶𝗻𝗴 𝗼𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝘄𝗵𝗲𝗻 𝗱𝗲𝗹𝗶𝘃𝗲𝗿𝗶𝗻𝗴 𝗮𝗻𝗱 𝗺𝗮𝗻𝗮𝗴𝗶𝗻𝗴 𝗰𝗼𝗺𝗽𝗹𝗲𝘅 𝗰𝗹𝗼𝘂𝗱-𝗻𝗮𝘁𝗶𝘃𝗲 𝗮𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻𝘀 𝗮𝗻𝗱 𝘀𝘆𝘀𝘁𝗲𝗺𝘀
🔹 𝗧𝗵𝗲 𝗶𝗺𝗽𝗮𝗰𝘁 𝗼𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗵𝗮𝘀 𝗮𝗰𝗿𝗼𝘀𝘀 𝘁𝗵𝗲 𝗲𝗻𝘁𝗶𝗿𝗲 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗰𝘆𝗰𝗹𝗲
🔹 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗼𝘄𝗻𝗲𝗿𝘀𝗵𝗶𝗽: 𝗛𝗼𝘄 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗳𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝗮𝗹 𝘁𝗲𝗮𝗺𝘀 𝗵𝗲𝗹𝗽 𝗮𝗰𝗵𝗶𝗲𝘃𝗲 𝘀𝘆𝘀𝘁𝗲𝗺 𝗦𝗟𝗢𝘀
🔹 𝗛𝗼𝘄 𝘀𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝗰𝗼𝗻𝘁𝗿𝗶𝗯𝘂𝘁𝗲 𝘁𝗼 𝗰𝘂𝘀𝘁𝗼𝗺𝗲𝗿 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 𝗮𝗻𝗱 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗶𝗺𝗽𝗮𝗰𝘁
🔹 𝗛𝗼𝘄 𝘁𝗼 𝗽𝗿𝗼𝗱𝘂𝗰𝗲 𝗾𝘂𝗮𝗹𝗶𝘁𝘆 𝗰𝗼𝗱𝗲 𝗳𝗼𝗿 𝗰𝗼𝗻𝘁𝗲𝘅𝘁-𝗮𝘄𝗮𝗿𝗲 𝘀𝘆𝘀𝘁𝗲𝗺 𝗱𝗲𝗯𝘂𝗴𝗴𝗶𝗻𝗴 𝗮𝗻𝗱 𝗺𝗮𝗶𝗻𝘁𝗲𝗻𝗮𝗻𝗰𝗲
Link: https://t.co/TXZVF4W7X8
_______
If you like my posts, please follow me, @milan_milanovic, and hit the 🔔 on my profile to get a notification for all my new posts.
Grow with me 🚀!
#technology #softwareengineering #devops #techworldwithmilan #book
Lost in the maze of coding principles?
Today, let's decode SOLID, DRY, KISS, YAGNI, WET, and HOLLYWOOD.
1. 𝗦𝗢𝗟𝗜𝗗 - A beacon of good design
Single Responsibility: One class, one job.
Open-Closed: Open for extension, closed for modification. Sounds like a secret society, doesn't it?
Liskov Substitution: Child classes must be substitutable for their base classes.
Interface Segregation: Clients shouldn't be forced to depend on interfaces they don't use.
Dependency Inversion: High-level modules shouldn't depend on low-level ones. Both should depend on abstractions.
2. 𝗗𝗥𝗬
Don't Repeat Yourself: If you've written it once, don't write it again. Code duplication creates more places for bugs to hide.
3. 𝗞𝗜𝗦𝗦
Keep It Simple, Stupid: Complexity is the enemy of understanding. Keep your code as simple and straightforward as possible.
4. 𝗬𝗔𝗚𝗡𝗜
You Aren't Gonna Need It: Do not add functionality until you absolutely need it. A minimalist approach to code can save time and reduce complexity.
5. 𝗪𝗘𝗧
Write Everything Twice: Contrary to DRY, WET suggests duplicating code can sometimes make sense, especially when the cost of making it reusable outweighs the benefits.
6. 𝗛𝗢𝗟𝗟𝗬𝗪𝗢𝗢𝗗 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲
Don't Call Us, We'll Call You: This principle encourages low-level components to be passive and to have high-level components decide when they need to act.
The beauty of these principles lies in their application. They serve as a compass, guiding us towards cleaner, more efficient code.
📌 𝗣.𝗦:- To learn about C# and .NET join my weekly .NET Newsletter with 𝟲𝟮𝟬𝟬+: https://t.co/TDNkmIWQEY.
Repost ♻️ to spread the knowledge
Aproveitando o PrimeDay como incentivo, pq eu queria fazer essa bagaça faz um tempo na real. Galera me pergunta muito sobre literatura em SRE / Confiabilidade. Segue uma Thread com todas as minhas recomendações.
São livros que eu realmente li / estou lendo. Então é sem migué.
Top architectural styles
In software development, architecture plays a crucial role in shaping the structure and behavior of software systems. It provides a blueprint for system design, detailing how components interact with each other to deliver specific functionality. They also offer solutions to common problems, saving time and effort and leading to more robust and maintainable systems.
However, with the vast array of architectural styles and patterns available, it can take time to discern which approach best suits a particular project or system. Aims to shed light on these concepts, helping you make informed decisions in your architectural endeavors.
To help you navigate the vast landscape of architectural styles and patterns, there is a cheat sheet that encapsulates all. This cheat sheet is a handy reference guide that you can use to quickly recall the main characteristics of each architectural style and pattern.
–
Subscribe to our weekly newsletter to get a Free System Design PDF (158 pages): https://t.co/4QcX8btXGL
a piada da "fila virtual" e sistemas resilientes
semanas atrás estava pensando sobre como usar "fila virtual" em ecommerces, sites de vendas, eventos online etc virou piada p/ muitos desenvolvedores
para alguns parece incompetência um site não aguentar uma Black Friday, mas...
Vc que é dev, ganha lá seus 15k e ja investe seu dinheiro.
Sabia que tem como vc pagar menos imposto fazendo previdencia privada?
Hj vc paga 27,5%, mas se vc botar até 12% da sua renda bruta anual num PGBL, vc pode transformar esse imposto em 10%
Ei dev,
Quando falamos sobre System Design é comum pensarmos em soluções complexas, escalas enormes, etc. Só que a maioria das empresas precisa de soluções simples.
Nessa thread, vou propor 10 desafios de System Design mais simples e triviais pra você praticar.
Segue o fio. ↓
Grow Your Technical Skills with Google for FREE
1. New to Computer Science?
https://t.co/jJ2Rv487mw
2. Foundation of Programming
https://t.co/hVgZgHxzSo
3. Data Structures & Algorithms
https://t.co/RdIRFpwgFs
{ More in the thread } 🧵👇
I've watched 1000+ Conferences Talks over the last 20 years in Tech. I used to watch one every night after dinner for years.
Below are The 22 Talks that Impacted my Career the most ➕ my main highlights from each one.
🧵🧵🧵