Green Software Development Community Meeting, October 2022, Sascha Böhme (Software Architect @ QAware).
== Dokument bitte herunterladen, falls unscharf! Please download slides if blurred! ==
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.
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
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
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
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?
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
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