Serverless microservices

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

20. 21

21. Compute Evolution in Cloud 22

22. 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

23. 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

24. 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

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

26. 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

27. • 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

28. Serverless – Paradigm Shift 29

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

30. 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

31. AWS Serverless Offerings 32

32. 33

33. 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

34. Common serverless use cases 35

35. Microservices 36

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

37. 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

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

39. 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.

40. 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

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

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

43. 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

44. 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

45. Information Hiding 46

46. 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.

47. API Contract 48

48. API Contract 49

49. 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/

50. Application Programming Interface 51

51. 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

52. Microservice Architecture 53

53. Databases in Microservices 54

54. Databases in Microservices 55

55. 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

56. 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

57. 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

58. Conway’s Law Org Structure Architectural Capabilities

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

60. Importance of Automation 61

61. Server To Digital Platform Journey 62

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

63. 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

64. 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

65. Q & A 66

66. Thank You! 67

67. Backup Slides 68

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

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

70. . 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