Today was the first day of the Microxchg 2016 conference in Berlin, Germany. More than 250 people from all around Europe gathered to learn and discuss about microservices, where and how to be used and their future.
Rodrigue Schaefer from Zalando, a leading fashion technology company in Europe with over 10,000 employees, 1000 of them in technology, spoke about their transition from a monolithic application to microservices. Trusting the developers is key to the transition. AWS for provisioning, Docker for deployment and Appdynamics and Zmon for monitoring are the tools of preference.
Developers get end to end responsibility from devops to QA to deployment. Each team must act as a SaaS to the other teams, delivering a service, even if it is purely internal. And API first means that all 70 different teams must align on API rules.
In contrast to that, the next speech by Susanne Kaiser, CTO of Just Software AG covered the startup perspective of this transition. In the startup world and in her opinion, a company trying to validate the initial hypothesis can start with a monolithic architecture, only to be evolved as it validates it and grows. In their experience, loose coupling between services but high cohesion within a service is key. Another key takeaway is that one shouldn’t violate DRY within a microservice, but should be relaxed about violating DRY across all services.
Rick Buskens of Google came up next, talking about Spinnaker. Spinnaker helps codify the process of reliably deploying artifacts to the cloud, leveraging industry best practices out-of-the-box. Spinnaker grew out of Netflix and now Google is helping advancing it. Spinnaker is available on Github and looking for contributors.
A controversial talk by Florian Thiel argued why microservices are not worth it. Namely, application performance, complexity and development velocity are the tradeoffs that a team must make if they want to try microservices architecture. Ultimately, a team must spend a lot of time to make microservices secure, testing is challenging and ultimately business and user experience will determine the requirements for application consistency. Contract based testing can help with the development velocity, replacing integration tests with contracts between services.
Finally, in one of the richest and most dense presentations of the day, Uwe Friedrichsen explained real-world consistency, giving some scary reminders of what can and will go wrong in production database systems. The key take away being to reason about distributed application consistency at the level of application operations, Uwe recommends that teams should thoroughly analyze storage and consistency requirements. Shouldn’t relax consistency requirements without a real reason. Shouldn’t try things like distributed transactions across microservices. Overall, should have developers in mind.
In the not so far future, Big Data datasets will fit into Terabyte memory servers, whereas storage class memory and non volatile memory will bring very low latency remote memory access, allowing for new use cases. Keeping the CPU busy will no longer be the core challenge and with lots of options to balance consistency constraints and intricacy of the programming model systems will be more balanced than today.
All presentations are available on microxchg's channel on Youtube.