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 to stay up to date!
You or someone you know looking to buy or sell?
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. You would think this should be self evident these days, but apparently not...