Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Lifting legacy to the cloud on api boosters api-strat
Similar to Lifting legacy to the cloud on api boosters api-strat (20)
Recently uploaded
Recently uploaded (20)
Lifting legacy to the cloud on api boosters api-strat
- 2. Lifting Legacy to the Cloud on API Boosters Seth Lachner, Avantas
- 3. A journey out of the datacenter All Images Nasa.gov unless noted
- 4. Avantas – Smart Square® We leverage technology and evidence-based solutions to help healthcare providers better manage their workforce.
- 5. Stuck in the Datacenter • Old Codebase • Outdated tech • Outdated architecture • Add-hardware Fixes • Overly-complicated logic • Spaghetti Code • etc Image from TechRepublic: http://www.techrepublic.com/pictures/real-world-server-room-nightmares/12/
- 7. Goal 1: Move It
- 8. Avantas always managed its own software...
- 9. The Cloud is Services •It’s not just “Someone else’s computer” •Services and Frameworks •Services provide features at scale •Composability •Frameworks provide access to the services •APIs are the ideal framework Teepublic.com
- 10. Leaving Behind •Dedicated Hardware •VPNs •Firewalls •DB Servers •Backup Systems
- 13. Service Based System Smart Square Core ServiceService Service Service APIs Partner API
- 14. Goal 2: Extend It
- 15. API First “API-first development is a strategy in which the first order of business is to develop an API that puts your target developer’s interests first and then build the product on top of it (be it a website, mobile application, or a SaaS software).” -Guy Levin, https://dzone.com/articles/an-api-first-development-approach-1
- 16. API Next What Preparing for a Service Level API Offering •The “real” reason for moving to the cloud •Long term thinking •Informs every decision •Priority factor •Finding the services •Internal •External
- 17. API Next How •Analysis •In-depth process level •Point-in-time component level •Business focused •Documentation
- 18. API Next How •Service Boundaries/Interfaces •Analysis driven •Identifies non-core features •Identifies atrophied modules •Exposes core components •Features we want to expose •Core competencies
- 19. API Next Why Strategy for the foreseeable future •We must focus on core features •We must modernize our architecture •We must provide an Open API interface •Clients need it •Partners will require it
- 20. We made it!
- 21. Let’s Get Going • Platform Equivalency • Load Partitioning • What Services will we need?
- 22. The Power of APIs (Velocity + Agility) •Rapid iteration •Build->Test->Teardown •Rapid proliferation •Scale it up •Rapid exploration •Get around the roadblocks
- 24. Visibility •Service providers are experts •Expert level insights •Nuanced implementation •API Structure informs •Guides the developer •Educates the developer
- 25. Team Focus Platform Migration + Product Enhancements + Maintenance – Limited resources = Tough choices and Requires FOCUS
- 26. Team Focus •Open APIs let the team focus on core solutions •We embrace the expertise in the service for ancillary features •We focus on our platform
- 27. I Wish I Knew More About Our Email ServiceToPlatform
- 28. Features •APIs give us access to expert features •Features we shouldn’t try to build •We build upon the strength of the commons
- 29. SMS Could Be Better… Copyright Melina Sampaio Manfrinatti https://www.flickr.com/photos/melinamanfrinatti/8391988575 https://creativecommons.org/licenses/by-sa/2.0/
- 30. Sold on Open APIs •Easy to compare •Easy to try •Can be combined, changed, or used in tandem •Integration is rapid •Patterns are repeatable/reusable •Interface is (variably) standardized
- 31. Our (Evolving) API Strategy ● Discovery ● Analysis ● Architecture ● Resolution?
- 32. Discovery (finding an external service) •Kin built a thing: •http://discovery.apievangelist.com/ •Marketplaces, Repos, search engines, directories •Talk to vendors •Talk to your community •Set a deadline •Compile your final list
- 33. Discovery (pruning) •Filter 1: Matrix •Requirements against features •Use vendor docs, OAI specs, or SDK •Filter 2: Docs •Completeness •Accessibility
- 34. Analysis •Confidence level •Team experience? •Community experience? •Build something •Simple and standalone •Focused on requirements •Vendor sandbox?
- 36. Analysis •Does the implementation pattern work for us? •Are there any code smells? •Are any requirements unmet? •Will this work with budget? •Does this vendor stay on the list?
- 37. Architecture •Pick the top of the list and start •Test through the integration •Engage beta ready clients •Early feedback closes the loop •Trust your users
- 38. Resolution? •Best case: Done •Celebrate •Archive the analysis •Worst case: Incomplete or worse •Post-mortem •Review need •Try Again? •Leave legacy for now
- 39. Layers for API Consideration •Telephony •SMS •E-mail •Extract, Transform, Load (ETL) •Networking (DNS, FW, router, etc.) •API Management •Content Delivery (CDN)