Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Modernizing the Legacy - How Dish is Adapting its SOA Services for a Cloud First Future

780 views

Published on

SpringOne Platform 2016
Speakers: Rob Bennett; Director, Development, Dish Networks; Chandra Nemalipuri; Principal Software Engineer, Dish Networks; Lax Rastogi; Senior Manager, Dish Networks

Like many companies, Dish has a large number of SOA services that have been built using previous generations of technology. In this session we will discuss the challenges faced in converting legacy services to cloud native applications and the different approaches we considered for resolving the conflicts. We will then dive deeper into the approach that we chose to modernize our services and put us on a track towards a microservices based architecture running on Cloud Foundry.

Published in: Technology
  • Be the first to comment

Modernizing the Legacy - How Dish is Adapting its SOA Services for a Cloud First Future

  1. 1. Modernization of Legacy How Dish is Adapting its SOA Services for a Cloud First Future By Rob Bennett, Lax Rastogi, Chandra Nemalipuri
  2. 2. Introductions • Rob Bennett – Director • Lax Rastogi – Sr. Manager • Chandra Nemalipuri – Principal Developer 2
  3. 3. Background • Strong tradition of Service Oriented Architecture • Coarse grained services • High Reuse • Services built on a platform mixing Java and config Recently… • Several teams working on Cloud Native projects • Want to adapt our SOA portfolio to Cloud Native • Microservices with SpringBoot & Cloud Foundry • TDD • CI/CD 3
  4. 4. Coarse Grained Service Challenges • Coarse Grained was great • Helped keep the “chattiness” low • Downsides of Coarse Grained • Mixed frequently changing business logic with slow changing • Services change a lot (fewer buckets for change) • Many clients – they have to release when we release o Or get into old version heck • Extensive Testing (TDD??) • Risky o So let’s only deploy at 2am! • Summary • Difficult to change services that change all of the time 4
  5. 5. Technology Platform Challenges • Development Challenges • Hard to hire for a unique development platform • Rigid IDE used for development • No out of box support for version control • Business logic within code cannot be extracted and reused • Operational Challenges • No support for cloud like environment • Lack of Continuous Integration/Deployment • Limited automation capabilities • Downtime for deploying newer versions • Requires validation efforts after every build • Performance issues 5
  6. 6. How do we get there from here? • Let’s switch to Microservices! • All we have to do is: • Analyze and decompose our coarse grained services into constituent parts • Define the contracts for the micro services • Orchestration/Choreography • Looks like we can have a lot of fun discussing that one • Re-write every client • That shouldn’t take long • What else can we do? 6
  7. 7. Dish’s Middleware • Supporting ~13.6 MM pay TV subscribers • Comprises of 100+ SOAP webservices with about 600 operations • Handling 60 MM transactions per day • ~600 application instances • Integrated with numerous internal as well as third party providers • Only about 5% Java code in current services • Some of the service functions are: • Integration with billing provider • Address, Email, phone validation • Credit scoring, credit card hold, payment • Order Creation, appointment scheduling, equipment activation • Generating more than a billion events per day 7
  8. 8. Services Roadmap 8 Front end apps, self service, IVR, CSRs Back end resources Legacy SOAP Services SHARED CODE LIBRARIES PCF SOAP Services STAGE 1 @endpoint REST Microservices STAGE2 Modified front end apps @RESTController
  9. 9. Preparing the migration • Services categorization • Design patterns used • Size of services • # of moving parts in each service • Deciding scope of work • Assigning priorities, efforts estimation • Choosing the right technology to support the services roadmap • Plan to start small, build the foundation, go big • Spread the word • Don’t forget the buy-in from management 9
  10. 10. Key Technologies 10
  11. 11. Where are we now? • No new development on legacy platform • 7 legacy services have been converted to PCF apps so far • New services are being built as microservices on PCF, stage 2 in roadmap • 12 microservices deployed using new technology stack • Reusing Integration TEST suite build for legacy services to test new services • Zero to minimal impact to services consumers • Each PCF service has 8 AIs (4 PROD, 2 TEST, 1 DEV and 1 INT) 11
  12. 12. Conversion Approach – Design • Development Tools/Conventions • @SpringBootApplication • Test Driven Development • 12 Factor app guidelines (http://12factor.net/) • Integration Tests Suite – reusing for CF service • Client Interfaces • SOAP (Spring-WS) • WSDL to Java using wsdl4j, JAXB with XJC • @Endpoint with @PayloadRoot • REST (Spring-Web) • @RestController with @RequestMapping 12
  13. 13. Conversion Approach – Runtime • Runtime Platform • Pivotal Cloud Foundry • Spring Cloud components • PCF Marketplace Services • Config Server • Rabbit MQ • PCF User Provided Service(UPS) • Database connection config • External service URIs • Elastic search • Mongo DB • Distributed caching using Gemfire 13
  14. 14. Conversion Approach – CI/CD • Automated CI/CD pipelines 14
  15. 15. Logging & Metrics • Latency analysis using Zipkin & SpringCloud Sleuth • LogStash consumer • KAFKA • Cassandra • OpenZipkin collector • OpenZipkin Query • OpenZipkin web server • Log Analytics • ELKK Stack 15
  16. 16. Dish’s Twelve Factor Checklist 16 Source: http://12factor.net • Stakeholders • Development Team • DevOps • PCF
  17. 17. Application Demo 17 • Walkthrough  Spring Boot  Dish_properties (Spring Cloud Config repo)  SOAP & REST  Spring Cloud Sleuth and Zipkin  Service Mocking  CI/CD  Cloud Native App Development Life Cycle • Source Code  springone-demo-app: https://github.com/nemalipuri/springone-demo-app  adapter-api-simulator: https://github.com/nemalipuri/adapter-api-simulator
  18. 18. 18

×