Microservices Architecture for MEAN Applications using Serverless AWS
•Télécharger en tant que PPTX, PDF•
7 j'aime•3,741 vues
Digital platforms are by nature resource intensive, expensive to build, and difficult to manage at scale. What if we can change this perception and help MEAN developers architect a digital platform that is low cost and low maintenance? This session describes the underlying architecture behind www.deep.mg, the microservices marketplace built by Mitoc Group and powered by AWS abstracted services like AWS Lambda, Amazon CloudFront, and Amazon DynamoDB. Eugene Istrati, the CTO of Mitoc Group, will dive deep into their approach to microservices architecture on serverless environments and demonstrate how anyone can architect AWS abstracted services to achieve high scalability, high availability, and high performance without huge efforts or expensive resources allocation.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Microservices Architecture for MEAN Applications using Serverless AWS
Similaire à Microservices Architecture for MEAN Applications using Serverless AWS (20)
Dernier
Dernier (20)
Microservices Architecture for MEAN Applications using Serverless AWS
- 1. Microservices Architecture for MEAN Applications using Serverless AWS http://www.meetup.com/MEAN-Stack-NYC/events/225892962 Eugene Istrati, Technology Partner eugene@mitocgroup.com www.mitocgroup.com
- 2. © 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved. Eugene Istrati, Partner @ Mitoc Group Microservices Architecture for Digital Platforms with AWS Lambda, Amazon CloudFront, and Amazon DynamoDB eugene@mitocgroup.com October 2015 ARC201
- 3. Web Applications Challenges Note: Credits and thanks are listed at the end of the presentation … … …
- 4. Average cost of downtime • $500K - $1M / hour (IDC, Dec 2014) • $140K - $540K / hour (Garner, July 2014) • $474K / hour (Ponemon Inst., Dec 2013) Most commonly reported consequences • Damage to reputation (38%) • Increase in customer churn (37%) • Damage to credit rating (28%) • Increase to insurance premiums (26%) Web Applications Challenges 27% 60% 13% Outage Degradation No impact 0% 20% 40% 60% 80% Impact of DoS/DDoS Attack Note: Credits and thanks are listed at the end of the presentation
- 5. Digital Enterprise End-to-end Platform
- 6. About Eugene Istrati • eugene@mitocgroup.com • Partner @ Mitoc Group Inc • 15+ years in IT; 7+ years on AWS • AWS Certified Solutions Architect (re-certified at re:Invent 2015) • Companies: Hearst, Amazon, GrubHub, Tenaris (Europe) Mitoc Group Inc • www.mitocgroup.com • Web Development Studio • AWS Technology Partner • Focusing on enterprise applications and platforms • Working with customers from media and entertainment industry
- 7. Agenda • Web Apps Hosting on AWS • Reference Architecture • Serverless Architecture • Demo: Setup Serverless AWS • Microservices Architecture • Powered by AWS Lambda • Tips and Tricks • Demo: todo.deep.mg • Q&A + Next Steps
- 8. Demo: todo.deep.mg • Inspired from open source • www.todomvc.com • Go to the GitHub repository • github.com/MitocGroup/deep -microservices-todo-app • Follow the steps from Getting Started to build and deploy • todo.deep.com
- 9. Agenda • Web Apps Hosting on AWS • Reference Architecture • Serverless Architecture • Demo: Setup Serverless AWS • Microservices Architecture • Powered by AWS Lambda • Tips and Tricks • Demo: todo.deep.mg • Q&A + Next Steps
- 10. Web Apps Hosting / Reference Architecture Availability Zone A Availability Zone B Auto Scaling Group Auto Scaling Group www.example.com static.example.com web servers web servers app servers app servers • Scales in minutes
- 11. Web Apps Hosting / Reference Architecture Availability Zone A Availability Zone B Auto Scaling Group Auto Scaling Group www.example.com static.example.com web servers web servers app servers app servers • Scales in minutes • Huge challenge for breaking news, viral content, or attacks
- 12. Web Apps Hosting / Reference Architecture Availability Zone A Availability Zone B Auto Scaling Group Auto Scaling Group www.example.com static.example.com web servers web servers app servers app servers • Scales in minutes • Huge challenge for breaking news, viral content, or attacks • Reduced operational complexity
- 13. Web Apps Hosting / Reference Architecture Availability Zone A Availability Zone B Auto Scaling Group Auto Scaling Group www.example.com static.example.com web servers web servers app servers app servers • Scales in minutes • Huge challenge for breaking news, viral content, or attacks • Reduced operational complexity • Requires DevOps with experience
- 14. Web Apps Hosting / Reference Architecture Availability Zone A Availability Zone B Auto Scaling Group Auto Scaling Group www.example.com static.example.com web servers web servers app servers app servers • Scales in minutes • Huge challenge for breaking news, viral content, or attacks • Reduced operational complexity • Requires DevOps with experience • Flexible choice of technology
- 15. Web Apps Hosting / Reference Architecture Availability Zone A Availability Zone B Auto Scaling Group Auto Scaling Group www.example.com static.example.com web servers web servers app servers app servers • Scales in minutes • Huge challenge for breaking news, viral content, or attacks • Reduced operational complexity • Requires DevOps with experience • Flexible choice of technology • Requires devs with rich skill set
- 16. Web Apps Hosting / Reference Architecture Availability Zone A Availability Zone B Auto Scaling Group Auto Scaling Group www.example.com static.example.com web servers web servers app servers app servers • Scales in minutes • Huge challenge for breaking news, viral content, or attacks • Reduced operational complexity • Requires DevOps with experience • Flexible choice of technology • Requires devs with rich skill set • Cost-effective
- 17. Web Apps Hosting / Reference Architecture Availability Zone A Availability Zone B Auto Scaling Group Auto Scaling Group www.example.com static.example.com web servers web servers app servers app servers • Scales in minutes • Huge challenge for breaking news, viral content, or attacks • Reduced operational complexity • Requires DevOps with experience • Flexible choice of technology • Requires devs with rich skill set • Cost-effective • Over-provisioning and over-paying
- 18. Web Apps Hosting / Reference Architecture Availability Zone A Availability Zone B Auto Scaling Group Auto Scaling Group www.example.com static.example.com web servers web servers app servers app servers • Scales in minutes • Huge challenge for breaking news, viral content, or attacks • Reduced operational complexity • Requires DevOps with experience • Flexible choice of technology • Requires devs with rich skill set • Cost-effective • Over-provisioning and over-paying
- 19. AWS re:Invent 2014 Note: Credits and thanks are listed at the end of the presentation
- 20. AWS Summit NY 2015 Note: Credits and thanks are listed at the end of the presentation
- 21. Web Apps Hosting … Reinvented Availability Zone A Availability Zone B Auto Scaling Group Auto Scaling Group www.example.com static.example.com web servers web servers app servers app servers S3 bucket CloudFront distribution Web Tier Cognito Identity DB Tier SQS DynamoDB LambdaCloudFront logs API Gateway www.example.com static.example.com App Tier AWS Region RDS Aurora
- 22. Agenda • Web Apps Hosting on AWS • Reference Architecture • Serverless Architecture • Demo: Setup Serverless AWS • Microservices Architecture • Powered by AWS Lambda • Tips and Tricks • Demo: todo.deep.mg • Q&A + Next Steps
- 23. What does “serverless” mean? Not involving a server; composed only of clients. http://www.wordsense.eu/serverless Serverless doesn’t mean servers are no longer involved. It simply means that developers no longer have to think "that much" about them. Computing resources get used as services without having to manage around physical capacities or limits. https://www.quora.com/What-is-Serverless-Computing
- 24. Serverless vs. Reference Availability Zone A Availability Zone B Auto Scaling Group Auto Scaling Group www.example.com static.example.com web servers web servers app servers app servers S3 bucket CloudFront distribution Web Tier Cognito Identity DB Tier SQS DynamoDB LambdaCloudFront logs API Gateway www.example.com static.example.com App Tier AWS Region RDS Aurora vs
- 25. Serverless Architecture – Web Tier S3 bucket CloudFront distribution Web Tier Cognito Identity CloudFront logs www.example.com static.example.com Availability Zone A Availability Zone B Auto Scaling Group www.example.com static.example.com web servers web servers
- 26. Serverless Architecture – Web Tier S3 bucket CloudFront distribution Web Tier Cognito Identity CloudFront logs www.example.com static.example.com • Static Assets • Same as in reference architecture • css, js, docs, images, videos + html • Dynamic Functionality • Use JS framework (e.g. Angular) • SEO-friendly (Custom Error Response + HTML5 History API) • Completely Serverless • Pre-scaled • Low-cost • Low-maintenance
- 27. Serverless Architecture – Web Tier S3 bucket CloudFront distribution Web Tier Cognito Identity CloudFront logs www.example.com static.example.com • Static Assets • Same as in reference architecture • css, js, docs, images, videos + html • Dynamic Functionality • Use JS framework (e.g. Angular) • SEO-friendly (Custom Error Response + HTML5 History API) • Completely Serverless • Pre-scaled • Low-cost • Low-maintenance
- 28. Serverless Architecture – Web Tier S3 bucket CloudFront distribution Web Tier Cognito Identity CloudFront logs www.example.com static.example.com • Static Assets • Same as in reference architecture • css, js, docs, images, videos + html • Dynamic Functionality • Use JS framework (e.g. Angular) • SEO-friendly (Custom Error Response + HTML5 History API) • Completely Serverless • Pre-scaled • Low-cost • Low-maintenance
- 29. Serverless Architecture – App Tier Cognito Identity SQS Lambda API Gateway App Tier Availability Zone A Availability Zone B Auto Scaling Group app servers app servers
- 30. Cognito Identity SQS Lambda API Gateway App Tier • Accelerated Backend • Write node.js functions and load into Lambda • Power up Lambda with RESTful endpoints on API Gateway • Cache, throttle, meter, version, etc. • Completely Serverless • Pre-scaled • Low-cost • Low-maintenance Serverless Architecture – App Tier
- 31. • Accelerated Backend • Write node.js functions and load into Lambda • Power up Lambda with RESTful endpoints on API Gateway • Cache, throttle, meter, version, etc. • Completely Serverless • Pre-scaled • Low-cost • Low-maintenance Serverless Architecture – App Tier Cognito Identity SQS Lambda API Gateway App Tier
- 32. Availability Zone A Availability Zone B Serverless Architecture – DB Tier DB Tier SQS DynamoDB RDS Aurora
- 33. DB Tier SQS DynamoDB RDS Aurora Serverless Architecture – DB Tier • First choice – DynamoDB + SQS • Schema-free • Scale only reads and writes • Completely Serverless • Pre-scaled • Low-cost • Low-maintenance • Next choice – RDS Aurora • Relational • MySQL-like approach, but 5x better
- 34. Serverless Architecture – DB Tier • First choice – DynamoDB + SQS • Schema-free • Scale only reads and writes • Completely Serverless • Pre-scaled • Low-cost • Low-maintenance • Next choice – RDS Aurora • Relational • MySQL-like approach, but 5x better DB Tier SQS DynamoDB RDS Aurora
- 35. Serverless Architecture – DB Tier • First choice – DynamoDB + SQS • Schema-free • Scale only reads and writes • Completely Serverless • Pre-scaled • Low-cost • Low-maintenance • Next choice – RDS Aurora • Relational • MySQL-like approach, but 5x better DB Tier SQS DynamoDB RDS Aurora
- 36. Agenda • Web Apps Hosting on AWS • Reference Architecture • Serverless Architecture • Demo: Setup Serverless AWS • Microservices Architecture • Powered by AWS Lambda • Tips and Tricks • Demo: todo.deep.mg • Q&A + Next Steps
- 37. Demo: Setup Serverless AWS 1. Security - Create IAM roles 2. Front-end - Create S3 bucket - Enable static website hosting - Add bucket policy - Create CloudFront distribution 3. Back-end - Create Lambda function - Upload code into Lambda - Create API Gateway endpoint 4. Database - Create DynamoDB table 5. Code - Load code into S3 bucket - View via CloudFront (S3 as backup) S3 bucket CloudFront distribution Web Tier Cognito Identity DB Tier SQS DynamoDB LambdaCloudFront logs API Gateway www.example.com static.example.com App Tier AWS Region RDS Aurora
- 38. Lessons Learned • Serverless approach is challengingly awesome • Frontend is restricted to JS (and JS Frameworks) • Backend is restricted to Python, Java or JS (for now) • SOA and APIs are required by design
- 39. Lessons Learned • Serverless approach is challengingly awesome • Frontend is restricted to JS (and JS Frameworks) • Backend is restricted to Python, Java or JS (for now) • SOA and APIs are required by design • Services must be as small as possible • AWS Lambda constrains • Browser limitations (on mobile devices)
- 40. Lessons Learned • Serverless approach is challengingly awesome • Frontend is restricted to JS (and JS Frameworks) • Backend is restricted to Python, Java or JS (for now) • SOA and APIs are required by design • Services must be as small as possible => microservices • AWS Lambda constrains • Browser limitations (on mobile devices)
- 41. Agenda • Web Apps Hosting on AWS • Reference Architecture • Serverless Architecture • Demo: Setup Serverless AWS • Microservices Architecture • Powered by AWS Lambda • Tips and Tricks • Demo: todo.deep.mg • Q&A + Next Steps
- 42. What does “microservices” mean? In computing, microservices is a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language- agnostic APIs. These services are small, highly decoupled and focus on doing a small task, facilitating a modular approach to system- building. https://en.wikipedia.org/wiki/Microservices
- 43. Microservices Architecture Keynote GOTO Conference: Microservices by Martin Fowler - https://www.youtube.com/watch?v=wgdBVIX9ifA State of the Art in Microservices by Adrian Cockcroft - https://www.youtube.com/watch?v=nMTaS07i3jk Sam Newman at ThoughtWorks London 2015: Deploying and Operating Microservices - https://www.youtube.com/watch?v=OTSlg7_y3bA
- 44. Speeding Up Digital Platforms on AWS Deploy in weeks Live for years Deploy in minutes Live for weeks Deploy in seconds Live for minutes/hours Deploy in milliseconds Live for seconds On-Premises Amazon EC2 Amazon ECS AWS Lambda
- 45. Agenda • Web Apps Hosting on AWS • Reference Architecture • Serverless Architecture • Demo: Setup Serverless AWS • Microservices Architecture • Powered by AWS Lambda • Tips and Tricks • Demo: todo.deep.mg • Q&A + Next Steps
- 46. Powered by AWS Lambda
- 47. AWS Lambda in Action • AWS Lambda scaled with no effort for us • 70M+ invocations / day • 10K+ concurrent invocations / second
- 48. Web Apps Hosting / Reference Architecture Availability Zone A Availability Zone B Auto Scaling Group Auto Scaling Group www.example.com static.example.com web servers web servers app servers app servers • Scales in minutes • Huge challenge for breaking news, viral content, or attacks • Reduced operational complexity • Requires DevOps with experience • Flexible choice of technology • Requires devs with rich skill set • Cost-effective • Over-provisioning and over-paying
- 49. AWS Lambda in Action • AWS Lambda scaled with no effort for us • 70M+ invocations / day • 10K+ concurrent invocations / second • AWS Lambda made it really easy for us • Comes pre-scaled and charges in 100ms blocks • No under- or over-provisioning (by design) • Developers love it (especially frontend JS folks) • DevOps still in play mode (learning to build ops code)
- 50. Agenda • Web Apps Hosting on AWS • Reference Architecture • Serverless Architecture • Demo: Setup Serverless AWS • Microservices Architecture • Powered by AWS Lambda • Tips and Tricks • Demo: todo.deep.mg • Q&A + Next Steps
- 51. Tips and Tricks • AWS Lambda is continuously evolving • Set up alarms for all 4 Lambda metrics in Amazon CloudWatch • Avoid S3 throttling by integrating S3 => SNS => Lambda • Beware of potential infinite loops
- 52. Tips and Tricks • AWS Lambda is continuously evolving • Set up alarms for all 4 Lambda metrics in Amazon CloudWatch • Avoid S3 throttling by integrating S3 => SNS => Lambda • Beware of potential infinite loops • Microservices are game changers • The shorter TTL, the more secure it becomes • First, build a service or a feature • Next, break it down into microservices
- 53. Tips and Tricks – From Monolithic Approach applicationsdevelopers Build Test Release development cycle
- 54. Tips and Tricks – To Microservices Approach applicationsdevelopers Build Test Release development cycle Build Test Release Build Test Release Build Test Release Build Test Release Build Test Release Build Test Release
- 55. Agenda • Web Apps Hosting on AWS • Reference Architecture • Serverless Architecture • Demo: Setup Serverless AWS • Microservices Architecture • Powered by AWS Lambda • Tips and Tricks • Demo: todo.deep.mg • Q&A + Next Steps
- 56. Demo: todo.deep.mg • Inspired from open source • www.todomvc.com • Go to the GitHub repository • github.com/MitocGroup/deep -microservices-todo-app • Follow the steps from Getting Started to build and deploy • todo.deep.com
- 57. DEEP Framework https://github.com/MitocGroup/deep-framework “DEEP Framework is a serverless web framework, core component of the Platform-as-a-Service that abstracts web apps and web services from specific cloud providers. This framework enables developers build cloud-native applications or platforms using microservices architecture in a completely serverless approach”
- 58. Agenda • Web Apps Hosting on AWS • Reference Architecture • Serverless Architecture • Demo: Setup Serverless AWS • Microservices Architecture • Powered by AWS Lambda • Tips and Tricks • Demo: todo.deep.mg • Q&A + Next Steps
- 59. Q&A + Next Steps github.com/MitocGroup medium.com/@MitocGroup beta@deep.mg www.deep.mg Thanks: http://www.meetup.com/MEAN-Stack-NYC/events/225892962 Darryle Steplight from MEAN Stack NYC Meetup Hosting Team from Talener
- 60. Credits and Thanks • Slide 3: Digital Platforms Challenges • http://www.buzzfeed.com/daozers/what-its-like-to-work-on-buzzfeeds-tech-team-during-record-t#.axR6WG9Yr • http://www.dailydot.com/crime/new-york-magazine-ddos-bill-cosby-cover/ • http://www.cio.in/topstory/flipkart%E2%80%99s-cto-explains-the-xiaome-launch-outage • Slide 4: Digital Platforms Challenges • http://www.slideshare.net/Radware/radware-cmg2014-tammyevertsslowtimevsdowntime • http://www.statuscast.com/application-downtime-according-to-idc-gartner-and-others • https://press.kaspersky.com/files/2014/11/B2B-International-2014-Survey-DDoS-Summary-Report.pdf • Slide 19: AWS re:Invent 2014 • https://venturebeat.com/wp-content/uploads/2014/11/aws-reinvent-lambda.png • Slide 20: AWS Summit NY 2015 • https://d0.awsstatic.com/events/aws-hosted-events/2015/AWS-Global-Summit-Series/new-york/press-room/introducing-amazon-api- gateway.jpg • Slide 46: Microservices Architecture • https://www.youtube.com/watch?v=nMTaS07i3jk - State of the Art in Microservices by Adrian Cockcroft • https://www.youtube.com/watch?v=wgdBVIX9ifA - Microservices by Martin Fowler • https://www.youtube.com/watch?v=OTSlg7_y3bA - Deploying and Operating Microservices by Sam Newman
Notes de l'éditeur
- Hello everybody and welcome! Thank you for taking the time to attend this session. I feel very humble and honored to be here today to talk about Microservices Architecture. The more I dive into microservices, the more it reminds me of the joke: That any software program can be reduced to one line of code ... that has a bug. I hope my presentation is better than my joke :)
- This talk is an evolution from my last month presentation at AWS re:Invent conference.
- The fundamental goal of every web application is to be up and running 24/7. But it’s a huge challenge to do it at scale. It recently happened to BuzzFeed, when they published this article that went viral. And New York Media when they have been hacked. And Flipkart, when their exclusive launch of low cost smartphone went wrong. Do you guys remember recent attacks on Github? Please raise your hand if you had similar scalability issues that brought down your web applications in the past. PAUSE. Me too, I have personally experienced a similar situation when Michael Jackson died in 2009 and the breaking news brought down our entire digital platform for a couple of hours. It was painful an unpleasant discussion with my manager.
- It is a big concern for us that 87% of attacks affect our applications. The average downtime costs us hundreds of thousands and millions of dollars per hour, not to mention damages in reputation and credit rating, customer churn and insurance increases. So is there something, that we can easily change in our architecture, that will solve these problems fundamentally?
- We’ve been doing it for a while, constantly helping customers, business owners or decisions makers, architects or developers, technical or none technical, we help making resilient web applications. That is how we ended up using abstracted services from AWS and building Platform-as-a-Service that we call Digital Enterprise End-to-end Platform, shortly deep.
- My name is Eugene Istrati. I’m the Technology Partner at Mitoc Group. I have been in IT for over 15 years, with last 7 years working on AWS. I am certified solution architect who worked at companies like Hearst, Amazon, GrubHub and Tenaris. Mitoc Group is a web development studio that focuses on enterprise applications and platforms. We are official AWS Technology Partner and most of our customers are media and entertainment companies.
- My presentation is focused around 3 major topics in context of MEAN applications: serverless architecture, microservices architecture and hands-on demos.
- My goal today is to show you hands on the value of microservices. At the end of this talk, I will demo some steps from our development process, based on the code that currently runs on todo.deep.mg. Because the initial provisioning takes some time, I’ll fire it up now, at the beginning of the presentation and spend the rest of the time explaining and showing.
- What is the reference architecture for web applications hosting on AWS?
- By the show of hands, let’s see how many of us are using this 3 tier architecture? PAUSE. Awesome! In a nutshell, the infrastructure spreads across multiple availability zones, which means it is running in separate physical datacenters that are millisecond latency apart from each other. Therefore it is no surprise that this architecture scales in minutes.
- But if you have experienced before breaking news, or viral content, or various attacks on your digital platforms, you know that scaling in minutes is just not enough. We had to build by ourselves additional complexity to scale the infrastructure faster and meet the spiking demands.
- Using this architecture on AWS makes it easier for us to maintain and support. Less operations makes the application less complex.
- But we still needed experienced devops engineers to do so.
- As developers, we can choose whatever technology stack we would like to use: Java or C#, Python or Ruby, Scala or Go, JavaScript or JavaScript.
- But we had to recruit and hire developers with rich skillset, who are able to build and support the entire technology stack.
- And, of course, this architecture is cost effective, if we implement it properly. We are paying only for resources that we are using.
- But when the infrastructure doesn’t scale fast enough to meet the demand, our engineering teams are over-provisioning to solve short-term problems and buy time until they figure out long-term solutions. Please raise your hand if you have done it before. PAUSE. Don’t tell my boss, but I did it as well.
- While we were trying to solve these problems for our customers, two major events happened that changed everything.
- 1. Last year, at the re:Invent, Amazon launched AWS Lambda, an event-driven computing service for dynamic applications.
- And 2. This year, at NY Summit, AWS launched Amazon API Gateway, a fully managed service for scalable API endpoints.
- These two new services enabled us to reinvent the reference architecture in a completely serverless approach.
- So let’s dive into serverless architecture next.
- What does serverless mean? Intuitively, there should be something related to “no servers”. And it is. Developers don’t need to deal with servers and all associated operations to keep them up and running at scale. Instead, developers get abstracted services that are highly secure and highly available, pre-scaled and pre-provisioned.
- So, the main question is: How can we get to the serverless architecture from the reference one? Let me show you how we did it, layer by layer.
- First question, how can we transform the web tier into a serverless one? Most of us think of S3 as a storage service available over the Internet. We think of S3 as a cluster of web servers behind load balancers that have turned off server side scripting modules. It is secured through IAM and there is no need to worry about underlying infrastructure.
- As we are doing this transformation, the static component stays exactly the same as in reference architecture. We load everything into S3: css, javascript, documents, images, videos. And even html, which usually is served by EC2.
- Because S3 doesn’t allow server side scripting, we use client side languages like JavaScript to add dynamic functionality. Modern JavaScript frameworks like AngularJS caught up a lot lately to other popular web frameworks. They provide similar patterns and best practices like Symfony, or Django, or Rails. And they are very friendly with search engines, allowing indexing of both new applications and legacy applications.
- But the biggest benefit – it is completely serverless. The infrastructure comes pre-scaled at AWS size, which is virtually infinite. I have heard some people saying quote: “You will reach your budget faster than AWS will reach its physical limits”. And the bigger it is, the better it gets and the lower it costs.
- Now let’s see how we transformed our app tier into a serverless one. AWS Lambda can roughly be described as a node.js environment running in a docker container. It deploys in milliseconds and executes code in seconds. Like in case of web tier, it is secured through IAM and there is no need to worry about underlying infrastructure.
- Because of the way Lambda is designed, we get out of the box an accelerated backend that has short time to live. We are writing small functions, loading them into Lambda, and consuming them through API Gateway. It is also possible to call Lambda directly, but then you need to build by yourself caching and throttling, metering and versioning. Why would you do that, when this comes pre-built into API Gateway?
- And like in case of web tier, it is completely serverless.
- How do we transform the database tier into a serverless one? We encourage all of us to use DynamoDB because the only operations you care about are reads per second and writes per second. And like in case of both web tier and app tier, it is secured through IAM and there is no need to worry about underlying infrastructure.
- DynamoDB is an amazing schema-less key-value database like MongoDB. We only increase or decrease, reads or writes, independently from each other. But at scale, by itself, DynamoDB could be cost intensive. Did anyone hear of Shazam, a mobile app that recognizes music and tv around you? I think they were the first to blog about offloading writes to SQS. We virtually put SQS in front of DynamoDB and store datasets into the queue that later gets asynchronously saved into the database. Apparently, this “eventual consistency” pattern saved Shazam 50% of their database cost.
- And again, guess what? It is completely serverless.
- But if you are for some reason coupled to relational databases, try out RDS Aurora. It is a MySQL like database, cloud native and scales seamlessly.
- I hope you guys are excited enough to see a demo of a serverless environment.
- In this demo I will setup from scratch a serverless environment in my AWS account by going through these 5 steps. I will be mindful of our time and setup only most relevant AWS services and features. This will enable my account to run my web application that I have in my GitHub. Provisioning in CloudFront could take up to 15 minutes, so if it will not be ready, I will show the website from S3. Cool? Ok, let’s do it.
- What did we learn? Well, serverless approach is awesome and has its own challenges. Some developers might find these challenges unpleasant and unwanted. We actually appreciate them a lot because it enabled us to achieve more by doing less. For example, dealing only with JavaScript allowed us to focus and avoid endless programming languages flame wars. Or, another example, not having alternatives to Services Oriented Architecture and Application Programming Interfaces forced everybody on the team to commit and build SOA and APIs.
- SOA also means we build services. But a service on AWS Lambda is constrained by design to 300 seconds execution time and 1.5G of memory. Not to mention browsers limitations with responsive design, especially on mobile devices.
- That is why we have turned to microservices architecture, which I will be talking about next.
- Alright. Microservices architecture.
- What does microservices mean? In a nutshell, it’s an architectural pattern that can be applied nowadays almost anywhere, either we are talking about infrastructure, or platform, or application. Think of it like a shredder for monoliths, that makes from complex into simple and from difficult into easy. If it’s software driven, it could be designed as microservices.
- Microservices architecture is the new trend that makes all of us curious and excited. My favorite speakers on this topic are Adrian Cockcroft, Martin Fowler and Sam Newman.
- I mentioned Adrian Cockcroft for two reasons: 1. He is Netflix former Chief Architect, famous for pioneering and evangelizing microservices architecture and 2. In his presentation State of the Art in Microservices, Adrian is talking about how to speed up platforms. The milliseconds in deployment time and seconds in execution time really pushed us and turned us into early adopters of AWS Lambda.
- Let me show you Microservices Architecture powered by AWS Lambda.
- This is the diagram of our 3rd iteration of publishing workflow, which by the way we have completely messed up in the first 2 iterations. If you would like to hear the story of those iterations, please ask me after the session, because it is kind of embarrassing. Back to 3rd iteration, the context here is that our digital asset management customers have lots of assets, microsites and static marketing websites. We helped them to migrate on AWS with just one click. The source of assets was in GitHub, or Subversion, or internal infrastructure, somewhere really hard to get. Either way, we have build a series of Lambda functions that a) get raw files into inbound S3 bucket, b) process / extract / transform / load into DynamoDB or S3, and c) move processed files into outbound S3 bucket.
- That being said, AWS Lambda scaled for us with absolutely no effort whatsoever. It is not BuzzFeed’s 670 thousands requests per second, but we are getting there.
- And remember the challenges that I have pointed out in the first part of this presentation?
- AWS Lambda solved them all out of the box. We love its pre-scaled nature that enables us to avoid under-provisioning and over-provisioning. Our developers grew a particular attraction for AWS Lambda because it is designed for simplicity. While our DevOps team is still experimenting and rethinking the ops code.
- Let me share with you some tips and tricks.
- AWS Lambda is about one year old, so be open minded while building code and expect the unexpected. Make sure you setup alarms in CloudWatch. You will thank me later for that. Also, SNS has a nice “delivery policy” feature that avoids at scale some throttling between S3 and Lambda direct integration. And beware of potential infinite loops, which happened to us in version 1 of the publishing workflow. We had 2 developers built 3 Lambda functions that ended up calling each other forever. This is one of those embarrassing stuff.
- Microservices are game changers that enable speed and security, because it is much harder to figure out how to attack something that quickly disappears. But if you are coming from monolithic architecture, a practical approach is to build a service or feature first and then break it down into microservices.
- Traditional or monolithic development process looks something like this, where lots of developers are expected to follow the same process.
- Microservices architecture empowers and enables developers to be independent, self sufficient, highly decoupled and focused on small and simple. But most important, it helps developers to define their own process and follow their own pace. I personally love it and would never go back to monolithic architecture.
- Alright, and there we are, at the final demo.
- In this demo, I will achieve the same goal as in the previous demo, only this time it is completely automated. I will go to GitHub and follow the steps from README, Getting Started section. After couple of command line executions, I will load in the browser the clone of todo app, that will be running my own AWS account as an web application. Let’s see what happens.
- I would like to call out DEEP Framework, a collection of nodejs libraries that abstracts web applications and web services from specific cloud providers. We currently built it on top of AWS, and we plan to add additional support for Google Cloud or Microsoft Azure, hopefully with additional help from the community.
- And that concludes our presentation and opens up the floor to more questions.