WordPress database error: [Disk full (/tmp/#sql-temptable-1-26124b-26bc.MAI); waiting for someone to free some space... (errno: 28 "No space left on device")]
SHOW FULL COLUMNS FROM `markjacobsen_options`

{"id":2163,"date":"2020-12-16T13:10:58","date_gmt":"2020-12-16T18:10:58","guid":{"rendered":"https:\/\/markjacobsen.net\/?p=2163"},"modified":"2020-12-18T16:23:02","modified_gmt":"2020-12-18T21:23:02","slug":"archconf-2020","status":"publish","type":"post","link":"https:\/\/markjacobsen.net\/2020\/12\/archconf-2020\/","title":{"rendered":"ArchConf 2020"},"content":{"rendered":"\n

Last week I had the opportunity to “attend” ArchConf<\/a> (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.<\/p>\n\n\n\n

If you’re interested, here are my notes for each session I attended and took notes for :). Replays<\/a> (for attendees only)<\/p>\n\n\n\n

Architecting Cloud Native Applications<\/strong><\/h2>\n\n\n\nNathaniel Schutta<\/a> – 3\/5<\/p>\n\n\n\n
Main Takeaway<\/em>: In order to successfully implement micro-services they must have consistent\/good monitoring<\/p><\/blockquote>\n\n\n\n
Responsible Micro-Services ebook<\/a><\/li>
Beware of developers implementing technologies\/languages\/patterns for “resume driven design” reasons… not for the right reasons.<\/li>
Shared servers are a liability<\/li>
The 12 Factor App: Best Practices in Cloud Native Applications and Microservices<\/a><\/li>
You can consider a service a function because you can spin the number of instances down to zero<\/li>
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.<\/li><\/ul><\/li>
The 7 Software \u201c-ilities\u201d You Need To Know<\/a><\/li>
Architecting For the -ilities<\/a><\/li>
Architecture Requirements are Ilities<\/a><\/li>
You have to consider what ility attributes are important for which stakeholder, and what decisions that results in.<\/li>
Evolutionary architecture book<\/a><\/li>
microservice = anything that can be re-written in 2 weeks or less<\/span>
I really like this definition and goal.<\/li><\/ul><\/li>
high cohesion, low coupling<\/li>
A Modular Monolith<\/a> 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.<\/li>
If you have to ask what something is (a tech, language, platform), you don’t need it.<\/li>
Monitoring is vital to a thriving microservice arch<\/span><\/li>
The Four Golden Signals for Monitoring Distributed Systems<\/a>: latency, traffic load, error rate, saturation<\/li>
Circuit Breaker Pattern<\/a><\/li><\/ul>\n\n\n\n
Paved Roads – Architecting for Distributed Teams<\/strong><\/h2>\n\n\n\nNathaniel Schutta<\/a> – 4\/5<\/p>\n\n\n\n
Main Takeaway<\/em>: Any alert someone gets should be informative and actionable. Otherwise, put it on a dashboard or report.<\/p><\/blockquote>\n\n\n\n
Even when we’re in person we’re still communicating remotely (sending IMs, Texts, etc)<\/li>
Fitness function = todo list from arch to devs<\/li>
Review boards don’t work!<\/span><\/li>
Just because we can measure it does NOT mean it matters<\/span><\/li>
If everything is an option, nothing is an option<\/li>
Look into spring cloud contract<\/a><\/li>
Temporal fitness function = essentially a reminder (ex: Review this code in 1 year)<\/li>
Keep track of non-decisions\/non-goals too (i.e. we don’t care about X because…)<\/li>
Fitness functions should be visible and reviewed at least annually.<\/li>
If you’re going to get an alert it needs to be informative AND actionable. Just informative goes on a dashboard or report.<\/span><\/li>
Look into building a “radar”<\/a><\/li>
thoughtworks.com\/radar<\/a><\/li><\/ul>\n\n\n\n
To Hug or to Strangle: Tips for Dealing with Monolith Pain<\/strong><\/h2>\n\n\n\nLaine Minor<\/a> & Josh Smith<\/a> – 3\/5<\/p>\n\n\n\n
Main Takeaway<\/em>: Consider “hugging” (applying micro-service best practices) legacy apps that are too big to strangle<\/p><\/blockquote>\n\n\n\n
pain = the thing that prevents you from doing the part of your job you came\/want to do<\/li>
pain = mental load of things you know are not as they should be<\/li>
You get an architecture whether you plan for it or not<\/span><\/li>
Long time between delivery is a BUSINESS problem<\/li>
Biggest benefit of microservices is clean lines<\/li>
Option 1: strangle, then hug<\/li>
Option 2: hug, then strangle<\/li>
Hugging = applying microservice best practices to a monolith (monitoring, etc)<\/li><\/ul>\n\n\n\nDeveloper To Architect<\/strong><\/h2>\n\n\n\nNathaniel Schutta<\/a> – 3\/5<\/p>\n\n\n\n
Main Takeaway<\/em>: Review boards and heavy handed governance doesn’t work.<\/p><\/blockquote>\n\n\n\n
Consequences can be positive and negative<\/li>
Maximizing one minimizes another<\/li>
Governance in most orgs is heavyweight, high ceremony… and it does NOT work<\/span><\/li>
SLA vs SLA. The A matters and it indicates a consequence. If there is no consequence its an SLO (Objective)<\/li>
A reform most often advances via indirection<\/li>
It’s not just about the tech. It’s the relationships<\/li>
Portfolio architect provides high-level architectural and software engineering expertise to managers and technical staff.<\/li>
Domain architect : the way he describes it is essentially what we describe as a digital architect<\/li>
Specifically mentioned TOGAF as a “meh” certification<\/li><\/ul>\n\n\n\nSifting Technologies – Separating the Wheat From the Chaff<\/strong><\/h2>\n\n\n\nNathaniel Schutta<\/a> – 3\/5<\/p>\n\n\n\n
Main Takeaway<\/em>: Consider implementing architectural briefings<\/p><\/blockquote>\n\n\n\n
Education isn’t something you finish<\/li>
Attention is like real estate. they’re not making any more of it.<\/li>
Architectural briefing: why, how, where should\/n’t we use<\/li>
Not just how much does the thing cost, but how much does it cost to use it (dev, maint, hardware, etc)?<\/li>
Speed reduces risk<\/span><\/li>
There’s a difference between a dead tech vs a mature one<\/li>
Developers are like cats. They’ll push back just on principle.<\/li><\/ul>\n\n\n\nBuilding Evolutionary Architectures<\/strong><\/h2>\n\n\n\nVenkat Subramaniam<\/a> – 5\/5<\/p>\n\n\n\n
Main Takeaway<\/em>: 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.<\/p><\/blockquote>\n\n\n\n
UFD = Up Front Design<\/li>
Now that we’re “Agile” we’re not doing enough UFD (nor big UFD)<\/li>
Power point architects = dangerous<\/li>
Scrum master was never intended to be a title, else there’s no such thing as a self organizing team<\/li>
“adaptive planning” and “feedback driven development” are the most important words for Agile<\/li>
Rate all features\/stories by business value and architectural impact<\/li>
Goal should be delivering value. Not using a particular tech.<\/li>
People confuse unfamiliar w\/ complex<\/li>
People confuse familiar with simple<\/li>
reversibility = the ability to back out of a decision (less expensive)<\/span><\/li>
postpone decisions until the last responsible moment<\/span><\/li>
YAGNI = You Aren’t Gonna Need It<\/li>
parsimony = the most minimal solution. Ask “do we have to” for everything<\/span><\/li>
triangulate = implement 1 way, then another, and abstract common code to Base class<\/li>
Don’t START with an abstraction. Refactor into it.<\/li>
Postel’s law = be generous about what you receive and conservative about what you send<\/li>
Good reuse comes from repeated active<\/em> use<\/li>
Be ruthless in minimizing dependencies<\/span> including libraries and frameworks<\/li>
http:\/\/www.agiledeveloper.com\/downloads.html<\/li><\/ul>\n\n\n\nCore Software Design Principles<\/strong><\/h2>\n\n\n\nVenkat Subramaniam<\/a> – 4\/5<\/p>\n\n\n\n
Main Takeaway<\/em>: Have the courage to postpone doing things, and when you do, keep it DRY<\/p><\/blockquote>\n\n\n\n
DRY = don’t repeat yourself<\/li>
Violating DRY results in duplication of effort, not just duplication of code<\/span><\/li>
Manual testing is a violation of DRY<\/li>
Manual deploy is a violation of DRY<\/li>
Effort: now > later -> postpone, now == later -> postpone, now < later -> eval probability of needing it<\/li>
We need to have the courage to postpone doing things<\/span><\/li>
SRP = single responsibility principle<\/li>
SLAP = Single Level of Abstraction Principle<\/li>
Then use the Compose Method Pattern to combine same level SLAPs<\/li>
OCP = open close principle<\/li>
Software modules (functions, classes, etc) must be open for extension but closed from modification<\/li>
LSP = Liskov Substitution Principle<\/li>
Inheritance should only be used for substitutability and not for reuse<\/li>
DIY = Dependency Inversion Principle -> class should not depend on another class. Both should depend on abstraction or interface.<\/li><\/ul>\n\n\n\nCloud Integrations and Data Architecture for Enterprise Applications<\/strong><\/h2>\n\n\n\nRohit Bhardwaj<\/a> – 3\/5<\/p>\n\n\n\n
Main Takeaway<\/em>: 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.<\/p><\/blockquote>\n\n\n\n
Application EA -> define our objects, what things they are part of, and the relationships between them<\/li>
Applications interact with domains and data flows between them<\/li>
Orchestration services should always queue requests and process\/respond async<\/li>
Lambda is basically serverless (functions)<\/li>
You might consider using topics\/queues for each service instead of load balancer<\/li>
https:\/\/github.com\/robertmrk\/docker-cometd-demos<\/li>
Check out CometD<\/a><\/li>
Use a correlation id to sync across systems<\/li>
API comes first! Then the implementation.<\/span><\/li>
schema.org<\/a><\/li>
MDM data cleansing: normalize data formats, replace missing values, standardize values, map attributes<\/li>
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<\/li><\/ul>\n\n\n\n
Modeling for Architects<\/strong><\/h2>\n\n\n\nNathaniel Schutta<\/a> – 2\/5<\/p>\n\n\n\n
Main Takeaway<\/em>: The value in the artifact is not in the artifact itself. It’s in the conversation it facilitates.<\/p><\/blockquote>\n\n\n\n
If the team can’t understand it, they can’t build it<\/li>
It’s ok to throw out or deprecate a diagram<\/li>
The value in the artifact is not in the artifact itself. It’s in the conversation it facilitates.<\/span><\/li>
Component diagrams, deployment diagrams, and sequence diagrams are most common<\/li><\/ul>\n\n\n\nArchitectural Awareness<\/strong>: Engineering Super-skill<\/h2>\n\n\n\nKen Sipe<\/a> – 3\/5<\/p>\n\n\n\n
Main Takeaway<\/em>: Question everything. Don’t be afraid of a little chaos or of making mistakes<\/p><\/blockquote>\n\n\n\n
Hardest part of architecting is being aware<\/li>
awareness = awareness or perception<\/em> of a fact<\/li>
chaos breeds creativity<\/span><\/li>
Dryfus model: novice, advanced beginner (most people in IT industry), competent, proficient, expert<\/li>
you get what you tolerate<\/li>
shame and fear are toxic<\/li>
We shouldn’t loosely couple everything. We should have it in the right places.<\/li>
Team strengths: empathy, vulnerable\/humble, collaborate\/communicate, ability to share vision.<\/li>
Is your process intentional or not?<\/li>
“scrum but…” = I want all the benefits but don’t want to pay for it<\/li>
Why are we doing ..x..? Should we do something else? Is it working?<\/span><\/li>
context matters… and context could be foreign<\/li>
embrace inconsistency<\/li>
dependencies matter<\/li>
it’s a mistake to worry too much about scalability from the start, but also to not think about it at all.<\/li><\/ul>\n\n\n\nArchitectural Resiliency<\/strong><\/h2>\n\n\n\nJeremy Deane<\/a> – 4\/5<\/p>\n\n\n\n
Main Takeaway<\/em>: Need to have ownership to have accountability, and ownership needs to be end to end.<\/p><\/blockquote>\n\n\n\n
Threat Modeling book<\/a><\/li>
openmastery.org<\/a><\/li>
promote accountability\/ownership. No orphans<\/li>
Correlate activities. use a tracking id\/correlation id<\/span><\/li>
Do synthetic transactions<\/li>
Look into “data dog<\/a>” for dashboarding<\/li>
Cloud hosting should be multi-region<\/li>
Security Resiliency: Secure by default, defense in depth, least privilege<\/li>
Event sourcing<\/li>
Postel’s Law – Be conservative in what you send, be liberal in what you accept<\/span><\/li>
Bulkheads. Limit failure exposure.<\/li>
Validate your input. Sanitize your output.<\/li>
Need to have end to end ownership<\/span><\/li>
https:\/\/prezi.com\/mb-vcfp-cry8\/architectural-resiliency\/<\/li><\/ul>\n\n\n\n<\/iframe>\n\n\n\n<h2 class=\"wp-block-heading\">Architectural Trade-offs<\/strong><\/h2>\n\n\n\n<a href=\"https:\/\/twitter.com\/jtdeane\" target=\"_blank\" rel=\"noreferrer noopener\">Jeremy Deane<\/a> – 4\/5<\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">Main Takeaway<\/em>: Be aware that there’s a trade off (negative) to any choice you make.<\/p><\/blockquote>\n\n\n\n<ul><li>RBAC = Role Based Access Control (ex: AD, Prism)<\/li><li>ABAC = Attribute Based Access Control (context based policies. ex: location based, etc)<\/li><li>Feature Toggles tend to result in technical debt<\/li><li>Blue green results in unnecessary releases<\/li><li>orchestration causes coupling and dependencies<\/li><li>choreography has complexity and needs monitoring<\/li><li>Need to understand the requirements and your domain!<\/li><li>Cloud providers tend to be “sticky”. Hard to get out of.<\/li><\/ul>\n\n\n\n<iframe loading=\"lazy\" src=\"https:\/\/prezi.com\/embed\/zgt7vz0q1oyy\/\" id=\"iframe_container\" frameborder=\"0\" webkitallowfullscreen=\"\" mozallowfullscreen=\"\" allowfullscreen=\"\" allow=\"autoplay; fullscreen\" height=\"315\" width=\"560\"><\/iframe>\n\n\n\n<h2 class=\"wp-block-heading\">How to Technology Good – Tips for Implementation at Scale<\/strong><\/h2>\n\n\n\n<a href=\"https:\/\/twitter.com\/lainieftw\" target=\"_blank\" rel=\"noreferrer noopener\">Laine Minor<\/a> & <a href=\"https:\/\/twitter.com\/architect_josh\" target=\"_blank\" rel=\"noreferrer noopener\">Josh Smith<\/a> – 2\/5<\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">Main Takeaway<\/em>: For good or bad, metrics (or data if you prefer) are needed to promote any tech<\/p><\/blockquote>\n\n\n\n<ul><li>Metrics help build understanding, certainty, and trust<\/li><li>Until you have metrics it’s a non-starter<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">Data as a Service (DaaS)<\/h2>\n\n\n\nDavid Sietz – 5\/5<\/p>\n\n\n\n<blockquote class=\"wp-block-quote\">Main Takeaway: <\/em>Publish data changes to your topics, have microservices consume the data as needed, and version as necessary.<\/p><\/blockquote>\n\n\n\n<ul><li>Data model changes are expensive<\/li><li>Use a NoSQL db<\/li><li>Version all data coming in<\/span><\/li><li>Provisioning data: real time, self guided flow, variable load, parallel<\/li><li>Publishing data: real-time, variable endpoints, variable load, managed access<\/li><li>Use a business lens: risks, rewards, volatility<\/li><li>ROI is not always monetary<\/span><\/li><li>Last Responsible Moment (LRM)<\/li><li>There’s nothing wrong with copying data as long as you understand the intent and retention<\/span><\/li><li>Build your data marts at the last responsible moment<\/li><\/ul>\nPlease remember to <a href=\"https:\/\/markjacobsen.net\/newsletter\" target=\"_blank\">subscribe to the newsletter<\/a> to stay up to date!<\/i><br\/>\n<br\/>\nYou or someone you know looking to buy or sell?<\/i>\n<a href=\"https:\/\/freedomre.com\" target=\"_blank\" rel=\"noopener\"><img decoding=\"async\" src=\"https:\/\/markjacobsen.net\/wp-content\/uploads\/2019\/09\/freedomre-glre-small.png\" border=\"0\" \/><\/a><br\/>\nDisclaimer: 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...<\/small><\/i>","protected":false},"excerpt":{"rendered":"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 … <a href=\"https:\/\/markjacobsen.net\/2020\/12\/archconf-2020\/\" class=\"more-link\">Continue reading ArchConf 2020<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"footnotes":"","_jetpack_memberships_contains_paid_content":false,"jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[58],"tags":[190],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_shortlink":"https:\/\/wp.me\/p2UXeD-yT","jetpack_sharing_enabled":true,"jetpack-related-posts":[],"jetpack_likes_enabled":false,"_links":{"self":[{"href":"https:\/\/markjacobsen.net\/wp-json\/wp\/v2\/posts\/2163"}],"collection":[{"href":"https:\/\/markjacobsen.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/markjacobsen.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/markjacobsen.net\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/markjacobsen.net\/wp-json\/wp\/v2\/comments?post=2163"}],"version-history":[{"count":5,"href":"https:\/\/markjacobsen.net\/wp-json\/wp\/v2\/posts\/2163\/revisions"}],"predecessor-version":[{"id":2171,"href":"https:\/\/markjacobsen.net\/wp-json\/wp\/v2\/posts\/2163\/revisions\/2171"}],"wp:attachment":[{"href":"https:\/\/markjacobsen.net\/wp-json\/wp\/v2\/media?parent=2163"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/markjacobsen.net\/wp-json\/wp\/v2\/categories?post=2163"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/markjacobsen.net\/wp-json\/wp\/v2\/tags?post=2163"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}