This article aims to help developers create a RealScale Architecture for their midsize web applications that can handle scaling up to one million visitors a day.
To find out what RealScale Architecture is and what attributes define it, read the 'RealScale Architecture for midsize web apps' article.
RealScale Architecture Bricks
To run cloud-native applications that blend together software with the infrastructure you need to carefully think about the components of that architecture. This is a short outline of the bricks that form part of the RealScale Architecture build.
#1 Servers
This is a most basic building brick in the software architecture. Each server can perform a variety of tasks, including the web API/mobile backend, load balancer and reverse proxies, static web servers, web application servers, and workers that support your application.
In RealScale Architecture, servers are dynamic. They have a short life cycle (weeks, days, hours or even minutes), and this allows them to handle large variations in workflow and scale. Different server types would require a different configuration but all of them have the same aim.
At Cloud 66
Check out our help page on how to add a Load Balancer to your Cloud 66 Stack.
#2 Databases
The second brick of RealScale Architecture is the database used for transactional, analytics, and search support. The real challenge sits in database scaling, where vertical or horizontal scaling is not enough.
Non-relational databases like NoSQL, Object Databases or XML Databases moved away from the common concepts like ACID (Atomicity, Consistency, Isolation, Durability), relational data and fix schemes to focus more on storage and retrieval of key and values pairs, which enables a new generation of scaling.
Different databases offer a different style of capabilities, storage, and performance alternatives to SQL-based data stores. This changes the way the data is managed in terms of transactions, relational data, fixed schemes, immediate vs eventual consistency and data locking.
At Cloud 66
Heve a look at our documentation about Data Replication at Cloud 66.
#3 Shared Object, File Storage
In a cloud-native architecture model, the servers are created and destroyed frequently. This places a new requirement of shared storage beyond the individual, local server.
We can identify four types of cloud storage solutions:
Local Ephemeral Storage - must be used only for storing temporary files and logs before they are moved to long-term storage. And it should be immediately replicated to another server.
Network Filesystem - is similar to Network Attached Storage, where shared filesystems utilize the network protocol for reading and writing files. It's not recommended for solutions that require direct block-level device I/O access.
Network Device/Block Storage - is similar to Storage Area Network, it is a block-level device offered over the network. Often used for high-performance data stores.
Object Storage - lives above the block or filesystem, allowing for the storage of data and associated metadata. The object storage can be accessed with the API.
#4 Centralized and Distributed Logging
Depending on the size of your architecture developers need to think of the strategies to manage the streams of logs generated by various server processes.
There is a wide number of logging solutions that distribute various files across a server. The list of different server log types included system logging, web access logging, application logging, database logging and event logging. Developers have three options for managing logs across a cloud-native architecture. Those are replication, syslog, and log collectors.
At Cloud 66
Learn more about Cloud 66 feature called Live-Logs.
#5 Message Brokers
As the application grows, you need to think how to improve the performance by offloading workload to background processes in a safe, scalable manner. The popular solution is a distributed messaging system. It enables your app to communicate by sending and receiving messages between various parts of the system.
The broker is responsible for routing the message to the proper destination only. This means that the message sender is not aware who will receive the message.
Distributed messaging is the foundation for a microservices architecture.
#6 The Domain Name System (DNS)
Another brick in the RealScale architecture is DNS. It is most often used to associate a server’s IP address to a hostname (A record), alias one name to another (CNAME record), route email to the proper mail server (MX record), and general use text entries (TXT records).
Understanding and applying DNS give developers the tools to manage high availability configurations, failover, and service discovery.
At Cloud 66
Check out Cloud 66 DNS Configuration and Failover Groups help pages and our blog on ElasticDNS to find out how Cloud 66 DNS works.
#7 Caching
While your application starts to receive more traffic, caching keeps common data and fragments in the memory to improve performance and reduce the burden from backend servers. Beside the database caching there are other caching strategies available, e.g. server page caching and server fragment caching.
The most popular cache servers are Memcached and Redis, which both store their data in a key-value format.
At Cloud 66
Read an article on Cloud 66 community page about Caching with Memcached and check out our blog post about Using Varnish as an HTTP cache.
Let's use all the bricks to build awesome RealScale Architecture for your application!