O’Reilly Software Architecture Conference 2020: A Young Engineer’s Review
Katas, Microservices, and Reactive Streams: a Buzzword Oasis
In 2015 O’Reilly started their Software Architecture Conference. Five years later, I attended the 2020 O’Reilly Software Architecture Conference in New York City. What follows is a summary of the two day training, a summary of my favorite talks, and miscellaneous thoughts. This was my first endeavor into formal software architecture so I approached this with a fresh mind.
Training
I signed up for the Fundamentals of Software Architecture training by Mark Richards. It seemed like the best fit for my interests since I wasn’t looking for tooling-oriented training. The fundamentals were a good fit for a young engineer like myself. The training was based on Mark’s new book, Fundamentals of Software Architecture, so you can read it for yourself if you want to learn more.
When the training started I was a little leery. It seemed like this might be a training session full of fluff and a smooth talking consultant. That was not the case. Mark quickly dove into the content and started asking questions that helped break down popular assumptions. One such belief is that architects set rules for everyone to follow and lay out some grand plan for the organization. However, an architect is in a more collaborative role. They might set some rules but they also create guidelines and work with engineers and business folks to discover and prioritize system attributes, or ilities as they may be called.
A key theme of the training is that everything is a tradeoff. People are quick to espouse the benefits of a new technology but there is always a tradeoff to using that new technology. The tradeoff is not always easy to find. One way to help find them is through the lens of quality attributes (aka nonfunctional requirements). These attributes should always be determined in collaboration with the business stakeholders.
The training suggested these steps to discover attributes with stakeholders:
- Show stakeholders a list of attributes
- Ask them to pick the the ones they’d like to see in their system
- Ask them to pick seven that are important
- Ask them to pick three of those seven that should be the highest priority*
*Asking them to rank them would be a fool’s errand. So don’t.
The difference between these attributes may be unclear at first. For example, is elasticity or scalability more important for a live sports streaming service? Like everything, it depends. But understanding the difference between scalability (the ability to easily add more capacity as user base grows) and elasticity (the ability to handle very spiky traffic) is important. As such, it’s necessary to examine these attributes through the lens of architecture.
Throughout the training we engaged in architecture katas. The katas brought the room to life and gave everyone a chance to practice what we learned. They were difficult but a lot of fun and gave us a chance to get to know each other.
Occasionally, we discussed tooling specific to architects. Archunit was the most novel to me. It is a testing library to enforce architecture decisions at a code level. You could create a test to check if the presentation layer is directly calling the persistence layer and, in combination with other CI/CD tools, prevent merging when the test fails.
As an architect, you should focus on expanding your breadth of knowledge or, knowing what you don’t know. The training suggested that it’s more important to know about a lot of technologies and their general overview than to know a lot about a few technologies. If you know one technology really well, you’ll see it as the solution to many problems. If you know many technologies at a high level you’ll know what tools to evaluate to help make the right decision.
Free resources to help expand your breadth of tech knowledge:
- https://www.infoq.com — Covers many tech trends and even has an architecture specific section
- https://dzone.com/refcardz — Refcardz provides concise summaries of technology topics
- https://www.thoughtworks.com/radar — Published twice a year. Predicts and discusses upcoming trends
Expanding your knowledge base is critical for an architect. If you think you don’t have enough time for reading these then try reframing if by replacing every “I don’t have time” with “it’s not a priority.” If you decide it is a priority, you could put that in place by spending 20 minutes each morning to see what’s happening in the tech world before you dig into your email.
We also covered architecture certifications. Even if paying for the certificate isn’t worth it to you, filling out the certification application will show you where there are gaps in your skills and experience. The most widely accepted certifications in the field are from The Open Group and the Enterprise Architecture Center of Excellence.
The second half of the training focused on the nuts and bolts of architecture patterns. We covered the following architectures: layered monolith, microkernel, microservices, service-oriented, event-driven (including mediator and broker topologies), and space-based. We spent time examining the fallacies of distributed computing.
The final topic was communicating decisions. They recommend using Architecture Decision Records, which are kind of like changelogs with reasoning but for high level implementation details.
Talks
The two days of training were followed by two days of talks. Some were just okay and others expanded my understanding of architecture. The not-so-good ones were either too generic or not closely related to architecture. They would be a better fit for a more general software conference.
My favorite talks:
Technical Debt: A Master Class
r0ml Lefkowitz | slides | description
He gave an overview of the history of technical debt, explained why it’s hard to grasp (hint: it’s not something you pay back), and argued that technical debt primarily comes from dependencies.
Maturing an Agile organization with intentional architecture
Nimisha Asthagiri (edX) | slides | description
She primarily talked about how edX has tried to get architects and developers to collaborate. On the surface it isn’t an interesting topic but she gave very concrete examples such as hosting architecture lunches with and without topics and different ways of organizing their “architecture guild” that failed and are still in trial.
Where do great architectures come from?
Mary Poppendieck (Lean Software Development Series) | slides | description
Mary started working at Bell Labs over half a century ago. She started off working on a phone system with redundancy and localization. Years later Google faced similar problems with redundancy at a hardware level. Today we’re going through the cycle again with AI and smart homes.
I don’t understand micro-frontends
Luca Mezzalira (DAZN) | slides | description
Micro-frontends are new to me and this was a good overview. The idea is to adapt Domain Driven Design to the frontend. Instead of having a huge front-end and forcing all the teams to use the same tools, you can create independent frontends. This enables faster deployment of changes and more flexibility for teams. How do you share headers/footers when following this pattern? Luca’s team did analysis and found that those components only changed a few times in the past several years so they decided to copy the code into each (of about 5) frontends instead of complicating matters with a shared code library.
Challenges to internationalize the largest digital bank in the world
Luiz Hespanha (Nubank), Lucas Cavalcanti (Nubank) | slides | description
This was one of the most concrete talks of the conference. They told the story of the Nubank architecture from providing a frontend for an outsourced credit card processor to deploying customized Kubernetes clusters across the world.
Miscellaneous Thoughts
- The organizers talked a lot about networking at this conference and how valuable it is. Do architects collaborate across organizations? I’m curious how this value manifests to architects.
- In the middle of the keynote they stopped for two minutes and asked everyone to talk to their neighbors. I loved this.
- I met great people and talked about mainframes, security tooling, and zhong tai. But it was not easy to choose who to strike up a conversation with.
- For a company that is supposed to showcase the latest and greatest in tech, O’Reilly’s events app is pretty rough 😬
- They sent a lot of emails reminding people to charge their devices before the event. It must have worked because there weren’t many chargers around but the ones I saw were usually available.
- Some tables at lunch displayed table topics such as what’s next?, what do you want to change in your organization?, and gRPC. The topic cards were a nice indicator of who people wanted to talk at lunch.
- There was also a talk that mentioned reactive streams, which is basically a way to give your processor the ability to control the amount of data coming from the source. This was a new idea for me.
All in all, I really enjoyed the conference and got a lot out of it. For the price, I don’t think I could recommend it to anyone who was footing the bill themselves. If your company is willing to pay for it (thanks NYT) then you should go for it. Thanks for reading and best of luck with your software architecture journey.
