Update on RRDMWG and internal Stat Reporting with openIDL (Peter Antley)
IaC and UI framework.
Architecture Decisions for OLGA
AOB:
Notes:
RRDMW and Stat reporting
OLGA
Stat Reporting
ingest homeowners, stat records from residential property lines
Weds - order of operations, what lines next?
confirm what they are doing for Jumne
Architectural Decisions for OLGA
HDS
native AWS
react web page, single page app, REST API
node based lambda functions
simple queue service
S3 buckets
at this time - utilizing TOAST UI (grid component to display table data)
elected to choose TOAST as toast makes most sense, other options for GRID components?
chose toast - grid component that didn't have any weird business tiers
most grid vendors give away for free, adv things charge for
TOAST UI - POS for restaurants
open source grid component - filtering and sorting
KS - gen discussion
know this is a ref implementation
any choices made could be changed
focusing on AWS, not azure
AWS is licensed thing, paid for services
thought important - open source code we publish to github as much as possible should not be dependent on purch or licensed software
code shouldn't have dependencies for things we need to license
bigger carriers - check everything as a dependency, bring in manually into our environ, trying to figure out how to decide whats ok and no
license/not licensed? pre-approval?
TOAST first place this came up
TOast, AG Grid, MuyTable
keep it from getting complicated, putting on license/non license
red herring? wrong place?
some decisions may run afoul
open source vs licensed but meet the need
should we always choose open source one
DR
policy vs practice
usually even open source or permissive licenses, enterprise adopts when some party bundles into a SaaS offering (agreeement, click thru, rest handled by someone else)
on internal projects, ok to do license wrangling, usually more common one agreement with primary partner
KS
from carrier perspective, not sure if it applies to ref implementation, not a SaaS
not running it for you, you are running in your enviroment
DR
most likely, 3rd party provider, abstract complexity
structure, buying a service from provider, agreements transparent, well defined, shift licensing burden to someone else
see it a lot with F/OSS projects, enterprise versions, spring to handle tech implementation as a service and abstract licensing
something considered
one more thing a carrier has to think about - not trivial
KS
we have 2 companies, TRV, Hartford - diff opinions
Hartford - run it ourselves, TRV - SaaS it
stay with less licensed software and less controversial security stuff
DR - diff between open sourced and licensed?
KS - pay money for, pay the vendor
when doing ref implementation, "dependency you have to pay for"
DR - few licenses are the gold standard, dont want to play in that game unless have to
network effects? get as many on as possible, out of the box doc - explains packages, licences, make avail more explicitly than you would do manually
might want to make it very explicit - here is the list of every license in this stack, their permissions and conditions
KS - licensing and purchasing are diff issues
DR
non trivial, not insurmountable, lay out the licenses and what they mean and what to do - go a long way in helping
KS
SK
open to both models (build vs SaaS)
open to subscription model as well (AAIS runs infra and services that go with that)
KS - other grid components? what do all use? React or Angular grid components (needs to work on React for sure)
TOAST.ui - leaning towards, functionally complete, less of a drag, checking license, possibly MIT license
AG Grid (pro license)
MUI Table (pro license)
"Our VPC or Vendor's VPC"
DR - if model requires anyone to have multiple licenses paid for and managed? problems
all permissive and open source one thing
a lot of vendor relationships to manage is another thing
13 licenses not ideal, harder if some subscript based
contracts and licenses and vendor agreements - less attractive
PA
paid will be unattractive
acceptable features
MUI Table - could be a fit
does grid component work well with ORM + REST
done a lot of doodling, ready to start doing POCs
getting working code pulled together
this iteration, goal is to load stat data to HDS w/o validations
JN - working on serverless implementation of rules engine and validations, modernized rules engine, getting it to run serverless, after he gets rules engine working work on stubbing out react pages and throw up grids THEN peter will do API stuff, end of June test UI to display and show
Serverless implementation -do IAC using SAM template, and use cloud formation for one persisitent server
objections?
KS
IAC (infrastructure as code easier as AWS native vs Terraform)
dont have much exp with Terraform inside of AAIS
cloud formation is simple in comparison, dont want to overburden with extra work
Serverless Architectural Model - declarative vs descriptive
SAM for Olga, not in general
another way to handle this - carrier participate - more complicated - participate in detail, maybe terraform brought in easier
right now, terraform affect timelines
PA - some prebuilt tools in AWS to implement SAM
KS - bad idea? think about?
Time
Item
Who
Notes
Documentation:
Notes: (Notes taken live in Requirements document)