What we learned by attending a major Software Architecture conference
Software architecture is the foundation of the applications we develop. Design choices in the architecture influence the scalability, maintainability and overall costs of running a software application. Not only that, but architectural choices at the start of the project can be very hard and expensive to change later on. Therefore, it is important to stay on top of our game when it comes to software architecture! That’s why we were present at the O’Reilly software architecture conference in London last month. In this article we’ll share our experiences with you.
Our high expectations
Personally, I am always a bit sceptical when it comes down to conferences. What you might learn is highly dependent on the program and the invited speakers. Thankfully, O’Reilly has a huge network and frequently invites leading experts. As a result, their conferences are top-notch and therefore we were expecting to learn a lot. Spoiler: the conference didn’t disappoint.
Apart from a lot of flat craft beer in pint glasses and English breakfasts, we hoped to learn a lot about a few hot topics in tech. Of course, Microservices have been all the hype the past couple of years, but the toolsets to actually support such an architecture were lacking. We were curious if there have been any big advances in this field to make it worthwhile for our clients’ projects: future and past. Talking about our projects, the conference hosted talks about API design and domain-driven development, which would be immediately useful for the projects we work on. With speakers from companies like Google and Fender, it would also be interesting to hear what kind of problems these bigger companies run into. And more importantly, how these big companies solve them.
Microservices: the next big thing?
The biggest topic by far addressed at the conference was Microservices. It was especially good to learn that the whole subject has matured significantly during the past few years. Deploying and maintaining a microservice architecture is much more manageable using tools such as Kubernetes. Tools such as Istio address issues such as observability and security. These tools greatly reduce the risk of using a microservice architecture. They bring scalable and possibly cheaper-to-maintain solutions closer to implementation in our clients’ projects.
The art of microservice maintenance
A significant portion of the costs of a software project lies in running the actual software. Virtual private servers hosted by providers such as Amazon Web Services run continuously and cost more money the bigger the virtual hardware. Implementing services serverless, for instance via AWS Lambda, means you actually pay for usage as the service only exists when it’s actually used. This might dramatically decrease maintenance costs for correctly architected projects. Insights given during the conference warrant further investigation by us!
Domain-driven design
Talks about domain-driven design not only gave insights into how to design the architecture of a system. It also gave us extra tools to sync with our clients; holding Event Storming sessions could help us identify the specific domains and functionalities within these domains for all involved stakeholders. More importantly, it helps us define a ubiquitous language everyone involved with the project speaks, from stakeholder to back-ender. That way, everyone speaks the same language and, for example, sales stakeholders know what the techies are talking about, avoiding miscommunication and wrong implementations because of misinterpretation.
The tip of the iceberg
All these learnings are just the tip of the iceberg: we haven’t even addressed API design and versioning, data-driven reliability, the inherent UX problems within microservice architecture, migrating to microservices, common pitfalls and much much more yet! Keep an eye out for more posts about all these specific subjects in the near future. All in all, attending the conference was a resounding success!
