DalleServiceOrienteArchitectures(SOA)aiMicroservizi

Claudio Bergamini CEO Imola Informatica cbergamini@imolinfo.it

Da: applicazioni “verticali”

Logica di Presentazione

Logica di Business

Gestione Dei Dati

Infr

astr

uttu

ra A

pplic

ativ

a Si

cure

zza,

Wor

kFlo

w, L

oggi

ng …

Appl.1 Logica di Business

Appl.2 Logica di Business

Appl.3 Logica di Business

Infr

astr

uttu

ra A

pplic

ativ

a Si

cure

zza,

Wor

kFlo

w, L

oggi

ng …

Logica di Presentazione

Gestione dei Dati

A: applicazioni “integrate”

Logica di Presentazione

Logica di Business

Gestione Dei Dati

Infr

astr

uttu

ra A

pplic

ativ

a Si

cure

zza,

Wor

kFlo

w, L

oggi

ng …

Siamo partiti da qui nel 2006

Siamo partiti da qui nel 2006

Siamo partiti da qui nel 2006

organizzato da:

5

Design SOA - Principi

• Separazione netta, chiara elogica tra le interfacce dei servizi e le tecnologie sottostanti

• Basso accoppiamento e interfacce dei servizi “ben fatte” riducono il rischio di rompere l’interoperabilità con altri servizi – Uno dei limiti degli approcci usati in passato

per l’object computing distribuito

organizzato da:

6

Loose Coupling

• Fisico – Nessun collegamento fisico diretto

necessario, uso di un intermediario • Nel tempo e nella comunicazione

– Asincronismo • Controllo della logica di processo

– Distribuita (vs centralizzata) • Pattern di interazione

– Messaggi auto-contenuti e data-centric (vs navigazione di complesse strutture OO)

• Tecnologico – Svincolato da piattaforma, OS, linguaggio

• Service discovery e binding – Dinamico, a runtime

organizzato da:

7

Granularità dei servizi

I servizi usati nelle SOA hanno valenza di business ➔ grana grossa

Attenzione ai tecnici: • sono più orientati verso servizi di basso livello

e non propriamente di business … • … procedendo a grana fine si ottiene una

miriade di servizi da gestire … • … con dettagli tecnici nelle loro interfacce

⇓ NON È SOA

organizzato da:

8

Composizione dei servizi

• Una delle fondamenta di SOA: nuovi servizi realizzati come composizione di servizi preesistenti (riuso)

• BPEL e ESB sono gli strumenti candidati • Previsioni/garanzie di

capacity e scalabilitàtanto più necessarieal crescere del riusodel servizio

Siamo partiti da qui nel 2006: la visione del percorso

Service-oriented architecture (SOA): an architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network.

Microservices:  a software architecture style in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs

“Microservices are the kind of SOA we have been talking about for the last decade. Microservices must be independently deployable, whereas SOA services are often implemented in deployment monoliths. Classic SOA is more platform driven, so microservices offer more choices in all dimensions.”- Torsten Winterberg

If Uber were built with a SOA, their services might be: GetPaymentsAndDriverInformationAndMappingDataAPI AuthenticateUsersAndDriversAPI If Uber were built with microservices, their APIs might be more like: SubmitPaymentsService GetDriverInfoService GetMappingDataService AuthenticateUserService AuthenticateDriverService More APIs, smaller sets of responsibilities.

Some say, microservices is just SOA done right. Some say, microservices has common roots with SOA but is really next-gen and lightweight and less-enterprisey.

Di cosa parliamo nel 2016

Fine-grained responsibility

Microservices may be single-task or single domain.

Need to convert RTF files to HTML. We used a library for that, so it was really easy. On the other hand, updating the library required us to re-deploy all instances of our application. Deployment was automated but anyway, for a team dozens of instances it required quite some attention. Wrapping that same library into a stand-alone application that’s listening for incoming HTTP requests was all that was necessary to turn it into a microservice. From that day on, updating that library was just a matter of re-deploying that single component (as long as the API stayed stable).

Nobody seriously thinks about creating separate services for those tasks and that’s the reason why it’s as fine-grained as it needs to be (and should be, probably).

I punti fermi

Built for fault tolerance

In-process method calls, are replaced with external calls between components. This requires attention but taking care of it appropriately makes your whole system much more stable and fault-tolerant by design already. Fault tolerance really is a central issue. Getting it done right early on is the key to succeed with microservices.

Characteristics of microservices architecture based application are as follows:

1. Service enabled, independently running components. 2. Independently running components classified around some business capabilities. 3. Product mentality over project. 4. Smart components using simple communication channels like simple RESTish protocol or lightweight messaging queue. 5. Decentralize standards. Each independent component can use their exclusive standard for development and deployment. 6. Decentralized data management. Observe in the above diagram, how individual components have their own data storage. 7. Automated infrastructure management. For deployment of independent components, we need to rely on automated infrastructure

management to reduce the complexity. 8. Application design considering failure in mind. There are several independent moving parts in applications. In the event of the

receiver not getting a response, it should be handled gracefully. 9. Evolutionary design for getting the best possible decomposed system, which can be replaced and upgraded without affecting its

collaborator.

Le caratteristiche risultanti di una MSA

Siamo partiti da qui nel 2006. E nel 2016?

1. No frequent and easy releases 2. Problem in continuous delivery 3. Difficult to manage team and project 4. Expensive scalability & performance 5. Lack of technology diversity 6. Not easy to replace components

Le criticità che migliora

1. Team communication overhead 2. Formal documentation overhead 3. Non uniform application 4. Dev-Ops complexity 5. Increased resource use 6. Increase network communication 7. Marshalling and unmarshalling 8. Network security 9. Testing 10.Production monitoring 11.High upfront cost

Le criticità che peggiora

GRAZIE

Claudio Bergamini cbergamini@imolinfo.it

IDEE DOMANDE