Programming

ArchConf 2020

Leave a comment

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

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
Please remember to subscribe to the newsletter or feed to stay up to date!

Disclaimer: Thoughts and opinions are my own, and do not reflect the views of any employer, family member, friend, or anyone else. Some links may be affiliate links, but I don't link to anything I don't use myself.

Leave a Reply