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 A T I O N

MOVING TO THE CLOUD

PRESENTED BY:STEFANO PALUELLO

STEFANO PALUELLOTech 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

[Click icon to insert photo]

ACTUAL SITUATIONGood old three tier application

The Good: It works! It’s standard and well known

The BadLegacy, don’t expect too much testsDifficult to achieve some “new” concepts

like separation of concepts, IoC, scalability, etc, etc…

Presentation Layer

Business Logic

DAL

SQL Server

Next Release

Business critical

Backward compatibility for the users

Worldwide availability

Possibly scaling

Data Management

Keep it simple and funny

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 color legend:Text - changes focused on UIText – changes focused on backend

THE GOOD AND THE BAD

GOOD Step by step evolutionWell known technologiesMost of the tools are

already used by the teamIt doesn’t scare the

management

BAD Uhm.. Nothing, it works pretty

good It’s not a real changeCould be boring for a team that

was expecting a shiftNot so “scalable” (ORM and not

so stateless code)Why don’t try something a bit

more “exciting”?

1st proposal

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

STARTUP LIKE

How does it look like?

2nd Proposal

Update(s)/Insert(s)

Lightweight async srv(nodejs)

Fast, schema less, queue (mongodb, redis, rabbitmq, …)

Append only Background workers (heavy computation)(M/R, python,

functional 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

THE GOOD AND THE BAD

GOOD Highly scalable, light and fastCAP (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

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

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

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 dataHigh scalable side

THE GOOD AND THE BAD

GOOD Highly scalable and still

reliableTry to get the good from

both previous solutionsMake the geek and the

business man both happy

BAD Could double the complexityToo much skills to manage (most

of them you need in any case if you decide to move forward with your solutions)

3st proposal