von javaee auf microservice in 6 monaten - the good, the bad, and the wtfs
Post on 11-Apr-2017
466 Views
Preview:
TRANSCRIPT
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
top related