Enabling Microservices from Startups to the Enterprise
•Télécharger en tant que PPTX, PDF•
1 j'aime•444 vues
Technology has become a competitive differentiator for modern enterprises as they navigate consumer expectations. Their customers want high performance, high availability, scalability, as well as new features that are shipped early and often. At the same time, the monolithic architectures that traditionally power enterprise applications make it difficult to scale, manage upgrades, and launch new services quickly. In the last few years, microservices have come to the forefront of the conversation. Microservices have been rapidly adopted due to their ability to provide modularity, scalability, high availability, as well as facilitate organizational alignment. Join us in this online event, where we will bring together two practitioners of Microservices, Jon Dokulil, VP of Engineering at sports software startup <a>Hudl</a>, and Yursil Kidwai, VP of Technology at <a>UPS i-Parcel</a>, to showcase * How they moved to a microservices architecture * Their implementation process * How they used microservices to better align their organization to ship code faster and cut costs
Recommandé
Recommandé
Contenu connexe
Plus de MongoDB
Plus de MongoDB (20)
Dernier
Dernier (20)
Enabling Microservices from Startups to the Enterprise
- 2. Agenda 1. Introduction to Microservices 2. UPS and Hudl Microservices Discussion 3. Q&A #mongodbwebinar
- 3. The Monolithic Application UI Layer Applicaton Layer Database Layer #mongodbwebinar
- 5. The Monolithic Approach Simple at first In-process latencies Single codebase, deploy unit Resource efficient at small scale Coordination overhead becomes more challenging Scaling characteristics are poor No decoupling Continuous Delivery is challenging PROS CONS #mongodbwebinar
- 6. What are Microservices? • Software architecture where applications are broken down into small autonomous services • Services focused on single purpose and decoupled by business boundaries • Each service is developed, tested, and deployed independently — modular and independent • Simple well defined interface that communicate over network over agreed APIs • Decoupled databases for each service #mongodbwebinar
- 8. Microservices Organizational Alignment Team Product CatalogTeam User Account Team Inventory Team Shopping Cart microservice microservice microservice microservice #mongodbwebinar
- 9. Considerations to Keep In Mind • Monitoring Challenges • More Operations Overhead • Incorrect Service boundaries • Expect Failure #mongodbwebinar
- 10. You Don’t Choose Chaos Monkey… Chaos Monkey Chooses You #mongodbwebinar
- 11. Why MongoDB is a good fit for Microservices Flexible data model Redundancy Monitoring & automation Scalability Expressive Query Language #mongodbwebinar
- 12. { first_name: ‘Paul’, surname: ‘Miller’, city: ‘London’, location: [45.123,47.232], cars: [ { model: ‘Bentley’, year: 1973, value: 100000, … }, { model: ‘Rolls Royce’, year: 1965, value: 330000, … } ] } MongoDB Document Model with Flexible Schema RDBMS #mongodbwebinar
- 13. An Expressive Query Language Rich Queries • Find Paul’s cars • Find everybody in London with a car between 1970 and 1980 Geospatial • Find all of the car owners within 5km of Trafalgar Sq. Text Search • Find all the cars described as having leather seats Aggregation • Calculate the average value of Paul’s car collection Map Reduce • What is the ownership pattern of colors by geography over time (is purple trending in China?) #mongodbwebinar
- 14. Replica Sets • Replica set – 2 to 50 copies • Makes up a self-healing ‘shard’ • Data center aware • Addresses: – High availability – Data durability, consistency – Maintenance (e.g., HW swaps) – Disaster Recovery A Single Shard #mongodbwebinar
- 15. Elastic Scalability withAutomatic Sharding • Increase or decrease capacity as you go • Automatic load balancing • Three types of sharding – Hash-based – Range-based – Tag-aware #mongodbwebinar
- 16. Ops Manager and Microservices Ops Manager allows you leverage and automate the best practices we’ve learned from thousands of deployments in a comprehensive application that helps you run MongoDB safely and reliably. Benefits include: 10x-20x more efficient operations Complete performance visibility Protection from data loss Assisted performance optimization #mongodbwebinar
- 17. MongoDB Atlas Features Database as a service for MongoDB MongoDB Atlas is… • Automated: The easiest way to build, launch, and scale apps on MongoDB • Flexible: The only database as a service with all you need for modern applications • Secured: Multiple levels of security available to give you peace of mind • Scalable: Deliver massive scalability with zero downtime as you grow • Highly available: Your deployments are fault-tolerant and self-healing by default • High performance: The performance you need for your most demanding workloads #mongodbwebinar
- 18. Resources • Case Study – FuboTV https://www.mongodb.com/blog/post/leaf-in-the-wild-leading- soccer-streaming-service-fubotv-scales-its-business-with- mongodb-docker-containers-and-kubernetes • Case Study – Square Enix https://www.mongodb.com/blog/post/leaf-in-the-wild-square- enix-scales-tomb-raider-hitman-absolution-deus-ex-and- more-on-mongodb • “Enabling Microservices – Containers & Orchestration Explained” white paper https://www.mongodb.com/collateral/microservices- containers-and-orchestration-explained • “Microservices: The Evolution of Building Modern Applications” white paper https://www.mongodb.com/collateral/microservices-the- evolution-of-building-modern-applications #mongodbwebinar
- 19. Jon Dokulil - VP of Engineering @jdokulil #mongodbwebinar
- 20. We help teams and athletes win.
- 21. We have products for teams at every level of competition. #mongodbwebinar
- 22. We work with the world’s best. #mongodbwebinar
- 23. #mongodbwebinar
- 24. #mongodbwebinar
- 25. #mongodbwebinar
- 27. Why MongoDB We experiment often ● Document model fits well with OO mindset ● Code is the schema ● Great scaling story #mongodbwebinar
- 28. Why MongoDB Fast Failovers ● Losing a primary no longer goes to PagerDuty ● DB maintenance is less scary #mongodbwebinar
- 29. 34 replica sets 5 versions (3.2.5 - 3.2.9) 3.2 billion documents 2.0 TB of data #mongodbwebinar
- 30. 34 replica sets 5 versions (3.2.5 - 3.2.9) 3.2 billion documents 2.0 TB of data 4 sharded clusters #mongodbwebinar
- 32. #mongodbwebinar
- 33. Lessons Learned ● Conway’s Law is legit, embrace it ● Full separation between services (no mullet services) #mongodbwebinar
- 35. Lessons Learned ● Conway’s Law is legit, embrace it ● Full separation between services (no mullet services) ● Invest in your foundation #mongodbwebinar
- 36. Questions?
Notes de l'éditeur
- If building monolith today it would probably look something like this UI Layer – Javascript if it’s on the web, IOS or Java or Android if building for mobile Application Layer – Written in Ruby or PHP Database at bottom Monoliths aren’t all bad. Many reasons why you would choose a Monolith architecture but it is the large scale problems where monoliths breakdown
- Web application that offers different functions such as Product Catalog, User Account, Inventory, Shopping Cart UI, Application and database are all confined in a single monolithic application. Application is a deployment monolith: It can only be deployed in it’s entirety. Whenever a feature is changed, the entire application needs to be recompiled, relinked, and test and deployed anew for even the smallest incremental release.
- Simple well defined interface that is modular, essential just SOA done properly with well defined principles Microservice term is new, but concept is old
- Functions are decoupled into four separate services (separate WAR files) and organized by business boundaries Web pages, Classes, Config files to a service are grouped together Services can evolve and iterate independently as each team can develop, test, and deploy code separately
- Microservices support team independence. Teams have more responsibilities. Teams decide architecture and own everything from Dev, QA, Test to what technology is used. Enable fragmentation of large organization into smaller ones. The need for communication decreases and allow teams to focus more on the implementation of the requirements. Changes and deployment of individual microservices are possible without complex coordination. This supports agile development.
- Monitoring -Difficulty when managing 100s of services -Automation is key High Skillset -Tight interlock between DevOps, testing and release. Developers need operations background as well. More Operations Overhead -More services = more monitoring, testing -Need to be quickly propagated through CD pipeline Incorrect Service Boundaries Problem is to create services from internal components without considering proper service boundaries. End up building giant monolith
- Chaos Monkey is a service which identifies groups of systems and randomly terminates one of the systems in a group. The service operates at a controlled time (does not run on weekends and holidays) and interval (only operates during business hours). In most cases we have designed our applications to continue working when a peer goes offline, but in those special cases we want to make sure there are people around to resolve and learn from any problems. With this in mind Chaos Monkey only runs in business hours with the intent that engineers will be alert and able to respond. Distributed systems have high complexities and require a high developer skillset. In order to handle the extra complexity, developers need to have a strong operations and production background.
- Flexible data model Fits in with the need to be agile Redundancy MongoDB replica sets -> can perform online upgrades and easily cope with rescheduling Monitoring & automation You have lots of moving parts in a microservice architecture – need to monitor and automate as much as possible Scalability MongoDB sharding lets your database scale just as easily as your stateless microservices Remember web-scale? Best practice for each service to have its own schema or database; MongoDB’s simplicity helps
- Here we have greatly reduced the relational data model for this application to two tables. In reality no database has two tables. It is much more common to have hundreds or thousands of tables. And as a developer where do you begin when you have a complex data model?? If you’re building an app you’re really thinking about just a hand full of common things, like products, and these can be represented in a document much more easily that a complex relational model where the data is broken up in a way that doesn’t really reflect the way you think about the data or write an application. Document Model Benefits Agility and flexibility Data model supports business change Rapidly iterate to meet new requirements Intuitive, natural data representation Eliminates ORM layer Developers are more productive Reduces the need for joins, disk seeks Programming is more simple Performance delivered at scale
- Rich queries, text search, geospatial, aggregation, mapreduce are types of things you can build based on the richness of the query model.
- High Availability – Ensure application availability during many types of failures Meet stringent SLAs with fast-failover algorithm Under 2 seconds to detect and recover from replica set primary failure Disaster Recovery – Address the RTO and RPO goals for business continuity Maintenance – Perform upgrades and other maintenance operations with no application downtime Secondaries can be used for a variety of applications – failover, hot backup, rolling upgrades, data locality and privacy and workload isolation
- MongoDB provides horizontal scale-out for databases using a technique called sharding, which is trans- parent to applications. Sharding distributes data across multiple physical partitions called shards. Sharding allows MongoDB deployments to address the hardware limitations of a single server, such as bottlenecks in RAM or disk I/O, without adding complexity to the application. MongoDB automatically balances the data in the cluster as the data grows or the size of the cluster increases or decreases. MongoDB supports three types of sharding: • Range-based Sharding. Documents are partitioned across shards according to the shard key value. Documents with shard key values “close” to one another are likely to be co-located on the same shard. This approach is well suited for applications that need to optimize range- based queries. • Hash-based Sharding. Documents are uniformly distributed according to an MD5 hash of the shard key value. Documents with shard key values “close” to one another are unlikely to be co-located on the same shard. This approach guarantees a uniform distribution of writes across shards, but is less optimal for range-based queries. • Tag-aware Sharding. Documents are partitioned according to a user-specified configuration that associates shard key ranges with shards. Users can optimize the physical location of documents for application requirements such as locating data in specific data centers.
- MongoDB Ops Manager can do a lot for [ops teams]. Best Practices, Automated. Ops Manager takes best practices for running MongoDB and automates them. So you run ops the way MongoDB engineers would do it. This not only makes it more fool-proof, but it also helps you… Cut Management Overhead. No custom scripting or special setup needed. You can spend less time running and managing manual tasks because Ops Manager takes care of a lot of the work for you, letting you focus on other tasks. Meet SLAs. Automating critical management tasks makes it easier to meet uptime SLAs. This includes managing failover as well as doing rolling upgrades with no downtime. Scale Easily. Provision new nodes and systems with a single click.
- Built and managed by the same team that builds the database, MongoDB Atlas provides the features of MongoDB without the operational heavy lifting, enabling you to focus on what you do best.
- Scaling story: Makes it a good fit for microservices Smallest cluster: 9MB of data Largest cluster: 1.09 TB of data, 8 shards, handles 2.1k writes and 7.4k reads per second
- Scaling story: Makes it a good fit for microservices Smallest cluster: 9MB of data Largest cluster: 1.09 TB of data, 8 shards, handles 2.1k writes and 7.4k reads per second
- Any piece of software reflects the organizational structure that produced it
- Any piece of software reflects the organizational structure that produced it