Introduction to Microservices and Cloud Native Application Architecture
•Download as PPTX, PDF•
15 likes•19,998 views
Presentation from IBM InterConnect 2015 covering the concepts of 12 Factor Apps and Microservices with reference to IBM Bluemix/Cloud Foundry.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to Introduction to Microservices and Cloud Native Application Architecture
Similar to Introduction to Microservices and Cloud Native Application Architecture (20)
More from David Currie
More from David Currie (15)
Recently uploaded
Recently uploaded (20)
Introduction to Microservices and Cloud Native Application Architecture
- 1. © 2015 IBM Corporation Introduction to Microservices and Cloud Native Application Architecture David Currie, Senior Software Engineer @dcurrie | david_currie@uk.ibm.com
- 2. Agenda • What does it mean to be Cloud Native? • Twelve Factor Apps • What are Microservices? • Developing and Deploying Microservices 1
- 3. What does it mean to be Cloud Native? • Clean contract with underlying OS to ensure maximum portability • Scale elastically without significant changes to tooling, architecture or development practices • Resilient to inevitable failures in the infrastructure and application • Instrumented to provide both technical and business insight • Utilize cloud services e.g. storage, queuing, caching, … • Rapid and repeatable deployments to maximise agility • Automated setup to minimize time and cost for new developers 2
- 5. Twelve Factors I. Codebase II. Dependencies III. Config IV. Backing Services V. Build, release, run VI. Processes VII.Port binding VIII.Concurrency IX. Disposability X. Dev/prod parity XI. Logs XII.Admin processes • One codebase tracked in revision control, many deploys • Bluemix: utilize IBM Bluemix DevOps Services or Cloud Foundry deployment tools (Urban Code Deploy, Gradle, Jenkins, …)
- 6. Twelve Factors I. Codebase II. Dependencies III. Config IV. Backing Services V. Build, release, run VI. Processes VII.Port binding VIII.Concurrency IX. Disposability X. Dev/prod parity XI. Logs XII.Admin processes • Explicitly declare and isolate dependencies • Typically platform dependent e.g. npm, bundler or Liberty feature manager • Never rely on system-wide dependencies • Bluemix: buildpack adds external dependencies
- 7. Twelve Factors I. Codebase II. Dependencies III. Config IV. Backing Services V. Build, release, run VI. Processes VII.Port binding VIII.Concurrency IX. Disposability X. Dev/prod parity XI. Logs XII.Admin processes • Store config in the environment • Separate config from source • Avoid ‘config groups’ • Bluemix: applications parameterized via system provided and custom environment variables
- 8. Twelve Factors I. Codebase II. Dependencies III. Config IV. Backing Services V. Build, release, run VI. Processes VII.Port binding VIII.Concurrency IX. Disposability X. Dev/prod parity XI. Logs XII.Admin processes • Treat backing services as attached resources • Local and remote resources should be treated identically • Bluemix: same mechanism for creating and binding to all services (including custom user provided)
- 9. Twelve Factors I. Codebase II. Dependencies III. Config IV. Backing Services V. Build, release, run VI. Processes VII.Port binding VIII.Concurrency IX. Disposability X. Dev/prod parity XI. Logs XII.Admin processes • Strictly separate build and run stages • Bluemix: output of build and staging is immutable container
- 10. Twelve Factors I. Codebase II. Dependencies III. Config IV. Backing Services V. Build, release, run VI. Processes VII.Port binding VIII.Concurrency IX. Disposability X. Dev/prod parity XI. Logs XII.Admin processes • Execute the app as one or more stateless processes • Never rely on sticky sessions • Bluemix: application instances are stateless (state held by services)
- 11. Twelve Factors I. Codebase II. Dependencies III. Config IV. Backing Services V. Build, release, run VI. Processes VII.Port binding VIII.Concurrency IX. Disposability X. Dev/prod parity XI. Logs XII.Admin processes • Export services via port binding • Bluemix: containers expose HTTP port externalised via route
- 12. Twelve Factors I. Codebase II. Dependencies III. Config IV. Backing Services V. Build, release, run VI. Processes VII.Port binding VIII.Concurrency IX. Disposability X. Dev/prod parity XI. Logs XII.Admin processes • Scale out via the process model • Individual VMs can only scale vertically so far • Stateless nature makes scaling simple • Bluemix: cf scale and auto- scaling service
- 13. Twelve Factors I. Codebase II. Dependencies III. Config IV. Backing Services V. Build, release, run VI. Processes VII.Port binding VIII.Concurrency IX. Disposability X. Dev/prod parity XI. Logs XII.Admin processes • Maximize robustness with fast startup and graceful shutdown • Application instances are disposable • Crash-only design is logical conclusion • Bluemix: architecture can rapidly start and stop instances but need to ensure the application can respond
- 14. Twelve Factors I. Codebase II. Dependencies III. Config IV. Backing Services V. Build, release, run VI. Processes VII.Port binding VIII.Concurrency IX. Disposability X. Dev/prod parity XI. Logs XII.Admin processes • Keep development, staging, and production as similar as possible • Use the same backing services in each environment • Bluemix: use for every environment
- 15. Twelve Factors I. Codebase II. Dependencies III. Config IV. Backing Services V. Build, release, run VI. Processes VII.Port binding VIII.Concurrency IX. Disposability X. Dev/prod parity XI. Logs XII.Admin processes • Treat logs as event streams • Don’t write to log files • Bluemix: loggregator provides event streams for applications; can be drained to third-party log management system
- 16. Twelve Factors I. Codebase II. Dependencies III. Config IV. Backing Services V. Build, release, run VI. Processes VII.Port binding VIII.Concurrency IX. Disposability X. Dev/prod parity XI. Logs XII.Admin processes • Run admin/management tasks as one-off processes • E.g. database migrations or for debugging • Bluemix: push single-shot applications bound to same services
- 31. Monolithic versus Microservices Monolithic Microservice Architecture Built as a single logical executable (typically the server-side part of a three tier client- server-database architecture) Built as a suite of small services, each running separately and communicating with lightweight mechanisms Modularity Based on language features Based on business capabilities Agility Changes to the system involve building and deploying a new version of the entire application Changes can be applied to each service independently Scaling Entire application scaled horizontally behind a load-balancer Each service scaled independently when needed Implementation Typically written in one language Each service implemented in the language that best fits the need Maintainability Large code base intimidating to new developers Smaller code base easier to manage Transaction ACID BASE 30
- 32. Microservice Challenges • Greater operational complexity – more moving parts • Devs need significant ops skills • Service interfaces and versioning • Duplication of effort across service implementations • Additional complexity of creating a distributed system – network latency, fault tolerance, serialization, … • Designing decoupled non-transactional systems is hard • Avoiding latency overhead of large numbers of small service invocations • Locating service instances • Maintaining availability and consistency with partitioned data • End-to-end testing 31
- 34. Reducing Operational Complexity • Platform-as-a-Service exists to remove the complexity of deploying applications – the PaaS provider also handles the complexity of managing and monitoring the infrastructure • Cloud Foundry provides a consistent deployment mechanism regardless of programming language • Buildpacks ensure that applications are kept up-to-date with new versions of the runtime and libraries • Routing and load balancing handled by Cloud Foundry router • Service dependencies are resolved at deployment time • Repeatable deployment through IBM DevOps Services or CLI, Maven/Gradle/Travis/Jenkins plugins (you can even run Jenkins on Cloud Foundry!) • Cloud Foundry V3 API to allow multiple processes per app 33
- 35. Service Discovery • Within a Cloud Foundry environment, routes and the CF router provide all that is needed to locate a service instance • Cloud Controller manages distribution and availability of application instances • Blue-green deployments supported by binding multiple application versions to the same route • cf cups (create user provided service) provides a convenient mechanism to inform one microservice of the route for a microservice on which it is dependent • Where instances of a microservice are deployed to multiple Cloud Foundry environments, consider using a runtime registry e.g. Eureka or highly-available data store e.g. etcd, consul or Zookeeper 34
- 36. Communication Protocols • Cloud Foundry currently only supports inbound HTTP • Web sockets is an option in preference to long polling • JSON may be the best fit for client facing services but consider other options such as Apache Thrift or Google Protocol Buffers where serialization efficiency is important • Typically start with synchronous protocols and add asynchronous (e.g. via MQ Light) where needed to support the interaction style or performance goals • Parallel invocation of downstream services may be required to ensure responsiveness is maintained • Consider using a reactive programming model (e.g. RxJava) or Java 8’s CompletableFuture 35
- 37. Design for Failure • Any service call could fail where failure could be anything from an immediate error code to never returning – need to handle that gracefully • Emphasis on real-time monitoring of technical and business metrics • Application monitoring through Monitoring and Analytics service or third-party service e.g. New Relic • Gives insights which might not be uncovered in a monolithic application • Implement patterns from ‘Release It!’ e.g. via Netflix Hystrix • Circuit Breaker – protect from downstream failures • Bulkhead – limit resources that can be consumed • Timeout • Testing for failures: Simian Army 36
- 38. Questions? 37
- 39. Summary • What does it mean to be Cloud Native? • Twelve Factor Apps • What are Microservices? • Developing and Deploying Microservices 38
- 40. Thank You Your Feedback is Important! Access the InterConnect 2015 Conference CONNECT Attendee Portal to complete your session surveys from your smartphone, laptop or conference kiosk.
- 41. Notices and Disclaimers Copyright © 2015 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in any form without written permission from IBM. U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM. Information in these presentations (including information relating to products that have not yet been announced by IBM) has been reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to update this information. THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY WARRANTY, EITHER EXPRESS OR IMPLIED. IN NO EVENT SHALL IBM BE LIABLE FOR ANY DAMAGE ARISING FROM THE USE OF THIS INFORMATION, INCLUDING BUT NOT LIMITED TO, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF PROFIT OR LOSS OF OPPORTUNITY. IBM products and services are warranted according to the terms and conditions of the agreements under which they are provided. Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice. Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary. References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business. Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation. It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law.
- 42. Notices and Disclaimers (con’t) Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products in connection with this publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to interoperate with IBM’s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. The provision of the information contained herein is not intended to, and does not, grant any right or license under any IBM patents, copyrights, trademarks or other intellectual property right. • IBM, the IBM logo, ibm.com, Bluemix, Blueworks Live, CICS, Clearcase, DOORS®, Enterprise Document Management System™, Global Business Services ®, Global Technology Services ®, Information on Demand, ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, SoDA, SPSS, StoredIQ, Tivoli®, Trusteer®, urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.
Editor's Notes
- We start with the idea of a monolithic application such as the original Acme Air architecture that I showed earlier. We had a single web front end behind which sat a number of components providing capabilities such as authentication, session management, and customer records. These would all run in a single logical process, for example an application server.
- Modularity within the application is typically based on features of the programming language e.g. packages, modules, or OSGi bundles.
- In order to scale the application, we would simply create more instances of that process. There are several disadvantages to this technique. Firstly, it is not possible to scale the components independently. Perhaps the customer data access is resource intensive but, to allow for that, I have to scale the entire application.
- Secondly, as we shall see in more detail later, if one component fails…
- …, it is likely to take out the whole process, and if it fails in once process, …
- … it is likely to take out the whole process, and if it fails in once process, there’s a reasonable chance that it’s going to fail in all of the other processes.
- Even a small change to one component involves re-deploying the entire application. This becomes an inhibitor to performing frequent deploys.
- A monolithic architecture also implies a significant commitment to a particular architecture stack as changing technology decisions often entails a complete rewrite.
- Lastly, there is the impact of monolithic applications on the developer to consider: it is often difficult to scale development activities on a single tightly coupled codebase and it is difficult for new developers to get up to speed.
- In a microservices architecture, the application is broken apart in to independent functions organized around business capability. Each function becomes its own microservice. From Conway’s Law, this means that we should have small development teams, each focused around an individual service working independently from one another (Amazon’s two-pizza teams). Those teams can chose to use the technologies and programming languages most suited to the service that they are aiming to provide. In the Netflix case, that means that is it packaged as a single virtual server instance containing the runtime, code and any ancillary services as a single deployable unit. The image also exposes several common management and monitoring interfaces.
- Communication between microservices is typically REST based. Payload may be JSON or, where serialization efficiency is important, other options such as Apache Thrift or Google Protocol Buffers may be appropriate. Typically applications begin with synchronous communication but, depending on the interaction style, it may be appropriate to introduce asynchronous messaging. Due to the potential for large number of service interactions (in a typical customer facing application, a single front end invocation could spawn off 20-30 calls to services and data sources) parallel invocation may be required to keep latency to a minimum. Options here might include a reactive streams implementation such as Netflix’s RxJava or, for those using Java 8, CompletableFuture.
- Now, when we scale the application, we can scale up and down instances of each service independently. When a service fails, it can fail independently rather than causing the whole application to fail. Having lots of microservices brings it’s own challenges though. For example, you now need to be more rigorous about deployment. We also have to consider how the services will discover one another.
- Now, when we want to make an update, whether that’s a simple code change or a complete change of the technology stack, this can be achieved at the service level. We even have the option to perform canary testing, slowly migrating traffic to the new implementation until we’re ready to remove the old. v Having lots of microservices brings it’s own challenges though. For example, you now need to be more rigorous about deployment. We also have to consider how the services will find one another.