Cloud ready applications design, a real one example (3 of 3)

To end these series of articles, focused on the design of cloud applications, we will see how it would used into a real live example.

To avoid complexity, we will use a very simple example, a web application based on WordPress, as could be the case with this blog. The cloud used as an example is Oracle’s second generation cloud, although what is exposed here is valid for any cloud with similar characteristics.

What is WordPress?

WordPress is an OpenSource tool for content management like blog, etc .. It is based on PHP and requires in addition to PHP itself, a web server and a database.


The basic and easiest one installation of a Worpdpress is put all the components in a single server, all together.

Wordpress Despliegue Inicial

This deployment, as you can imagine, is not scalable at all, and doesn’t take advantage of any of the design features offered by the cloud. How to improve this?

If we attend to the design principles we saw in the previous articles, we should get:

  • Scalability
  • Flexibility
  • Fault tolerance
  • Performance

so we need to “upgrade” our application

web+php & BBDD roles in different servers:

This is probably the first step that will have occurred to you, for the simplicity of undertaking it and the obviousness of it.

WordPress BBDD Separada

Duplicate components:

Now that we have separated the role of web server and BBDD, our next logical step will be to create more web servers and deploy a load balancer that allows us to balance the load and grow or decrease our capacity when necessary.

Wordpress Balanceo

we take advantage of the fact that the balancer allows us to have the instances spread across the 3 availability zones to achieve greater fault tolerance.

Wordpress Balanceo

At this point we must be careful with one thing, where does the content reside?

Most of the content resides in the database, so this isn’t a problem when creating multiple web servers attacking the same database, however, the static images are stored in the server they have been uploaded to, so we will have to synchronize these images between the different web servers.

The next step will be to replicate the database in different areas of availability, to achieve improvement in performance and fault tolerance, in a similar way to what we have done with web servers. This replica can be Active / Passive if we only want to increase fault tolerance, or Active / Active if we also want to improve our performance.

Wordpress BBDD Duplicada

great we have already got a wordpress application that allows you to grow on demand and at the same time offers the best availability rates.

How to improve this design?

Of course. As you can see the whole design is scalable, offers high availability, etc., but there is a part that we are doing in a slightly rough way.

It’s time to refine the replication of static data between web servers, that although it is true we can automate it in a simple way, it would be much more elegant that it was contained in some sort of shared storage and used as a service.

The type of storage I am referring to could be:

Wordpress Final

I hope you have found it interesting.

Below you can find the links to the two previous articles:

Diseño de aplicaciones Cloud Ready (1 de 3)

Diseño de aplicaciones Cloud Ready (2 de 3)

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

Aviso de cookies