Evolve or Die! How many times havethey told you, „You still coding in that?“. Come to this session to discover the infamous land of legacy ColdFusion applications, their why and existence motivations. We will then discover how to finally evolve them and take them to the wonderful land of Modern ColdFusion. Come and be inspired to kill the legacy monsters that have haunted you for far too long. We will deliver you once and for all of these inhumane beasts, so you can be proud of writing kick-ass applications with kick-ass tools in ColdFusion. Evolve or Die!

1. A TALE OF LEGACY TO MODERNIZATION

2. WHO AM I?
• Luis Majano - Computer Engineer
• El Salvador
• Texas
• Computer Engineer
• CEO of Ortus Solutions
• Creator of many boxes
www.ortussolutions.com
@ortussolutions
@lmajano

3. Story Time
You are still coding in that!

4. ME @ 2013
tooling
engine roadmaps
ecosystem
CLI
Package Manager
Frustration

5. CFML SHAMING
• Lack of tooling
• Package Management
• CLI
• OS Integrations
• Applications
• Legacy Hell
• Way behind the cool kids

6. CFMLTOOLING LANDSCAPE
Copy + Paste

7. HOW DO WE MODERNIZE CFML?

8. Vendors Cannot Do It All!
THE HARD REALITY
Make CFML HUUGE Great AGAIN!!

9. Tooling
Community
Engine Portability
Containers
OUR FOCUS
Legacy Apps

10. TOOLING

11. CLI Package
Manager
REPL
Read-Eval
Print-Loop
Integrated
Server
ScaffoldingForgeBox
CFML
ColdFusion Automation
3+Years Now!

12. Come On! Get with the program!

13. COMMUNITY
•Newbie Initiatives
•Documentation Priorities
•ITB, ODW
•All CFML Conferences
•Non-CFML Conferences
•API Implementations
•Rollbar, github, bcrypt, S3, Google,
freshbooks, twitter, salesforce, etc.
•Slack, blogs, webinars

14. FORGEBOX.IO
CFML Repository
438+ contributions
9 Releases in < 1 year
Growing Features
Do you have an account?

15. CONTAINERS

16. CFML + CONTAINERS
• Eliminate Dev-Ops Headaches
• Increased Security
• Zero-Downtime Deployments
• Scaleability and FaultTolerance

17. DOCKER
Run any CFML Engine
Run any WAR
Portable Server Settings
Portable CFML Engine Settings
Image Healthchecks
Secure Headless Modes

18. DOCKER
H2 DB or any RDBMS
Auto session distribution
Auto cache distribution
Redis/Couchbase
Headless Mode

19. CFML
Engines
PORTABILITY

20. • Package any server with server.json
• Updating CF engine install is a non-issue
• Use multiple CF engines/versions at the same time
• New Docker images make it easy for cloud scaling
• CFConfig one tool to rule them all
$ docker pull ortussolutions/commandbox
$ docker run -v "/path/to/your/app:/app" ortussolutions/commandbox
PORTABILITY

21. BUT…..

22. LEGACY PROBLEM
• Gives CFML a bad name
• Security Issues
• Performance Issues
• Employee Issues
• Development Issues
• Finding Developer Issues

23. LEGACY PROBLEM
•>35% No MVC
•>60% No DI
•>55% No Testing

24. CAN’T FIND DEVELOPERS!
• MVC Framework or spaghetti hell?
• OO or cfinclude hell?
• Automated Tests? Continuous Integration?
• Agile/Scrum Methodologies?
• Source Control? (Zip files don’t count!)
• Continuous Delivery? Container Strategy?
• Developer Automation?

25. YOU NEED TO ACT!
• Drive innovation internally
• Get out of legacy hell, modernize
• Build cool apps,APIs, libraries
• Collaborate with open source
• Share in forgebox.io
• Blog, present, share your knowledge
• Proud of your CFML apps again!

26. EVOLVE OR DIE!

27. The end!!

28. LEGACY PROBLEM

29. PAST EXPERIENCES

30. SPAGHETTI CODE (PROCEDURAL)
• Quick and dirty
• Logic and display mixed together
• Monolithic app design
• No separation
• Difficult to extend/scale

