Software Architecture

From MyInfoRepo
Jump to navigation Jump to search

Topics covered by this course are: fundamentals of software architectures, modeling and designing software architectures, architectural patterns and styles, architecture viewpoints and perspectives, the role of the software architect, analyzing and evaluating software architectures, component and plug-in frameworks, software product lines, service oriented architectures, code quality, technical debt, refactoring.

Software Architect: what is it

suggested vid: https://www.youtube.com/watch?v=Zq2VcRZmz78

..

We look at the responsibilities of architects, to see how they should operate. Architects carry overall responsibility for all technical decisions in an organization. They will lead the organization to take the right decisions, this includes a responsibility to communicate well with people inside the organization. It is a leadership role, beside the technical role, they have to be able to take action when needed and keep processes organized. Architects should also see when a decision has to be held off and taken at a more appropriate time.

Consequently, architects have to posses the skills to solve hard problems to see where the biggest complications are. They should promote good practice in their field, to make sure the team produces quality output. The impact of decisions should be well understood by the architect before one is made. After it was made, they should be able to defend the design decision and make sure any releases contains the appropriate update. The architect should have technical skill, to know and understand relevant technology. One should be able to evaluate and influence the choice of 3rd party frameworks.

Architects are also quite important in business impact, they should know impacts of decisions. It used to be that problem domains were mapped to solution domains, which tends a bit to the waterfall approach. It may be better to look at capabilities of the software and turn those toward new business opportunities. They should be able to translate technical risk into business risk, going hand in hand with switching technical and business perspectives. Cost vs speed and other factors are examples of these risks.

Architects have to be good communicators, they are an essential contact for product managers, stakeholders, developers and other teams and relations. The architect creates a shared story, which is a representation of the product vision that can be shared in different levels of abstraction with all types of contacts. This shared story should clearly explain the product, it should be simple and concise. A credible roadmap should support the story, as well as a good architectural foundation. The product manager and architect work closely together on this.

Change is an important part of software designs and organizations. Architects should enable and embrace change. You want to introduce change in an early stage, anticipating change, and deferring change-blocking decisions. Dev-ops, CI/CD are important tools to make sure rapid change is possible.

Sam Newmans ideas about architects: CDNtvdg.png - Vision: - Empathy: - Collaboration: - Adaptability: - Autonomy: - Governance:

Architecture and Operations

Operations are a large part of creating an architecture. Choosing an integration strategy, failure recovery and quality assurance can all influence the architecture of a system. It needs to be monitorable and the system should be able to recover from different kinds of failure. If the architecture is not built to support failure, the whole system will suffer.

DevOps

In software development, the DevOps has been becoming more important and followed. Architectures should also keep organizational structures in mind. Previously these two clashed, operators wanting the system to be up the maximum amount of time, and developers wanting to publish new features. By aligning their goals and responsibilities, the deployments are sped up and more closely monitored.

4 Teams

While building a project architecture,

CI/CD

The practice of integrating the newest code that has been developed into the production server. This comes with some struggles, which can be addressed by implementing some features.

Pushing to Production

By having feature toggles, we can have multiple implementations in the code base. This has the benefit of being able to push a a feature, without having the risk of breaking old features. An option for implementing this is dependency injection. (https://martinfowler.com/articles/feature-toggles.html#ImplementationTechniques)

Dealing with failure

Circuit Breaker

A circuit breaker deals with failure To prevent errors to be sent back to the client, and to manage requests to

Asynchronicity

A client requests work to be done, which will not be done immediately. Event driven systems make use of this by having producers sending events. Consumers will then consume this event.

Quality vs innovation

In development, we have a trade-off between quality and innovation. Producing quality software takes time, which makes being innovative harder. Innovation comes at the price of risk of uptime. We can not develop robust systems in a short time without sacrificing either innovation or quality. Site reliability engineering (SRE) is a practice created by Google to keep track of (agreed on) quality. SRE's goals are creating scalable and reliable software, while also being able to quantify these terms. SRE has three main components that are looked at, Service Level Agreements (SLA), Service Level Indicators (SLI) and Service Level Objectives (SLO). The indicators provide the actual numbers of uptime and therefore quality of the system.

Error budget

Aiming for 100% uptime in the SLO is nearly impossible and not worth it. Doing updates at designated times for example, with some downtime, saves a lot of development (creating pipelines) time for a small bit of downtime. It may be good to aim for a higher uptime than the SLA indicates. Keeping the SLI between the SLA and SLI provides a good balance between quality and room for error.

Toil

Toil is a concept that improves parts of the system where bugs are triggering lots of work. This can happen while the solution may be small. Assigning a single engineer for a time to toil-problems may be beneficial, as the rest of the team can continue working on the features they should be working on.


Observability

Quick observations need to be made for timely error interception. This can be done with monitoring dashboards. Focus lies on the customer..... By reducing false positives, we can maintain a good upkeep of error message handling. Reducing false negatives is also important. If customers do not report issues, errors can stay in the system for a long time before being discovered.

Finding bugs: When developing, only limited runtime and data are seen. On production a lot more data and runtime is seen and this will cause more bugs.

Describe bugs objectively, so we can determine the impact. By formulating multiple hypotheses, we can find the actual culprit. Running experiments can expose the true hypothesis. After each experiment, log the output objectively.

Post mortem: Communication and technical quality need to be observed to improve future bug handling:

timeline: (slack chats)

impact
resolution (we did this, to resolve.., this is when we resolved)

root cause (Meet with the team, find out the root cause) follow up (what will be improvement steps)

public communication (emails)
improvements 
 organizational (improve people on call)

Quality: The broken window theory can be used to explain the decay of quality in a system. It occurs when the quality is low due to negligence in a small part of a system, after which people are less inclined to work hard on parts adjacent to these areas. This causes a wider scope of negligence and lower quality of the system. Over time this will result in a poorly constructed system, with bad quality.