Digitalization with its demand of further services poses a challenge to reduce emissions. These seemingly contradicting goals, more services and less emissions, can be balanced with an appropriate choice of applied tools. Based on examples, we demonstrate that substantial savings are possible for fully-featured enterprise-grade applications. We focus on technology rather than on infrastructure and show the tools and libraries that help in building green enterprise services.

1. qaware.de
The Path to
Green Enterprise Applications
Sascha Böhme
sascha.boehme@qaware.de

2. Once upon a time, there was a service …
QAware | 2

3. Our challenge
QAware | 3
Digital transformation produces further
services that are constantly running
IT provides value to
business and customers
IT enables new,
previously unthinkable
business models
How to limit the
increase in energy
consumption?
How to limit the
rebounce effect?
This bad-case prediction lacks changes that are
currently unknown, yet is a good warning sign

4. QAware | 4

5. QAware | 5
A personal perspective

6. Advantages in using Payara
● in use since many years
● well understood
● proven
● stable
● standardized
● full of functionality
● few surprises
QAware | 6

7. Drawbacks in using Payara
QAware | 7
● long start times
● long turnaround times
● moderate performance
● high memory consumption
● large container images
● little documentation besides
standards

8. QAware | 8
Should we continue that way?

9. Or should we rather
try new paths?
QAware | 9

10. “If your service is too slow, re-implement it in Go”
QAware | 10
Go:
● fast
● small
● easy to learn
● widely applied in the cloud-native
world

11. “Use Quarkus to build fast and lightweight applications”
QAware | 11
Quarkus:
● close to JakartaEE
● regular innovations
● rich documentation
● native executables

12. “You’d be stupid not to switch over to AWS Graviton2”
QAware | 12
ARM Graviton2 vs. comparable x86:
● similar in single-thread benchmarks
● superior in multi-thread benchmarks
● considerably fewer costs
● half of the energy consumption

13. QAware | 13
What is the right time for change?

14. QAware | 14

15. QAware | 15
Enterprise Software
Today
1
Measures for
Green Software
2
Greener
Enterprise Software
3

16. Enterprise Software Today

17. QAware | 17
Microservice
Database
Backend
Service
Mesh
Gateway
Load
Balancer
Kubernetes
Enterprise application infrastructure – a simplified view
Microservice

18. QAware | 18
Characteristics of enterprise microservices
Configuration Security
Documentation
Interfaces Data storage Resilience
Logging Tracing Metrics
Version control Continuous integration
Elasticity

19. The DevOps model applies to enterprise microservices
QAware | 19

20. Measures for Green Software

21. What is green software?
QAware | 21
#include <stdio.h>
#include <go-green.h>
int main() {
printf(“Hello, green world!n”);
return 0;
}

22. Benefit
Energy
high
energy
efficiency
low
energy
efficiency
Green = energy-efficient
QAware | 22
reduce the energy
required to provide
services or products
maximize the
benefit for the
consumed energy

23. Every DevOps phase requires energy
QAware | 23

24. Measures in operating microservices
QAware | 24
Power consumption in computer hardware:
● CPU
● memory
● I/O (network, disk)
● cooling
● everything else
Power consumption with virtualization:
● decoupled from real hardware
● measure usage of CPU, memory,
network
● consider capacity and load for CPU
and memory
Measurable benefits of microservices:
● availability: percentage of errors
on total requests
● latency: response time
● throughput: number of processed
requests per time unit

25. Making microservices green is an optimization problem
QAware | 25
Goals:
● minimize CPU usage
● minimize memory usage
● minimize I/O usage
● minimize latency
● maximize throughput
Simple strategies:
● be faster
● do less
● something else
Which goal can be sacrificed?

26. Greener Enterprise Software

27. A promising approach?
QAware | 27

28. A promising approach: a hello-world service
QAware | 28
Payara @Path("/hello")
@ApplicationScoped
public class HelloResource {
@GET
@Produces (MediaType.APPLICATION_JSON)
public Response sayHelloWorld () {
return Response.ok(new HelloResponse( "Hello, world!" )).build();
}
}
func main() {
http.HandleFunc( "/api/hello" , func(w http.ResponseWriter, r *http.Request) {
helloResponse := helloResponse{Text: "Hello, world!" }
js, _ := json.Marshal(helloResponse)
w.Header().Set( "Content-Type" , "application/json" )
_, _ = w.Write(js)
})
log.Fatal(http.ListenAndServe( ":9090", nil))
}
Go

