Node.js to Serverless by Dror Arazi | SeaLights' Meetup | 17/1/17
•Télécharger en tant que PPTX, PDF•
1 j'aime•701 vues
We’ll see how node.js developers can get up running AWS serverless style in no time using claudia.js. Also, since we know it’s difficult to find proper tools to monitor and profile serverless architecture, we’ll take AWS X-Ray for a spin straight out of re:invent. We’ll see what developers(java/node.js)can learn about their service performance within microservices/serverless architecture running on AWS, and how X-Ray stacks up against existing solutions. (should new-relic be worried?)
Recommandé
Recommandé
Contenu connexe
Dernier
Dernier (20)
En vedette
En vedette (20)
Node.js to Serverless by Dror Arazi | SeaLights' Meetup | 17/1/17
- 2. Node js to Serverless
- 3. <whoami />
- 4. Trust me, I have a beard dror@sealights.io
- 5. The first cloud-based, continuous testing platform SeaLights
- 8. Evolution of compute | Public cloud infrastructure Application code instances
- 10. Application code Evolution of compute | Serverless
- 12. <effects />
- 13. Datacenter Snowflakes Deploy in months Live for years Virtualized and Cloud Deploy in minutes Live for weeks Container Deployments Deploy in seconds Live for minutes/hours AWS Lambda Deploy in milliseconds Live for seconds Life’s getting shorter
- 14. Monolith Container Container Container Function Function Function Function Breaking microservices
- 15. Client Proxy/LB Server Database Client Auth Service API Gateway Web Delivery Function A Function B Database Service No “black box” architecture
- 16. <actors />
- 17. What’s all the FaaS?
- 18. <AWS-lambda />
- 19. AWS Lambda | Capabilities
- 20. AWS API Gateway
- 21. quick low-cost scaleable focus simple no-ops Pros
- 22. multitenancy lock-in overhead cold start monitoring short-lived Cons
- 23. <frameworks />
- 25. Howdy Claudia
- 27. Claudia.js DEMO
- 28. <monitoring />
- 30. X-Ray unlocks inner traces
- 31. X-Ray DEMO
- 32. ARM Wrestling Traditional Topology detection
- 33. <summary />
Notes de l'éditeur
- Welcome all First I wanna thank the organizers for this cool setup. Let’s jump right to it
- About me: Coder, Technologist ~10y experience developer -> architect -> evangelist Love my fam - Tom just had her 2yo b-day
- החברה שלנו מפתחת את פלטפורמת הענן/סאס הראשונה לבדיקות איכות רציפות/מתמשכות - continuous-testing. אנחנו יודעים לנטר כל בדיקה, מכל כלי, בכל סביבה. מה שמאפשר למדוד את איכות הקוד, תוך שמירה על מהירות תהליך הפיתוח. יש פה הרבה חברה עם חולצות יפות שישמחו לדבר אתכם יותר לעומק אם תרצו. As part of my job, i'm visiting our company's future tech roadmap. Realized the way we developed sealights platform (micro, decoupled, async, event-based) makes a great use-case to practice serverless. Here’s what I found:
- Control your own VM. Sysadmin needed. Need to solve install+ship+deploy in multiple envs - deploy/config mgmt tools (puppet/chef/ansible) Story about production limited r&d tech-stack at liveperson.
- Docker had a fresh approach to solve this. Isolation, tech agnostic. But wait… Since it’s already here… why won’t we...
- A Natural Evolution Docker enable (IS) serverless - Containers-on-demand Vendor will manage that container orchestration overhead for all of us together Instances are now abstracted away Elastic/scalable out of the box SHORT CIRCUITS OPS AND MOVES INFRASTRUCTURE RUNTIME CLOSER TO DEVS - skip dockerizing everything
- Serverless = marketing = cloud compute evo = no-ops A tweet by @adrianco (VP Cloud Architecture Strategy at AWS) for your judgement - what do you think?
- ops: Unit lifespan: getting even more volatile/ephemeral Compliments short frequent decoupled deployment cycles Billing changed just as phone calls used to be charged by the minute, never pay for idle Green computing - Typical servers resource utilization is ~[5%-15%] mean for 1 year.
- Architect: Getting even more decoupled and stateless (this time for real) Code design: reuse by sharing modules (module repo needed)
- Dev: Then: magic happened inside the server - opinionated/subjective service separation by vertical Now: module separation by role = Maintainability!
- Big players are entering this game: Microsoft Azure Functions Google functions Aws lambda ← focusing on aws Joyent manta IBM Openwhisk iron.io
- Bring your own code, but code only. Simple resource model: only choose RAM size - the rest is pre-set accordingly Granular Permissions Control: Each Lambda has an IAM role - service access secured Flexible triggers: Api gateway ← (next slide) IoT Alexa Cloudfront Cloudwatch CodeCommit Cognito DynamoDB Kinesis S3 SNS
- Meet api-gateway - lambdas best friend (lambda = serverless app, api-gateway = serverless web service) Key features: - Unified API frontend for multiple micro-services and versions (dynamic/customizable) - Authenticate and authorize requests to a backend - DDoS protection, caching and throttling for your backend - Docs + client SDK generation (native/web)
- Though we are talking about aws lambda essentially it’s true over all serverless implementations PROS Reduced time to market and er software release. Lower operational and development costs. no need for developers to implement scale mgmt and administrators do not need to upgrade existing servers or add additional ones. Agile by nature and allows developers to focus on code. Reduces the complexity of software (short, decoupled = readable, maintainable). Simple packaging and deployment - no-ops
- Though we are talking about aws lambda essentially it’s true over all serverless implementations CONS Serverless is not efficient for long-running applications. Vendor lock-in. additional overhead for function/microservice calls (RTT). “Multitenancy” with a noisy neighbour will impact performance regardless. Cold-start, can be handled. MONITORING/LOGGING
- open source projects like the Serverless framework and Claudia.js exist, to abstract the developer from implementation-specific concepts and allow them to use regular code. JAWS - opinionated framework Claudia - better flexibility
- Why claudia? tailor made by node js developers to node js developers as they expect. NPM based. automates all the error-prone/tedious deployment/configuration tasks. Great integration with api-gateway. Multi-version support for dev/test/prod workflows. Inject stage env-vars per version. Supports deployment for all triggers discussed.
- Explain use-case first
- Since lambda is all aws - monitoring and logging will be cloudwatch based. X-Ray will be the last missing piece of the puzzle. unlock visualization of requests lifecycle within your solution and all aws services. The bad: Bleeding edge, Preview only Static instrumentation only at the moment - node,java,.net Dynamic lambda support about to roll out The good: Simple setup E2E tracing AWS services integration Request sampling Service map Custom metrics filtering (business specific) API/CLI access
- Helps us to: • Identify performance bottlenecks and errors • Pinpoint root cause to specific service in your application • Identify impact on users of the application No other ARM provider can get cross-aws-services traces - like browser dev tools for inner aws services - the more serverless is adopted, more worries comes to ARM service-providers minds.
- Explain use-case first
- All have AWS lambda plugins, but limited to your code only (some other metrics via cloudwatch etc). Appdynamics and IOPipe (allegedly - couldn’t test) detect topology, but again - limited to your services only.
- Having said all that - summary: Not the correct approach for every problem It’s a moving target, be flexible, still hard to debug (till x-ray gets out) reduced feedback loop with ‘lean’ approaches Conclusion - With this research I was able to map and resolve many issues. it’s safe to say, in our case, that as soon as x-ray is out - it’s getting in our roadmap.
- Thanks for listening. Here’s how you can find me. Here’s how you can find the code. Keynote will be uploaded soon, we’ll notify by email. By the way - if that sounds interesting we are recruiting. questions?