Webinar : Microservices and Containerization
•Als PPTX, PDF herunterladen•
1 gefällt mir•198 views
Webinar : Microservices and Containerization
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Webinar : Microservices and Containerization
Ähnlich wie Webinar : Microservices and Containerization (20)
Mehr von Newt Global Consulting LLC
Mehr von Newt Global Consulting LLC (7)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Webinar : Microservices and Containerization
- 1. 2017 Newt Global |www.NewtGlobal.com | Confidential Follow us on: Microservices Webinar
- 2. Speakers 5/25/2017 Copyright 2 • Venkat is DevOps Practice Leader, His area of expertise includes DevOps Practice, Consult Fortune 100 customers on DevOps IT Strategy. Responsible for building the global pre-sales, consulting and delivery team for NewtGlobal • He has 16+ years of IT industry experience and delivered multiple enterprise scale projects for Fortune 500 customer base Venkatnadhan Thirunalai DevOps, Practice Leader NewtGlobal
- 3. Housekeeping Instructions • All phones are set to mute. If you have any questions, please type them in the Chat window located beside the presentation panel • We have already received several questions from the registrants, which will be answered by the speakers during the Q & A session • We will continue to collect more questions during the session as we receive and will try to answer them during today’s session • In case if you do not receive answers to your question today, you will certainly receive answers via email shortly • Thanks for your participation and enjoy the session! 5/25/2017 Copyright 3
- 4. About Newt Global Onboarding Zone Engineering Zone Re-Architecture Zone DevOps Pipeline CI/CD Enabled QA Infrastructure Automation Cloud Enablement Modernize Architecture Consulting Tool chain selection, Implementation and Integration Test Automation framework, Intelligent # Tag Infrastructure as code. Spin up/down infrastructure on demand and manage it as code Assessment of application Refactor application Data Migration services Micro services based architecture & domain based design Engagements at various levels of maturity Agile Process Benefits: Improve Agility To enable instant change deployment Accelerate time to market Shorten the development to deployment lifecycle Increase Productivity Reduce downtime during deployment & errors caused by manual intervention Enhance ROI Optimize tooling expenditure, increase productivity,
- 5. Monolithic Applications 11/2/2016 Confidential 5 All Module are implemented at in one place(DB-Access, messaging, web components) Difficult to Understand, fixing bugs and implementing new features. Longer start-up time. Difficult to scale and its unreliable. Different modules have conflicting resource requirements. Difficult to adopt new frameworks and languages.
- 6. What are Microservices 16/8/2016 Confidential 6 Monolithic Microservice • In a Microservices Environment Individual Services can be scaled on demand after registering with store front • Each Individual component/Microservice can be individually deployed/Scaled on demand • In a Monolithic Environment Individual Services cannot be scaled on demand • The entire bunch of services have to be scaled impartially • Even a small change entails complete build, test and deploy of the monolith, thereby hampering agility
- 7. Why do we need Microservices 16/8/2016 Confidential 7 Loosely coupled processes Built and deployed by itself Runs in its own process Owns its own data storage Spanning web, mobile and wearable's Development environment of Service may differ Clear ownership for each service
- 8. Microservices - Tackling the Complexity 11/2/2016 Confidential 8 Each microservice is a mini-application that has its own architecture consisting of business logic along with various adapters. Each back-end service exposes a REST API and most services consume APIs provided by other services. Each service has its own database schema. Enables each service to be scaled independently. You can deploy just the number of instances of each service that satisfy its capacity and availability constraints.
- 9. Microservices Scalability 11/2/2016 Confidential 9 Trip Management service deployed with Docker running on Amazon EC2. At runtime, the Trip Management service consists of multiple service instances. Each service instance is a Docker container. Containers are running on multiple Cloud VMs for high availability. Load balancer distributes requests across the instances as well as manages caching, access control, API metering and monitoring.
- 10. Easy to guess the benefits here.!! Tackles the problem of complexity by decomposition into manageable chunks. Service has a well-defined boundary in the form of an RPC or message-driven API. Enforces a level of modularity . Individual services are much faster to develop, much easier to study and maintain. Developers are free to choose whatever technologies make sense, provided that the service honors the API contract. Since services are relatively small it becomes feasible to rewrite an old service using current technology. Each Microservice is deployed independently. CD (DevOps)* Each service can be scaled independently** 5/14/2015 Confidential 10
- 11. Taking Microservices to Production… The first steps •Choose Language? •Choose Concurrency model? •Temporal Decoupling ?
- 12. Monolith to Microservices Rewrite Finding system boundaries New Services Defining Business Events
- 13. Context Mapping
- 14. Some Patterns Backend Service Backend Service 2
- 15. Some Patterns Backend Service Backend Service 2
- 16. Some Patterns Backend Service Backend Service 2
- 17. Some Patterns Circuit Breakers Backend Service Backend Service 2
- 18. Orchestration Of Services in Production: Sample Ecommerce Application Ecommerce UI Search Product Checkout Catalog Payment Product DB Catalog DB Checkout DB Browser Around 1000 users traffic at any given time 995 do window shopping 5 actually add something to cart 3 End up buying something A General Ecommerce Scenario
- 19. Search Search Search Search Non Linear Scaling based on service load Search Product Checkout Catalog Payment Product DB Catalog DB Checkout DB Product Product Product Product Product Search
- 20. Docker in production Quick deployment Resource Management Backup management System security Container monitoring Image and storage management
- 21. Docker Swarm for Container Orchestration
- 24. High Availability and State Replication
- 25. High Availability and State Replication
- 26. Manager Back up Instances
- 27. Manager Back up Instances
- 28. Manager Back up Instances
- 30. Starting of •Start with a boring app and extract •Microservices are complex and create a lot of operational overhead •especially in smaller apps
- 31. Start as a monolith….. Look for a proper use case for microservice CB 4 APP Exception Code Block CB 2 CB 3
- 32. Scaling of the app just for one service CB 4 Exception Code Block CB 2 CB 3 CB 4 Exception Code Block CB 2 CB 3 CB 4 Exception Code Block CB 2 CB 3 APP CB 4 Exception Code Block CB 2 CB 3
- 33. Scaling is simpler Exception CB 4 APP Exception Code Block CB 2 CB 3 ExceptionExceptionExceptionExceptionException
- 34. Database schemas Exception CB 4 APP Exception Code Block CB 2 CB 3 ExceptionExceptionExceptionExceptionException V1 V1
- 35. Database schemas Exception CB 4 APP Exception Code Block CB 2 CB 3 ExceptionExceptionExceptionExceptionException V1 V2
- 36. Database schemas CB 4 APP Exception Code Block CB 2 CB 3 V1 V2 Exception Service … …
- 37. Lock Step Deployments CB 4 APP Exception Code Block CB 2 CB 3 V1 Exception Service … … V1 V2
- 38. Lock Step Deployments CB 4 APP Exception Code Block CB 2 CB 3 V1 Exception Service … … V1 V2
- 39. Solution Semantic Versioning CB 4 APP Exception Code Block CB 2 CB 3 V1 Exception Service … … V1 V1.2
- 40. Solution Semantic Versioning CB 4 APP Exception Code Block CB 2 CB 3 V1.2 Exception Service … … V1.2 V1.2
- 41. Solution Semantic Versioning CB 4 APP Exception Code Block CB 2 CB 3 V1.2 Exception Service … … V1.2 V1.2 Exception Service … … V2
- 42. Solution Semantic Versioning CB 4 APP Exception Code Block CB 2 CB 3 Exception Service … … V1.2 Exception Service … … V2 V2 V2 V1.2
- 43. Use Queues to smoothen your workload
- 44. Database schemas CB 4 APP Exception Code Block CB 2 CB 3 ExceptionExceptionExceptionExceptionException Worker
- 45. Hardcoded IPs and Ports
- 46. Debugging • Use of Correlation IDs APP Microservice Microservice Microservice Microservice CID 15329 CID 15329 CID 15329 CID 15329
- 47. Operational Explosion … PaaS
- 48. Summary Start monolith. Look for reasons why microservices Pay attention to schemas Decouple your services with Queues Use Discovery tools Implement circuit breakers Debugging made simpler with CIDs Use a PaaS
- 49. Thank you
Hinweis der Redaktion
- new application would have a modular hexagonal architecture core of the application is the business logic - modules that define services, domain objects, and events Surrounding the core are adapters that interface with the external world – database access components, messaging components that produce and consume messages, web components that either expose APIs or implement a UI. The application is packaged and deployed as a monolith. applications are packaged as WAR files and deployed on application servers such as Tomcat. Simple to develop, test & deploy . You can implement end-to-end testing by simply launching the application and testing the UI with Selenium -Growing over time – difficult to scaleworld of pain - Any attempts at agile development and delivery will flounder - overwhelmingly complex. monstrous, incomprehensible big ball of mud. All modules are running within the same process, a bug in any module, can potentially bring down the entire sys - extremely difficult to adopt new frameworks and languages - 2 million lines of code from framework XX to YY --You are stuck with whatever technology choices you made at the start of the project. you have a successful business-critical application that has grown into a monstrous monolith that very few developers understand. It is written using obsolete, unproductive technology that makes hiring talented developers difficult. The application is difficult to scale and is unreliable. As a result, agile development and delivery of applications is impossible.
- enabling the agile development and delivery of complex enterprise applications. Amazon, eBay, and Netflix, have solved this problem by adopting what is now known as the Microservices Architecture pattern split your application into set of smaller, interconnected services. A service typically implements a set of distinct features or functionality, such as order management, customer management Each microservice is a mini-application that has its own business logic along with various adapters. Some microservices would expose an API that’s consumed by other microservices or by the application’s clients. Other microservices might implement a web UI. At runtime, each instance is often a cloud VM or a Docker container. web application is split into a set of simpler web applications Each back-end service exposes a REST API and most services consume APIs provided by other services Eg Driver Management uses the Notification server The UI services invoke the other services in order to render web pages Services might also use asynchronous, message-based communication --Inter-service communication REST APIs are also exposed to the mobile apps used by the drivers and passengers X-axis scaling runs multiple instances of each service behind a load balancer for throughput and availability Y-axis scaling decomposes the application into microservices Z-axis scaling (or data partitioning) an attribute of the request (for example, the primary key) is used to route the request to a particular server.
- X-axis scaling runs multiple instances of each service behind a load balancer for throughput and availability. Y-axis scaling decomposes the application into microservices Z-axis scaling (or data partitioning) an attribute of the request (for example, the primary key) is used to route the request to a particular server. Every resource that a microservice uses should be an external one that is provided via a connection string or parameters. For instance; PostgreSQL as a database, RabbitMQ as a messaging service, Redis as a cache provider and S3 or Swift as file storage.
- *Developers dont need to coordinate the deployment of changes that are local to their service. These kinds of changes can be deployed as soon as they have been tested. The UI team can, for example, perform A|B testing and rapidly iterate on UI changes. The Microservices Architecture pattern makes continuous deployment possible. **deploy just the number of instances of each service that satisfy its capacity and availability constraints use the hardware that best matches a service’s resource requirements. deploy a CPU-intensive image processing service on EC2 Compute Optimized instances deploy an in-memory database service on EC2 Memory-optimized instances.
- Quick deployment One of the key features of Docker is its ease of deployment. Containers can be deployed quickly and managed using orchestration tools such as Docker Swarm or Kubernetes. Resource Management Resource management is a very crucial aspect in Docker systems. Host machine resources such as CPU, memory, I/O, etc. are shared among the containers. Over time, traffic spikes can happen and containers may face resource shortage. Not having enough resources can cause containers to crash, thus disrupting the business. Backup management Backups are vital for any live server. Disasters may strike any moment unexpectedly and an unavailable website can lead to a loss of business income. Having backups handy, helps to ensure business continuity and to minimize the downtime. We maintain custom scripts to backup and restore the container data.