Skip to main content

How to design application architecture for the cloud

By October 24, 2016Article

The cloud has significantly changed the software industry for the better. With the ability to scale as needed, predict costs and be easily and globally accessible to both in-house folks as well as outsourced teams, it simply makes developers’ lives easier and brings more value to companies. 

We all agree it’s wonderful, but how can you design an application architecture for the cloud that is flexible and scalable? The first step is to approach this by knowing and understanding the common quality attributes of the cloud:

  • Time to market
  • Scalability
  • Availability
  • Monitoring
  • Security
  • Cost
  • Resilience

There are always multiple challenges to creating an architecture design, but you can start solving them by utilizing different tactics in order to archive the common attributes of the cloud and ensure you have utilized all of them. Let’s go through each one. 

Time to market 

In most cases, the key driver for any cloud application architecture decision is dependent on the time to market. Business needs and goals always dictate when the cloud environment needs to be live. To achieve time to market, you should first consider utilizing an off-the-shelf solution. Why reinvent the wheel if you don’t have to? Always start by checking to see if there is a ready-to-use solution provided by your cloud provider or available on the market. This decision can significantly reduce your cost and the time it takes to implement. 


In order to achieve a flexible and scalable cloud infrastructure, don’t think about servers as static resources. Servers in the cloud can be easily terminated, replaced or added if you follow these two tricks: 

  1. Golden images: Create server images with the specific version of your system.
  2. Bootstrap scripts: For this approach, use a Chef, Puppet, Ansible or even bash scripts.

Also, remember:

  • If you want to achieve horizontal scalability, you need to design stateless components.
  • Design a system with loose coupling components and use messaging for communication between components.


The main strategy when creating a cloud architecture is to design for a failure. Here are some time-saving and foolproof tips on how to ensure high availability:

  1. Distribute your servers and services between different geographic locations.
    • Use messaging for communication between components. This can guarantee that you will not lose a message when some component is not available.


Monitoring is like analytics. The data is only useful when it’s quickly and easily understood and accessible. This is true if you are running one or multiple servers. 

To perform troubleshooting and incidents investigation in the elastic cloud environment, you need to publish server logs on a remote server that you can access and search at any time from anywhere. 

If you want to build your own log aggregation solution, Elastic is the de facto standard. If you prefer to use SaaS, I always recommend using Sumo Logic or Loggly


Security is always important. First, you need to decide how you’re going to manage access to the cloud. Most cloud providers offer multiple ways; but regardless of the method, I always recommend you apply the following items to your individual setup:

  1. Encrypt communication between all service components.
  2. Encrypt all sensitive information.
  3. Grant the minimum required access level to the cloud services for your software applications.
  4. Design a solution that rotates encryption keys and credentials.
  5. Use VPNs.


Cost is always a factor in any business and can significantly impact software developers when trying to create solutions to real-world business problems. There are two ways I’ve always found reliable in cutting costs:

  • Make sure you shut down any and all unused resources. Oftentimes, only a handful of users need access to the system at night. Find out how many you actually need and then shut down and spin up servers on a time and day schedule.
  • Horizontal scalability is a powerful tool for cost optimization. While it’s not always the right solution, do your due diligence and see if it can be the right solution for each project. Also, you may be able to use a tactic where you have one big server that handles a normal load and a smaller one that you can use to increase system capacity as needed.


Resilience is a system ability to handle errors and recover after failures. Let’s say you have a few hundred web servers that use a MySQL database server. For some reason, the database server was unavailable for some time, and now it’s back online. Will your system be able to reconnect to the database after the connection failure? Will you need to restart your web servers in order to reconnect to the database? In the cloud infrastructure, you don’t have any control over the network and availability of remote services. When designing, it is recommended that you use well-known design patterns:

  • Circuit breaker is a pattern that allows you to design a system that may temporarily disable access to the remote resource when it’s in the failed state. When the remote service is available again, the system detects this and enables usage of the remote resource.
  • Retry pattern. The idea here is pretty simple: if a remote resource is unavailable for some reason, try accessing it once again after some timeout. Only after a couple of unsuccessful attempts will the system raise an error that a remote resource is unavailable.

In general, the approach to architecture design for the cloud is the same as for any other software. As usual, you need to start with defining the target quality attributes that describe your expectations. Then you should apply one of the tactics mentioned above.

The difference between designing for the cloud and for on-premises applications is that in the cloud infrastructure is also software. It means that you need to design your cloud solution as if software and infrastructure are one single piece of the whole. In order to do this, you will need to find tradeoffs between software design and infrastructure. However, every application and business case is unique, so the tradeoff will have to be customized and carefully considered in order to find some harmony between the target quality attributes, design and business needs. 

Vadym Fedorov is a solutions architect at SoftServe. He has over 12 years of experience in the industry. Vadym holds multiple industry certifications and was awarded at the Ukrainian IT Awards in 2015 for Software Architecture. He writes for several tech publications and is a regular contributor to the SoftServe United blog. Check out more of his musings on cloud solutions there.