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”
To Hug or to Strangle: Tips for Dealing with Monolith Pain
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
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
- Check out CometD
- Use a correlation id to sync across systems
- API comes first! Then the implementation.
- 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.
Jeremy Deane – 4/5
Main Takeaway: Need to have ownership to have accountability, and ownership needs to be end to end.
- Threat Modeling book
- 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
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
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
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...