ArchConf 2020

Wed, 16 Dec 2020 18:10:58 +0000

Last week I had the opportunity to “attend” ArchConf (virtually). Of the sessions I attended, Venkat Subramaniam’s presentation of “Building Evolutionary Architectures” was easily the best and combined an engaging and enthusiastic style with useful content. David Sietz’s “Data as a Service (DaaS)” presentation was also very good and applicable for my needs. Aside from that, Joshua Smith and Laine Minor from RedHat were probably the most entertaining/fun/funny.

If you’re interested, here are my notes for each session I attended and took notes for :). Replays (for attendees only)

Architecting Cloud Native Applications

Nathaniel Schutta – 3/5

Main Takeaway: In order to successfully implement micro-services they must have consistent/good monitoring

Responsible Micro-Services ebook
Beware of developers implementing technologies/languages/patterns for “resume driven design” reasons… not for the right reasons.
Shared servers are a liability
The 12 Factor App: Best Practices in Cloud Native Applications and Microservices
You can consider a service a function because you can spin the number of instances down to zero
Quality Attributes/Requirements = Non Functional Requirements (NFR)
- Personally I would really like to see us start using “Quality Attributes” or “Quality Requirements” instead of NFR.
The 7 Software “-ilities” You Need To Know
Architecting For the -ilities
Architecture Requirements are Ilities
You have to consider what ility attributes are important for which stakeholder, and what decisions that results in.
Evolutionary architecture book
microservice = anything that can be re-written in 2 weeks or less
- I really like this definition and goal.
high cohesion, low coupling
A Modular Monolith might be a better approach in certain situations. A modular monolith is a software design approach in which a monolith is designed with an emphasis on interchangeable (and potentially reusable) modules.
If you have to ask what something is (a tech, language, platform), you don’t need it.
Monitoring is vital to a thriving microservice arch
The Four Golden Signals for Monitoring Distributed Systems: latency, traffic load, error rate, saturation
Circuit Breaker Pattern

Paved Roads – Architecting for Distributed Teams

Nathaniel Schutta – 4/5

Main Takeaway: Any alert someone gets should be informative and actionable. Otherwise, put it on a dashboard or report.

Even when we’re in person we’re still communicating remotely (sending IMs, Texts, etc)
Fitness function = todo list from arch to devs
Review boards don’t work!
Just because we can measure it does NOT mean it matters
If everything is an option, nothing is an option
Look into spring cloud contract
Temporal fitness function = essentially a reminder (ex: Review this code in 1 year)
Keep track of non-decisions/non-goals too (i.e. we don’t care about X because…)
Fitness functions should be visible and reviewed at least annually.
If you’re going to get an alert it needs to be informative AND actionable. Just informative goes on a dashboard or report.
Look into building a “radar”
thoughtworks.com/radar

To Hug or to Strangle: Tips for Dealing with Monolith Pain

Laine Minor & Josh Smith – 3/5

Main Takeaway: Consider “hugging” (applying micro-service best practices) legacy apps that are too big to strangle

pain = the thing that prevents you from doing the part of your job you came/want to do
pain = mental load of things you know are not as they should be
You get an architecture whether you plan for it or not
Long time between delivery is a BUSINESS problem
Biggest benefit of microservices is clean lines
Option 1: strangle, then hug
Option 2: hug, then strangle
Hugging = applying microservice best practices to a monolith (monitoring, etc)

Developer To Architect

Nathaniel Schutta – 3/5

Main Takeaway: Review boards and heavy handed governance doesn’t work.

Consequences can be positive and negative
Maximizing one minimizes another
Governance in most orgs is heavyweight, high ceremony… and it does NOT work
SLA vs SLA. The A matters and it indicates a consequence. If there is no consequence its an SLO (Objective)
A reform most often advances via indirection
It’s not just about the tech. It’s the relationships
Portfolio architect provides high-level architectural and software engineering expertise to managers and technical staff.
Domain architect : the way he describes it is essentially what we describe as a digital architect
Specifically mentioned TOGAF as a “meh” certification

Sifting Technologies – Separating the Wheat From the Chaff

Nathaniel Schutta – 3/5

Main Takeaway: Consider implementing architectural briefings

Education isn’t something you finish
Attention is like real estate. they’re not making any more of it.
Architectural briefing: why, how, where should/n’t we use
Not just how much does the thing cost, but how much does it cost to use it (dev, maint, hardware, etc)?
Speed reduces risk
There’s a difference between a dead tech vs a mature one
Developers are like cats. They’ll push back just on principle.

Building Evolutionary Architectures

Venkat Subramaniam – 5/5

Main Takeaway: Postpone decisions until the last possible moment because it’s possible YAGNI and doing so lessens the considerations for reversibility. Keep all code as simple as possible.

UFD = Up Front Design
Now that we’re “Agile” we’re not doing enough UFD (nor big UFD)
Power point architects = dangerous
Scrum master was never intended to be a title, else there’s no such thing as a self organizing team
“adaptive planning” and “feedback driven development” are the most important words for Agile
Rate all features/stories by business value and architectural impact
Goal should be delivering value. Not using a particular tech.
People confuse unfamiliar w/ complex
People confuse familiar with simple
reversibility = the ability to back out of a decision (less expensive)
postpone decisions until the last responsible moment
YAGNI = You Aren’t Gonna Need It
parsimony = the most minimal solution. Ask “do we have to” for everything
triangulate = implement 1 way, then another, and abstract common code to Base class
Don’t START with an abstraction. Refactor into it.
Postel’s law = be generous about what you receive and conservative about what you send
Good reuse comes from repeated active use
Be ruthless in minimizing dependencies including libraries and frameworks
http://www.agiledeveloper.com/downloads.html

Core Software Design Principles

