Microservices architecture ext
•Download as PPTX, PDF•
1 like•392 views
My talk @ T-Mobile for the B2B and Commissions teams as part of T-Mobile's move to Uncareer architecture and obsessive customer focus. This effort is to define a path for these two team to move from the current way of Monoliths to a more distributed Microservice architecture while understanding the landmines/risk on the way. Also has a mention of event sourcing architecture and CAP theorem
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Microservices architecture ext
Similar to Microservices architecture ext (20)
Recently uploaded
Recently uploaded (20)
Microservices architecture ext
- 1. FRONTLINE SYSTEMS Microservice Architecture Vikash Kodati
- 2. AGENDA 4/6/2016 T-MobileConfidential2 • Microservice: What it IS and NOT • Motivation • Characteristics of Microservice • Monolith vs Microservice • Activities @ T-Mobile • Q&A
- 3. WHAT IS A MICROSERVICE? 6/13/2016 T-MobileConfidential3 Microservice is an architecture style in which a large application is built as a suite of modular services. Each service supports a specific business function. Each service is developed, tested, deployed, updated/replaced and scaled independently without impacting the entire application Organize around business capability Organize around product not project Have it own data storage/db and runs on its own process Microservice Fault Tolerance, Smart End Point, Cloud Ready Componentize, containerize developed & deployed independently Common Characteristics Highly decoupled and focused on doing a single task
- 4. WHAT A MICROSERVICE IS NOT 4/6/2016 T-MobileConfidential4 • A simple API to a more complex service implemented as part of a monolithic application. • A service implemented with a small amount of code. • A service implemented with share database • A service exposed via API by external service provider (if T-Mobile doesn’t have control of the implementation, it’s just a service) • A component, service or capability, labeled as a "microservice" by a vendor
- 5. MOTIVATION 6/13/2016 T-MobileConfidential5 Whats our Motivation?
- 6. OUR MONOLITHs 6/13/2016 T-MobileConfidential6 It’s easy to start building applications that become Monolithic • Diverse business functions/capabilities/modules under one umbrella • Entire Dev team deals with all parts of the application • Diverse external libraries in one Classpath, Cross cutting concerns • Every release and deployment process resulting in ONE logical executable • Tightly coupled integrations (PL/SQL inserts, synchronous handshakes etc…) • More data, more users leads to SCALING OUT the application Super Cool Application UI Component Business Logic Persistency Layer
- 7. MONOLITHs CONTINUED… 6/13/2016 T-MobileConfidential7 Super Cool Instance Super Cool Instance Super Cool Instance Super Cool Instance Super Cool Instance Super Cool Instance Super Cool Instance Super Cool Instance
- 8. FRONTLINE SYSTEMS - MISSION 6/13/2016 T-MobileConfidential8 Enable T-Mobile’s Frontline teams to consistently interact with our customers throughout the selling and serving lifecycle, delivering an exemplary and intuitive experience enabled by operational excellence and innovation
- 9. MOTIVATION DEFINED 6/13/2016 T-MobileConfidential9 BRIDGE the gap Applications have to be decomposed into microservices for improving deployability and scalability and simplifying adoption of new technologies
- 10. WHAT IS MICROSERVICE? 6/13/2016 T-MobileConfidential10 Microservice is an architecture style in which a large application is built as a suite of modular services. Each service supports a specific business function. Each service is developed, tested, deployed, updated/replaced and scaled independently without impacting the entire application
- 11. CHARACTERISTICS OF MICROSERVICES 6/13/2016 T-MobileConfidential11 • Componentization via services • Organized around business capabilities • Products not projects • Smart endpoints and dump pipes • Decentralized Data Management • Infrastructure Automation • Design for failure
- 12. COMPONENTIZATION VIA SERVICES 6/13/2016 T-MobileConfidential12 • Break software into components • Components should be independently • Replaceable • Upgradeable • Model the SERVICE as a Component • Self sufficiently running in its own process • Interacting with other services via web service requests
- 13. ORGANIZED AROUND BUSINESS CAPABILITIES 6/13/2016 T-MobileConfidential13 Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. -- Melvyn Conway, 1967
- 14. CONTINUED… 6/13/2016 T-MobileConfidential14 • Make teams will be cross-functional • Team responsible for development, operations, communications & business value • Services take up a broad-stack (UI, Storage and 3rd party collaborations) • Well defined boundaries
- 16. SMART ENDPOINTS AND DUMB PIPES 6/13/2016 T-MobileConfidential16 • End points should contain • Business logic, routing rules • Have a robust and efficient pipping mechanism (plumbing) • Connect everything together • Direct RESTful calls • Lightweight message bus (Kafka or RabbitMQ) • Analogous to Unix filters : receiving a request, applying logic and produce a response
- 17. SMART ENDPOINTS AND DUMB PIPES 6/13/2016 T-MobileConfidential17
- 18. SMART ENDPOINTS AND DUMB PIPES 6/13/2016 T-MobileConfidential18
- 19. DECENTRALIZED DATA MANAGEMENT 6/13/2016 T-MobileConfidential19
- 20. X Y Z AXES DEFINED 6/13/2016 T-MobileConfidential20
- 21. INFRASTRUCTURE AUTOMATION 6/13/2016 T-MobileConfidential21 • Server provisioning • Configuration management • Automated builds • Automated testing • Automated deployments • Monitoring Goal: Infrastructure As Code • Provision and Tear-down universes (server farms) at the click of a button/command
- 24. DESIGN FOR FAILURE 6/13/2016 T-MobileConfidential24 Typical first year for a new cluster: ~0.5 overheating (power down most machines in <5 mins, ~1-2 days to recover) ~1 PDU failure (~500-1000 machines suddenly disappear, ~6 hours to come back) ~1 rack-move (plenty of warning, ~500-1000 machines powered down, ~6 hours) ~1 network rewiring (rolling ~5% of machines down over 2-day span) ~20 rack failures (40-80 machines instantly disappear, 1-6 hours to get back) ~5 racks go wonky (40-80 machines see 50% packet loss) ~8 network maintenances (4 might cause ~30-minute random connectivity losses) ~12 router reloads (takes out DNS and external vips for a couple minutes) ~3 router failures (have to immediately pull traffic for an hour) ~dozens of minor 30-second blips for dns ~1000 individual machine failures ~thousands of hard drive failures slow disks, bad memory, misconfigured machines, flaky machines, etc. Note: Data taken from Jeff Dean’s slides
- 25. CAP Theorem 6/13/2016 T-MobileConfidential25 It is impossible for a distributed system to simultaneously provide all 3 guarantees 1. Consistency: All nodes see the same data at a given time 2. Availability: Every request receives a response 3. Partition Tolerance: Tolerant to failure of a part of the system • Not P => CA – MySQL • P => C XOR A – CP System – AP System
- 27. DATA MODELS 6/13/2016 T-MobileConfidential27 • Relational – RDBMS like MySQL • Key-Value – Support put, get, delete based on a primary key • Column-Oriented – Tables are still used and Joins are handled at the client – Store data by column as opposed to traditional row-oriented databases • Document-Oriented – Stores structured documents like XML, JSON – No Joins
- 28. MONOLITHIC vs. MICROSERVICE 6/13/2016 T-MobileConfidential28 Monolithic Architecture Microservice Architecture Simple: Built as a single, autonomous unit of app Partial Deployment: Each element of functionality is a separate service Consistency: Tightly coupled. One database for the entire app. Highly decoupled. Each service has its own database. Eventual consistency A modification made to a small section of an app might require building, testing and deploying an entirely new version Preserve Modularity: Each service can be developed/changed/replaced, tested and deployed individually The entire app run in one process. Scale by replicating the entire app Each service run on it own process/instance (JVM). Scale by replicating each service ACID (Atomicity, Consistency, Isolation, Durability) BASE (Basically Available, Soft State, Eventually Consistent) Super Computer: Adding resources to a single node Distributed System: Adding more nodes
- 29. APPLICATION STACK COMPARISON 6/13/2016 T-MobileConfidential29 Typical Monolith Application 29 Single/Multiple Machines File System RDBMS Application Framework Multiple Machines (Cluster) Distributed File System COMPUTATIONAL Framework Application Application NoSQL Stores Distributed Miscroservice Application
- 30. OTHER RESOURCES and REFERENCES 6/13/2016 T-MobileConfidential30 • Microservices, Martin Fowler, James Lewis • http://martinfowler.com/articles/microservices.html • A day in the life of a Netflix Engineer using 37% of the internet • http://fr.slideshare.net/AmazonWebServices/dvo203-the-life-of-a-netflix-engineer-using- 37-of-the-internet • Dzone – Geting started with Microservices • https://dzone.com/refcardz/getting-started-with-microservices • SoundCloud – How we ended up with microservices • http://philcalcado.com/2015/09/08/how_we_ended_up_with_microservices.html • gRPC - boilerplate to high-performance scalable APIs • http://fr.slideshare.net/AboutYouGmbH/robert-kubis-grpc-boilerplate-to- highperformance-scalable-apis-codetalks-2015 • Twelve-Factor methodology:http://12factor.net/
- 31. FUTURE TOPICS? 6/13/2016 T-MobileConfidential31 • Docker • Python and Jupyter notebook • Light weight message buses & Dataframes (e.g., Kafka) • Machine Leaning • Circuit Breaker (e.g., Hystrix) • Mobile Architecture • Solr/Lucene • Case Studies? Use Cases? • Others?
- 32. THANK YOU & QA 6/13/2016 T-MobileConfidential32 Vikash Kodati • Email: Vikash.Kodati@t-mobile.com • Yammer: https://www.yammer.com/t-mobile.com/users/vikashkodati • Github: https://github.com/vikashkodati • LinkedIn: /in/vikashkodati • Twitter: @vikashkodati • Blog: https://tmobileusa.sharepoint.com/portals/hub/personal/vikashkodati
- 33. MICROSERVICE is not the answer for all service 4/6/2016 T-MobileConfidential33 Please ask yourself You don’t need microservice ! You need microservice ! are you 100% sure you need microservices? I think so ! If I have to change any thing in this monolith app I will kill my self
Editor's Notes
- Encourage interactive session Informal discussion Eat lunch My Goal is to keep us all on the same page at a conceptual level. Please stop me and ask questions
- Again a set of statements.
- What does it really mean? Hard to define. It has to be a common ground of all the above statements. Least Common Denominator The resulting system is a Network of communicating processes as opposed to a single process in case of a monolith Function and Capability used interchangeably Honeycomb is an efficient structure in terms of min material used and min weight while maximizing the impact.
- Again a set of statements.
- So Microservice is a common denominator of all those characteristics. So what? Why should we talk about this Do we use it OR do we not use it? Why should we spend time on this . Aren’t we already doing good work in the constraints we have? To answer that we need to first look at Where we are today in the grand scheme of things. Relative to technology, processes and the kind of limitations that imposes on us. Once we understand that, it will offer a reason for us to consider microservices
- So lets cast some light on our current way of doing things. Projects start small If successful they will grow Single process Module boundaries Method communication OS level stack One persistence storage for all diverse capabilities. Technology and vendor lock in
- This limits us to be successful Problems Prevents from being innovative. Cant try new technologies quickly Large code base ties us to the technology choices that we made at the beginning. Not easy to try new things/techs Long time to market, we may loose opportunities Operationally Scaling requires scaling of the entire application rather than parts of it that require greater resource. Fear of change: a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed. Lot of testing Overload the IDE and less productive Slow down the container or the application server Simple but does not scale or rather brute force scaling (Scale out) behind load balancer - All nodes talking to one persistence mechanism
- Given those current processes and limitations we have our new MISSION from Bill.
- How do we bridge the gap between the current realities and our new MISSION? Make them granular
- Now that we identified the need and understood why we should be doing this let dive into its characteristics.
- Its still hard to come up with a firm definition. Instead of defining think about common characteristics. Most of those who are doing MS will be doing most of these things Lets go through each of these
- Software should be broken down in components: Idea was there for a while. Component : Analogy Assemble to build stereo components (amplifier, cd payer,) Software components: in a monolith 3rd party lib part of the single process. One component may depend on java 8 and the other on 7 MS Interprocess communication Using services like this does have downsides. Remote calls are more expensive than in-process calls, and thus remote APIs need to be coarser-grained Service is logically at one process but in reality could be multiple (because of its own DB) MS: A Service should have one responsibility ()
- When looking to split a large application into parts, often management focuses on the technology layer, leading to UI teams, server-side logic teams, and database teams. We can relate this to: Applications having dev and Op responsibilities under different leaderships Deloitte team doing the dev all by themselves
- Imp. Theme Companies organize themselves around the technology Convay Law?? MS Org. around biz capabilities. (MS view) Each team should have some elements right the way through the end users themselves Each team should be responsible for their communication right the way through end user experience. How this effects business outcomes. Divide yourself up around business organization and make it as full stack as possible. Boundaries for services, teams 2 pizza teams.
- X and Z are the traditional ways of scaling But Y is the functional decomposition that needs to be happen to move to the new world. Partition by noun. -- order service -- customer mgmt service -- checkout service
- In the grand scheme of things here the MW should be looked upon as a pipe Lets get some powerful piece of middleware that will automatically do all the magic Route messages Do the transformation Mashups Apply biz rules ESB: Egregious Spaghetti Box
- In the grand scheme of things here the MW should be looked upon as a pipe Lets get some powerful piece of middleware that will automatically do all the magic Route messages Do the transformation Mashups Apply biz rules ESB: Egregious Spaghetti Box
- In the grand scheme of things here the MW should be looked upon as a pipe Lets get some powerful piece of middleware that will automatically do all the magic Route messages Do the transformation Mashups Apply biz rules ESB: Egregious Spaghetti Box
- Has a huge impact on architecture. Monolith has this huge single database containing all the data for all business functions. MS should be responsible for its own data and its peristence. Removes integrated at db level Use data store that makes sense for the problem You may never talk to another service’s datastore. You may only talk to another service via its API Choice of db tech will be upto the service group Including languages. Event oriented architecture. What if Service-A needs the data of Service-B How a service landscape is governed and also in terms of data management
- Z One commonly used routing criteria is an attribute of the request such as the primary key of the entity being accessed. Another common routing criteria is the customer type. For example, an application might provide paying customers with a higher SLA than free customers by routing their requests to a different set of servers with more capacity. Challenge: MS-A needs a data element from MS-B for its own function. Solution: event sourcing.
- Automation is a must to make all this work Got to have good monitoring
- On-Premise: T-Mobile IaaS: Amazon EC2 PaaS: Cloud Foundry SaaS: Gmail , SalesForce
- Spring Boot: Convention over Configuration Also has maven and gradle configuration that packages the application as a self contained executable job file Health check On-Premise: T-Mobile IaaS: Amazon EC2 PaaS: Cloud Foundry SaaS: Gmail , SalesForce
- Netflix randomly brings down nodes and simulate failure to check resiliency Bring up CAP theorem here
- The most critical starting point is to define a clear strategy.
- Talk about eventual consistency This concept is also known as BASE (as opposed to ACID) – Basically Available, Soft State, Eventually Consistent ACID (Atomicity, Consistency, Isolation, Durability)
- Graph databases (may be for SHMS hierarchy)
- Good example. One comma brought down the website of Netflix. Testing is hard Distributed programming is complex Distributed txn w/o 2 phase commit. MS is not just copying one big war file but a lot of moving parts. Eventual consistency Event driven/sourcing BASE (as opposed to ACID) – Basically Available, Soft State, Eventually Consistent ACID (Atomicity, Consistency, Isolation, Durability
- COMPUTATIONAL Framework. That’s the key.. Bring the computation to the data and not the other way round. a 20mb jar is more transportable than 1TB of data input. One good example of this paradigm will be: 1. Bring commission engine to our data than the other way around.