Cloud cost models provide new perspectives on architectural decisions

[suchona.kani.z]

The software becomes simpler, contains fewer errors and is completed more quickly.


The consumption-dependent costs in the cloud make a different approach to operating costs necessary.


In a classic software project, running costs only play a role at the start of the project. Then the required hardware and licenses are queried. Once the software is in operation, running costs hardly play a role. If changes are ordered to reduce license costs - for example, to replace an expensive database system with a cheaper one - this has little effect. Since the infrastructure is in place and has been paid for in advance, more efficient software does not lead to savings afterwards. Running costs are not broken down into individual software components and from a software development perspective, running costs are viewed as costs that already exist.


There are different consumption-based pricing models in the cloud. More efficient software can lead to immediate savings by requiring fewer billable calls, using less storage, or requiring fewer or smaller virtual machines.

Tagging allows the operating costs to be assigned to individual software components. This sometimes even makes it possible to calculate the cost of a single transaction or the cost per user.


The impact of an architectural change on operating costs can be calculated and related to the costs of the change. A worthwhile cost reduction can then be the sole reason for changing a software. A prerequisite for a calculation is sufficient data from the previous operation of the software.

When choosing a technology, operating costs can suddenly play a algeria consumer email list​ decisive role. For cloud applications, for example, you should check whether an SQL database is really necessary or whether a cheaper key-value database would be sufficient.

Serverless functions are a real cloud innovation for which there is no equivalent in on-premise data centers. At AWS, serverless functions are called "Lambda Functions" and allow code artifacts - for example JavaScript, Python scripts or Java Jar files - to be executed in the cloud without your own server. Billing is based on the number of calls, the time used and the memory used. During pauses between Lambda function calls, the runtime environment may be dismantled and rebuilt the next time it is called. A runtime environment that starts quickly is therefore important for good performance.

Impact on Architecture
The cost model and the start behavior of lambda functions speak against the use of frameworks with high memory and start overhead such as Spring Boot or Java EE. The overhead has a direct impact on the operating costs. Slow-starting frameworks lead to high latencies when first called. In the Java area, this led to the emergence of leaner and more efficient frameworks such as Quarkus and faster-starting environments such as GraalVM.

The startup behavior makes it unfavorable to use resources with high initialization effort, such as SQL database connections. A persistence layer based on SQL databases is therefore unfavorable for Lambda Functions.

We are now increasingly seeing complete applications being developed based on Lambda Functions. This offers a cost advantage for applications with low load.

Conclusion
In the cloud, we can build customized and innovative applications with less risk by selecting the right managed services. The cloud's cost models add an additional factor to architectural decisions. And with serverless functions, new, leaner architectural approaches are emerging.