migrating to cloud-native architectures using microservices: an experience report

Migrating to Cloud-Native Architectures Using

Microservices: an Experience Report

Armin Balalaie, Abbas HeydarnooriSharif University of Technology

Pooyan Jamshidi Imperial College London

MicroservicesA cloud-native architecture

Developing a single application as a suite of small services

Source: http://martinfowler.com/articles/microservices.html

Services are built around business capabilities


Services are independently deployable by fully automated deployment machinery


Feedback to Dev is necessary from Ops and Micro-services facilitate it • Micro-services as native cloud architecture that enable DevOps• Performance-aware DevOps• Design-time performance models• Performance monitoring• Performance change detection• Performance anti-patterns detection• Evolution: Filling the gap between Dev and Ops• Software Architecture Optimization for Performance • Resource provisioning and management

More details on “performance-oriented DevOps” published by SPEC Research Group on DevOps: https://research.spec.org/news/single-view/article/technical-report-on-performance-oriented-devops-published.html

There is a bare minimum of centralized management of the services (Polyglot-ness)


SSaaS (Server Side as a Service)A platform that makes mobile application development easier

Features of SSaaS• Mobile application developers can use server-side capabilities without

knowing any server-side programming languages• RDBMS as a Service• Define data models in SSaaS dashboard• Use the models’ objects in mobile application development• Built-in user management

• Chat as a Service• Integration with RDBMSaaS user authentication

Architecture of SSaaS before the migration

Reasons for migration• On-demand capability of Chat as a Service• The need for a reusable resource manager• Management of resources like relational database instances, e.g. MySQL

database.

• The need for decentralized data governance• Chat service’s metadata needed a dedicated place

• The need for automated deployment• The need for built-in scalability

Target Architecture of SSaaS

Migration StepsIncremental steps

Preparing the Continuous Integration Pipeline

Transforming DeveloperData to a Service

Introducing Continuous Delivery

Introducing Edge Server

Introducing Dynamic Service Collaboration

Introducing Resource Manager

Introducing ChatServices and DeveloperInfoServices

Clusterization

Lessons LearnedExperiences in migrating to microservices

Deployment in the development environment is

difficult for a typical developer

Service contracts are double important

Distributed system development needs skilled

developers

Creating service development

templates is important

The research on Micro-services has started only in 2015,Plenty of opportunities ahead!

1. Kratzke, N.: About microservices, containers and their underestimated impact on network performance. CLOUD (March 2015)

2. Levcovitz, A., Terra, R., Valente, M.T.: Towards a technique for extracting microservices from monolithic enterprise systems. VEM (September 2015)

3. Rahman, M., Gao, J.: A reusable automated acceptance testing architecture for microservices in behavior-driven development. SOSE(March 2015)

4. Stubbs, J., Moreira, W., Dooley, R.: Distributed systems of microservices using docker and serfnode. IWSG (June 2015)

5. Viennot, N., L´ ecuyer, M., Bell, J., Geambasu, R., Nieh, J.: Synapse: A microservices architecture for heterogeneous-database web applications. EuroSys. (April 2015)

More details? http://arxiv.org/abs/1507.08217

Our current agenda!• Migration patterns for micro-services• Architectural tactics• Situational method engineering for extracting common reusable

practices• Method chunks• Pattern template for documenting practices• Migration patterns vs. design patterns

Migration Transition Graph

C2C1

On-premise Platform

Cloud Platform

C2

C1

On-premise Platform

Cloud Platform

C2

C1

On-premise Platform

Cloud Platform

C2C1

On-premise Platform

Cloud Platform X

Initial application architecture Target application architecture

Intermediate application architecture


Time

Migration pattern

C2

C1

On-premise Platform

Cloud Platform X


Cloud Platform Y

Cloud Platform Y

Cloud Migration through Pattern Composition

• The migration patterns can be seen as a sequence of activities by which an application is gradually migrated to the micro-services.

• The migration patterns can be composed (i.e., executed sequentially) to move a monolithic application to micro-services.

Migration Pattern Selection

Objective MP1 MP2 MP3 MP4 MP5 MP6 MP7 MP8 MP9 MP10 MP11 MP12 MP13 MP14 MP15

Time to market -- -- -- -- --

New capabilities -- -- -- --

Reduce operational cost -- -- -- -- -- --

Leverage investments -- -- --

Free up on-premise resources

Scalability -- -- -- -- -- -- --

Operational efficiency -- -- -- -- -- -- -- --

Re-h

ost

Clou

dific

atio

nRelocation

RefactorRebinding

Replacement

Mod

erni

zatio

n

Assembly-based Situational Migration

Assembly-based Migration Plan Construction

Migration Pattern Meta-Model

MigrationPattern

AtomicAggregate

BeforeMigration

AfterMigration

Descriptor

ReuseSituation

ReuseIntention

MigrationPlan

1-*

2-*

1

1

1

1

Architecturemodel

1

1

Migration Patterns in the context of Cloud-RMM

Migration Planning Migration Execution Migration Evaluation

Cross-cutting Concerns

Process I Process II Process III

Umbrella Process I

mig

ratio

npl

an

clou

dsy

stem

artif

acts

evaluation report

P. Jamshidi, A. Ahmad, C. Pahl, "Cloud Migration Research: A Systematic Review", IEEE Transactions on Cloud Computing, 2013, DOI:10.1109/TCC.2013.10.

Migration patterns Primarily facilitate

planningEnable Auto-Deployment of Multi-Tier Systems in Hybrid Cloud Environment

http://dx.doi.org/10.1109/TCC.2013.10

Developing a single application as a suite of small services


Architecture of SSaaSbefore the migration

Target Architecture of SSaaS

Clusterization

Services are built around business capabilities


Services areindependently deployable by fully automated deployment machinery


There is a bare minimum of centralized management of the services (Polyglot-ness)


Transforming DeveloperDatato a Service Introducing Continuous Delivery

Introducing Edge Server Introducing Dynamic Service Collaboration Introducing Resource Manager

Deployment in the development environment is difficult for a

typical developer

Service contracts are double important

Distributed system development needs skilled developers

Creating service development templates is important