Presentation created for Third and Final Year students of , The Department of Information Technology, Bharati Vidyapeeth (Deemed to be University) College of Engineering, Pune. Collage has invited myself for a training program on “Recent Trends in Information Technology”. I presented on topic of "Serverless Microservices". It is Level-100 Session.

1. Serverless Microservices
Lalit Kale
https://ie.linkedin.com/in/lalitkale

2. Preface
• Audience:
• Engineering Students, faculties
• interested in software design and development
• having trouble in understanding and Implementing software design Principles and Patterns
• People who are keen on improving their craft
• Presentation:
• Approx. Time: ~2 Hour (1 hr. + 5 min break + 30 min + 20 min Q&A )
• No need to take notes. This presentation will be available at https://www.slideshare.net/lalitkale
• This is introduction of topic. Advanced Level topics are not covered.
• Code Snippets to understand the concepts
• All Views/Opinions expressed here are mine and nothing to do with my current/past employers
2

3. About Me
• 15 years in industry
• solution architect at Verizon Connect, Dublin, Ireland
• Interests: software architecture, distributed Systems and
internet scale systems
• Using AWS Cloud since 2006
• Published book on Microservices in 2017 – “Building
Microservices with .NET Core”

4. Overview
• Introduction
• Business Shift
• Cloud Computing
• Understanding Cloud Services Models
• Compute Evolution in Cloud
• Serverless Technologies
• Microservices
4

5. Business Shift
5

6. In The Beginning…
6

7. Once Upon a time..
• Late 1990’s –
• Internet in formed from ARPANET with
HTML
• Mosaic – first web browser
• Yahoo! Search engine
• Amazon.com is formed as online
bookstore
• Start of web programming
7

8. Software Business - 1990’s To 2000’s
• Era of Desktop computers
• Software sales: per user
• Medium: CD/DVD
• Ex. Microsoft Office
• Software Releases: Annual
• Upgrades: Sold separately
• Markets: Regional
• Rate of innovation: slow
• Project Management Methodology:
Waterfall methodology
• Internet Speed: Slow
• Popular websites: Yahoo! AOL, Hotmail
8

9. Software Business - 1990’s To 2000’s
• On-Premise Computing
• Business’s own large-scale datacenters
• Requires hardware, space, electricity, cooling
• Requires managing OS, applications and updates
• Software Licensing
• Difficult to scale
• Too much or too little capacity
• High upfront capital costs
• You have complete control and Responsibility
9

10. Software Business Shift
• 1990’s To 2000’s
• Era of Desktop computers
• Software sales: per user
• Medium: CD/DVD
• Ex. Microsoft Office
• Software Releases: Annual
• Upgrades: Sold separately
• Markets: Regional
• Rate of innovation: slow
• Project Management Methodology:
Waterfall methodology
• Internet Speed: Slow
• Popular websites: Yahoo! AOL, Hotmail
10
• 2010 - 2020
• Era of Mobile and 4G/5G Internet
• Software Sales Model: Freemium
model or “pay as you use” or
subscription model
• Ex: Google office
• Software Releases: Continuous
• Upgrades: Free
• Markets: Global
• Rate of innovation: Rapid
• Project Management Methodology:
Agile (Scrum, Kanban)
• Internet Speed: Ultra-Fast
• Popular websites: Google, Amazon,
Netflix, Facebook, WhatsApp, Flipkart

11. So What’s changed? – Customer Perspective
11
Pay As you GoSmooth Customer
Onboarding
Rapid and
Painless Innovation
Simplified IT
Management
Available Everywhere

12. Software Company (ISV) Perspective
12
Increased Agility
Expanded markets and Global Reach
Improved Operational
Efficiency Through
Multitenancy
Increased margins
Through economy of scale
Customer
Demand

13. Managing Demand
Time
IT Capacity
Entry barrier
Under capacity
Over capacity
Forecast demand
Potential
business loss
Wasted
capacity
Compute capacity

14. Demand Burst
Time
IT Demand
Concert ticket web site
Ticket sales open
Ticket sales open
Ouch! How do we deal with this?

15. IT Agility
• How quickly can you
• Scale up the infrastructure and applications?
• Upgrade to the latest OS?
• Respond to a company merger with new requirements for business process
and IT capacity?
• Respond to a selling off a company

16. Cloud Computing
16

17. Cloud Computing - A Simple Definition
Making computing resources available as a utility service
Just like the National Electricity Grid
Electricity:
No need to know about how or where it’s generated
Available through a well defined interface
Available everywhere and for many devices
Power output, scales on demand
Low capital expenditure for consumers
Pay for what you use
Reliable

18. Cloud Computing - Characteristics
• Shared, multi-tenant environment
• Pools of computing resources
• Resources available on demand
• Available via the Internet
• Private clouds can be available via private WAN
• Pay as you go

