This year I’ve had the pleasure to visit the Software Design & Development (SDD) conference in London. In this blog I will be posting some of my takeaways from the sessions I’ve attended.
Saving the world, one application at a time
In the keynote Andrew Clymer and Richard Blewett emphasised that we, as people, focus a lot on reducing our energy consumption. We isolate our homes, we start to drive electric vehicles, we pick new dishwashers and TVs based on high energy efficiency, but how about our field of work?
As software engineers we should be aware about the impact we have on the climate and we should focus on what we can do to reduce our footprint. We’ve already invented quite some energy consuming concepts like cryptocurrencies and AI, and business are now wondering: “We need to jump on AI or we lose our competitive edge.” But does everything need to be powered by AI?
Cloud computing
How about cloud computing? According to the Green Software Foundation : “The cloud already emits more global GHG emissions than the commercial airline industry, surpassing emissions of over 22.2 million flights annually.”. But what can we do?
Well, we could for example schedule heavy computational operations or training AI models during times when energy is generated by renewable sources. If the operation can’t wait, you can even deploy it into another region where there is renewable energy generated at that time. We can use APIs like WattTime to give us real-time information about electric grids around the world.
Website optimisation
If you have a website with 10 daily user you won’t make as much of an impact, however this doesn’t mean you shouldn’t take this into consideration. But lets say you have 10.000 or even 100.000+ daily users. How optimised is your website? Have you ever measured it? Websites like Website Carbon Calculator can give you a broad idea of how you score compared to others.
Videos and images take up most of the page weight, which is the overall size of a particular page served over a request. How can we optimise this? Well, here are a few tips:
- Start with using better compression formats for delivery of those images. The WebP image format reduces images by 26% for PNGs and by 25-34% for JPEGs. It’s supported by most browsers , except IE…
- Choose the right size for the right device using media queries in your CSS, or with the
<picture>HTML element. There is no point in serving too big images that are reduced in size afterwards - You can use SVGs instead of a JPEG or PNG for icons
- Lazy load images as they come into focus, instead of sending everything at once
- Consider if videos really need to be auto played when the page is loaded
- Do not overuse dynamic content generation but rather focus on serving static pages as much as possible
Some require a bit more effort, yet most of these are easy to implement and have a considerable impact on the amount of data that is sent over the wire.
Cloud storage
It turns out that 1 GB of cloud storage uses 7 KwH per year, which is the same amount of energy as frying chips for an hour. That is a lot of chips, how is that possible?
Well the server hosting your data is always on, it requires cooling, it has to be available 24/7 in multiple regions. Typically it has 3 times (or even more) redundancy built in and that is without counting all the network traffic to move that data. Most of the things we store (personally) we don’t even need (anymore) so clean it up where you can, or move it to local, unplugged storage. Imagine the amount of chips that we can fry…
Unfortunately there is no one big thing we can do, but by doing these smaller improvements and being aware about how much we actually produce we can definitely make a difference. Some of these practices you already implement into your workflow, and some require some more planning and thought, some might even reduce operational or development cost, so use energy wisely and responsibly.
Understanding the structure of a system
Anyone who has ever spoken to an architect, read a book or listened to a podcast about architecture must have heard the famous answer to everything: “It depends”. You probably also have heard the counter-question: “It depends on what?”.
The fact is, they are both valid and accurate in the way that they describe software architectures. Just like software patterns, there is no silver bullet to all the problems. Otherwise everyone would be creating highly performant, highly scalable, highly-everything architectures. Each architecture is (hopefully) derived from a set of trade-offs, which might even be the least worst option.
Expectations of an architect
In his workshops and talks, Neal Ford layed out some of the expectations that fit the role of an architect. Although this role is widely used in many different contexts and organizations, they share common behaviours and functions. This is definitely not an exhaustive list, but can give you a broad idea:
- Define architectural decisions and design principles to guide technology decisions
- Ensure compliance with the architecture and govern what you build
- Continually analyse the current technology and industry trends, and recommend solutions for improvements
- Have experience with and be exposed to multiple and diverse technologies, platforms and environments
- Have a certain level of interpersonal skills
- Understand the political climate of the enterprise and be able to navigate the politics
Try to put yourself in as many situations where you are not accustomed to, which will allow you to gather new experiences and become better at objective trade-off analysis
Defining an architecture
Before you can create solutions you first have to understand what boundaries you are working with. By defining architecture characteristics you can get a better understanding of the goals that your system need to achieve. So what are these architecture characteristics?
Well, any word that ends with "-ility"
, scalability, agility, maintainability, reusability, stability, and so on. You can even come up with your own! Pick a word, postfix it with “-ility” and you are good to go.
Jokes aside, the key here is that you have to translate ‘business talk’ into those characteristics. Architectural characteristics specify non-domain design considerations and influence structural aspects of the design.
For example, if a quick time to market is key to business success you probably need to come up with an architecture that has a certain level of feasibility, agility and simplicity while scalability and testability might be of lesser importance. This can impact the architecture you decide to choose. Perhaps a simple layered architecture will do the job (for now).
Be aware that this does not mean this architectural style is a one time decision. Those characteristics might change over time, and so does your architecture. It also does not mean that you can pick any combination of characteristics. Remember, everything has trade-offs. Some characteristics are entangled with each others. If you increase the securability you are probably going to have less performance and reduce simplicity.
Choosing an architecture style
Once you have an idea of which characteristics are important, you can start thinking about what components you need. This is where sessions like event storming can be helpful. At this point you want to model workflows and not entities so that you can identify core components and assign user stories to them. This allows you to analyse the roles and responsibilities these components require and which characteristics map to those components. You might learn that the administrative side of your app does not need the same degree of scalability and reliability as the consumer side of it.
At this point you should have a broad idea of which characteristics and components are needed. Based on this information we can choose a style that fits our problem domain. Can it be a monolith, or does it have to be distributed? What kind of patterns do I need to implement to make sure component x is compliant to characteristic y. There can be a range of different choices. This however deserves an article of its own.
Analysing and measuring your architecture
When you’ve decided upon an architecture you most likely want to measure it in one way, or another. If you don’t, how do you know you are building it right or how do you detect if things are changing?
It’s not easy and you are going to need to think about what is important and how you measure it. It is possible that there are no tools readily available and you have to build some sort of program or script yourself to aggregate this data.
There are also several architectural levels you can govern and measure. Each has its own different set of tools. For example, a fairly simple one are tools like ArchUnit to validate if teams adhere to an agreed code structure. However, you might want to periodically do a risk storming session to identify if there are any particular areas that have degraded or require rethinking or hardening. In an modular monolith you could validate the afferent and efferent coupling of your system. Or perhaps you measure certain thresholds to see if performance and start-up times are degrading over time.
There are a thousand and one ways to analyse and gather metrics. The main goal is to gather the metrics that matter and define fitness functions , because architectures degrade. Just like any physical structure it most of the time does not collapse instantly. After a longer period of time small cracks appear and the structure needs renovation. This same thing applies to software architecture. Small changes will result in to degradation of the system over time and by having manual or preferably automatic metrics we can get an idea of how the system performs.
Bonus takeaways
There were many more sessions with interesting content and excellent speakers. Unfortunately I can’t write about it all. So here are seven extra things I definitely learned from the conference in no particular order.
- Any kind of complexity is gonna work against us, keep it simple, you are not netflix!
- Identify the characteristics in your domain and define your architecture based on those characteristics
- Create and use an ubiquitous language around your teams and organisation, communication is key
- Create awareness about the energy you produce and consume in your applications, small improvements add up quickly
- Coherency across your system is good, but remember there is no silver bullet, so standardising 2 or 3 designs allow development teams to solve their problems appropriately
- Software architecture is not a linear, one time process. You will discover flaws and business changes, so your architecture has to change with it
- We can’t improve what we don’t measure, but don’t measure things that we do not want to improve