2. What to Expect from the Session
• Problem. Digital platforms at scale are getting slower, cost-
intensive, and vulnerable to various attacks
• Solution. Serverless Platform-as-a-Service on AWS
• Presenter. Why we’re qualified to talk about this topic
• Dive Deep. Technical details, lessons learned, tips and
tricks, and hands-on demos
• Success. Enable customers to achieve more by doing less
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%)
Digital Platform 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
6. About
Eugene Istrati
• eugene@mitocgroup.com
• CTO @ Mitoc Group Inc
• 15+ years in IT; 7+ years on AWS
• AWS Certified Solutions Architect
– Associate Level
• 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: Set up Serverless Environment
• Microservices Architecture
• AWS Lambda in Action
• Tips and Tricks
• Digital Enterprise End-to-end Platform
• Demo: dam.deep.mg
• Q&A + Next Steps
8. 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
9. 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
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
• Huge challenge for breaking
news, viral content, or attacks
• Reduced operational complexity
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
• Reduced operational complexity
• Requires DevOps with experience
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
• Requires DevOps with experience
• Flexible choice of technology
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
• Flexible choice of technology
• Requires devs with rich skill set
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
• Requires devs with rich skill set
• Cost-effective
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
• Cost-effective
• Over-provisioning and over-paying
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
• Over-provisioning and over-paying
18. AWS Summit NY 2015
Note: Credits and thanks are listed at the end of the presentation
19. 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
20. Agenda
• Web Apps Hosting on AWS
• Reference Architecture
• Serverless Architecture
• Demo: Set up Serverless Environment
• Microservices Architecture
• AWS Lambda in Action
• Tips and Tricks
• Digital Enterprise End-to-end Platform
• Demo: dam.deep.mg
• Q&A + Next Steps
21. Serverless Architecture 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
22. 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
23. 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
24. 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
25. 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
26. 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
27. 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
28. • 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
29. Availability Zone A Availability Zone B
Serverless Architecture – DB Tier
DB Tier
SQS DynamoDB
RDS Aurora
30. 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
31. 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
32. 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
33. Agenda
• Web Apps Hosting on AWS
• Reference Architecture
• Serverless Architecture
• Demo: Set up Serverless Environment
• Microservices Architecture
• AWS Lambda in Action
• Tips and Tricks
• Digital Enterprise End-to-end Platform
• Demo: dam.deep.mg
• Q&A + Next Steps
34. Demo: Set up Serverless Environment
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
35. Lessons Learned
• Serverless approach is challengingly awesome
• Frontend is restricted to JS (and JS Frameworks)
• Backend is restricted to JS and Java (for now)
• SOA and APIs are required by design
36. Lessons Learned
• Serverless approach is challengingly awesome
• Frontend is restricted to JS (and JS Frameworks)
• Backend is restricted to JS and Java (for now)
• SOA and APIs are required by design
• Services must be as small as possible
• AWS Lambda constrains
• Browser limitations (on mobile devices)
37. Lessons Learned
• Serverless approach is challengingly awesome
• Frontend is restricted to JS (and JS Frameworks)
• Backend is restricted to JS and Java (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)
39. Recap
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
• Reference architecture for web
application hosting on AWS
40. Recap
• Reference architecture for web
application hosting on AWS
• Transformed to serverless
architecture on AWS
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
41. Agenda
• Web Apps Hosting on AWS
• Reference Architecture
• Serverless Architecture
• Demo: Set up Serverless Environment
• Microservices Architecture
• AWS Lambda in Action
• Tips and Tricks
• Digital Enterprise End-to-end Platform
• Demo: dam.deep.mg
• Q&A + Next Steps
42. Microservices Architecture
Keynote GOTO Conference: Microservices by Martin Fowler -
https://www.youtube.com/watch?v=wgdBVIX9ifA
State of the Art in Microservices -
https://www.youtube.com/watch?v=nMTaS07i3jk
Interprocess
Comms in
Cloud: Pros,
Cons of
Microservices
Architectures -
https://www.youtube.com/watch?v=CriDUYtfrjs
43. 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
44. Agenda
• Web Apps Hosting on AWS
• Reference Architecture
• Serverless Architecture
• Demo: Set up Serverless Environment
• Microservices Architecture
• AWS Lambda in Action
• Tips and Tricks
• Digital Enterprise End-to-end Platform
• Demo: dam.deep.mg
• Q&A + Next Steps
46. AWS Lambda in Action
• AWS Lambda scaled with no effort for us
• 70M+ invocations / day
• 10K+ concurrent invocations / second
47. 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
48. 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)
49. Agenda
• Web Apps Hosting on AWS
• Reference Architecture
• Serverless Architecture
• Demo: Set up Serverless Environment
• Microservices Architecture
• AWS Lambda in Action
• Tips and Tricks
• Digital Enterprise End-to-end Platform
• Demo: dam.deep.mg
• Q&A + Next Steps
50. 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
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
• 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
52. Tips and Tricks – Example
• Identifying UI and UX needs (frontend)
• Show plans and related data points
• Manage credit cards securely
• Download payment receipts
• Identifying REST API calls (backend)
• Endpoint: /plans => 4 Lambdas for CRUD
• Endpoint: /creditcards => 4 Lambdas for CRUD
• Endpoint: /payments => 4 Lambdas for CRUD
• Identifying datasets to be stored (database)
• Entity: Plans
• Entity: CreditCards
• Entity: Receipts
53. Tips and Tricks – Example
• Identifying UI and UX needs (frontend)
• Show plans and related data points
• Manage credit cards securely
• Download payment receipts
• Identifying REST API calls (backend)
• Endpoint: /plans => 4 Lambdas for CRUD
• Endpoint: /creditcards => 4 Lambdas for CRUD
• Endpoint: /payments => 4 Lambdas for CRUD
• Identifying datasets to be stored (database)
• Entity: Plans
• Entity: CreditCards
• Entity: Receipts
54. Tips and Tricks – Example
• Identifying UI and UX needs (frontend)
• Show plans and related data points
• Manage credit cards securely
• Download payment receipts
• Identifying REST API calls (backend)
• Endpoint: /plans => 4 Lambdas for CRUD
• Endpoint: /creditcards => 4 Lambdas for CRUD
• Endpoint: /payments => 4 Lambdas for CRUD
• Identifying datasets to be stored (database)
• Entity: Plans
• Entity: CreditCards
• Entity: Receipts
55. Agenda
• Web Apps Hosting on AWS
• Reference Architecture
• Serverless Architecture
• Demo: Set up Serverless Environment
• Microservices Architecture
• AWS Lambda in Action
• Tips and Tricks
• Digital Enterprise End-to-end Platform
• Demo: dam.deep.mg
• Q&A + Next Steps
68. Recap
• Reference architecture for web
application hosting on AWS
• Transformed to serverless
architecture on AWS
• AWS Lambda in action
69. Recap
• Reference architecture for web
application hosting on AWS
• Transformed to serverless
architecture on AWS
• AWS Lambda in action
• Tips and tricks with an example
70. Recap
• Reference architecture for web
application hosting on AWS
• Transformed to serverless
architecture on AWS
• AWS Lambda in action
• Tips and tricks with an example
• Digital Enterprise End-to-end
Platform
71. Agenda
• Web Apps Hosting on AWS
• Reference Architecture
• Serverless Architecture
• Demo: Set up Serverless Environment
• Microservices Architecture
• AWS Lambda in Action
• Tips and Tricks
• Digital Enterprise End-to-end Platform
• Demo: dam.deep.mg
• Q&A + Next Steps
81. DEEP Value Proposition – Examples
CMS (aka Content
Management System)
DAM (aka Digital
Asset Management)
DMP (aka Data
Management Platform)
for image management for video management
for microsite management for content management
for microsite management for data management
82. DEEP Value Proposition – Examples
CMS (aka Content
Management System)
DAM (aka Digital
Asset Management)
DMP (aka Data
Management Platform)
for image management for video management
for microsite management for content management
for microsite management for data management
83. DEEP Value Proposition – Examples
CMS (aka Content
Management System)
DAM (aka Digital
Asset Management)
DMP (aka Data
Management Platform)
for image management for video management
for microsite management for content management
for microsite management for data management
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.
In this session I will show you how we have built a scalable digital platform on AWS that is fast, secure, low cost and easy to maintain. We will present what we do as a group and dive deep into technical conversations with hands-on examples. Our goal today is to show you the value of microservices architecture on serverless environments and enable you achieve more by doing less.
The fundamental role of every digital platform is to be up and running 24/7. But if you are an employee of BuzzFeed, or New York Media, or Flipkart, you have most probably experienced recently a high level of stress and pressure. In BuzzFeed’s case it was caused by traffic peak generated by the famous article “what is the color of this dress?”. In case of New York Magazine, it was an attack led by some extremist individuals. In case of Flipkart, it was an exclusive launch of a low-cost smartphone that lots of customers wanted. Please raise your hand if you have been in similar situation before? 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. Yes, it was painful.
It is a big concern for us that 87% of attacks affect our digital platforms. 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? Well yes, otherwise I wouldn’t be here :)
We’ve been doing it for a while, constantly helping customers on AWS, business owners or decisions makers, architects or developers, technical or none technical, we help everybody improve their digital platforms. That is how we ended up using serverless and abstracted services from AWS and building Platform-as-a-Service that we call Digital Enterprise End-to-end Platform.
My name is Eugene Istrati. I’m the CTO of 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.
So let’s get started with 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 platform 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, 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.
The main question is: How can we get to the serverless architecture from the reference one? Here is the successful recipe that helped us improve our digital platforms, described 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 CassandraDB or 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 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 60 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.
But before doing that, let’s recap what we have covered so far.
Reference architecture for web application hosting on AWS.
Transformed to serverless architecture on AWS.
Any questions so far? Let’s take only 2 questions, since we have a Q&A session at the end.
Alright. Now the cherry on the top of the cake. Microservices architecture.
Microservices architecture is the new trend that makes all of us curious and excited. My favorite speakers on this topic are Adrian Cockcroft, Technology Fellow at Battery Ventures, and Martin Fowler, Chief Scientist at ThoughtWorks. And there are bunch of re:Invent sessions from last year on youtube, as well as this year, which I will mention at the end.
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 AWS Lambda in action.
This is the diagram of our 3rd iteration of deployment 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 code 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 frontend developers grew a particular attraction for AWS Lambda because it is designed for simplicity, while our devops engineers are still in love-hate mode, trying to learn how to build 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 deployment 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.
For example, let’s take a look at billing feature from our Software-as-a-Service. We needed to show in UI billing plans, manage credit cards and debit cards, as well as provide invoices and receipts. That is what our UI/UX team built in plain HTML, completely decoupled from other teams.
Next, our backend-focused team took this HTML and for each frontend feature-set identified corresponding RESTful API endpoint. Every endpoint exposed 4 Lambdas for each CRUD action: create, retrieve, update, delete.
At the end, our database team came up with json structure that needed to be stored into the database. The beauty of NoSQL databases like DynamoDB is that schemas can change in time without affecting legacy datasets.
Now let me briefly describe what added value our team brings with Digital Enterprise End-to-end Platform.
If you look at AWS Products and Services diagram, we would be a small tiny thing up there on the top right. I don’t expect you guys to see anything, so let me zoom a little bit.
Better now? First of all, Digital Enterprise End-to-end Platform (shortly DEEP) is enabling developers and businesses to achieve more by doing less. Second, DEEP is focusing to make digital platforms low cost and low maintenance by default. And third, DEEP is enforcing security by design, where end users have the flexibility to choose role-based access without having developers to write security specific code.
We are using mainly abstracted services from AWS like CloudFront, Lambda and DynamoDB. And we are integrating them using low cost patterns.
Then, we take the open source projects like node.js and AngularJS. But DEEP is very flexible. Developers could use on frontend AngularJS, or React.js or any other JavaScript framework. As well as on backend node.js, or Java, or any other languages that AWS Lambda will support in the future.
We have abstracted everything in DEEP and created a framework, to make it developer friendly and easier for us to use.
It was built for internal needs, but today I am proud to announce that we are opening it to developers under MIT license.
The core components of the platform are DEEP microservices. They are logically structured to manage frontend, backend and database layers in the same codebase, as well as include unit testing and documentation.
We encourage developers to take a look on GitHub at DEEP Microservices HelloWorld repository. We want to help you to get started as easy as possible and be successful in building serverless digital platforms.
Overall, this Platform-as-a-Services helped us build products and package them as Software-as-a-Service. For example, DEEP Management is a low-cost and low-maintenance digital asset management system, hosted on dam.deep.mg. Next, I will do a short demo of some features in this application.
Alright, final demo.
In this demo, I will achieve the same goal as in previous demo, only this time it is completely automated and UI driven. I will create a property called awsreinvent2015.com, which right now is empty. Next, I will publish the code from GitHub. After couple of clicks in UI, I will go back to awsreinvent2015.com and refresh. Let’s see what happens.
Let’s recap what we have covered so far.
AWS Lambda in action.
Tips and tricks, with a practical example.
And Digital Enterprise End-to-end Platform, running on top of AWS.
And that concludes our presentation and opens up the floor to more questions.