Last week, a lot of Babbel developers attended MicroXchg, the Microservices Conference here in Berlin.
The conference itself was really well-organized. Like really, really well. The speakers were very good, the schedule was audience-friendly (lots of longish breaks to socialize, eat and drink), and the talks were balanced between enthusiastic and down-to-earth.
This post summarizes our impressions and the learnings we returned with.
Microservices represent the Single responsibility principle applied to the architecture of a system. Sam Newman from ThoughtWorks pictured it as:
Small autonomous services that work together
That’s how complex systems should be built. Chad Fowler compared this approach to one of the most complex systems we know: Living organisms. While each cell performs a distinct job, in unison, these cells compose compose a system that is able to adapt and even repair itself, by destroying the parts that are no longer functioning as intended.
Of course, this idea is anything but new. Microservices can be seen as separation of concerns, a design principle that has been around for 40 years. Service-oriented architecture (SOA), a kind of heavy-weight predecessor to Microservices, has also been around for over 10 years.
When should you think about implementing microservices?
Microservices might help you when an architecture review yields results such as:
- features are taking too long to ship
- teams are blocking each other
- technical debt is known but not addressed
- long, complicated deployments
- replacing things is too expensive
Just to give you an idea of how bad it can be: Speakers at the conference have given examples of systems being deployed only once a month and teams having to rewrite the whole application (with millions of monthly active users) from scratch.
What are the benefits and costs of microservices?
The most important benefit microservices have to offer comes from decoupling: Instead of one monolithic application, you have several smaller apps that are easier to develop, deploy, debug, and scale. Your architecture is thus more responsive to changing requirements which aligns microservices with agile software development frameworks such as Scrum or Kanban. On a technical level, microservices enable you to explore new technologies and languages. When all you have is a single monolithic application, you are less likely to experiment because you cannot simply rewrite just part of your application. With microservices, you can do just that. (In fact, companies who have successfully introduced microservices report a more diverse production stack and tool chain because of the switch.)
On the other hand, microservices require your organization to have cross-functional feature teams. Imagine the engineering part of your organization is split into the silos of development, QA, and operations. How are you going to have teams build and run their own microservices in production if all decisions must involve other teams? This idea was popularized as Conway’s law. In a nutshell, microservices might require organizational changes. “Use Conway’s Law as an enabler”, as one speaker put it.
With a number of teams autonomously building and running services without a shared codebase, your organization will likely encounter duplication. This is a point where you have to balance pace of change and possible re-use of code.
How to get from monolith to microservices?
This is one of the big questions the conference tried to answer. Numerous companies have presented their varying degrees of success.
For companies that do not have the opportunity to start from scratch, the advice is usually to start with low-risk tasks in order to build trust. Add new features as a separate service next to your existing monolith to learn, and plan your next move according to what works and what doesn’t.
Start with bigger services. It’s easier to tear apart big services than to join small ones. (And their number will increase anyway, several speakers confirmed). Start with small services and you will get the architecture wrong, plus functionality is hard to move.
How microservices apply to Babbel
We already have some cross-functional teams at Babbel. And we are in the process of decoupling our architecture to accomodate for the growth we are experiencing. But we are not there yet.
Most speakers at the conference emphasized the need for organizational change that must precede any attempt to implement a microservices architecture within a company, and we definitely have to start with that.
We are pretty confident that the microservices architecture offers huge potential for Babbel, and we have learned a lot at the conference.
Thanks again to the organizers!
Recommended presentations
- The State of the Art of Microservices
- Measuring microservices
- From Homogenous Monolith to Radically Heterogenous Microservices Architecture
Photo by Shelbey Miller on Unsplash