Recording Venue: JAX conference, Mainz, Germany
Micro services is an emerging trend in software architecture that focuses on small, lightweight applications as a means to avoid large, unmaintainable, monolithic systems. This approach allows for individual technology stacks for each component and more resilient systems. Micro services uses well-known communication schemes such as REST but also require new technologies for the implementation. Methodologies like the Twelve-Factor App provide a set of rules for the deployment and operation of such systems. Teams take care of several of those services and deal with separate business domains to make the best use of Conway’s Law. These business domains provide a more coarse-grained software architecture.
In this episode, Stefan Tilkov discusses these new approaches as well as their benefits and drawbacks with Eberhard Wolff. Stefan is CEO and Principal Consultant at innoQ in Germany. He works as a software architect and is a well-known speaker at international conferences. More recently, he has joined Software Engineering Radio as a host.
Show Notes
Related Links
- Stefan’s timeline at the innoQ Blog: https://www.innoq.com/people/st
- The Twelve Factor App: http://12factor.net/
- Slides from one of Stefan’s talks: https://www.innoq.com/en/talks/2014/02/architektur-201x/
- Java EE architecture diagrams: http://docs.oracle.com/javaee/7/tutorial/doc/overview003.htm
- Martin Fowler on Micro Services http://martinfowler.com/articles/microservices.html
- Stefan on Pragmatic SOA: http://www.infoq.com/presentations/Pragmatic-SOA
- Martin Fowler on Micro Services and the First Law of Distributed Objects: http://martinfowler.com/articles/distributed-objects-microservices.html
- One of the projects using the suggested approach: http://qconlondon.com/london-2014/presentation/From%20Parts%20to%20a%20Whole:%20Modular%20Development%20of%20a%20Large-Scale%20e-Commerce%20Site
- Talk about the architecture at Groupon: http://qconlondon.com/london-2014/presentation/I-Tier:%20Breaking%20Up%20the%20Monolith
- Chaos Monkey and Simian Arm: https://github.com/Netflix/SimianArmy/wiki/Chaos-Monkey
- Dropwizard: http://dropwizard.github.io/dropwizard/
- Michael T. Nygard’s book Release It!: https://pragprog.com/book/mnee/release-it
- Hystrix: https://github.com/Netflix/Hystrix
- Stefan Tilkov on Twitter: @stilkov
- Stefan’s personal timeline: https://www.innoq.com/people/st
Great episode! However, the links to qcon presentations didn’t work for me. Here are valid ones: http://www.infoq.com/presentations/modular-ecommerce-website and http://vimeo.com/96250640
I listened this podcast with great interest, since microservices became a hot topic this year – 2014.
To be very short, in my opinion, Mr. Tilkov advocates a wrong approach in regards to tying the UI component to its 1:1 backend correspondence. This can easily lead to: 1) loosing the reusability of some components, since they don’t serve a generic purpose anymore and not driving the development towards that direction, rather ending up with a concise implementation for the sole purpose of serving a UI; 2) limit the interaction between services and forcing you to use some sort of backend state-persistence to share a session among multiple subsystems, far more than what SSO requires; 3) you even loose the reusability of the UI, having multiple independent UIs, you end up maintaining each of them separately.
The strongest example that I can offer to showcase my argument is Google’s gmail web client.
Here are some of the key aspects of this architectural approach that made Gmail a successful product and a great piece of software engineering. I will leave aside the complexity of this application, but lean towards some generic architectural lines.
1. Totally decoupled from backend, using async http calls to retrieve data;
2. It’s using different backend services by integrating them in a coherent one-page-application (I will come back to this aspect later on);
3. It makes its frontend components play nice together, even though they originate from different backend services (take the example of chat-email integration);
4. Each component can evolve separately and still be able to maintain the contract with the other.
Now talking about the one-page-application, Google sees this as a architectural policy, this is also the reason for backing the Angular project. The great advantage of this design is that it mitigates the page transition times by partial rendering. This is not possible in a non-microservices architecture.
Keep in mind that this is a 10+ years product that didn’t change much from its initial lines of architecture and turned out they were right.
Other than that, the interview was nice. Keep doing this great job!
Alexandru, Not sure I agree with you. I don’t think Stefan is arguing against a Micoservices architecture. He’s just saying that you shouldn’t restrict the ideas of the Microservices architecture to just the backend. Maybe Stefan said it in the podcast or I heard it somewhere else but traditionally we have undervalued our investment in the UI and the complexity of the UI. I’ve seen many applications built with monolithic UIs talking to monolithic backends. Just focusing on moving the backend to a microservices architecture is not sufficient. We need to get better at building integrated user experiences using similar decoupling ideas to that being proposed for microservices, where different areas of the the integrated user interface could be coming from decoupled “applications” too. In the scheme of things Gmail is a relatively small app.
[…] Show Notes: http://www.se-radio.net/2014/09/episode-210-stefan-tilkov-on-architecture-and-micro-services/ […]
[…] Episode 210: Stefan Tilkov on Architecture and Micro Services […]