A short report of how we moved an important, worldwide core legacy system from the private intranet to the Cloud.

1. E V O L U T I O N S C E N A R I O S F O R A L E G A C Y A P P L I C AT I O N
MOVING TO THE CLOUD
PRESENTED BY:
STEFANO PALUELLO

2. STEFANO PALUELLO
Tech Leader by day, geek by night 
 Passionate geek
 Working with mainstream and Open Source tools
 Now dealing with functional languages and Data
 Agile enthusiast and team working advocate
 Always looking for something new

3. ACTUAL SITUATION
Good old three tier application
The Good:
It works!
It’s standard and well known
The Bad
Legacy, don’t expect too much tests
Difficult to achieve some “new” concepts
like separation of
concepts, IoC, scalability, etc, etc…
Presentation Layer
Business Logic
DAL
SQL Server

4. Next
Release
Business
critical
Backward
compatibility
for the users
Worldwide
availability
Possibly
scaling
Data
Management
Keep it simple
and funny

5. FROM INTRANET TO THE CLOUD
Modify the DAL. Introduce
ORM (light), Repository
and TEST(!!)
Introduce Separation of
concerns: Asp.Net MVC
Time to go REST: Asp.Net
MVC API
New UI: Single Page
Application (using
AngularJS, Backbone, etc)
First Proposal
Today…
Ready for
the Cloud
Text - changes focused on UI
Text – changes focused on backend

6. THE GOOD AND THE BAD
GOOD 
Step by step evolution
Well known technologies
Most of the tools are
already used by the team
It doesn’t scare the
management
BAD 
Uhm.. Nothing, it works pretty
good 
It’s not a real change
Could be boring for a team that
was expecting a shift
Not so “scalable” (ORM and not
so stateless code)
Why don’t try something a bit
more “exciting”?
1st proposal

7. STARTUP LIKE
Use new technologies (maybe still in beta)
Fast delivery then fix after
Web oriented (NoSQL, Open source, MEAN stack)
Command & Query Responsibility Segregation (CQRS) (write != read)
Scale and performance in mind
Second
proposal

8. STARTUP LIKE
How does it look like?
2nd Proposal
Update(s)/Insert(s)
Lightweight
async srv
(nodejs)
Fast, schema
less, queue
(mongodb, redis, rab
bitmq, …)
Append only
Background
workers (heavy
computation)
(M/R, python, func
tional lang..)Read and
remove
computed data
(queue like)
Update output
data Light schema (few or
no joins) storage (SQL
or NoSQL)
Lightweight async
REST API
(nodejs+express)
Light Web
App/SPA

9. THE GOOD AND THE BAD
GOOD 
Highly scalable, light and fast
CAP
(Consistency, Availability, Partition
tolerance)
Cheap (licenses and hw
requirements)
Your geek/hacker team will
love you (new toys.. ops
tools  )
BAD 
Requires new skills (devops, new
patterns, architectures, …). Not
so bad after all…
Most of the technologies are not
mainstream and well known or
easy to manage (to be polite)
The next version??
Your CEO and the Board just got
a stroke
2st proposal

10. THE MIDDLE EARTH
Trying to get the best from both scenarios
Introduce new technologies a little bit smoother
Focus on scalability and performance but also on business and
reliability
You could make the board and your team both happy
Win-win situation?
Third
proposal

11. THE MIDDLE EARTH3rd Proposal
 Two sides approach (you can split the team)
 Split up the storage (one for the input and one for the output)
 On the input side:
 fast async I/O API server (nodejs)
 Input data storage (schema less, fs storage, eg. MongoDB, Hbase, Cassandra)
 A, set of, background worker(s) that take the input data, transform, adapt and move to the output storage
(M/R, batch-like jobs)
 On the output side:
 SQL Server 2012 or later, leveraging advanced feaute (unstructured data, encryption, replicas, always-on, BI
tools)
 Asp.Net MVC API with async methods, light ORM, Stored Procedure
 Lightweight web client (SPA w/AngularJS or Backbone or Asp.Net MVC)
 Ok… actually it’s a three sides approach 

12. THE MIDDLE EARTH3rd proposal
Input side
Lightweight
async srv
(nodejs)
Fast, schema less
storage, with
distributed FS
Background
workers (heavy
computation)
Output side
Asp.Net MVC API
Web Client
SQL Server
Business valuable data
High scalable side

13. THE GOOD AND THE BAD
GOOD 
Highly scalable and still
reliable
Try to get the good from
both previous solutions
Make the geek and the
business man both happy
BAD 
Could double the complexity
Too much skills to manage (most
of them you need in any case if
you decide to move forward
with your solutions)
3st proposal