Javaland 2017: "You´ll do microservices now". Now what?

“So, ihr macht dann mal Microservices!”

Und nu?

André Goliath

(English slide deck for a german title, because why not)

Disclaimer

Everything in this talk is based on experiences…

… from my current project

… from other projects I worked on

… from other colleagues’ projects

… from other smart people

About me?

Full-Stack Dev. since around 2006.

But basically just a guy that worked on

and discussed a lot about microservices.

Spoiler:

That´s not how it works.

Before we start:

What are we actually talking about?

What is a microservice?

A microservice is not…

… something with X lines of code.

A microservice is not…

… your monolith cut into pieces.(Well, maybe it is, if it was a good one.)

(But most likely not.)

A microservice is not…

… the cure to all your pain.

Anyway, let´s start coding!

Microservices are not about code.

They are about functional domains.

(Bummer, I know.)

Designing a microservice landscape

is all about bounded contexts

and domain driven design.

https://www.infoq.com/minibooks/domain-driven-design-quickly

Loose Frontend Integration

Accounts

Custo

mer

Managem

ent

Cre

dit

Card

Managem

ent

One Microservice represents

one domain.

Domains are technically separated

all the way from the Frontend to the Backend.

The concept of ‘microservices’

is only the first step in the right direction.

Eventually we want to achieve

truly Self Contained Systems.

Messaging / Data Sync.

Big Pile of HTML

Accou

nts

Big Pile of Data

Custo

mer

Managem

ent

Cre

dit

Card

Managem

ent

You are not doing it right if your microservices

somewhat represent bounded contexts,

but everything above and below is shared

and tightly coupled. Things WILL break.

Please read up on domain driven

design before doing microservices.

Legacy Backends are no excuse.

Okay, okay, got it. Domain first.

So we can code now, right?

Yes, but know what you are doing!

Spring Boot can be scary!(and sometimes somewhat frustrating)

Get to know it.

Understand auto configuration

C:\example\target>java -jar demo-0.0.1-SNAPSHOT.jar –debug

…

2017-03-26 13:54:24.371 DEBUG 5316 --- [ main]

AutoConfigurationReportLoggingInitializer :

=========================

AUTO-CONFIGURATION REPORT

=========================

Positive matches:

-----------------

DispatcherServletAutoConfiguration matched:

- @ConditionalOnClass found required class

'org.springframework.web.servlet.DispatcherServlet';

@ConditionalOnMissingClass did not find unwanted class (OnClassCondition)

- @ConditionalOnWebApplication (required) found StandardServletEnvironment

(OnWebApplicationCondition)

…

Negative matches:

-----------------

ActiveMQAutoConfiguration:

Did not match:

- @ConditionalOnClass did not find required classes

'javax.jms.ConnectionFactory', 'org.apache.activemq.ActiveMQConnectionFactory'

(OnClassCondition)

Auto Configuration Test Questions• What does @EnableAutoConfiguration do?

• What is the purpose of spring.factories files?

• How would you replace the standard Spring Boot error page?

Try to solve this without looking up the docs, dive right into

org.springframework.boot.autoconfigure.web.ErrorMvcAutoConfiguration

Read the release notes!

There WILL be breaking changes

going from 1.x to 1.y

shamelessly copy&pasted from

https://github.com/spring-projects/spring-boot/wiki/spring-boot-1.3-release-notes

Now you´ve got 1 Microservice.

How about 2? Or 100?

1) Code sharing

2) Communication

3) Ops & Deployment

4) Compliance, Processes, Team Setup

1)

Code Sharing

sharing is caring

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, logging, monitoring,…)

Error handling

Profile / Environment configuration

Logging configuration

Common documentation

If you have no regrets

about sharing your code

on github, it is probably

framework code

2)

Communication

Blah, blah, blah, blah…

There are (at least) 2 different kinds

of communication going on

Client Microservice Communication

REST, but how?

HATEOAS yes/no/maybe?

One API for all clients?

Customer Search Card Management Account Management

„Backend“ Microservices

Mobile App Online Banking Branch

Actual Frontends

Customer Search Card Management Account Management

„Backend“ Microservices

