Mein Foliensatz zum JUG Cologne Vortrag vom 16.11.2015

1. Von JavaEE auf
Microservice in 6 Monaten
The Good, the Bad, and the wtfs...
André Goliath

2. ENTERPRISE IT

4. MY VISION
(AND MY KEY HOLDER, TOO)

6. SO, HOW TO GET THERE?

7. WHEN
WHY
WITH WHOM
TO WHAT EXTENT
SO, HOW TO GET THERE?

8. WHEN
WHY
WITH WHOM
TO WHAT EXTENT
SO, HOW TO GET THERE?

9. Now!

11. „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

12. „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

13. WHEN
WHY
WITH WHOM
TO WHAT EXTENT
SO, HOW TO GET THERE?

14. Because we can!

15. 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?

16. 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…

17. 6 Monoliths.
600 Services. 15 Clients. 25 Backends.
Featuring code from 1995 till today.
(Anyone remember J2EE1.2 ?)

18. Don´t get me wrong.
Monoliths are not bad.
(at least not all of them)

19. WHEN
WHY
WITH WHOM
TO WHAT EXTENT
SO, HOW TO GET THERE?

20. How to code?
How to deploy?
How to use?
SO, HOW TO GET THERE?

21. How to code?
How to deploy?
How to use?
SO, HOW TO GET THERE?

22. Spring Boot

23. But be careful!

24. How to catch a 404 error
and wrap it in your own JSON response?

25. 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.

26. 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?

27. Share framework code, nothing else.

28. Share framework code, nothing else.
If you have no regrets
about sharing your code
on github, it is probably
framework code

29. 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

30. How about communication?

31. Customer Search Card Management Account Management
„Backend“ Microservices
Mobile App Online Banking Branch
„Gateway“ Microservices
Mobile App Online Banking Branch
Actual Frontends

32. 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

33. Spring Cloud
„Production-Ready“ Features…
… but only in an ideal world.

34. Spring Cloud
Actuator 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.

35. How to code?
How to deploy?
How to use?
SO, HOW TO GET THERE?

36. Automation!
Tests
Builds
Provisioning
Deployments

37. 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.

38. The most important rule
Use the same deployment toolchain
for development, UATs, and production!

39. So here is what we did.

40. Step 1: Prepare everything for coding

41. Code Repo
Developer
Jenkins
Deploy
Scripts
Ansible
ansible-playbook create.yml

43. Step 2: Code and Test

44. 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

45. Step 3: Deploy to Production

46. 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

47. Why no Docker?

48. 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.

49. How to code?
How to deploy?
How to use?
SO, HOW TO GET THERE?

50. Working software
over comprehensive documentation
- agilemanifesto.org -

51. Test-Driven Documentation
using spring-restdocs

55. Swagger UI

57. WHEN
WHY
WITH WHOM
TO WHAT EXTENT
SO, HOW TO GET THERE?

58. You must overcome Conway‘s Law

59. Vertical Teams
Just get used to it.

60. 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!?!

61. WHEN
WHY
WITH WHOM
TO WHAT EXTENT
SO, HOW TO GET THERE?

62. There is no need for a big bang

63. We started with 1 service and 1 client

64. There are viable migration paths
even for legacy code

65. Bottom Line?

66. It works. Even in enterprises.

67. One step at a time,
and you´ll be fine.

68. Thank You!
André Goliath
Senior Technical Consultant
andre.goliath@senacor.de