Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Serverless microservices

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.

  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Serverless microservices

  1. 1. Serverless Microservices Lalit Kale https://ie.linkedin.com/in/lalitkale
  2. 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. 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. 4. Overview • Introduction • Business Shift • Cloud Computing • Understanding Cloud Services Models • Compute Evolution in Cloud • Serverless Technologies • Microservices 4
  5. 5. Business Shift 5
  6. 6. In The Beginning… 6
  7. 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. 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. 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. 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. 11. So What’s changed? – Customer Perspective 11 Pay As you GoSmooth Customer Onboarding Rapid and Painless Innovation Simplified IT Management Available Everywhere
  12. 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. 13. Managing Demand Time IT Capacity Entry barrier Under capacity Over capacity Forecast demand Potential business loss Wasted capacity Compute capacity
  14. 14. Demand Burst Time IT Demand Concert ticket web site Ticket sales open Ticket sales open Ouch! How do we deal with this?
  15. 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. 16. Cloud Computing 16
  17. 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. 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. 19. Understanding Cloud Services Models 19
  20. 20. 21
  21. 21. Compute Evolution in Cloud 22
  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. 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. 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. 25. Containerization – Paradigm Shift 26 Fig: Comparing Containers with Virtual Servers
  26. 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. 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. 28. Serverless – Paradigm Shift 29
  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. 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. 31. AWS Serverless Offerings 32
  32. 32. 33
  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. 34. Common serverless use cases 35
  35. 35. Microservices 36
  36. 36. Systems and Modules • Allow for independent working • Single Responsibility • Reuse • Namespaces, Packages 37
  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. 38. Microservices, when done right, are a form of modular architecture - Sam Newman, Microservices Expert
  39. 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. 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. 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. 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. 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. 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. 45. Information Hiding 46
  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. 47. API Contract 48
  48. 48. API Contract 49
  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. 50. Application Programming Interface 51
  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. 52. Microservice Architecture 53
  53. 53. Databases in Microservices 54
  54. 54. Databases in Microservices 55
  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. 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. 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. 58. Conway’s Law Org Structure Architectural Capabilities
  59. 59. Reversing the Conway’s Law • Two Pizza Teams focused on Business Capability • You Build it, You Run it! • Microservices
  60. 60. Importance of Automation 61
  61. 61. Server To Digital Platform Journey 62
  62. 62. Serverless Microservices – Real World Example 63 https://github.com/awslabs/serverless-image-handler
  63. 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. 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. 65. Q & A 66
  66. 66. Thank You! 67
  67. 67. Backup Slides 68
  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. 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. 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

×