The journey from monolith to microservices is different for every organization. A variety of challenges come with introducing microservices itself, but also organizational circumstances impacting the transformation that needed to be considered.
In this talk Susanne would like to share some lessons learned from a microservices journey from a startup perspective - and in hindsight, what to watch out for if starting the journey again.
While microservices and containers promise to deliver endless scalability it doesn't mean we automatically get high performing code in these distributed application architectures.
After analyzing the top performance bottleneck reasons for all 2017 we saw familiar patterns such as excessive service roundtrips, bad connection pooling, missing cache layers or simply sending too much data between service tiers.
In this session Andreas will show you how to quickly pinpoint potential performance bottlenecks - even without executing large scale performance tests.
Regardless of the application architecture (monolith, microservices, or other), an application that is delivered must comply with the quality attributes (performance, scalability, maintainability, etc.).
Architectural goals and constraints may all change independently of functional expectations.
Introducing metrics and fitness functions in the continuous delivery pipeline can provide continuous feedback for architectural conformance.
Software projects often mistake organizational problems for technical issues and treat the symptoms instead of the root cause.
The main reason is that the organization that builds the system is invisible in our code. From code alone, we cannot tell if a module is a productivity bottleneck for five different teams, or whether our microservice boundaries support the way our codebase evolves or not.
This session closes that gap by taking a behavioral view of code combined with insights from social psychology to measure aspects of software development that we haven't been able to capture before. You learn how this information lets you detect modules with excess coordination needs, measure how well your architecture supports your organization, suggest and guide refactorings, as well as why Conway's law is an oversimplification. To make it specific, each point is illustrated with a case study from a real-world codebase.