Mobile App Online Banking Branch

Actual Frontends

„API Gateway“ / „BFF (Backend For Frontend)“ Microservices

Mobile App

BFF Service

Online Banking

BFF Service

Branch

BFF Service

Customer Search Card Management Account Management

„Backend“ Microservices

Mobile App

BFF Service

Online Banking

BFF Service

Branch

BFF Service

Mobile App Online Banking Branch

Actual Frontends

„API Gateway“ / „BFF (Backend For Frontend)“ Microservices

Data

TailoringHATEOAS

Links

Service

Orchestration

Clientspecific

Security

Microservice Microservice Communication

REST will usually work.

But many use cases profit

from asynchronous messaging.

(Just talk to one of the ‘reactive’ experts)

3)

Ops and Deployment

Keep in mind:

Microservices make devs’ life a lot easier,

but will make ops’ life much more difficult.

Keep in mind:

Microservices make devs’ life a lot easier,

but will make ops’ life much more difficult.

TALK TO THEM. EARLY. OFTEN.

THEY ARE YOUR FRIENDS.

The three golden rules

of microservice deployments

(In my opinion. Don´t ask for scientific proof.)

1) Build once, run everywhere.

Build once, run everywhere.

A microservice JAR file is built exactly once

and then never touched again.

Goodjava –jar service.jar –spring.profiles.active=“production”

Badmvn clean install spring-boot:repackage -P “production”

2) Use the same tools. Everywhere.

Use the same tools. Everywhere.

Development, test, production. Everywhere.

Use the same tools. Everywhere.

Development, test, production. Everywhere.

no can do

in

Production

“You can not use the same software tools and

infrastructure components in test and production.”

– No regulatory body, never.

DeveloperJenkins / Ansible / PaaS / …

Development / Test Environment

Service

Host A

Service

Host B

Config

Server

Ops Guy

Production Environment

Gateway

Jenkins / Ansible / PaaS / …

Service

Host A

Service

Host B

Config

Server

Use a gateway if you need to.

“You can not use the same software tools and

infrastructure components in test and production.”

– No regulatory body, never.

Note: This has nothing to do with DevOps*.

*) DevOps is helpful, but by no means required. Nevertheless, Dev and Ops need to talk.

3) if it hurts, do it more often.

You’ve heard that one before?

SCRUM feedback cycles maybe?

if it hurts, do it more often.

The most important steps of a delivery pipeline

should be based on the most tested and

bullet-proof processes and tools.

That´s hardly the case

if you deploy to production only twice a year

and use production-only scripts for that.

if it hurts, do it more often.

The most important steps of a delivery pipeline

should be based on the most tested and

bullet-proof processes and tools.

4)

Compliance, Processes, Team Setup

Strong, the dark side is with this one...

Very specific to your individual setting.

Here are two general tips though.

1)

Don´t let the word ‘Compliance’ stop you

from taking the first steps to revamp

your software delivery process.

2)

The company needs to work vertically,

not horizontally.

Team „Business“

Team „Frontend Developer“

Team „Middleware Developer“

Team „Database and Backend Gurus“

Credits Online Channels

Internal Online

JEE COBOL

COBOL DB Admins

Teaming up along technology

antagonizes a domain driven

software architecture.

(Ever heard of

Conway’s law?)

Team „Credit“

Domain Experts

Domain Experts

Frontend Frontend

Tester

Tester

BackendBackend

Teaming up along domain

expertise makes

Domain Driven Development

much easier.

Team „Account“

Team „Credit“

Domain Experts

Domain Experts

Frontend

Tester

Tester

BackendBackend

Still, Tech Experts

need to be aware

of each other.

But it remains a

“Domain First” organization.

Team „Account“

Frontend

Key Takeaways

A microservice is defined by a Bounded Context,

not by anything else.

Know your Spring Boot (or whatever else you use).

Build once, run everywhere.

Use the same tools. Everywhere.

if it hurts, do it more often.

Don’t let ‘Compliance’ stop you.

Only vertical teams will succeed.

Thank You!

André Goliath

andre.goliath@senacor.de

https://www.slideshare.net/andregoliath

https://blog.senacor.com/author/andre/