From January 2015, she started to practice leetcode questions; she trains herself to stay focus, develops "muscle" memory when she practices those questions one by one.
2015年初, Julia开始参与做Leetcode, 开通自己第一个博客. 刷Leet code的题目, 她看了很多的代码, 每个人那学一点, 也开通Github, 发表自己的代码, 尝试写自己的一些体会.
She learns from her favorite sports – tennis, 10,000 serves practice builds up good memory for a great serve. Just keep going.
Hard work beats talent when talent fails to work hard.
Thursday, October 15, 2020
System design: Microservice - 10 Tips for failing badly at Microservices by David Schmitz
Microservices are just a bunch hip new framework plus some AngularJS frontend or React, right?
So, if you want to make sure that you absolutely and definitely fail at your Microservice project, then watch this talk and learn how.
Using real world experience from multiple green field and brown field projects, I can show you:
- how to ignore the mandatory organizational impact
- how to focus on the code only without any regard towards ops and testing
- continuous deployment is for losers. Real projects use their meat cloud for delivery
- jumping onto every new and untested framework is a must
- Event Sourcing and CQRS are both free lunches. So, you can add complexity without any real need
- ...and more
If you mind my tips, then surely you will fail at Microservices and your boss will never again try to move away from your beloved vintage monolith.
Pricinpal architect at Senacor Technologies with a history of + 13 years of working in various projects using a bunch of different stacks and environments.
Current focus is on migrating architectures and organizations, such that our customers can cope with the challenges of the digital age.
10) Tooling - Prefer one well-established tech stack. Too many tools often result in unintended complexity across the board.
9) Data Ownership - Prefer separate databases or schemas for each micro-service to keep clear table ownership.
8) Event Sourcing - Research whether you actually need it and design carefully.
7) Coupling - Beware dependency versions and shared libraries (especially in-house ones). Microservices are often more coupled than we realize.
6) Automation - Use CI/CD and automate your processes. Keep in mind that everything "hand-crafted" complicates your infrastructure.
5) Failure - Design for failure. It's a distributed, networked environment. And, again, avoid making a highly coupled microservice monolith monstrosity that fails simultaneously
.4) FE Responsibilities - Have clear responsibilities. Associate certain frontend pages with certain APIs so that you know what microservice is responsible when something fails.
3) Tooling - Having a few well-defined tools is a virtue; but, remain open to clearly better tools. Let teams use what works best on their project.
2) Design - Model your services around the company's domain and make sure management is aware of the high-level architecture.
1) Communication - Communication between teams is a must. Have someone that understands how everything works together and what different teams are responsible for.