The number of resources to scale an application are abundant, but every application has its own challenges to scale successfully, and the solution to this problem doesn’t come handy. This two-part article focuses on the best approaches to build a scalable application, software-as-a-service (SaaS) application, mobile app, or WordPress-, Drupal- or Magento-based website. The scope of the approach extends to both auto scaling and manual scaling.

In my experience, there are two types of applications: ones that use an admin and Admin panel to modify the code, layout and functionality (WordPress, Joomla, Drupal, etc.) and modern, next-generation applications that are stateless and follow the 12-factor app approach.

But first, we have to decide whether to use auto scaling or manual scaling. It is an important decision to make in the very beginning, as it changes the whole approach and complexity of developing your app. We will be discussing both, but in essence of auto scaling, you will need to consider how to maintain the code synchronized across the web nodes and how to maintain new web nodes that constantly are being created/deleted in the auto scaling group. (With stateless apps this is not an issue, as the images or static content can go to Amazon S3, CDN or isolated services. Later on will explain a bit about these technologies.) Working with manual scaling will facilitate your work—you just need your code synced across all the web nodes. All of the approaches mentioned below apply to manual scaling.

But on the other hand, auto scaling with an admin application is a headache for some common reasons: Every time a front-end developer  changes something in the admin, code will be inconsistent across multiple web nodes along with the Git versioning.  Because of this issue, I don’t  recommend using Git for such applications—there are always discrepancies between the last commit/version in Git and the last update in the admin CMS, which makes auto scaling with admin even more complicated.

Let’s cover some approaches to solve this problem. Using an NFS distributed file system will resolve everything for a CMS app, but as everybody knows, this approach pulls down the performance.

What’s Important for Scaling:

• Designing a deployment workflow that is easy for your team, your manager and developers—that’s why you are here, to improve development productivity by defining a good mechanism to deploy code to your cluster or auto scaling group. Here, you can think of Webhooks, rsync cronjob, bash scripts, Jenkins, CircleCI, DeployBot, manual pulls or AWS CodeDeploy.

• Isolating and centralizing all services. Databases, caching session, integrate s3 for static content, implement CDN, worker servers, cronjobs, Load Balancer, app server, web server, etc., to name a few.

• Dynamically synchronizing code in a live application with many web nodes behind a load balancer or AWS auto scaling Group.

• Ability to use the 12 factor approach for next generation applications, or stateless apps. You may be using this approach already but you don’t know it!

• Bootstrapping your application with a stateless approach—this will facilitate all your work when you implement a scalable infrastructure. There are many ways to bootstrap your base application using bash scripts, docker files, vagrant file, AWS code deploy, git, user data file from AWS and baked AWS AMI, among others.

• Using immutable servers in your environment. Make sure your applications and servers are in a pre-configured image state. Every moment a new server/instance is created in an auto scaling mechanism, the instance should be identically cloned of any other instance in production without any further configuration. As you know, AWS, Docker, Google Cloud, and cloud-based providers are much more easier for immutability. This really helps to deliver software faster and decrease time to market.

• For CMS based apps, stay out of git for now, unless you have a very good code change control with your CMS admin and a very good discipline to push your changes with every dashboard/back-end change in the CMS.

• A load balancer for auto scaling, such as AWS ELB, Google Cloud LB, Nginx or HAProxy.

Advised Practices for Code Storage

Understanding how your application works in terms of how visitors dynamically change your application data is very important. It’s imperative to understand how the session is saved, either locally or in Redis/Memcached. If it’s saved locally, you need to add this data to your synchronization mechanism. Another storage change is the user image uploads for WordPress or Magento-like CMS-based websites; use of plug-ins such as Wp super cache or w3 total cache makes image upload configuration easy. Plus, the option to integrate with a CDN, Amazon s3 or a cloud storage pushes the boundaries even further.

But if you have a modern application, you need to understand and guide your development team how to change local image uploads path to a cloud storage or CDN. Make sure all your dynamic data is saved in a SQL or NoSQL database, and all cached database data (db queries, objects, sessions, keys, etc.) is saved to redis/memcached, Taking care of these factors will facilitate your scaling journey.

Why not use NFS?

Well, we hear a lot around the internet that the easiest way to achieve scalability is integrating NFS. Though it is the simplest way to look for and implement a fix, reducing the work for a service provider/developer  by almost 50 percent, it’s a real sacrifice in terms of application performance. Autoscaling an environment with a slow response speaks against the whole cause of the setup! It is very irritating to a client whose application speed is 1 second to 2 seconds when switching to a scalable environment with NFS slows the application by at least 50 percent.

It’s also very disappointing when your small EC2 instance is much faster than your auto scalable environment with NFS. Additionally, using NFS has a point of failure, unless you have a failover in the cloud that is rarely used. It is just not worthwhile to have a complete standby environment waiting for a failure, and it’s better to use this environment within your cluster and have more resources to consume your traffic, or even better use this redundant environment to balance between different regions or data centers.

Why not use Amazon S3 to Share Code?

What about using Amazon S3, Google Cloud Files or any cloud storage to share code?

Implementing Amazon S3 to share code between nodes will slow down your site similar to NFS. There’s not much of a difference accessing the S3 URL to mounting the S3 to a Linux directory, so don’t use Amazon S3 as the document root or code base folder. Keep the use of S3 limited to static content that needs to be fetched over time. Yes, there are websites that can survive and work decently using Amazon S3 for static web pages, but from my experience, I don’t recommend it for websites that support an application responsible for driving revenue to the company.

Stay tuned for Part Two of our conversation on scaling for cloud environments.

About the Author / Alfonso Valdes

Alfonso Valdes is the CEO and Founder of ClickIT Smart Technologies, a IT agency focused in the architecture and implementation of Modern Cloud Applications highly resilient in Linux and Open Source technologies. He combines more than 8 years of IT experience in the field of scalable architectures, distributed systems and developing cloud-native applications, and has worked for different U.S companies such as: Sprint Nextel, Texas Instruments and Nike USA. Nowadays he is encouraging enterprises to join the cloud. Connect with him on LinkedIn.