Downloaded 10 times
Uploaded byNewt Global Consulting LLC
Webinar : Microservices and Containerization
- Venkat is the DevOps Practice Leader at NewtGlobal with over 16 years of experience delivering enterprise projects. - The webinar will discuss microservices and include a Q&A session. Questions can be asked in the chat window. - Moving from monolithic to microservices architecture allows individual components to be independently deployed, scaled, and developed using different technologies. This improves agility but also increases complexity.
More Related Content
Similar to Webinar : Microservices and Containerization
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 • Allphones 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 OnboardingZone 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 AllModule 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 Confidential6 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 weneed 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 - Tacklingthe 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 TripManagement 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 guessthe 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 toProduction… The first steps •Choose Language? •Choose Concurrency model? •Temporal Decoupling ?
- 12. Monolith to Microservices Rewrite Findingsystem boundaries New Services Defining Business Events
- 13.
- 14.
- 15.
- 16.
- 17. Some Patterns CircuitBreakers Backend Service Backend Service 2
- 18. Orchestration Of Servicesin 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 SearchSearch 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 Quickdeployment Resource Management Backup management System security Container monitoring Image and storage management
- 21. Docker Swarm forContainer Orchestration
- 22.
- 23.
- 24. High Availability andState Replication
- 25. High Availability andState Replication
- 26. Manager Back upInstances
- 27. Manager Back upInstances
- 28. Manager Back upInstances
- 29.
- 30. Starting of •Start witha boring app and extract •Microservices are complex and create a lot of operational overhead •especially in smaller apps
- 31. Start as amonolith….. Look for a proper use case for microservice CB 4 APP Exception Code Block CB 2 CB 3
- 32. Scaling of theapp 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 CB4 APP Exception Code Block CB 2 CB 3 ExceptionExceptionExceptionExceptionException
- 34. Database schemas Exception CB 4 APP Exception CodeBlock CB 2 CB 3 ExceptionExceptionExceptionExceptionException V1 V1
- 35. Database schemas Exception CB 4 APP Exception CodeBlock CB 2 CB 3 ExceptionExceptionExceptionExceptionException V1 V2
- 36. Database schemas CB 4 APP Exception CodeBlock CB 2 CB 3 V1 V2 Exception Service … …
- 37. Lock Step Deployments CB4 APP Exception Code Block CB 2 CB 3 V1 Exception Service … … V1 V2
- 38. Lock Step Deployments CB4 APP Exception Code Block CB 2 CB 3 V1 Exception Service … … V1 V2
- 39. Solution Semantic Versioning CB4 APP Exception Code Block CB 2 CB 3 V1 Exception Service … … V1 V1.2
- 40. Solution Semantic Versioning CB4 APP Exception Code Block CB 2 CB 3 V1.2 Exception Service … … V1.2 V1.2
- 41. Solution Semantic Versioning CB4 APP Exception Code Block CB 2 CB 3 V1.2 Exception Service … … V1.2 V1.2 Exception Service … … V2
- 42. Solution Semantic Versioning CB4 APP Exception Code Block CB 2 CB 3 Exception Service … … V1.2 Exception Service … … V2 V2 V2 V1.2
- 43. Use Queues tosmoothen your workload
- 44. Database schemas CB 4 APP Exception CodeBlock CB 2 CB 3 ExceptionExceptionExceptionExceptionException Worker
- 45. Hardcoded IPs andPorts
- 46. Debugging • Use ofCorrelation IDs APP Microservice Microservice Microservice Microservice CID 15329 CID 15329 CID 15329 CID 15329
- 47.
- 48. Summary Start monolith. Lookfor 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.
Editor's Notes
- #6 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.
- #9 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.
- #10 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.
- #11 *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.
- #21 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.