The software architectures are changing. In order to gain validated learning and reduce risk and uncertainty while developing new products one has to bring each increment into production. Only information gathered from behaviour of real users with each increment ensures that you build the right thing in the end. In this session you'll learn how you can stop building monolithic systems and start designing software based on microservices - each having its own lifecycle and being an independent deployment unit. You'll get a pretty good feeling about how to manage such distributed applications in production successfully as well. We'll use an online shop application based on microservices to discuss topics like deployment and operational questions like monitoring and logging.

1. Microservices and Conversion
Hunting
Howtobuildsoftwarearchitecturesforchangeableness
Bernd Zuther - IT Consultant Big Data
codecentric AG

2. 2/59

6. Conversion
Conversion Rate =
Number of Goals achieved
Visits
act of converting site visitors into paying customers
proportion of visits to a website which take action to go beyond a
website visit
·
·
6/59

7. FeatureToggle
public class TopSellerRecommendationPanel extends AbstractShopBasePanel {
@SpringBean
private FeatureToogleBean featureToogleBean;
...
@Override
protected void onConfigure() {
super.onConfigure();
setVisible(featureToogleBean.isTopSellerFeatureEnabled());
}
...
}
JAVA
7/59

8. Continuous Improvement
Continuous
Improvement
(Agility)
Architecture
Continuous
Delivery
Big Data
Innovation
8/59

9. Architecture
Continuous
Improvement
(Agility)
Architecture
Continuous
Delivery
Big Data
Innovation
9/59

10. White Label-Shop
Company BCompany A
give subset of
products
Landing Page BOnline Shop A
Logistics A
create order
ship order
publish products
10/59

13. Disadvantages of a Monolith
Development:
Product Management:
·
Reduction of development speed
Increase of turnaround times
Increase of build time
Strange behavior after changes
Application Scalability
-
-
-
-
-
·
Increase of time to market
A/B testing of process changes nearly impossible
Scalability of Workload
-
-
-
13/59

15. Microservice
Data
Functionality
15/59

16. Microservice Architecture
Data
Functionality
Data
Functionality
Data
Functionality
Functionality
Data
Functionality
Data
16/59

17. Microservice Taxonomy
Microservice
Application
Frontend
Service
Service
Repository
Service
Discovery
Contract Implementation Interface
Business
Logic
Data
17/59

18. Differences to SOA
Lightweight infrastructure and protocols (e.g. REST)
Greater flexibility of architecture (e.g. can contain GUI)
Managed as products, with their own lifecycle and delivery
Deployed as processes (Unix packages or Container)
·
·
·
·
18/59

19. Online Shop - Use cases
Online Shop
order products
Buyer
view catalog
<include>
create cart
<include>
19/59

20. Online Shop - Migration
<<device>>
Microservice Server
<<web server>>
Ngnix
<<service>>
Cart Service
<<service>>
Product
Service
<<device>>
Monolith Server
<<application server>>
Tomcat
<<artifact>>
shop.war
<<artifact>>
Catalog View
<<artifact>>
cart-service.jar
<<artifact>>
product-
service.jar
Cart
Catalog
Product
20/59

24. Challenges of Microservices
Require integration.
Require a multi deployment pipeline.
Require automation of deployment and configuration.
Require logging and monitoring.
·
·
·
·
24/59

25. Leavitt - Communication Structure
Type Star Chain Circle Complete Structure
centralization high medium low very low
communication low medium much very much
controllability much medium low very low
25/59

26. Leavitt in Action
<<device>>
Microservice Server
<<web server>>
Ngnix
<<service>>
Cart Service
<<service>>
Product
Service
<<device>>
Monolith Server
<<application server>>
Tomcat
<<artifact>>
shop.war
<<artifact>>
Catalog View
<<artifact>>
cart-service.jar
<<artifact>>
product-
service.jar
Cart
Catalog
Product
26/59