29. A promising approach: artifacts und runtime behavior
QAware | 29
Start time
Container image size
Throughput
Maximum memory usage
Payara
Go
15 s
< 1 s
Payara
Go
10.000 req/s
25.000 req/s
Payara
Go
560 MB
15 MB
Payara
Go
350 MB
7 MB

30. Why aren’t we using
Go everywhere?
QAware | 30

31. QAware | 31
Let’s run a competition
Inspired by:
● Computer Language Benchmarks Game
● Energy Efficiency across Programming Languages

32. QAware | 32
Measure and compare
Scenario:
● microservice
● HTTP, JSON, SQL
● containerized
Competitors:
● Payara
● Quarkus
● Go
Benchmarks:
● idle vs. load
● limits on CPU and memory

33. A sample microservice
QAware | 33
1. HTTP API using JSON representation
2. HTTP client using JSON representation
3. Relational database
4. Logic (mapping, merging)
HTTP API
HTTP client
SQL DB
Logic
1
2
3
4

34. QAware | 34
Ready, steady, go!

35. Measurements – build
QAware | 35
JVM native
container image 363 MB 384 MB 81 MB 12 MB
build time 10 s 10 s 320 s 30 s

36. Measurements – start
QAware | 36
JVM native
start time 45 s 5 s 1 s 1 s
start CPU 110 % 110 % 1 % 1 %
start memory 477 MB 80 MB 10 MB 5 MB
idle CPU 1 % 1 % 0 % 0 %
idle memory 470 MB 80 MB 9 MB 5 MB

37. JVM native
10 rps
1 CPU – 1024 MB
20 ms
18% — 435 MB
20 ms
15% — 120 MB
11 ms
4% — 80 MB
8 ms
2% — 10 MB
50 rps
1 CPU – 1024 MB
18 ms
50% — 464 MB
16 ms
40% — 145 MB
9 ms
18% — 90 MB
6 ms
6% — 10 MB
100 rps
1 CPU – 1024 MB
214 ms
95% — 515 MB
47 ms
65% — 189 MB
8 ms
27% — 94 MB
8 ms
35% — 11 MB
200 rps
1 CPU – 1024 MB
n/a
888 ms
85% — 250 MB
15 ms
50% — 98 MB
16 ms
50% — 110 MB
Measurements – load
QAware | 37

38. Measurements – load and limits
QAware | 38
JVM native
10 rps
0.25 CPU – 256 MB
OOM at start 21 ms
13% — 124 MB
11 ms
5% — 28 MB
11 ms
4% — 10 MB
50 rps
0.25 CPU – 256 MB
n/a
6850 ms
29% — 240 MB
10 ms
21% — 30 MB
9 ms
18% — 10 MB
100 rps
0.25 CPU – 256 MB n/a n/a
48 ms
27% — 35 MB
4850 ms
27% — 45 MB
[0.75%]

39. Measurements – results
QAware | 39
Payara
● fast build
Quarkus (JVM)
● fast build
● fast start
● low runtime footprint
Go
● fast build
● tiny container image
● fast start
● very low runtime footprint
Quarkus (native)
● small container image
● fast start
● very low runtime footprint

40. QAware | 40
Is Go ready for enterprise microservices?
Configuration Security
Documentation
Interfaces Data storage Resilience
Logging Tracing Metrics
Version control Continuous integration
Elasticity
✓ ✓ ✓
✓
✓
✓
✓ ✓
✓
✓ ✓
✓

41. Where to go from here?
QAware | 41

42. QAware | 42
Future directions
Optimize further BizDevOps phases:
● re-consider design decisions
● choose other technologies (e.g., gRPC for less network usage)
● optimize code if appropriate measurement setup is in place
● optimize CI/CD
● use ARM infrastructure
Consider further frameworks and languages:
● Spring, Rust, C++, …
● respect enterprise criteria: maturity, IDE support, tooling, libraries, documentation

43. Let’s make
software green!

44. qaware.de
QAware GmbH
Aschauer Straße 32
81549 München
Tel. +49 89 232315-0
info@qaware.de
twitter.com/qaware
linkedin.com/company/qaware-gmbh
xing.com/companies/qawaregmbh
slideshare.net/qaware
github.com/qaware