Srinivas Sarathy, TD Bank - Architechting Organizational Change, OpenStack Israel 2015
Download as PPTX, PDF•4 likes•2,529 views
This document discusses architecting organizational change at a large Canadian bank. The bank aims to evolve into a lower-risk retail focused bank by standardizing and automating its infrastructure using open source cloud technologies. The objective is to move applications to a commodity standard platform for increased agility and lower costs. The implementation involves deploying open source orchestration, automation, monitoring and other tools across multiple environments in a componentized, iterative way adhering to standards. Cultural change is needed including clear strategy, focused execution, a cloud first policy, training teams and measured migration.
Srinivas Sarathy, TD Bank - Architechting Organizational Change, OpenStack Israel 2015
- 1. Architecting Organizational Change Keynote Srinivas Sarathy Head of Cloud Engineering 06.15.15
- 2. Background Strategy: Evolve into a lower-risk Retail Focused Bank, with a Francize Dealer. Key Business Segments Include: TD Canada Trust TD Commercial Banking TD Auto Finance Credit Cards TD Insurance TD Wealth TD Bank, Americas Most Convenient Bank TD Ameritrade* TD Securities North American Ranking: 5th by Total Assets (C$1080b) 6th by Market Capitalization ($93b)
- 3. Moon Shot Drivers Multiple Businesses Aggressive Growth Transactional Focus Consequence Vendor Centric Very Diverse Highly Custom Little Re-use 3 Objective Commodity / Standard Self-serve / Automation Increased Agility Lower Cost Faster, Better, Cheaper
- 4. Architecture Principles 4 Componentized – Best of Breed – Iterative – Works on-cloud and off-cloud Open Source – Debuggable – Searchable – Community Standards Based – TOSCA But Lots of Integration Points!
- 5. And the Winners Are… 5 Dedicated, Forward Thinking. Open, Pure Play Orchestration. Maturing TOSCA Tools. Biggest Hosting Provider. Creators of OpenStack. Changed their Business Model for us, x3 RHEL OSP Service. Canadian Marketplace. On-premises Private Cloud. Very Niche, Very Technical Injection of Expertise; Culture Change
- 6. Implementation 6 CLOUD Developer Operations Active Directory (AD) Strongloop API Manager API Gateway / Proxy SaltStack 2014.7 Splunk 6.2 Rundeck 2.4 Redis RabbitMQ InfluxDB Cloudify Broker Storm UI Sonatype Nexus FlapJack, Sensu, Grafana Rundeck Broker ... Other Apps Cloudify 3 ... Tenant / LoB 1 Environment: abc Cloudify Manager SaltStack Plugin OpenStack Plugin API Environment: xyzCloudify Manager SaltStack Plugin OpenStack Plugin API ... SaltStack SaltStack AD / QIP DNS NTP Developer Tools (Maven, Jenkins, etc) Ping (SAML / OAuth2) RedHat Satellite, JBoss Operational Network (JON) WAS Admin Console IBM Tivoli Manager / Omnibus Microsoft SCCM / SCOM ... CloudCruiser Chocolatey GitLab 7.8 Bind 9 / VitalQIP Tyk 1.5 Deployed pattern Deployed pattern Java 1.7.0 Python 2.7 Ruby 1.8 NuGet PowerShell 4.0 nodejs flask gunicorn nginx logstash elasticsearch diamond Go 1.3 angular Gluu 2.0 SQL Server 2008 ... Git riemann Packer 0.7.5 Consul 0.5 Docker 1.4 OSSEC 2.8 AuditD 2.3.7 AIDE 0.14 Shibboleth OX Trust Salt 2014.7 Splunk 6.2 Keystone Nova Glance Horizon Neutron Cinder Swift Ironic Ceilometer Production Environment & Tenant Cloudify Manager SaltStack Plugin OpenStack PluginAPI SaltStack Deployed pattern nodejs Mongodb 3.0 nagios Storm
- 7. Cultural Change Transform –Clear Strategy and Roadmap –Focused Service Execution –Cloud First Policy Partner –Sell the Benefits –Train Federated Technology Team –Enable Teams Sustain –Sponsor –Portfolio Analysis –Measured Migration
Editor's Notes
- #5: I am here to represent the implementation team at TD. I want to make sure it is clear that I cannot claim the credit for the success. The TD team including members currently in the audience have been significantly more instrumental. If you ask me hard technical questions, I will direct you to them. Monolithic architectures do not serve our purposes. We need to be able to not just service new apps, but provide an onboarding opportunity for many apps that were never intended for the cloud. We need a more flexible and adaptable tool chain. We looked at some of the large full-service vendors and the experience was that questions were slow to be answered, the solutions were never all the way there because the space is evolving so fast that everyone is immature. We like buying or using products, but we need to retain control of the solution and avoid vendor lock-in. Big box vendors are also unlikely to bend their roadmaps to introduce features just because we need them… there are exceptions. We don’t choose Open Source because it’s free, but because it is open. We can investigate bugs more quickly, we can come up with workarounds and we can search documentation or forums. Open Source projects have communities and that allows for a force multiplier as far as your support organization is concerned. Standards are important to ensure portability: both from vendor to vendor, but also an orchestration standard allows us to move from one IaaS to another. We are actually going to exploit this benefit, because we could not stand up Oracle RAC on OpenStack, but can on VMWare. The client does not care.
- #6: FIRST RISKFOCUS THESE ARE THE SMARTEST MOST TECHNICAL GUYS ON THE PLANET, AND WE NEEDED HELP WORKING THROUGH THE IMMATURITY, INTEGRATION AND FRANKLY OVERWHELMING COMPLEXITY OF AN OPENSOURCE CLOUD SOLUTION. RACKSPACE CREATED OPENSTACK AND ARE THE LARGEST HOSTING PROVIDER IN THE WORLD. LETS TALK ABOUT THE DEFINITION OF A PARTNER. THEY’VE CHANGED THEIR BUSINESS MODEL THREE TIMES FOR US. INCORPORATING IN CANADA (NEW MARKET FOR THEM), STANDING UP A REDHAT OSP SERVICE FOR US, AND MOST SIGNIFICANTLY FOR THE FIRST TIME OFFERING AN ON-PREMISES SOLUTION. WE CHOSE 7 PRODUCTS TO HELP US WITH PAAS; THE MOST SIGNIFICNT WAS CLOUDIFY. THIS IS THE KEY TO THE BANK BEING ABLE TO DEPLOY APPLICATION PAYLOADS TO ANY CLOUD VENUE. ALL PEOPLE WHO LIKE TO DO IT ONCE AND GET IT RIGHT. AND WILL DIE TRYING.
- #7: Control Plane drives the on-premises and off-premises Clouds. The Control Plane is actually the existing vSphere implementation. There is a very large number of components, but they were not all put-in at the same time… some like Consul are not there yet. The light-green ones are the transitive dependencies brought-in by the various products. Cloudify Manager alone contains a huge number of them, but it runs within a single docker container. We are also essentially witnessing a fractal architecture: we have a componentized architecture, where some of the off-the-shelf components are themselves componentized architectures.