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 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.
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.
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.
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.
New Serverless World
Cloud Native Apps
SOLUTION ARCHITECT AT HAUFE-GROUP
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.
Event FasS User
… To Cloud Native Apps
Monolith – Microservices – Serverless
From Servers to Serverless
Cloud providers offers
Serverless Framework & Amazon SAM
◦ Logging and Monitoring
◦ SQL and NoSQL
From Monolith to Serverless
You take care of
Checking if everything
Handle all the overload
Hard to change and
with a lot of effort
Deploy once run
Is self aware
You manage containers
Easy to change and
maintain and scale
You need to take care
Deploy once run
You take care of your
stuff he takes care of
Less Control comes
with Less Responsibility
Easier to interact with
Deploy once run a
couple of minutes
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.
Keeping micro-services stateless and immutable
Focus more on product then infrastructure
No pay for idle
Web Site Storage
Use… as Cloud Logic Layer
 COGNITO IS FREE FOR < 50K MAUS AND $0.00550/MAU ONWARDS.
 LAMBDA IS FREE FOR < 1M REQUESTS AND 400000GB-SECS OF COMPUTE.
 DYNAMODB GIVES 25GB OF FREE STORAGE.
 S3 GIVES 1GB OF FREE TRANSFER.
Service Rate Cost
API Gateway $3.5/M reqs + $0.09/GB transfer $2.20
Lambda Free $0.00
$0.0065/hr 10 write units,
$0.0065/hr 50 read units $2.80
$0.023/GB storage, $0.005/K PUT,
$0.004/10K GET, $0.0025/M
$0.085/GB transfer + $0.01/10K
$0.50 per hosted zone + $0.40/M
Certificate Manager Free $0.00
*1000 daily active users making 20 requests per day to our API and storing around 10MB of files on S3. 6.10$ Per Month.
Microsoft Serverless Offer…
API Management Cosmos DB
Azure Blob Storage
Google Serverless Offer…
Cloud CDN Cloud Storage
Cloud Endpoints Google Cloud BigTable
Different mind set
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
AWS Lambda vs. Azure Cloud Functions
Azure BlobStorage vs. Amazon S3
From Monolith to Microservices
Serverless Architectural Patterns