The cloud changed our software architectures

The cloud provides new services

Cloud providers offer a large number of ready-made services, such as databases, user management, message brokers and much more. This means that the operating environment of our software in the cloud differs significantly from the environment found in a traditional data centre.

In the on-premise data centre

When we create software in the Java environment that is to run in the customer’s data centre (on-premise), the environment is usually an application server or a Docker environment and a relational database. Other services such as

• NoSQL databases
• Queueing servers
• User administration for external users

are rare. If the new software is not the customer’s core system, it is also not possible to get these types of services ready for production. This would require addressing at least the following issues:

• High availability
• Patch management
• Authentication
• Data encryption
• Backup and restore

However, the expertise needed for new services is often lacking. The costs and the risk of disruption to operations associated with the new service are usually too high.

Managed services with cloud providers

For cloud providers, services are not costs and risks, they are a product that makes money. That is why investments are made differently in this area, and services that could not be provided in the on-premise data centre are suddenly available.

In this blog post, I will draw on Amazon Web Services (AWS) for examples. Google Cloud and Azure offer similar services, but I personally specialise in AWS.

In the cloud, we can run a service, such as a database, ourselves in a virtual machine. However, this does not offer any advantage over having your own data centre. If we choose an AWS-powered database instead, AWS will take care of the operational issues I mentioned before.

When it comes to databases, AWS offers not only SQL databases but also key-value, document and graph databases, full-text search engines, as well as more outlandish ones such as blockchain databases. AWS offers more than 200 services in total.

The impact on architecture

Whenever we want to add a new service, such as a database, using a managed service from a cloud provider, we build on the infrastructure we already have, the strengths and weaknesses of which we are already familiar with. This significantly lowers the risk that adding the service entails. There are always uncertainties when adding a self-operated service to your environment – and these can lead to delays and higher costs. Removing these risks from the equation allows you to focus more on developing the actual application and feel empowered to develop more innovative software. Being able to use new services that are not SQL databases and application servers enables us to select and integrate services that are a better fit for our software. In the past, for example, a lack of alternatives meant I often had to

• implement user administrations,
• manage graphs organisational structures in a relational database,
• store images and documents in a relational database and
• simulate asynchronous events in a database.

Having the right services makes all of this redundant. As a result, the software is simpler, contains fewer errors and is finished faster.

Cost model

The consumption-based costs incurred in the cloud mean organisations need to take a different approach to operating costs.

On-premise Centro de Datos

In a traditional software project, operating costs only play a role at the start of the project. Then, the required hardware and licences are requested. The operating costs cease to play any real role once the software has gone live. Change requests – for example, to replace an expensive database system with a cheaper one – have little impact. Since the infrastructure is in place and has been paid for in advance, having more efficient software does not lead to savings after the fact. Operating costs are not broken down to individual software components and, from a software development perspective, operating costs are seen as pre-existing costs.

In the cloud

Different, consumption-based cost models can be found in the cloud. More efficient software can lead to immediate savings by resulting in fewer chargeable calls, using less memory or requiring fewer or smaller virtual machines.

Operating costs can be assigned to individual software components via tagging. This sometimes even makes it possible to calculate the cost of a single transaction or the cost per user.

The impacts on architecture

Cloud cost models enable organisations to look at architectural decisions from a fresh angle. They can calculate the impact that an architectural change will have on operating costs and relate it to the cost of the change. A meaningful reduction in costs can then be the sole reason for changing a software program. Making this type of calculation requires having a sufficient amount of data from running the previous software program.

Operating costs can suddenly become a critical factor when choosing a technology. When it comes to cloud applications, an organisation should check whether it really needs an SQL database or whether a cheaper key-value database would also suffice, for example.

Serverless functions

Serverless functions are the epitome of cloud innovation, and there is no equivalent for them in on-premise data centres. In the realm of AWS, serverless functions are called ‘lambda functions’ and allow code artefacts – such as JavaScript, Python scripts or Java Jar files – to be executed in the cloud without their own server. They are invoiced based on the number of calls and the amount of time and memory consumed. If there are pauses between lambda function calls, the runtime environment is dismantled and rebuilt with the next call. A runtime environment that starts quickly is therefore important for good performance.

The impacts on architecture

The cost model and the start-up behaviour of lambda functions argue against using frameworks with a high memory and start-up overhead, such as Spring Boot or Java EE. The overhead is directly reflected in the operating costs. Slow-starting frameworks lead to high latencies during the first call. In Java, this led to the emergence of leaner and more efficient frameworks such as Quarkus, as well as faster-starting environments like GraalVM.

This start-up behaviour makes using resources with a high initialisation effort, such as SQL database connections, a poor option and by extension makes a persistence layer based on SQL databases detrimental for lambda functions.

We are now seeing complete applications being developed on the basis of lambada functions with greater regularity. This provides a cost benefit for low-load applications.

Conclusion

We can build customised and innovative applications in the cloud with less risk by selecting the right managed services. The cost models of the cloud create an additional factor to consider when making architectural decisions. And new, leaner architectural approaches are emerging thanks to serverless functions.

You will find more exciting topics from the adesso world in our latest blog posts.