19. Understanding
Cloud Services Models
19

21. 21

22. Compute Evolution in Cloud
22

23. Virtual Machines
• Hardware virtualization is the virtualization of computers as complete hardware platforms,
certain logical abstractions of their componentry, or only the functionality required to run
various operating systems. Virtualization hides the physical characteristics of a computing
platform from the users, presenting instead an abstract computing platform
• Hardware independence
• Faster provisioning speed (minutes/hours)
• Trade capex for opex
• More scale
• Elastic resources
• Faster speed and agility
• Reduced maintenance
23

24. Applications Migration To Virtual Machines
• Lift and Shift Migration Strategy
• Lift-and-shift is the process of migrating a
workload from on premise to Cloud with
little or no modification. A lift-and-shift is a
common route for enterprises to move to
the cloud, and can be a transitionary state to
a more cloud native approach.
• Pros:
• Minimum work required to move
• Faster migration and deployment
• Cons:
• Typically does not take full advantages of
cloud platforms features
• In some cases may cost more to operate in
cloud
24

25. Containerization – Paradigm Shift
• Containerization is defined as a form of operating system virtualization, through which
applications are run in isolated user spaces called containers, all using the same shared operating
system (OS). A container is essentially a fully packaged and portable computing environment:
• Everything an application needs to run – its binaries, libraries, configuration files and dependencies – is encapsulated
and isolated in its container.
• The container itself is abstracted away from the host OS, with only limited access to underlying resources – much like
a lightweight virtual machine (VM).
• As a result, the containerized application can be run on various types of infrastructure—on bare metal, within VMs,
and in the cloud—without needing to refactor it for each environment.
• Containerization Engines: Docker, Rkt, Runc
25

26. Containerization – Paradigm Shift
26
Fig: Comparing Containers with Virtual Servers

27. Containerization – Paradigm Shift
• Package Software into Standardized
Units for Development, Shipment and
Deployment
• Platform independence
• Consistent runtime environment
• Higher resource utilization
• Easier and faster deployments
• Isolation and sandboxing
• Start speed (deploy in seconds)
27

28. • Still Some overheads
• Operating Systems patching and
upgrades
• Container runtime version and
choice
• Network access and firewall
configuration
• Choice of security hardening
solution
• System access permissions
• Need orchestrator like Kubernetes
or Mesos for scaling
28
Containerization – Paradigm Shift

29. Serverless – Paradigm Shift
29

30. Serverless
Serverless is a methodology for planning, building and deploying
software in a way that maximizes value by minimizing undifferentiated
heavy lifting…” – Jeremy Daly

31. Serverless – Paradigm Shift
• Amazon pioneered this deployment architecture with their “AWS Lambda “ Service
• Serverless does not mean absence of servers. However, all the operational responsibility of
provisioning, scaling and operating systems management is given to cloud vendor
• Every Cloud Vendor has their serverless offerings.
• Amazon AWS – Lambda, Step Functions, API Gateway, AppSync
• Microsoft Azure – Azure Functions, Azure Durable Functions
• Google – Functions, Pub/Sub Flow, Firebase
31

32. AWS Serverless Offerings
32

33. 33

34. Benefits of Serverless
34
Focusing on what is
important to your
business
Faster time to
market
Reduce initial
investment
Automagical
scalability
Modular and
decouple
architecture

35. Common serverless use cases
35

36. Microservices
36

37. Systems and Modules
• Allow for independent working
• Single Responsibility
• Reuse
• Namespaces, Packages
37

38. Microservices
• Flavor of distributed system
• “Modules” run on different computers
• Communication between the modules
are done via network calls
• Allows for easier independent
deployability
38

39. Microservices, when done right,
are a form of modular
architecture
- Sam Newman, Microservices Expert

40. Martin Fowler on Microservices
• The microservice architectural style is an approach to developing a single
application as a suite of small services, each running in its own process and
communicating with lightweight mechanisms, often HTTP resource API.
• These services are built around business capabilities and independently
deployable by fully automated deployment machinery.
• There is a bare minimum of centralized management of these services, which
may be written in different programming languages and use different data
storage technologies.

41. Microservices and Information Hiding
• “On the Criteria To Be Used in Decomposing Systems into Modules” – D.L. Parnas , 1971
• Looked at how to best define module boundaries and found that “information hiding”
worked best
• The effectiveness of a “modularization” is dependent upon the criteria used in dividing the
system into modules
• “module” = Work Assignment Unit
• Development time should be shortened because separate groups can work on each module
(microservice) with little need for communication.
• Product flexibility should be improved – it was hoped that it would be possible to make quite
drastic changes or improvements in one module (microservice) without changing others.
• Comprehensibility – it was hoped that the system could be studied a module (microservice)
at a time with the result that the whole system could be better designed because it was
better understood.
41
https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria_for_modularization.pdf

