Lessons being learnt from moving a legacy app

Lessons being learnt from moving a legacy app to the cloud

Legacy application Ingested Data ● ● ● Processing Data is onsite Ingested via a crawler Installation via shell scripts Once deployed happy user can find their data Guaranteed physical and internet security Accessed via Browser

Things to consider before starting • Not just about the technology • Why/worth doing it? • Consider customer experience as moving from sales driven to website driven • Minimum friction needed to drive adoption • Security becomes a concern due to being external to organisations • Target segment

So what is the cloud?

So you are doing it. . . What now? Tidy up what you have, remove cruft • Want to make items repeatable, automated, scalable • Understand your limitations • Understand what the cloud can and can’t deliver • Security concerns become more apparent • Releases no longer exist, just implementation of new features •

Dilbert always has the answer….

So how did we plan to move? We virtualized the processes ready to move it to the cloud. • Understand your stack complexity and business pressures • Not a one time job • We have Java/Python portions that communicate over the network - makes life a bit easier • Make sure the business agrees • Understand what you app can and can’t do • Multi tenancy the backend / Physically separate? • How many users? • Costs? •

Step 1 - Moving it whole • Moved from manual deployments through to automated deployments • Shell scripts replaced by configuration management (bash -> puppet) - straight port. • Still a single physical appliance • Still targeting legacy customers • Man time reduced to hours rather than days • Still had legacy issues (upgrades/maintenance)

Step 2 - Splitting it up • Move configuration management from full stack to each component • Place components into logical groups for containers • Add in logic to scale up each subsystem • Get them to speak to each other • Resolve scaling issues with original approach • End up with legacy and new approaches to maintain

Step 3 - Getting it ready for the outside world • • Security now becomes a major concern Remote crawler VPN as have to access on site data Single backend per customer for initial release Understand control costs Recurring revenue vs a single payment Choose your infrastructure provider Beta test with trusted customers

Step 4 - Going live (not quite there yet) • • • Ordering system Support methods SLA Backups Business process change for deployments of releases Unknowns

What new issues will we face? • • Managing 3 rd parties Security / Backups Availability Performance Feature requests Support Multi tenancy requirements Customer feedback methods

Questions? Q&A