31. OBJECT ORIENTED (OO) - WITH MEATBALLS
• Logic organized better
• Service-oriented
• Monolithic app design
• Some separation
• Difficult to scale

32. MVC
• Separates layers of concerns
• Helps enforce OO
• Specialized team members
• but….
• Layers are still tightly coupled

33. N-TIER - MEXICAN CHALUPA
• Add more layers for organization
• Layers are still tightly coupled
• Still monolithic!

34. ONCEYOUR APP GROWS….
• Complex real-life apps
• Large “surface area”
• So...much...code...
• No one understands it all
• Too big for one plate
// Don’t change this value, else things break.
// Not sure how this works, don’t change.
// Don’t remove this please, else nothing displays

35. PERFORMANCE

36. IF IT DOESN’T PERFORM…
…BIGGER HARDWARE!

37. IF IT STILL DOESN’T…
…MORE HARDWARE!

38. A
FUNDAMENTAL
CHANGE IN
APPROACH OR
UNDERLYING
ASSUMPTIONS.
PARADIGM SHIFT:
MODERNIZE…

39. CFML : EVOLVED
• Modularization (HMVC)
• Cohesion + Coupling
• Containerization
• Feature Maps
• Parallel Development
• Continuous Improvement
• Microservices

40. MODULARITYTOTHE RESCUE
• HMVC - Hierarchical MVC
• Software Modules (ColdBox)
• Break app into logical pieces
• Microservices
• Drop-in functionality
• Re-usable
• Multi-team approach
• Easier to distribute

41. HMVC

42. COHESION AND COUPLING

43. REAL LIFE MIGRATION
ColdBox
Platform
<3

44. MODULE MAPS
ColdBox
MVC 4
I18n
Validation
JavaLoader
Mail Services
Debugger Security
AntiSamyORM
• 85% source code reduction
• Rich eco-system
• Less coupling
• Higher cohesion
• 35% performance improvements
• Agile + Maintainable
• Sanity

45. MICROSERVICES
AN APPROACH TO DEVELOPING A SINGLE
APPLICATION AS A SUITE OF SMALL SERVICES,
EACH RUNNING IN ITS OWN PROCESS AND
COMMUNICATING WITH LIGHTWEIGHT
MECHANISMS.
Martin Fowler

46. MICROSERVICES
• Make legacy code updates less
intimidating
• Fewer resources required to maintain
fault tolerance
• Versionable & maintainable
• Short release cycles
• Monolithic apps can be evolved piece
by piece

47. MICROSERVICES
M C
V
M C
V
M C
V

48. PLATFORMS AS SERVICES (PAAS)

49. NEW PARADIGM: ORCHESTRATION
> Less is more
> Applications as collections of
independent parts
> Incremental upgrades and versioning
in lieu of massive release cycles

50. NEW PARADIGM: ORCHESTRATION
> Hardware Independence
> Platform independence
> Disposable instances: scale on-
demand, teardown when demand
decreases

51. FORMULA FOR SUCCESS
MICROSERVICES

52. STEP 1:
Identify performance
bottlenecks and pain points
in your application

53. STEP 2:
Build, test, and deploy new
microservices to address
and deliver the functionality
of your pain points

54. STEP 3:
Update endpoints in
monolithic app to use new
microservice endpoints

55. STEP 4:
Rinse and repeat, with
additional bottlenecks and
pain points

56. TOOLSET

57. HMVC
REST
Dependency Injection
BDD
Continuous Integration
Docker

58. IN A…

59. INSTEAD OF ONE
BIG THING, DOING
MANY THINGS…
ISOLATE
ALL THE THINGS!

60. …WE DEVELOP
MANY THINGS,
EACH
DOING ONE THING
VERY, VERY WELL.
ISOLATE
ALL THE THINGS!

61. IF WE DO THIS,
ONE
SMALL
PIECE AT A TIME

62. SOMEDAY SOON, THIS

63. EVOLVES INTO TO THIS

64. • Work is required
• Renewed Creativity and Inspiration inYour Work
• Sense of Accomplishment and Pride of Platform
( CFML! )
• The REST if up to you!
NEW HORIZONS

66. The End!