42. Not Information Hiding?
• If an upstream consumer can reach
into your internal implementation..
• Then you can’t change this
implementation without breaking
consumer
42

43. Not Information Hiding?
• If an upstream consumer can reach
into your internal implementation..
• Then you can’t change this
implementation without breaking
consumer
43

44. Information Hiding
• Hide your secrets (state)!
• Be Explicit about what is shared and
what is hidden
• Hidden Things can change, shared
things can’t
44

45. Information Hiding
• “The Connections between modules
are the assumptions which modules
make about each other” – D.L.Parnas
• Information hiding is about reducing
the assumptions one module has on
another.
• JSON Schemas help to remove the
assumptions and establish contracts
45

46. Information Hiding
46

47. Application Programming Interface
47
• An application programming interface (API) is a computing interface which
defines interactions between multiple software intermediaries. It defines the
kinds of calls or requests that can be made, how to make them, the data formats
that should be used, the conventions to follow, etc.
• In case of microservices, generally API referred to Web API.

48. API Contract
48

49. API Contract
49

50. Most Used API Types
50
Simple Object Access Protocol
(SOAP)
This is a standard protocol that defines how
two objects in different processes can
communicate through XML data exchange.
Representational State Transfer
(REST)
This is a simple way to send and receive data
between the client and server and does not
have many standards. It can send and receive
JSON, XML or plaintext.
API: https://api.google.com/v1/tag/
Endpoint: /v1/tag/

51. Application Programming Interface
51

52. AWS API Gateway
52
Backend For
FrontEnd
•Unify
multiple
microservices
under single
API front-end
Security
•Authenticate
and authorize
the requests
•DDOS
protection
Throughput
•Throttling
•Rate Limiting

53. Microservice Architecture
53

54. Databases in Microservices
54

55. Databases in Microservices
55

56. Designing Microservices
• ‘Micro’ is misleading most of implementations
• It is NOT about how many lines of code in your microservice have
• Should be Manageable by a small, self-sufficient team
• Evolutionary design

57. Principles of Microservices
Deployment
Technology
Versions
Languages
Infrastructure
Operations
Developm
ent
Testing
Security
Fail
Predictably
No SPoF
Automated
Recovery
Based on Business
Capability
Single
Responsibility
Hide
‘Implementation
’
Independence Independence Independence IsolationIndependence Automation Fail-Safe

58. Conway’s Law
"Any organization that designs a system (defined more broadly here
than just information systems) will inevitably produce a design whose
structure is a copy of the organization's communication structure.“
-Melvin Conway

59. Conway’s Law
Org Structure Architectural Capabilities

60. Reversing the Conway’s Law
• Two Pizza Teams focused on Business Capability
• You Build it, You Run it!
• Microservices

61. Importance of Automation
61

62. Server To Digital Platform Journey
62

63. Serverless Microservices – Real World Example
63
https://github.com/awslabs/serverless-image-handler

64. Summary
• Cloud Computing is the de-facto way now for the industry to develop
and deploy the applications.
• Microservices architecture style is suitable for large scale systems
where business needs to respond to new challenges.
• Using Serverless technologies like from AWS Lambda, application
delivery can be faster and software engineers and developers can
focus on delivering business value.
• Learn and adopt serverless microservices today!
64

65. Resources
• https://martinfowler.com/articles/microservices.html
• https://docs.aws.amazon.com/whitepapers/latest/microservices-on-
aws/introduction.html
• https://arxiv.org/pdf/1902.03383.pdf=> research paper => Cloud
Programming Simplified: A Berkeley View on Serverless Computing
• https://aws.amazon.com/education/awseducate
• https://github.com/awslabs/serverless-image-handler
• Example = Profile-Photo Service
• https://image-processing.serverlessworkshops.io/
• https://www.cloudflare.com/learning/serverless/glossary/serverless-
microservice/
65

66. Q & A
66

67. Thank You!
67

68. Backup Slides
68

69. Cloud Vendors and their Offerings
• Microsoft – Azure Cloud
• Amazon – Amazon Web Services (AWS)
• Google – Google Cloud Platform (GCP)
• Others – IBM, Cloudflare, DigitalOcean
69

70. Geo-Distributed Datacentres
Larger Cloud vendors have proven track records for running services for large numbers of
customers hosted in their own datacentres

71. .
This presentation is shared under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license. More information for this license is available at http://creativecommons.org/licenses/by-nc-sa/4.0/
All trademarks are the property of their respective owners. Lalit Kale makes no warranties, express, implied or statutory, as to the information in this presentation.
Lalit Kale
https://ie.linkedin.com/in/lalitkale