A Quick Recap of the 1st Vienna Seminar on the Relation of Software Architecture and DevOps / Continuous Delivery
This week, Uwe Zdun, Florian Rosenberg, and me organized the “1st Vienna Seminar on the Relation of Software Architecture and DevOps / Continuous Delivery”. The goal was to create a Dagstuhl-like, by-invitation event where we wanted to bring together academics and practitioners working somewhere in the vicinity of software architecture, cloud application development, DevOps, continuous delivery, and software experimentation. We were a bit frisky with the event date — we deliberately set the event to happen in the last week before Christmas, partly because meeting rooms at University of Vienna were easy to get at this time, partly because we hoped that most academics would be free of teaching. In the end, I was extremely happy with the turnout — we managed to attract 48 distinguished participants, about half of which were practitioners.
The seminar ran over 4 full days, alternating between half-hour keynote talks, 15-minute lightning talks, and breakout discussion sessions. Uwe and his team organized awesome social events every evening, including an invitation to a gala dinner in the city hall and a visit to one of Vienna’s famous Christmas markets. There was significant tweeting, so a good way to follow the entire event is by reviewing the #vss17 hashtag on Twitter.
Overall, our presentations and discussions seemed to circle around a few (interconnected) topics:
Software architecture, and how much of it we need in an agile, fast-moving continuous deployment projects
Maybe the most heated discussions centered around the notion of software architecture. For instance, Uwe van Heesch still sees a lot of need for and value in documentation. Other participants have argued in discussion sessions that explicit, up-front architectural planning and documentation is basically dead, especially in fast-moving DevOps / cloud computing projects. Most participants don’t really seem believe anymore in traditional top-down, UML-centric architectural planning for such projects.
The value of APIs and ecosystems
We had a set of presentations and discussions around standards, APIs, and ecosystems. Erik Wilde has observed (lamented?) that “standard” has by now become almost a dirty word in the community. There were also some interesting discussions around the upcoming PSD2 regulation, which will force European banks to provide APIs to their core services. We discussed what strategies banks fundamentally have to deal with this (provide a great API to build an ecosystem? provide a by-design horrible API to keep a walled garden around their services?).
Micro- and Nanoservices
There was fairly broad agreement that Microservices are here to stay, and fundamentally important to deliver new features reliably and fast. Eberhard Wolff pointed us to a very interesting repository of microservice examples that he is maintaining for this books. Cesare Pautasso gave a very interesting talk about one challenge with microservices, namely that it’s theoretically impossible to back them up in a way that no data inconsistencies are possible after disaster recovery. We also had some breakout discussions related to serverless computing(e.g., AWS Lambda) as one promising implementation technique for very small microservices. There was a lively debate how “new” and/or important technologies such as AWS Lambda actually are. Eberhard commented that the incredible hype in industry is at least a good indicator that there is something fundamentally relevant in the serverless movement.
Continuous integration and delivery pipelines
As far as I could tell, most participants assumed it as a given that you need a continuous integration and deployment pipeline to move fast. We had a number of different talks and discussions on CI builds, and how to set up CD pipelines. Eberhard has argued that even if you can’t release continuously due to your domain, the technical benefits of CI and CD alone are worth it for many companies. David Lebutsch mentioned that he sees security as an important driver for continuous deployment — if you have a security problem and you can’t roll out a fix quickly, you have a big problem. Bram Adams, Shane McIntosh, and others talked about CI builds, build failures, performance testing in pipelines, code reviews, and other similar topics.
A/B testing, and the limits thereof
Another focal point of the seminar was on software experimentation and A/B testing. Katja Kevic and Brendan Murphy talked about experimentation in Microsoft, and Laurie Williams reflected on a relevant Silicon Valley workshop that she has been organizing for a few years. Interestingly, a lot of discussion on the topic nowadays seems to be around when not to do it, and what the downsides and ethical challenges are. The hype certainly seems to have dampened a little bit.
Cultural issues
Finally, even though this was not the explicit topic of any presentation, there was often an undercurrent of “culture” to many of the technical discussions at the seminar. It is clear that continuous delivery and deployment are not only technical challenges, but often need to deal with team culture and organisational management. Techniques such as A/B testing interfere with how products are typically designed, and microservices as well as DevOps change how software teams operate.
Now, after the seminar is finished, it’s time for us to consider whether we want to run this back, either next or in the following year. Initial participant feedback seems to suggest that most felt the seminar was worth their time, so we are definitely open to a second iteration in the foreseeable future. Personally, I have certainly learned a lot this week!
