Scalable applications are by nature resource intensive, expensive to build and difficult to manage. What if we can change this perception and help developers design full-stack applications that are low cost and low maintenance? This session describes the underlying architecture behind www.deep.mg, the microservices marketplace built by Mitoc Group using AngularJS, NodeJS and powered by abstracted services like AWS Lambda, Amazon CloudFront, Amazon DynamoDB, and so on.
Eugene Istrati, Technology Partner at Mitoc Group, will dive deep into their approach to microservices architecture using serverless platform from AWS and demonstrate how anyone can use serverless computing to achieve high scalability, high availability, and high performance without huge efforts or expensive resources allocation.
Serverless Microservices - Real life story of a Web App that uses AngularJS, AWS Lambda and more
1. Serverless Microservices
Real life story of a Web App that uses AngularJS,
AWS Lambda and more
Eugene Istrati, Technology Partner
eugene@mitocgroup.com
www.mitocgroup.com
http://angular.camp
3. About
Eugene Istrati
• eugene@mitocgroup.com
• Partner @ Mitoc Group Inc
• 15+ years in IT; 7+ years on AWS
• AWS Certified Solutions Architect
• Companies: Hearst, Amazon,
GrubHub, Tenaris (Europe)
Mitoc Group Inc
• www.mitocgroup.com
• Technology Company focusing on
Innovative Enterprise Solutions
• AWS Technology Partner
• Featured AWS Lambda Partner
• Media and Entertainment Industry
5. Demo: todo.deep.mg
• Inspired from open source
• www.todomvc.com
• Go to the GitHub repository
• github.com/MitocGroup/deep
-microservices-todomvc
• Follow the steps from Getting
Started to build and deploy
• todo.deep.com
7. 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
8. 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
9. 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
10. 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
11. 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
12. 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
13. 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
14. 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
15. 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
17. AWS Summit NY 2015
Note: Credits and thanks are listed at the end of the presentation
18. Reference Architecture … 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. 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
21. 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
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. 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
34. 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)
35. 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)
37. 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
39. Demo: todo.deep.mg
• Inspired from open source
• www.todomvc.com
• Go to the GitHub repository
• github.com/MitocGroup/deep
-microservices-todomvc
• Follow the steps from Getting
Started to build and deploy
• todo.deep.mg
41. Q&A + Next Steps
github.com/MitocGroup blog.mitocgroup.com
beta@deep.mg
www.deep.mg
Thanks:
Willy & Forest from Open Camps
Hosting team from United Nations
http://angular.camp
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 Serverless Microservices.
This presentation has emerged and evolved over time from our breakout session at AWS re:Invent conference back in October 2015.
My name is Eugene Istrati. I’m the Technology Partner at Mitoc Group. This slide describes a little bit about myself and my company, which is very relevant and important to emphasize the experience, but I won’t spend too much time here.
My presentation today is focused around 3 major concepts: serverless infrastructure, microservices architecture and sample web application with a hands-on demo.
My goal today is to show you hands on the value of serverless microservices. At the end of this presentation, 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’ve launched everything before this webinar, to make sure we don’t spend time waiting.
Let’s begin.
Most of us are using this reference architecture for web applications. 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 web application, 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.
While we were trying to solve these problems for our customers, two major events happened that changed everything.
1. In 2014, at the re:Invent, Amazon launched AWS Lambda, an event-driven computing service for dynamic applications.
And 2. Last year, at NY Summit, AWS launched Amazon API Gateway, a fully managed service for scalable API endpoints.
These 2 new services enabled us to reinvent the reference architecture in a completely serverless approach.
Let’s dive next into serverless microservices.
Every SaaS offering is Serverless. But what does serverless mean? Intuitively, there should be something related to “no servers”. And it is. The key concept is that customers don’t need to deal with servers and all associated operations to keep them up and running at scale. Instead, we are getting abstracted services that are highly secure and highly available, pre-provisioned and pre-scaled.
So, the main question is: How can we get to this serverless architecture? Let me show you how we transformed our customers applications running on reference architecture, explained 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 docker container on steroids. It deploys code 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 nodejs 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. 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 AWS customers like 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, you can choose RDS Aurora. It is a MySQL like database, cloud native and scales seamlessly.
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, 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.
Microservices architecture is the new trend that makes all of us curious and excited. And 2 years ago, it almost didn’t exist.
What does microservices mean? In a nutshell, it’s an architectural pattern that can be applied 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.
Finally, we are getting to our demo.
In this demo, I will achieve the deploy my serverless application to AWS 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 in my own AWS account as a custom web application. Let’s see what happens.
And that concludes my presentation and opens up the floor to questions.