von javaee auf microservice in 6 monaten - the good, the bad, and the wtfs

Von JavaEE auf

Microservice in 6 MonatenThe Good, the Bad, and the wtfs...

André Goliath

ENTERPRISE IT

MY VISION(AND MY KEY HOLDER, TOO)

SO, HOW TO GET THERE?

WHEN

WHY

WITH WHOM

TO WHAT EXTENT

SO, HOW TO GET THERE?

WHEN

WHY

WITH WHOM

TO WHAT EXTENT

SO, HOW TO GET THERE?

Now!

„Digitization“

Cloud Computing Internet of Things

Virtual Reality

Microservices

$anything as a Service

fastIndustry 4.0

Web 2.0

Social Media

Big Data

Privacy & Security

„Digitization“

Cloud Computing Internet of Things

Virtual Reality

Microservices

$anything as a Service

Industry 4.0

Web 2.0

Social Media

Big Data

Privacy & Security

yeah, let´s

do this!

fast

WHEN

WHY

WITH WHOM

TO WHAT EXTENT

SO, HOW TO GET THERE?

Because we can!

Because we need to!

How long does it take from idea to production?

How long does it need to take from idea to production?

What is the cost of implementing an one-liner feature?

What should the cost be?

Because we need to!

How long does it take from idea to production?

How long does it need to take from idea to production?

What is the cost of implementing an one-liner feature?

What should the cost be?

6 months

Cost to develop x 5

and then some…

6 Monoliths.600 Services. 15 Clients. 25 Backends.

Featuring code from 1995 till today.(Anyone remember J2EE1.2 ?)

Don´t get me wrong.

Monoliths are not bad.(at least not all of them)

WHEN

WHY

WITH WHOM

TO WHAT EXTENT

SO, HOW TO GET THERE?

How to code?

How to deploy?

How to use?

SO, HOW TO GET THERE?

How to code?

How to deploy?

How to use?

SO, HOW TO GET THERE?

Spring Boot

But be careful!

How to catch a 404 error

and wrap it in your own JSON response?

How to catch a 404 error

and wrap it in your own JSON response?It took us about 30 work hours to figure this one out.

And it involves manipulating the embedded Tomcat.

Without a specific Spring Boot API for that feature.

Coding 1 Microservice? Easy.

Coding 100 Microservices? Not so easy.

How do we organize our configuration?

Do we want to share code?

Do we want to force all microservices to use the same Spring Boot version?

Do we allow communication between services?

What aspects do we NEED to be the same for all services?

HATOEAS? Service Boundaries?

Share framework code, nothing else.

Share framework code, nothing else.

If you have no regrets

about sharing your code

on github, it is probably

framework code

Share framework code, nothing else.

Filter (Security, Authentication, Logging, Monitoring)

Error Handling

Profile / Envíronment Configuration

Logging Configuration

Common Documentation

If you have no regrets

about sharing your code

on github, it is probably

framework code

How about communication?

Customer Search Card Management Account Management

„Backend“ Microservices

Mobile App Online Banking Branch

„Gateway“ Microservices

Mobile App Online Banking Branch

Actual Frontends

Customer Search Card Management Account Management

„Backend“ Microservices

Data

Tailoring

Mobile App Online Banking Branch

„Gateway“ Microservices

Mobile App Online Banking Branch

Actual Frontends

HATEOAS

Links

Service

Orchestration

Clientspecific

Security

Spring Cloud„Production-Ready“ Features…

… but only in an ideal world.

Spring CloudActuator endpoints

Good for quick debugging, but how to integrate them in an enterprise monitoring world?

Configserver

You better play by the rules. Don´t use a – in your service name!

Routing Stuff (Eureka, Zuul, Ribbon)

Works. But only if you commit to doing routing the Netflix-way.

How to code?

How to deploy?

How to use?

SO, HOW TO GET THERE?

Automation!Tests

Builds

Provisioning

Deployments

Automation! But…

Strict Hardware and OS Restrictions

No direct communication between development and production environments

No SSH connections to production

„I don´t trust those tools“ (senior dev.)

You want to put something into production?

Fine, here complete these forms,

and have them signed by 10 people,

who have never heard of you,

and have no clue what you are doing.

The most important rule

Use the same deployment toolchain

for development, UATs, and production!

So here is what we did.

Step 1: Prepare everything for coding

Code Repo

Developer

Jenkins

Deploy

Scripts

Ansibleansible-playbook create.yml

Step 2: Code and Test

Code Repo

Developer

Jenkins

Deploy

Scripts

git push origin f-newStuff

git

post-push

hook

ssh

scp

Development / Test Environment

Service

Host A

Service

Host B

Config

Server

Apache

mod_proxy

Step 3: Deploy to Production

Code Repo

Developer

Deploy

Scripts

POTS:

„Please deploy v1, I‘ll mail you the paperwork“

ftp

ssh

Development / Test Environment

Service

Host A

Service

Host B

Config

Server

Apache

mod_proxy

Ops Guy

Production Environment

Gateway

Service

Host B

Config

Server

Apache

mod_proxy

some proprietary protocols…

Service

Host A

Why no Docker?

Why no Docker?Getting into Docker is easy. Even at a later stage.

Getting back from Docker to something else is a hell of a ride.

How to code?

How to deploy?

How to use?

SO, HOW TO GET THERE?

Working software

over comprehensive documentation

- agilemanifesto.org -

Test-Driven Documentationusing spring-restdocs

Swagger UI

WHEN

WHY

WITH WHOM

TO WHAT EXTENT

SO, HOW TO GET THERE?

You must overcome Conway‘s Law

Vertical TeamsJust get used to it.

Customer Search Card Management Account Management

„Backend“ Microservices

Mobile App Online Banking Branch

„Gateway“ Microservices

Mobile App Online Banking Branch

Actual Frontends

All developed in

one team!?!

WHEN

WHY

WITH WHOM

TO WHAT EXTENT

SO, HOW TO GET THERE?

There is no need for a big bang

We started with 1 service and 1 client

There are viable migration pathseven for legacy code

Bottom Line?

It works. Even in enterprises.

One step at a time,

and you´ll be fine.

Thank You!

André Goliath

Senior Technical Consultant

andre.goliath@senacor.de