Software Architecture Conference Notes

16-18 October 2017, London

Day 1

Architect as a Storyteller 

  • Architects are elevators going from engine room to penthouse
  • Don’t try to create another dry document, focus on story telling
  • Architects are the institutional memories of companies 
  • Architecting is hard 
  • Architects decide which JavaScript library we will regret 6 months later
  • We are agile, we don’t need an architect…. 6 months later, 4 different UI frameworks found in codebase. Every agile team decides on Architecture or at least someone in the team does. So Architects are the technical decision makers that have to convince everyone in the business for the right solution 

Practical Examples of Serverless Architecture 

  • Next 10 Years of web development is more likely to be all functions as service
  • We live in a world of abstractions. FaaS is an abstraction of servers
  • Conversational UI belongs to web 
  • IOT and Conversational UIs are best with FaaS
  • This moves organisations up to value chain so you get benefits of someone else’s expertise on scale
  • FaaS couples your code to 3rd party Backend as Services
  • Application of FaaS can go beyond and cover a lot of accessibility features 
  • Logins can be a greater application of FaaS because users don’t login to0 frequently 
  • If your function needs to run 24/7 then Serverless is not for you
  • FaaS is all about speeding up the development/developer and not really about speeding up the Platform
  • AWS Lambda works best with JS so that if you run your function less then 100ms, it becomes totally free. Other languages can take time while spinning up the function even without running it esp Java.

Reactive Frontend Architectures

  • Moving from Imperative to Reactive means more stable states and immutability 
  • Reactive programming can be mixed with functional or imperative programming 
  • Mainly reacting to events
  • Flux is the latest lean architecture that covers most of the latest business needs esp. covering  constant chang
  • Flux means unidirectional flow of data
  • You can achieve the smallest architecture that can be scaled easily with a lot of components and a massive architecture 
  • Communicate between components only using observables
  • Strong separation of concerns

Building Microservices Using .Net Core

  • some microservices are restful but not all restful services are microservice
  • We should be expert on our business model and domain and not security, logging, storage etc. Let experts do what they do best on these non functional layers
  • If your service is buggy or broken none of the other layers can save you and fix it. They can detect but can not fix 
  • Protocol buffers can be used to achieve good distribution (gdrc specs)

Complex event flows in distrusted systems 

  • event driven architectures rely on immutable facts which happened in the past
  • Sender and receiver doesn’t know each other
  • Every event receiver should create a command by transforming the even. This will make sure you have enough flexibility in your flow
  • Commands are your intents where events are facts
  • You need to have a state managed by state machines rather then muting the data I.e. order status
  • State machine can handle timeouts, retry, compensations etc
  • An entity service can own the flow as specification. Like order service knows the whole flow but not individual micro services about how an order is processed

Balancing social technical complexity in software architecture 

  • most of the challenges in architecture is just communication 
  • It is not easy to change mindset of people the level of speed you want to change your architecture. It is all about feedbacks and questions flow.
  • Often technical issues are consequences of organisational problems. So technical and social balance is important for the success of the software project 
  • Communication: It is the artefact of your ideas. It is not that different from code
  • Value Congruence: if things are not aligned in values then the success will never come. Predictability and Trust should complete the loop when we share a lot of information and knowledge during software project. This also closes the gap between designed and implemented architecture.
  • Conway’s Law: Any organisation that designs a system will produce a design whose structure is a copy of the organisation’s communication structure.
  • Sunk Cost Fallacy: It is like keep watching a movie even if it is really terrible after first hour because you spent already an hour and can not switch off type of feeling…. This is something most of the projects happen to be. The feeling of wasting already time spent for something not working and keep doing it in the hope of finishing good. However, movie was really bad and will be bad so don’t keep watching it.

Day 2

How to break rules 

  • Technology can bring benefit if and only if it reduces limitations : Eliyahu Goldratt
  • If don’t understand the benefit of diminishing limitations then the new tech is no really what we look for
  • What rules enabled us the limitations 
  • What new rules we need to apply to get the new tech limitations 
  • If a new tech reduces a calculation from a week to a overnight then this is your limitation and rule 
  • If you want to enable a new tech then it has to break the existing rule, limitations
  • Trunk based development is the only ultimate solution but the hardest one
  • What is the power of this new tech? How can we exploit it to make good or bad
  • Recognise the limitation of the new tech will diminish so prove if it is your problem 
  • Identify existing rules to manage limitations
  • Identify and implement new rules
  • New tech can be a thread to some people already accustomed to existing rules

Planning Ahead For Persistent Memory

  • This is a new tech coming from Intel
  • Intel believes this is a new revolution for the storage
  • This could be not only used in cloud but also some autonomous cars, drones, medicines etc
  • It is not like DRAM or SSD
  • It is a 3rd tier of storage between memory (ram) and storage (ssd)
  • You can write to a persistent memory from network without touching CPU
  • We don’t need to rewrite the whole application as Microsoft implemented a backward compatible API in windows. I’m not sure when it will be available in Azure

  • running all on Azure and F#!!!
  • Uses DDD and event driven architecture 
  • Events occur when there is a change in system. Some components aysnc take action. Source doesn’t know the receiver at all.
  • Event Sourcing: Store state of the system as sequence of events. Enabled rolling back in time. 
  • Different apps can consume the same events but create a different view. Saving event could trigger a state change

Mysteries of Distributed Systems

  • Each microservice handles its own authorisation. Requires all teams to think about authorisation systems. Introduced a lot of boilerplate code for audit etc. Requires rigorous standardisation 
  • Authorisation middleware at the edge resolves above issues. However, it must scale to highest scale system. Introduces a lot of monolith practices. So overcome these issues, expert or allowed systems were skipping this layer but still it is single failure of point
  • The ideal goal is having one team expert on user authorisation 
  • Services owning entities should be able display it
  • Services should not go to owner of data
  • Instead authorisation rules stored as data
  • It is also distributed using the existing event system

Evolutionary Architecture

  • There is no definition of software architecture to support change
  • As we do changes in architecture it should not degrade the -ility of given fitness function 
  • How we can support ecosystem change? We have testing pyramid for business requirements change
  • How are we going to have a long term plan while everything is changing?
  • Support guided incremental change across multiple dimensions 
  • Guided: Fitness Function: lets you measure if you are close enough to your goal. 
  • Incremental: how you deploy things without creating regression. How do you make sure these Function fitness applied by Devs
  • Multiple dimensions: 
  • Fitness function : guided change: 
  • Runs agains a single context / atomic
  • Runs agains a shared context / holistic
  • Runs based on an event / triggered
  • Runs always / continous 
  • Fixed result / static result
  • Dynamic result / rely on shifting base context (more users can degrade system)
  • Monitor also routing between services to remove unnecessary services
  • Cyclic dependency will harm the architecture so it will degrade some of the fitness function 
  • Identify dimensions affected by evolution
  • Define fitness functions on each dimension 
  • Use deployment pipeline to automate fitness functions 
  • Hypothesis and data driven development so that you can evolve and change the existing complex systems 

Serverless in production

  • be small
  • Be fast
  • Have zero downtime 
  • Loosely coupled through messaging 
  • 95% cost saving can be achieved
  • Run e2e to validate the integrity of your function in your system 

Published by

What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.