Learning from Giants #0
Micro-service architecture, becoming an organizational leader, and more.
đ Hi, this is Mathias with your weekly drop of the 1% best, most actionable, and timeless resources to grow as an engineering or product leader. Handpicked from the best authors and companies.
Did a friend forward this to you? Subscribe to get these weekly drops directly in your inbox. Read the archive for even more great content. Also: I share these articles daily on LinkedIn.
Domain-Oriented Microservice Architecture at Uber
âFor organizations that have already adopted a microservice architecture there is no turning back. It becomes a case of âcanât live with them, canât live without them.â
We read stories like this daily. But I believe there is a huge selection bias. Companies that do not do microservices are less likely to have an engineering blog to talk about it.
When your team and codebase grow, you will need a structural way of separating concerns.
âArchitecturally, microservice architectures force you to ask the question âwhy does this service exist?â more clearly defining the roles of different components.â
People refer to DDD, SOA, and Clean Architecture as if they were a bible on this topic. I am not saying these are wrong, but we should never follow them blindly. Instead, we should try to understand where they come from, what problems they solve, and how they are applied in the best software companies.
đ Uberâs Introducing Domain-Oriented Microservice Architecture is my go-to article in that area. Adam Gluck explains why microservices are hard, Uberâs microservice history, and what their latest iteration in 2020 looked like. The article offers a well-written description of the architecture and concepts they defined, along with high-quality examples.
If youâre a start-up, donât have 2000 microservices, and wonder how it applies to you, I promise this read will be worth your time.
PS: Of course, there are examples of good monolithic companies. But their monolith would often represent a âdomainâ at Uber's scale.
Growing from a Team Lead to an Organizational Leader at Square
Itâs Friday, so you might be reflecting on your week and asking what impact you had.
Youâre a few years into your software engineering career and are one of the best leads of your team.
"Ultimately, you are responsible for your personal growth. Learning opportunities might depend on projects and teams, but itâs crucial to acknowledge that you are the driving force behind what you want to learn next.â
How can you grow from a team leader to an organizational leader as an individual contributor?
"Before looking to the next level,[âŠ] self-reflect and assess where you are right now, look at the ladder [âŠ] and see where you are currently meeting, or not meeting expectations."
đ Because career ladders are not usually extensive enough, Michael Ortali wrote Square Engineeringâs Becoming an Organizational Leader to detail what it takes to out-grow the team lead position as an individual contributor. He also lists questions you should ask to identify opportunities for impact inside your company.
Random question picks:
Are there gaps in your software that will block future integrations? Are your team APIs explicit and simple enough? Are they returning good error messages?
Are your frameworks enabling you to build robust solutions on top of a given technology? What are some of the missing elements?
For the current application architecture, are there areas that require more investment than others for the team to continue to operate
Do you know when your services will scale-out (for instance, exceed storage capacity)? When should the team address it?
Are you able to mentor other engineers to understand how to address concerns and reach a consensus?
PS: If youâre on the other side of the table and are an engineering director looking for resources around ladders, you should read Squareâs. I will share some more resources in a later post.
See you next week!