by Dan Manastireanu
O'Reilly Software Architecture
Have you ever wondered what a conference dedicated to Software Architecture looks and feels like?
I was curious too, as it was the first time I attended a non-developer conference.
Join me and find out my impressions from O'Reilly Software Architecture in Berlin.
Location
The conference was held in Berlin, at the CityCube, a facility dedicated to conventions and conferences.
I arrived on Wednesday morning and went directly from the Berlin Schönefeld Airport to the location. The S9 train connection was quite good and I arrived just as people were doing their check-in.
The CityCube building has four levels, two levels with conference rooms (both medium and large), one for checkin and one for sponsor booths, and lunch area.
For some of the events, like the keynotes, two of the large conference rooms were connected together to form an even bigger room.
Overall the location was great, perfect fit for a conference, just don't expect to have anything else to do or visit in the area.
During this time, Berlin was celebrating the 30th anniversary of the fall of the Berlin Wall, and in the evening there were all sorts of events in the city center: 3D projections on buildings, concerts, etc.
As you can imagine the city was packed, and you needed a bit of luck to find a place for dinner.
Day 1 Sessions
Like most conferences, it was split into two days of workshops and two days of presentations.
I attended only the presentations, but from what I've heard some of the workshops were also interesting.
Since I can't fit two days worth of presentations into a single blog post, I will only write here about a few interesting talks.
Video recordings and slides can be found on learning.oreilly.com
Rise and fall of microservices
While people in Berlin were celebrating the fall of the Berlin Wall, we were discussing the fall of microservices.
- Wait a minute, are microservices dead?
- I thought they were the greatest thing since sliced bread.
- Are they done?
Nope. Microservices are not dead.
Long live microservices! (but use them with care)
Just because microservices are cool doesn't mean they solve every problem.
Just because they have the word micro in them doesn't mean you need to split everything in as small as possible pieces.
Yes, microservices should do one thing well, but that is not the whole story. Many factors can influence granularity: some of them encourage splitting, others encourage consolidation. You should consider all when designing a system.
| Depending on | You should |
|---|---|
| Functionality | split |
| DB transactions | consolidate |
| Data dependencies | consolidate |
| Workflow choreography | consolidate |
Most developers only look at splitting by functionality.
You should also take into consideration that distributed transactions are hard to implement and too much communication is expensive.
As with most things in life, a good architecture should reach a balance. Focusing only on one factor can break your entire system and turn it into a tangled mess.
Always remember, microservices is not the only architecture around :)
All architectures have tradeoffs.
Resources: Slides, Conference details page
Micro Frontends
Are portals back in fashion? Have we come full circle again?
Maybe...
There were quite a few presentations on this topic, as it seems to be hyped up like micro-services were when they first appeared.
I am a bit skeptical of micro-frontends, so I attended two of the presentations to see if they will change my mind. While I now understand a bit better when they make sense,I still don't think they are the right fit for the contexts I work with. My advice: before jumping on the hype bandwagon you should think hard if you have the problems they solve.
The number one problem Micro-frontends solve is team scaling.
Micro-frontends work well:
- in huge apps (100+ devs)
- with many small cross-functional teams
- that work on distinct non-overlapping parts.
If you don't tick all of the boxes above, micro-frontends are not for you (especially if you are a small team).
Benefits include:
- incremental upgrades
- independent deployment
- autonomous teams
- each team can pick own stack -> can lead to disaster
Downsides include:
- more code and duplicate dependencies
- bigger download size
- worse performance
- integration is not seamless
- keeping a consistent style is hard
If you still decide you need micro frontends, the next step will be to figure out how to integrate them.
| Solution | Details |
|---|---|
| Iframes | Simplest, but most limited solution |
| Server-side includes | Have better html integration and caching, but do nothing for js/css |
| SPA composition | Most advanced option with the best integration, at the cost of using a bootstrapping library like single-spa, Frint.js |
Communication is done by using window directly, or an event bus like Eev; except for iframes where window.postMessage must be used.
Resources: Micro-frontends: A microservice approach to the modern web, Patterns for micro-frontends
On launching a distributed system to global markets
N26 is a modern online bank (similar to Revolut).
It was founded in Germany and expanded to the EU, and most recently to the USA.
This was a very interesting presentation of challenges of a different nature than we expect when scaling a system out to a global level.
Most of us expect technical challenges, but there are other unexpected ones: cultural and legal.
For N26 legal constraints meant that US and EU data should not mix on the same servers.
The solution involved hosting in the cloud, but using different zones (EU/US) and routing based on incoming IP.
The only problem is that people travel, and that meant that at least some information (the user account) must be shared between clusters, otherwise users could not log in abroad.
After further legal review, even this was not enough, and they had to find clever ways to anonymize user emails and ids by irreversible hashes.
After another round of legal reviews, this solution was accepted, and deployed globally. Now users can use the app worldwide, and the only difference they will notice is a slight network delay as their data is brought from their home continent.
Lessons learned:
- always double-check with the legal department
- business & product decisions come before technical ones
- scaling challenges can come in all shapes and sizes: technical, cultural, legal
Resources: Conference details page
Ignite Berlin
We closed the first day with an Ignite session - a session of short presentations, back to back, 20 slides each, 15 seconds per slide.
It was an interesting way to discover many topics in a short time, and most of the presentations were very engaging and funny.
Among other things we learned about:
- using machine vision to fingerprint the ground
- Zero Trust applications, when VPN based security is not enough
- how to apply open source inside an organization
- what we can learn from children
And finally, we learned that "Everything that has a beginning has an end" and "Zombies are the worst".
Resources: Ignite Schedule
Day 2 Sessions
“Good enough” architecture
What is architecture?
Architecture can mean many things, and there are many complicated definitions for it, but at its core it is:
A property of the system as it is, not a description of its intended design.
Whatever the architect considers important enough to merit their attention.
The things that are hard to change later.
When is architecture good enough and when is it in the way?
To answer these questions we went over a list of seven real-world examples where architecture failed.
We analyzed the business context and the architectures that went wrong, and extracted some lessons learned:
- If your design attempts to satisfy everyone, you’ll likely end up satisfying no one
- Value specific over generic solutions
- Everybody wants to be Netflix, but nobody is
- Faced with too much rigidity, a way around the rules will be found
- You cannot decide to not have an architecture; if you don’t actively create it, be prepared to deal with the one that emerges
- Successful systems often end up the worst architecture
At the end of the presentation we derived a list of five things to keep in mind when designing architecture:
- Don’t be afraid of architecture
- Choose the simplest thing that will work
- Create evolvable structures
- Manage your system’s architectural evolution
- Don’t build roadblocks – create value and get out of the way
Resources: Slides, Conference details page
Scaling out architectural decision making
During this presentation we looked at scaling of a different kind, not scaling of hardware and software, but of teams and architectural decisions.
Patrick Kua took us through the steps N26 took when they went from one office to many geographically distributed offices, each with their own teams and architects.
N26 streamlined decisions by separating them into architectural and design types.
Architectural decisions are the ones that are hard to change later, or those that are across services. These should be taken with care.
Design decisions are lower level ones, about code and libraries. These are easier to change and can be delegated to the developers.
They also implemented Working Groups that are fast and efficient at solving a specific problem and an Architecture Guild that takes care of the big picture.
Since developer buy-in is important for the correct implementation of a decision, they use a system similar to w3c RFCs. This way everybody can contribute to a decision, and all decisions and the reasoning behind them are logged and preserved.
Resources: Slides, Conference detail page
Booths
Like all conferences, O'Reillys Software Architecture had a section dedicated to sponsor booths.
To encourage people to visit all the booths the organizers created a puzzle game for which you got the first 5 pieces at registration and the other 15 pieces from the different booths. People that completed the puzzle won a hoodie or a book (depending on availability).
As with most IT conferences, the regular sponsors were present: Gitlab, JetBrains, JFrog.
There were a lot of companies targetting large scale application monitoring: Instana, SignalFX, Fusion Reactor.
Oracle was marketing hard its cloud infrastructure solution, trying to catch up to Amazon/Google/Microsoft. Their demos looked good, performance-wise, and as far as I could tell their security is strong, but I'm not sure developer interest is high enough to get them back in the race.
Amongst all of the marketing pitches, I found a couple of interesting solutions that we might try in the future.
- LaunchDarkly has a nice feature flag solution that works at scale.
- here.com has a lot of location based apis, maps, and related products.
- StormForger is a good tool for running performance testing at scale.
- Contentful looks like a good CMS solution where you can define your own models, and then rely on their CDN networks for performance.
- Akamas presented an interesting platform that uses AI reinforcement learning to optimize applications from operating system settings, to JVM or Mongodb parameters.
Speed Networking
During the conference, a lot of focus was placed on networking and making connections.
Both days started with a Speed Networking session. Also some of the speakers, before starting the talk, instructed people to speak with the persons nearby.
On Wednesday I talked with a guy from Belgium working together with 25 colleagues in the IoT field, processing data from thousands of digital utilities meters.
On Thursday I met somebody from Istanbul that was working on a WhatsApp like application with 40+ million downloads in the app store.
Conclusions
My expectation was that there will be a lot of generic talks without much content and without clear real-life examples.
While that was true in 60% of the presentations, I was refreshingly wrong on the other 40%, and that made it worth it overall.
I saw real examples of architectural challenges, failures, and solutions. I saw how a full scale worldwide infrastructure looks like, and the tools that can make it happen.
What surprised me was the importance put on networking and socializing, and I realized that architecture is not something you can do alone, you need to learn from others. The lifecycle of an architecture is too long lived to do experiments on your own, and the risks are too high. More importantly, architecture is not something you can enforce, there needs to be a buy-in from developers, and it's not something fixed, that you do once, it needs to evolve.
Ratings:
- Interesting: 3/5
- Usefulness or applicability: 3/5
- Fun factor: 2/5
- Food for thought: 4/5