Venkat Subramaniam – 4/5

Main Takeaway: Have the courage to postpone doing things, and when you do, keep it DRY

DRY = don’t repeat yourself
Violating DRY results in duplication of effort, not just duplication of code
Manual testing is a violation of DRY
Manual deploy is a violation of DRY
Effort: now > later -> postpone, now == later -> postpone, now < later -> eval probability of needing it
We need to have the courage to postpone doing things
SRP = single responsibility principle
SLAP = Single Level of Abstraction Principle
Then use the Compose Method Pattern to combine same level SLAPs
OCP = open close principle
Software modules (functions, classes, etc) must be open for extension but closed from modification
LSP = Liskov Substitution Principle
Inheritance should only be used for substitutability and not for reuse
DIY = Dependency Inversion Principle -> class should not depend on another class. Both should depend on abstraction or interface.

Cloud Integrations and Data Architecture for Enterprise Applications

Rohit Bhardwaj – 3/5

Main Takeaway: The API should come first. Or, when implementing an API for an existing implementation, don’t model the API on the internal workings of the system.

Application EA -> define our objects, what things they are part of, and the relationships between them
Applications interact with domains and data flows between them
Orchestration services should always queue requests and process/respond async
Lambda is basically serverless (functions)
You might consider using topics/queues for each service instead of load balancer
https://github.com/robertmrk/docker-cometd-demos
Check out CometD
Use a correlation id to sync across systems
API comes first! Then the implementation.
schema.org
MDM data cleansing: normalize data formats, replace missing values, standardize values, map attributes
Identify sources (producers and consumers of master data) -> collect and analyze metadata -> appt data stewards -> implement data gov program and council -> dev MD model and choose toolset -> Design infra, generate and test MD -> Modify producing and consuming -> implement maint process

Modeling for Architects

Nathaniel Schutta – 2/5

Main Takeaway: The value in the artifact is not in the artifact itself. It’s in the conversation it facilitates.

If the team can’t understand it, they can’t build it
It’s ok to throw out or deprecate a diagram
The value in the artifact is not in the artifact itself. It’s in the conversation it facilitates.
Component diagrams, deployment diagrams, and sequence diagrams are most common

Architectural Awareness: Engineering Super-skill

Ken Sipe – 3/5

Main Takeaway: Question everything. Don’t be afraid of a little chaos or of making mistakes

Hardest part of architecting is being aware
awareness = awareness or perception of a fact
chaos breeds creativity
Dryfus model: novice, advanced beginner (most people in IT industry), competent, proficient, expert
you get what you tolerate
shame and fear are toxic
We shouldn’t loosely couple everything. We should have it in the right places.
Team strengths: empathy, vulnerable/humble, collaborate/communicate, ability to share vision.
Is your process intentional or not?
“scrum but…” = I want all the benefits but don’t want to pay for it
Why are we doing ..x..? Should we do something else? Is it working?
context matters… and context could be foreign
embrace inconsistency
dependencies matter
it’s a mistake to worry too much about scalability from the start, but also to not think about it at all.

Architectural Resiliency

Jeremy Deane – 4/5

Main Takeaway: Need to have ownership to have accountability, and ownership needs to be end to end.

Threat Modeling book
openmastery.org
promote accountability/ownership. No orphans
Correlate activities. use a tracking id/correlation id
Do synthetic transactions
Look into “data dog” for dashboarding
Cloud hosting should be multi-region
Security Resiliency: Secure by default, defense in depth, least privilege
Event sourcing
Postel’s Law – Be conservative in what you send, be liberal in what you accept
Bulkheads. Limit failure exposure.
Validate your input. Sanitize your output.
Need to have end to end ownership
https://prezi.com/mb-vcfp-cry8/architectural-resiliency/

Architectural Trade-offs

Jeremy Deane – 4/5

Main Takeaway: Be aware that there’s a trade off (negative) to any choice you make.

RBAC = Role Based Access Control (ex: AD, Prism)
ABAC = Attribute Based Access Control (context based policies. ex: location based, etc)
Feature Toggles tend to result in technical debt
Blue green results in unnecessary releases
orchestration causes coupling and dependencies
choreography has complexity and needs monitoring
Need to understand the requirements and your domain!
Cloud providers tend to be “sticky”. Hard to get out of.

How to Technology Good – Tips for Implementation at Scale

Laine Minor & Josh Smith – 2/5

Main Takeaway: For good or bad, metrics (or data if you prefer) are needed to promote any tech

Metrics help build understanding, certainty, and trust
Until you have metrics it’s a non-starter

Data as a Service (DaaS)

David Sietz – 5/5

Main Takeaway: Publish data changes to your topics, have microservices consume the data as needed, and version as necessary.

Data model changes are expensive
Use a NoSQL db
Version all data coming in
Provisioning data: real time, self guided flow, variable load, parallel
Publishing data: real-time, variable endpoints, variable load, managed access
Use a business lens: risks, rewards, volatility
ROI is not always monetary
Last Responsible Moment (LRM)
There’s nothing wrong with copying data as long as you understand the intent and retention
Build your data marts at the last responsible moment

Conference on MarkJacobsen.net

ArchConf 2020

Architecting Cloud Native Applications

Paved Roads – Architecting for Distributed Teams

To Hug or to Strangle: Tips for Dealing with Monolith Pain

Developer To Architect

Sifting Technologies – Separating the Wheat From the Chaff

Building Evolutionary Architectures

Core Software Design Principles

Cloud Integrations and Data Architecture for Enterprise Applications

Modeling for Architects

Architectural Awareness: Engineering Super-skill

Architectural Resiliency

Architectural Trade-offs

How to Technology Good – Tips for Implementation at Scale

Data as a Service (DaaS)