Software development is currently undergoing a shift: it’s no longer enough to make product increments potentially shippable — changes actually have to go live. In order to still generate innovation and new growth in saturated markets, business departments are increasingly working with Lean Startup methods. One method within Lean Startup is forming hypotheses that are then validated through tests. To do this, different variants of the software are rolled out, and it’s observed how customers react to a given change. Depending on the test result, parts of the software are then removed again or adjusted. This makes it essential to get software in front of users quickly.
Getting software into production faster isn’t easy with most software architectures. Monolithic applications are common, and they’re complicated to deploy — even small changes often require coordinating many teams. To decouple parts of the software and reduce the coordination overhead between teams, it’s often suggested that an application be broken down into small services, frequently referred to for short as a microservices architecture.
Using a concrete example, we’ll look at how an existing architecture can be transformed into a microservices architecture, and what consequences this has at the technical level. For instance, microservices lead to multiple deployment pipelines, and you need concepts for quickly provisioning different parts of the software on different machines as well. You also need to think about logging and monitoring in operations — otherwise running such a highly distributed system can quickly become a nightmare.
Slides
- slides/zuther/slides/02_bobkonf/index.html
- Source code
- https://github.com/zutherb/AppStash/
- Article in Java-Aktuell 02/2015
Retrospective (2026)
Reading this talk again a decade later, I’m struck by how much of it still holds: the coupling between business experimentation speed and architecture was real, and microservices did solve that problem — at the cost of the operational complexity I warned about, which many teams underestimated for years afterward. What I didn’t foresee was that the next big decoupling wouldn’t be service boundaries at all, but agents: autonomous AI components that negotiate, deploy, and monitor themselves with far less human coordination than even the leanest microservice team ever managed. The “logging and monitoring” problem I flagged in 2015 has only gotten harder — now you’re not just tracing requests across services, you’re tracing decisions across autonomous agents. Looking back, AppStash was a reasonable example for its time, but I’d design it very differently today, with observability and agent-driven orchestration built in from day one rather than bolted on afterward.