The slides for my talk at JavaLand 2017. Note: The slides are in english, only the title is german. The talk is all about do's and dont's in microservice landscapes.

1. “So, ihr macht dann mal Microservices!”
Und nu?
André Goliath
(English slide deck for a german title, because why not)

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

4. Spoiler:
That´s not how it works.

5. Before we start:
What are we actually talking about?
What is a microservice?

6. A microservice is not…
… something with X lines of code.

7. A microservice is not…
… your monolith cut into pieces.
(Well, maybe it is, if it was a good one.)
(But most likely not.)

8. A microservice is not…
… the cure to all your pain.

9. Anyway, let´s start coding!

11. Microservices are not about code.
They are about functional domains.
(Bummer, I know.)

12. Designing a microservice landscape
is all about bounded contexts
and domain driven design.
https://www.infoq.com/minibooks/domain-driven-design-quickly

13. Loose Frontend Integration
Accounts
CustomerManagement
CreditCardManagement
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.

14. Big Pile of HTML
Accounts
Big Pile of Data
CustomerManagement
CreditCardManagement
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.

15. Okay, okay, got it. Domain first.
So we can code now, right?

16. Yes, but know what you are doing!

17. Spring Boot can be scary!
(and sometimes somewhat frustrating)
Get to know it.

18. Understand auto configuration

19. C:exampletarget>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)

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

21. Read the release notes!
There WILL be breaking changes
going from 1.x to 1.y

22. shamelessly copy&pasted from
https://github.com/spring-projects/spring-boot/wiki/spring-boot-1.3-release-notes

23. Now you´ve got 1 Microservice.
How about 2? Or 100?

24. 1) Code sharing
2) Communication
3) Ops & Deployment
4) Compliance, Processes, Team Setup

25. 1)
Code Sharing
sharing is caring

26. Share framework code, nothing else.

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

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

29. 2)
Communication
Blah, blah, blah, blah…

30. There are (at least) 2 different kinds
of communication going on

31. Client  Microservice Communication
REST, but how?
HATEOAS yes/no/maybe?
One API for all clients?

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

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

34. 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
Tailoring
HATEOAS
Links
Service
Orchestration
Clientspecific
Security

35. Microservice  Microservice Communication
REST will usually work.
But many use cases profit
from asynchronous messaging.
(Just talk to one of the ‘reactive’ experts)

36. 3)
Ops and Deployment

37. Keep in mind:
Microservices make devs’ life a lot easier,
but will make ops’ life much more difficult.

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

39. The three golden rules
of microservice deployments
(In my opinion. Don´t ask for scientific proof.)

40. 1) Build once, run everywhere.

41. Build once, run everywhere.
A microservice JAR file is built exactly once
and then never touched again.
Good
java –jar service.jar –spring.profiles.active=“production”
Bad
mvn clean install spring-boot:repackage -P “production”

42. 2) Use the same tools. Everywhere.

43. Use the same tools. Everywhere.
Development, test, production. Everywhere.

44. Use the same tools. Everywhere.
Development, test, production. Everywhere.
no can do
in
Production

46. “You can not use the same software tools and
infrastructure components in test and production.”
– No regulatory body, never.

47. Developer
Jenkins / 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.

48. 3) if it hurts, do it more often.
You’ve heard that one before?
SCRUM feedback cycles maybe?

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

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

51. 4)
Compliance, Processes, Team Setup
Strong, the dark side is with this one...

52. Very specific to your individual setting.
Here are two general tips though.

53. 1)
Don´t let the word ‘Compliance’ stop you
from taking the first steps to revamp
your software delivery process.

54. 2)
The company needs to work vertically,
not horizontally.

55. 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?)

56. Team „Credit“
Domain Experts
Domain Experts
Frontend Frontend
Tester
Tester
Backend
Backend
Teaming up along domain
expertise makes
Domain Driven Development
much easier.
Team „Account“

57. Team „Credit“
Domain Experts
Domain Experts
Frontend
Tester
Tester
Backend
Backend
Still, Tech Experts
need to be aware
of each other.
But it remains a
“Domain First” organization.
Team „Account“
Frontend

58. Key Takeaways

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

60. Thank You!
André Goliath
andre.goliath@senacor.de
https://www.slideshare.net/andregoliath
https://blog.senacor.com/author/andre/