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.

1. Modernization of Legacy
How Dish is Adapting its SOA Services for a Cloud First Future
By Rob Bennett, Lax Rastogi, Chandra Nemalipuri

2. Introductions
• Rob Bennett – Director
• Lax Rastogi – Sr. Manager
• Chandra Nemalipuri – Principal Developer
2

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. 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. 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. 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. 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. 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. 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. Key Technologies
10

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. 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. 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. Conversion Approach – CI/CD
• Automated CI/CD pipelines
14

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. Dish’s Twelve Factor Checklist
16
Source: http://12factor.net
• Stakeholders
• Development Team
• DevOps
• PCF

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