5 ways to architect your application to maximise the value of the cloud

August 31, 2016 bentannahill


“All value of the field of IT is associated with applications” – Bernard Golden.

So you need to make the most of them. And there’s a lot of hype around the public cloud as a home for your applications. And its justified: whichever angle you take – cost, ease of access, maintenance, scalability, elasticity, versatility – the cloud is better than on-premises. The effect of which is that you can accelerate your application lifecycle, build better apps, faster, and beat your competition.

On paper at least.

But moving an application to the public cloud – when it’s not ready for the cloud – is the technological equivalent of buying an ice cream and just watching it slowly melt all over your fingers.

You’re not getting any of the value out of it.

And given enough time and enough ice cream it’s also expensive. Not to mention sticky.

Your applications need to be designed or rearchitected in order to make the most of huge advantages that the cloud can offer you.

So here are five characteristics of the cloud that you need to watch out for when designing applications for the cloud.

#1: the cloud is a distributed system

On-premises infrastructure is a centralised system. Everything is (essentially) in one place. In the cloud, however, servers and databases are distributed. I.e. not in one place.

The best way of describing the consequences of this is with the ‘pets versus cattle’ analogy.

Traditional on-premises hosting is like having pets. You look after every server like an old Persian cat, doing everything you can to look after them, because if one gets sick, you’ll have to fix it ASAP.

In the cloud, your servers are cattle. If you server fails, it is cast aside and a new one is automatically reprovisioned. The individual servers don’t matter (unlike with centralised systems), the system matters.

The entire point is that you don’t have to look after the hardware yourself, which means that you can’t control if a server fails or not. A consequence of this is that you don’t build resilience into each machine, you build it into the system.

This means that you need to build your application for failure.

#2: you need to build for failure

As a result of the cloud’s distributed nature, you can no longer assume that the nature of your application infrastructure is stable.

Your application topology is now dynamic. Because a node can be moved or removed at any time, you can’t assume that any particular files, host names or IP addresses, for example, are permanent.

If your application has any specific infrastructure dependencies it will eventually break. This means that you need to use an external service registry to resolve service endpoints, or route via a load balancer with a virtual name.

This changes how you distribute your application also. For example, you should ensure that you don’t write to a local file system. Because if an application instance crashes or stops for any reason, those local files will disappear when the application is restarted.

Let’s take an example: session data. You used to put store cookie data in temporary files. But this doesn’t work in elastic systems in which servers are being de- and re-provisioned all the time.

#3: don’t be monolithic

To maximally take advantage of the distributed nature of the cloud, you should design your application as a collection of cloud services (a “service-oriented architecture”).

The distributed nature of the cloud means that it is incredibly well-suited to dealing with services and data ‘individually’, tracking the various components of your application and releasing and pulling resources where and when appropriate.

Breaking down your application into individual services also means that they can be leveraged independently – including being used by other applications, which is a despicably efficient use of resources.

#4: separate data and process

You decouple the data for the same reason you want to build the application out of services. Binding either data or services tightly to the application goes against the grain of the cloud’s distributed nature and makes any application very difficult to scale.

If you decouple the data from the app, you can then store and process it on any cloud instance, public or private. So, for example, you could keep your important customer data on a private cloud, but take advantage of relatively inexpensive elastic compute in the cloud for running the application.

State is a great example. If a node is moved and you lose state, then your application will not be functioning effectively. For this reason, in a cloud environment, it’s preferable that apps be stateless for the sake of scalability and portability. The right approach is to decouple state and the application and move state into a separate storage location (a database or a distributed caching store) that has built-in redundancy and can allow any server to access that state.

#5: build for automation and scale.

The cloud is a distributed system in which infrastructure can be provisioned with code. As a result, your environments will be created and destroyed more often than with on-premises environment.

This means that being able to automate the tasks associated with creating environments and deploying your application is critical.

For example, you will need to install your application very frequently and on demand. You should script the installation process so that it can be automated and carried out easily and repeatably so that you don’t have to carry it out manually every time a new instance is created.

Also consider an application management solution that removes the need for manual operations interactions and that can automatically add and remove resources. These tools can automate the process of installation, deployment and post-deployment issues, such as monitoring and auto-scaling.

Your application also needs to be able to scale with your infrastructure. You need to understand how your application components will be able to handle greater loads. Which components will be under the most stress and how can you assure that they get sufficient resources? Will you need more database instances? More compute? More storage?

Ask yourself “what would happen if I had ten times the anticipated workload?”. Then build your application on that basis.

Don’t leave money on the table!

Most of the problems that people come across in the cloud can be traced back to poor application design, not poor cloud technology. And it ultimately results in money being left on the table.

So get to licking that ice cream off your fingers and start architecting your application to maximise the value of the cloud!


Previous Article
Is the sysadmin dead?
Is the sysadmin dead?

Is the sysadmin dead?

Next Article
The unsung hero of ecommerce: how to use a single, centralised database to supercharge your online sales!
The unsung hero of ecommerce: how to use a single, centralised database to supercharge your online sales!

How to use a single, centralised database to supercharge your online sales