New Serverless World Cloud Native Apps
•Télécharger en tant que PPTX, PDF•
3 j'aime•795 vues
This document discusses serverless computing and moving from monolithic architectures to serverless. It begins by explaining that serverless allows you to build and deploy code as single functions that are run in response to events, without having to manage infrastructure. It then discusses moving from monoliths to microservices to serverless architectures. The rest of the document covers serverless offerings from AWS, Azure, and Google Cloud, challenges like authentication and monitoring, and strategies for addressing those challenges.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à New Serverless World Cloud Native Apps
Similaire à New Serverless World Cloud Native Apps (20)
Dernier
Dernier (20)
New Serverless World Cloud Native Apps
- 1. New Serverless World Cloud Native Apps MELANIA ANDRISAN SOLUTION ARCHITECT AT HAUFE-GROUP
- 2. Serverless You “play” with functions, You build a function, deploy it as a single unit and the ”Cloud” takes care of everything else. That functions can handle events, save data in your storage or return the data from that storage. Function Event FasS User
- 3. … To Cloud Native Apps Monolith – Microservices – Serverless From Servers to Serverless Cloud providers offers Serverless Framework & Amazon SAM Challenges ◦ Authorization ◦ Orchestration ◦ Security ◦ Logging and Monitoring ◦ SQL and NoSQL
- 5. Microservice Source: http://www.roypetitfils.com/understanding-normal-vs-abnormal-teenager-behavior/
- 7. From Monolith to Serverless You take care of everything Checking if everything is ok Handle all the overload Hard to change and with a lot of effort Deploy once run forever Monolith Is self aware You manage containers Easy to change and maintain and scale Needs orchestration You need to take care of aggregation… Deploy once run forever Microservices Is independent You take care of your stuff he takes care of his Less Control comes with Less Responsibility Easier to interact with Deploy once run a couple of minutes Serverless
- 8. Why Serverless? BECAUSE IN OUR DAYS REQUIREMENTS ARE CHANGING EVERY DAY AND WITH SO FINE GRANULARITY YOU HAVE THE FLEXIBILITY TO SUPPORT THIS FLOW OF REQUIREMENT WITHOUT A LOT OF INVESTMENT.
- 9. Serverless Keeping micro-services stateless and immutable Focus more on product then infrastructure Less Control Less Responsibility Increased Automation Continuous scaling No pay for idle
- 10. 3-tier Architecture Web Site API Gateway Functions Cloud Logic Data Storage Web Site Storage Browser
- 11. Use… as Cloud Logic Layer Google Cloud Functions AWS Lambda Functions Azure Cloud Functions IBM OpenWhisk
- 12. Amazon Serverless Offer… S3 API Gateway AWS Lambda Functions Browser DynamoDB
- 13. Costs… [1] COGNITO IS FREE FOR < 50K MAUS AND $0.00550/MAU ONWARDS. [2] LAMBDA IS FREE FOR < 1M REQUESTS AND 400000GB-SECS OF COMPUTE. [3] DYNAMODB GIVES 25GB OF FREE STORAGE. [4] S3 GIVES 1GB OF FREE TRANSFER.
- 14. Service Rate Cost Cognito Free[1] $0.00 API Gateway $3.5/M reqs + $0.09/GB transfer $2.20 Lambda Free[2] $0.00 DynamoDB $0.0065/hr 10 write units, $0.0065/hr 50 read units[3] $2.80 S3 $0.023/GB storage, $0.005/K PUT, $0.004/10K GET, $0.0025/M objects[4] $0.24 CloudFront (CDN) $0.085/GB transfer + $0.01/10K reqs $0.86 Route53 (DNS) $0.50 per hosted zone + $0.40/M queries $0.50 Certificate Manager Free $0.00 Total $6.10 *1000 daily active users making 20 requests per day to our API and storing around 10MB of files on S3. 6.10$ Per Month. Source: http://serverless-stack.com/chapters/why-create-serverless-apps.html
- 15. Microsoft Serverless Offer… Browser Azure Cloud Functions Azure CDN API Management Cosmos DB Azure Blob Storage
- 16. Google Serverless Offer… Browser Google Cloud Functions Cloud CDN Cloud Storage Cloud Endpoints Google Cloud BigTable
- 17. Let’s put them all together…
- 19. Cloud Formation Azure Resource Manager Template and Azure Function project Google Deployment Manager
- 20. SAM(AWS Serverless Application Model)
- 21. How they work on AWS
- 23. Challenges DEV, AUTHENTICATION, SECURITY, LOGGING AND MONITORING, SQL AND NOSQL
- 24. Development YOU CAN DEVELOP LOCALLY USING SERVERLESS-OFFLINE AND DYNAMODB OFFLINE
- 25. Be a service Customer DESIGN FOR FAILURE PLAN TO BE THROTTLED PLAN TO RETRY (429) CACHE WHEN APPROPRIATE https://www.youtube.com/watch?v=oRIYtOsAlzk
- 26. You can be a Service Provider PUBLISH STANDARD METRICS IMPLEMENTATION DETAILS ARE PRIVATE MAKE BACKWARDS COMPATIBILITY
- 27. Cold Start … … AND STEP FUNCTIONS
- 28. Step Functions
- 29. Authentication & Authorization COGNITO & IDENTITY AND ACCESS MANAGEMENT
- 30. Security SECURITY AT DIFFERENT LEVELS
- 31. Security Firewalls ( network firewalls, application firewalls) Encryption with TLS (Transport Layer Security) across all services DDoS (Distributed Denial of Service) Mitigation Identity and Access Control ◦ IAM(Identity and Access Management) ◦ Multi-factor authentication Penetration Testing … https://d0.awsstatic.com/whitepapers/Security/DDoS_White_Paper.pdf
- 32. Monitoring BUILT IN MONITORING OR OTHERS LIKE NEW RELIC X-RAY DEAD LETTER QUEUE
- 33. AWS CloudTail
- 35. Logging USER STANDARD LOGGING IN YOU APP (DATE-TIME, MODULE, ID, [INFO, DEBUG, ERROR])
- 36. SQL vs. NoSQL SYNCHRONIZING UPDATES DENORMALIZED DB THINK IN TERMS OF QUERIES NOT IN TERMS OF OBJECTS
- 37. DB Transactions BEGIN TRANSACTION. PUT ITEM #1. … PUT ITEM #N. COMMIT TRANSACTION. https://aws.amazon.com/blogs/aws/dynamodb-transaction-library/
- 38. …>25% from Proper Microservices Architecture Security Monitoring and Alerting Continuous Deployment Network and Traffic Configuration Service and Resource Discovery
- 39. AWS
- 40. Azure
- 41. Google Cloud
- 42. Recap Different mind set Good citizenship Build software with grown up solutions Build Infrastructure as code using solutions like Serverless Framework Focus on building extraordinary products not state of the art infrastructure Many offers, many possibilities, you can even combine then The non-functional challenges can be overcome with services
- 43. Resources Serverless Architecture AWS Lambda vs. Azure Cloud Functions Immutable Infrastructure Azure BlobStorage vs. Amazon S3 From Monolith to Microservices Serverless Architectural Patterns
Notes de l'éditeur
- Hi, I am Melania Andrisan, a solution Architect working for Haufe Group in Timisoara, and when I am not in the office I a mom for a beautiful 2 years old girl. I am passionate about new technologies and study the trends as much as I can and as it looks the new architecture trends go into serverless directions. Today I want to give you and overview of my thought regarding serverless, what are the important things which I focused on and also what are the plusses and minuses when we have a look at different other types of architecture.
- I what to tell you a story about three brothers, the monolith the microservice and the serverless and how they grow up together. What are the benefits and what we can do the create an independent serverless child. To be able to have a serverless app we need to rely on the functionality provided by different Cloud providers and all the major providers they have already a vast offer. They offer Authentication, Storage, a way to write your Cloud Logic, Monitoring, Logging and a lot more and in the end we need to be able to put them all together and make our application work. To do that I tried Serverless Framework and had a look at Amazon SAM(Serverless Application Model). Now that I was able to create my app I needed to have a look at different challenges like Authorization, Orchestration, Security (we always need to have I eye on Security) Logging, Monitoring and of course the storage and the challenges when you switch from SQL to NOSQL.
- This is the way I see the monolith brother, he is small, and needs a lot of care, you need to check up on him every time, you cannot leave him alone and changes are pretty hard to make and he will not be so happy about them. He usually knows a language, or at list understands one. You can feed him with all of stuff but instead of growing into an independent little man he will get fatter and fatter and need your help more and more.
- I see the micro-service like a teenager who can take of himself but needs your money to get dresses to eat to go to school, he still needs your help on different stuff but for sure he can do a lot of stuff on his own too. Being able to communicate better to him you are able to make him aware of different changes and when it comes to apply different changes to him this are easy accepted. The teenager usually knows more then one language(polyglot friendly) and you can interact with him more easily.
- And now the Serverless, here she is and independent child with a clear job, you can interact with her from time to time, go for a coffee and get an Email when she has a problem but for sure she does not need your money anymore, you will pay just for the phone call and for the E-mail notification and that’s it. She is a really polyglot knowing languages like Java, Go, c#, JavaScript(node.js)... And a lot more. She is very opened to changes and you can be sure she is available when you need her and also can handle a lot of requests from your part without quitting of letting you with the job not done.
- And know having them side by side. With the monolith you take care of everything, servers, security, firewalls IPs, and all of that. Easy to write in the beginning with hard to change when it grows bigger, and for sure you can deploy it once and it will be alive for as long as you have power and internet to that machine. With microservices is a little bit better, but you need to be careful to no grow your microservice into a monolith. Usually you will mange it by managing containers and being small it handles changes much more easier. Usually you will need and orchestration tool and when it comes to aggregation, there are different possibilities in doing this but for sure a golden rule is that a transaction can only create or update a single aggregate. When It comes to being alive you will deploy the container once and can run forever of for as long as you set it up to be alive. And now with Serverless… is more or less end of the abstraction line, usually is completely independent, you need to write the service handlers and deploy a zip package and that’s it. When you will need them you will relay on the cloud provider that it will answer and give you the needed answer. There are completely state-less and with all of this comes less responsibility from your side but also less control. And one more thing… The function is the unit of deployment and you will deploy them in seconds and It will be alive just for some minutes and I will give you more info in this in a bit. But now… let’s see why serverless?
- More or less was something like, why we did not thought of this till now?... But till you not get through the hard topic and learn from mistakes you do not realize what is the simplest solution to be applied to your problem. And this is what I think happened to Amazon when launched Lambda, they ware changing they apps constantly and used it internally a lot and realized that maybe the entire world should use it because each and every project is changing a lot this days and needs a platform to embrace these changes not fight against them.
- To be able to make everything work you need to make all the services stateless and immutable. Stateless is clear, you do not have state in your service, everything that you need to relay on you need to save it in a form of storage, being it files, blob storage, SQL or NOSQL. When it comes to immutability you can understand different things and here is what I understand: If I have a service and I need to create a new version for it, I just replace what I had before and put the new version instead. If you’ve ever been a Java application developer, the WAR or EAR that Maven generates for you can also be considered “immutable”; it’s a runnable artifact. If you want to make changes to the application, you update the Java source code, recompile into classes, and get a new deployable artifact. As I said, this all comes with less control, less responsibility and increased automation. Other 2 big plusses are that you have a continuous scaling and you pay for what you use when you use it, there is no pay for idle time.
- And now let’s have a look at the classical 3 tiers architecture and what does it means to have it in a Cloud Native App. In a 3-tier architecture usually we have an website, a logic component and a data storage. Of course the website needs to be stored some ware and to access the logic in a common way we can have an API Gateway put in place. To have a website we can have some HTML and JS and publish it, the heavy logic is done in the Cloud Logic and we will see what are the offers on the market.
- What the Cloud Providers offer is this, we have Lambda from Amazon, Azure Cloud Functions from Microsoft, Cloud Functions from Google and the IBM OpenWhisk. I had a look at the first three and this is what I found. Let’s chat adults they built. https://serifandsemaphore.io/azure-cloud-functions-vs-aws-lambda-caf8a90605dd
- Amazon has a very strong implementation for Serverless offering all the needed pieces to go all Serverless. To exposes your Static Website you need to deploy it in S3 and check a check box which says you want to make this content available over HTTP and to accelerate the delivery of your website you can enable a CDN and the Amazon offer for this is Amazon CloudFront. Now that we have our frontend we need to take care of our backend too, to expose properly our Logic written as Lambda Functions we set un an API Gateway which has exactly this name in AWS and for storage there are a lot of offers but to have the DB as service an No-SQL, because this is the trend in serverless, but is not mandatory, we can use DynamoDB, a very strong No-SQL implementation in Amazon which is offered as a service. In case you want to document your API properly the API Gateway documentation generation is done using Swager.
- And here I can give you some costs. A lot of them are free or almost free. For example Lambda is free for 1 million requests.
- Here are some numbers for 1000 active users which make 20 requests/day to our API and store around 10 MB of files. With this number we end up with 6.1 $ a month. A SB coffee. And now let’s see some other offers which have a similar cost.
- The Microsoft offer is relatively similar but the implementation of the Azure Cloud Functions is somehow different. They offer a Web App which has Cloud Functions which share the same memory or you can set up a dynamic Cloud Function which offers the possibility to not pay for idle time. Off course also the implementation of Blob Storage is different from what S3 offers and I have a link in the resources slide which covers this in details but and the end both of them are able to deliver a static website. The database solution with Microsoft is also interesting, offering Cosmos DB as a generic storage with different types of APIs depending o the type of data you want to store in, SQL, key-value or graph. https://azure.microsoft.com/en-us/services/documentdb/ https://docs.microsoft.com/en-us/azure/cosmos-db/create-documentdb-dotnet https://docs.microsoft.com/en-us/azure/cosmos-db/
- And now Google, I was impressed of how nice and consistent have done their documentation. This is shown also in they way they built their icons and everything. Just check it out. A nice to know is that Google Cloud Functions uses just JavaScript with Node.js. The other 2 support all kinds of languages like Java, c#, Go, PHP . Now that we know what we can use we need to put them all together because we do not what to have a lot of different config files for each and every components. https://cloud.google.com/functions/
- And what are the offers in this sense?
- We have serverless framework which can create us a structure of the Serverless project. Even though it says just AWS Lambda on their main page here is what service providers they support:
- And the good part is that it has support for all the major cloud providers.
- Amazon launched SAM at the beginning of this year and it works very similar to Serverless and here is how they do it: https://aws.amazon.com/about-aws/whats-new/2016/11/introducing-the-aws-serverless-application-model/ https://github.com/awslabs/serverless-application-model http://docs.aws.amazon.com/lambda/latest/dg/deploying-lambda-apps.html
- You have your source code in your repository and the definition of your app either in Serverless Framework defined or in SAM, both of them build a Cloud Formation definition and Cloud formation either creates or updates the defined resources. Configure API Gateway, Lambda function, Dynamo DB authorization tags and everything that you can thing of. Now that we know how to put all together there are also other important topics to take into account when you build a real app and I call them Challenges.
- There are a lot of them and I will cover the ones that I found most important like what does it mean to build and user this small services, how the Lambda functions really work and how we can overcome different problems; Authorization and Authentication, security, logging, monitoring and some others. Let’s take them one by one. Serverless Architectural Patterns https://www.youtube.com/watch?v=b7UMoc1iUYw&t=1452s
- For sure is a change in mindset, you are a service customer and you need to be prepared and design for failure, plan to be throttled and also plan to retry when you get a 429, also make sure you will use cache when appropriate.
- On the other hand you can also be the service provider and with this hat you need to be careful and do not expose you implementation details as well as build you services to be backwards compatible.
- And now with our mindset set we will have a look at what Lambda does: Lambda is stateless and every state needs to be stored somewhere, it is deployed in a container and you can not really know for how long it will stay alive, the first time the lambda function is accessed it takes a little bit longer and after that the container is reused Cold start and the initialization phase take longer and it depends if it will affect or not the performance overall but once initialized the container executes just your handler. To make sure the initialization does not takes a lot of time make your Lambda Function as small as possible. To make sure you have a worm function you can use CloudWatch scheduler and worm up your function. Having the lambda functions small comes with another challenge: How you can build complex step machine workflows. Basically how you can do orchestrations? The solution offered by Amazon is Step Functions.
- They look something like this, and can live for days not for minutes like Lambda functions. You can set them up using the UI or the JSON file provided by Amazon and have sequential Steps, Branch Steps or Parallel Steps.
- When it comes to authorize all of this and to authenticate the user Amazon Cognito is an option, you can use your own user pool or create one in Amazon, you can authenticate the user with the received token with which you can authorized further requests to your API. You can set up 2 factor authentication and they also offer a workflow to register users sending them custom verification email and all of that.
- And now Security…
- When it comes to security you can come with a lot of ideas I can tell you a couple of things offered as services by Amazon. They have firewall as service for your app, offer Encryption across all services, they do Mitigation for Distributed Denial of Service attack with for example throttling and offer also a white paper with about 30 pages of description of the problems and their solutions. For Identity and Access control you can use Identity and Access Management Service or Multi-factor authentication. And they even offer you a possibility to ask for a penetration test.
- You can use the AWS Service for monitoring or you can use services like New Relic. In case your service is not responding you can add the error in a Dead Letter Queue, and Build a Lambda Function to do something when something enters in that Queue, you can do even simple things like just sending an Email or an SMS to the On Call developer. They have in case you want to visualize graphically the debug you can use AWS X-Ray. And if you want to have a history of what happened Amazon gives you AWS CloudTail.
- And here is how it works: you have you functions stored in S3, and some clients which will call these APIs, the CloudTail will capture the API activity and log it send it either to S3 for storage or to CloudWatch logs or Events, if you send the logs to CloudWarch events you can triger other Lambda functions to do all sort of things with that data. And some good practice about Logging:
- The idea is to add a date, the module that gives that log some entity id to find it fast and also labels like INFO, DEBUG, ERROR to be able to trigger proper CloudWarch Events when needed. And have a look at Custom CloudWatch metrics. And that’s about it… And a last challenge for this session is Database…
- SQL or NoSQL, to be honest I think you should choose the type of database which suits the task. If you have to many relations between your entities use a SQL DB, if not… have a look at the NoSQL offer. But this is true for all types of architectures. The only big change in mindset is that When you use SQL you thing in terms of objects, and coming from Java or C# is easy to thing in OOP way. When you use NoSQL you thing in terms of Queries and how you can get the needed data in a control doing just a request and no having all sort of joins to handle. Of course thin means you have a deformalized DB and you need to be able to synchronized you update and to handle properly the consistence.
- There are different API that you can use and for JAVA there is also a Transaction API implemented for DynamoDB. For any other languages there is a batchUpdateItem API which can be used. Or there is now a new trend which says you update the DB after every field update, in this case you do not loose anything but you pay for multiple updates. As you see, there are different options and depending what you want to trade off you choose one possibility over the other.
- They say the development is just 75% from the time of your project the other 25% is spent on this topics like security, networking and others. I touched a couple of them there are so may other things that you can think of like CD, Resource Discovery, Caching, Queuing, Handle Slow responses and in the lasts 2 years Amazon tried to find solutions for a lot of them, and the same did the others.
- Here is Amazon.
- This is MS
- And here is Google
- Some resources https://medium.freecodecamp.com/how-you-can-speed-up-serverless-development-by-simulating-aws-lambda-locally-41c61a60fbae