Donald Ferguson - Old Programmers Can Learn New Tricks

Old Programmers Can Learn New Tricks: But they whine a lot and sometimes leave a mess on the floor. Donald F. Ferguson CTO and Co-Founder, SPARQtv [email protected]

Old Programmers Can Learn New Tricks http://serverlessconf.io/

Damian Bringas Martin Baspineiro Morgan Caitlin Sebastian Taranto Yiannis Stanvrou

2 Old Programmers Can Learn New Tricks http://serverlessconf.io/ (2016)

Contents •  Introduction

–  Overview of solution we are building. –  Overview of current technology choices.

•  (Very) High-Level Architecture –  Overview. –  “Old dogs” think in terms of components and composition. –  Our “component model.”

•  After Action Review from building the Alpha –  What worked. –  What did not work. –  What we should do differently. –  What we would like to have.

•  Discussion, Q&A


My Role at this Conference


My Role at this Conference


Solution Overview

•  End-Users –  Interact with integrated “streams” and

“moments” –  Chat and participate in communities.

•  Content Developers –  Produce content. –  Integrate and link with “cloud”

content. –  Interact/collaborate with consumers.

•  3rd Parties –  User APIs to gain data insight. –  Advertise and interact.

•  Content Deliverers –  Reuse the platform. –  Using various models, e.g. SaaS,

APIs.

Connector/Integration with

•  Digital asset/content management.

•  Internal, private collaboration.

•  Public social media.

•  … …


Technology •  Used in alpha

•  Solution deployment. •  Collaborative development. •  Debug/management.

•  High priority for beta. •  Some other technology

•  AngularJS, RESTAngular. •  Java •  XMPP •  Cloud digital asset mgmt,

transcoding and streaming.

•  Swagger.

Slack

SQS Asynch

Ops.


User Info

Content Management

Social Media

… … … …

High-Level Application Architecture Overview Integration Composition Services

“Browser”


How “Old Dogs Think”


Customer Content … …

Document/ Command

Standard REST Msg

F F F F F F F F F F F F


Interface Model/Implementation Model •  There is one Lambda function implementation, that may have multiple instances.

–  “Run Command=‘XXX’ with ‘O1’ on ‘YYY’ –  Sub-dispatches (via table) on com.sparq.YYY.service. –  And we surface as POST http://sparq.tv/app/commandProcessor, which means

you “POST” to do a “GET” by setting Command = “GET.”

•  We also surface “more natural” REST interface –  Standard verbs (GET, POST, DELETE, UPDATE) –  Just resource JSON body in/out. –  Single, very complex integration mapping converts between

–  Body, path params, headers, query params, … –  And CMD/document interface into “generic service” service.

•  We did this for four core reasons. 1.  Unit testing via Eclipse SDK and Lambda test UI, without going through GW and mappings. 2.  Support the option of other “bindings,” e.g. SQS, XMPP. 3.  Single gateway mapping/config for all resources/verbs. 4.  Rapidly enable cheating for “verbs” that spanned resources and do not look like CRUD.


Did the Old Guy Learn the Principles? •  Compute service/code-on-demand: Yes. •  Single Purpose, Stateless Functions Yes.

–  But in a WTF? way. –  Distinction between packaging the function and function invocation/execution. –  Flourish might cause us to think differently. –  An approach to code reuse similar to ExpressJS app.use(), req/rsp, etc, but multi-protocol.

•  Event-based/push-based Epic Fail –  Will get there, but less critical at early stage of web app. –  The students in my course “Micro-Services Apps and APIs” had TREMENDOUS difficulty

grasping and applying concept not matter how many times I covered. (Not sure what to conclude) •  Thick client, no middleware Sort Of

–  “Middle is an app design best practice, not a topology statement.”| Thick clients have a “middle-tier” model/integration layer/tier.

–  Solutions that deliver value via APIs may not have a client, but derive value from composing and integrating cloud APIs.

•  User 3rd Party Services. Yes.


After Action Review What worked and was totally awesome

–  No team, effort, etc. to set up and configure app servers, classpaths, right version of XXX, … This saves significant cost and time.

–  Very, very incremental deployment and versioning of code. –  I want to change POST on /customers/{id}/sociallogins –  But not change ANY other path’s or verb’s implementation, including …/sociallogin/{id}

–  One and only one configuration of code per path/verb. The config MAY be the same, but is not necessarily the same.

–  Incremental testing –  Wrap with local Java main() and local resources. [app testing] –  Test locally but call remote AWS resources. [distributed testing] –  Test with the Eclipse “upload and run” Lambda function. [Lambda RT testing] –  Test with console unit test for Lambda. [Paranoid testing] –  Test through API Gateway with CommandProcessor. [GW independent of

config] –  Test via normal REST/path [Test integration maps]


After Action Review What did not work/we screwed up.

–  Web application design –  There are two ways to build an app: datamodel à code à API or API à code à datamodel –  We started with the datamodel. –  This caused us no end of grief. We had type-space and format mappings and errors at every stage.

–  Java –  We chose for various reasons

–  COBOL is not supported. –  New product built by a team that previously build Java/J2EE solutions à leverage some code and skills. –  Server side JavaScript freaks old-guys out.

–  Very little documentation, best practices, sample applications, … compared to other languages. –  All kids of weird stuff happened, e.g.

–  The occasionally non-stateless JVM. –  Gradually, reverse engineered EXACTLY what came into our code from the gateway.

–  Configuration/property management. –  Where do you put/how do you handle config and property files. –  We tried several approaches for various reasons.

–  Software configuration management –  There is no concept of “all these pieces make up an application.” –  Stuff in S3, Lambda functions, SQL scripts, integration mappings, …


After Action Review •  What would we do differently.

–  Start with API and Swagger, and “Generate” everything from there, e.g. –  Transfer Objects –  SQL –  RESTAngular –  Swagger helps enormously with using the API gateway, but we still do a lot of cut and paste

for mapping templates and “x-amazon-apigateway-integration.” –  Designed our object model differently

–  We have standard POJOs. –  We should use typed interfaces mapped to internal JSON objects with data.

–  Thought more carefully about “query” upfront. –  …?x=123&y=“abc” works pretty well for basic resources. –  But gets unwieldy when the resource is a composite. –  We ended up writing a “query processor” and commands that are like “stored procedures.”


After Action Review What we would like.

–  Near term/incremental –  API Gateway improvements, including tools. –  More incremental consumption of AWS capabilities.

–  API Gateway + Lambda + Policy + IAM + … is extremely powerful. –  But projects start wanting 10% of this and 5% of that and 20% of this …

–  Examples, examples, .. Patterns/anti-patterns. –  All h*ll broke loose with WebSphere 3.0. –  Programmers made all kinds of naïve errors. –  We produced a presentation with 30 patterns/anti-patterns and our “customer crit-sits”

dropped by 90%. –  We made all kinds of AWS mistakes because of lack of samples and patterns.

–  More strategically –  Graph database. –  Chat, control message, presence, … service. –  “Function composition abstractions/DSLs”

Date post:	06-Jan-2017
Category:	Internet
Upload:	serverlessconf
View:	468 times
Download:	1 times

Donald Ferguson - Old Programmers Can Learn New Tricks

Internet