29. Postel’s Law
{
firstname: "Bernd",
lastname: "Zuther",
street: "Elsenheimerstraße 55a",
city: "München",
zip: 80687
}
JAVASCRIPT
29/59

30. Postel’s Law
{
firstname: "Bernd",
lastname: "Zuther",
birthday: "1983/08/15",
street: "Elsenheimerstraße 55a",
city: "München",
zip: 80687
}
JAVASCRIPT
30/59

32. Postel’s Law
{
firstname: "Bernd",
lastname: "Zuther",
birthday: "1983/08/15",
addresses : [{
street: "Elsenheimerstraße 55a",
city: "München",
zip: 80687,
type: "WORK"
}]
}
JAVASCRIPT
32/59

34. Postel’s Law
{
firstname: "Bernd",
lastname: "Zuther",
birthday: "1983/08/15",
street: "Elsenheimerstraße 55a",
city: "München",
zip: 80687,
addresses : [{
street: "Elsenheimerstraße 55a",
city: "München",
zip: 80687,
type: "WORK"
}]
}
JAVASCRIPT
34/59

36. Alternatives
URL:
Custom request header:
Accept header:
·
simply whack the API version into the URL, e.g. https://shop
/api/v2/cart/all
-
·
same URL as before but add a header “api-version: 2”-
·
modify accept header to specify the version, e.g. “Accept:
application/vnd.cart.v2+json”
-
36/59

37. Continuous Delivery
Continuous
Improvement
(Agility)
Architecture
Continuous
Delivery
Big Data
Innovation
37/59

39. Multi Deployment Pipeline
Build Test Publish
UI-Test
Build Test Publish
Deploy
Load-Test
Catalog View
Productservice
39/59

42. Deployment
@RestController
class CartController {
@Autowired
def CartRepository cartRepository;
@RequestMapping(value = "/create", produces =
MediaType.APPLICATION_JSON_VALUE, method =
RequestMethod.PUT)
@ResponseBody
def UUID create(@RequestBody CartItem item) {
cartRepository .create(item)
}
<<executable>>
cart-service.jar
build
Configuration
CART_SERVICE_PROFILES=production
CART_SERVICE_PORT=18100
CART_SERVICE_REDIS_URL=redis.microservice.io
release
release
<<package>>
cart-service.debrelease
Infrastructure Code
#! /bin/sh
PIDFILE=/var/run/cart.pid
BASE_DIRECTORY=/usr/share/shop/cart/bin
42/59

44. Docker Environment
<<device>>
Docker Deamon
<<container>>
Ngnix
<<container>>
Cart Service
<<container>>
Product
Service
<<artifact>>
checkout
.war
<<artifact>>
catalog.tar
<<artifact>>
cart-service.jar
<<artifact>>
product-
service.jar
<<container>>
Tomcat
<<container>>
MongoDB
<<container>>
Redis
<<container>>
Navigation
Service
<<artifact>>
navigation-
service.jar

45. Kubernetes - Cluster Management
45/59

46. Pod
kind: Pod
desiredState:
manifest:
containers:
- name: mongodb
image: dockerfile/mongodb
cpu: 100
memory: 50000000
ports:
- containerPort: 27017
YAML

47. Replication Controller
kind: ReplicationController,
desiredState:
replicas: 4
podTemplate:
desiredState:
manifest:
containers:
- name: product
image: zutherb/product-service
YAML

48. Service
48/59

49. Big Data
Continuous
Improvement
(Agility)
Architecture
Continuous
Delivery
Big Data
Innovation
49/59

53. Summary
Pro Needs
better A/B testing monitoring
effective technologies centralised logging
solution orientation
fully automated deployment
pipeline
incremental migration cluster management
Microservices do not guarantee more conversion!
You need to run experiments with your customers!

54. <Thank You!>
g+ plus.google.com/+BerndZuther
twitter @Bernd_Z
www bernd-zuther.de
github github.com/zutherb/