How to design a Cloud App
You suddenly get the best app idea. Being the awesome person you are, you want to design and build it yourself. So you sit in front of your computer but start looking like this after while ??
Is that true?
Knowing how to design and architect an application used to be super esoteric. Unless you are a full-stack developer or a software engineer, there wasn’t a need to know what goes on behind many applications that we use regularly. However, with cloud providers such as AWS, Google, and Azure rapidly gaining popularity in the tech world, it is always beneficial to have an understanding of underlying cloud application architecture.
In this article, I want to explain how to design a simple cloud app in six steps. You may have seen simpler designs and probably a lot of more complicated designs. But I digress.
Step 1: Define the type of application
Here you can outline what you want to accomplish with your application. Questions such as; What is its purpose? Whom does it serve? Where is the user base located? What kind of data would it collect? Should be answered.
The best method is to begin simply and iterate as the application develops. You can focus the design just on the MVP (Most Viable Product) at the beginning to avoid unnecessary complications.
At this stage, you can also design wireframes showcasing the UI if applicable.
Step 2: Define the application layers
Typically applications follow a three-tier architecture. The tiers are:
- Presentation Layer
- Business Logic Layer
- Data Layer
The tiers are logical, not physical, and may or may not run on the same physical server. However, since we are creating a cloud app, we design the tiers using resources that are offered by cloud providers. Such as, compute engines, serverless functions, container environments (for containerized apps), and databases.
Presentation Layer
Presentation Layer mainly consists of components that are visible to end-users. Most commonly HTML pages, CSS files, and JavaScript. You deploy the presentation layer via a web browser for web applications and mobile OS for mobile apps.
The presentation layer communicates with the next layer, the Business Logic Layer, by using APIs. We can use cloud provider API gateway such as AWS API gateway or Google Cloud Endpoints to manage and secure our APIs. API gateways are instrumental for managing API access rights (who has access to what APIs). They also improve application performance by integrating with CDNs (Content Delivery Networks) and caches.
Between the presentation and logic layer, you can add resources to improve the performance, scalability, fault tolerance, disaster recovery (DR), and security of your application. These would include load balancers, firewalls, and DNS, which we can discuss in detail later.
Business logic layer
The Business Logic layer contains code and middleware that will transform user actions to application functionality. This layer will most likely contain serverless resources such as AWS Lambda or Google Cloud Functions.
Many serverless functions follow an event-driven workflow where a function is automatically triggered based on the occurrence of a particular event. This event can be something simple, such as a user uploading an image to a storage bucket (S3 or Cloud Storage) or something a little more complicated, such as responding to a messaging service (Pub-Sub, SNS/SQS) or a data streaming service (Kinesis, Dataflow).
Depending on the functionality of your application, you can design the logic layer with the correct components to streamline operations between your users and databases.
Data layer
The Data layer contains databases and other data analytic tools. Choosing a data store for your application is highly dependent on your application requirements. There are so many database offerings that selecting the best database for your needs can be quite cumbersome at first. Cloud providers offer consultative services where they can suggest the best DB/DBs for you based on your application requirements.
The following diagram will give you a basic understanding of the type of DB you need.
And purposes of different DBs
https://cloud.google.com/products/storage/
Decoupling data
Defining a Data layer provides you with a significant advantage in application designing, which is decoupling the data from the rest of the app. Separating databases from the rest of the application gives you the flexibility to host your data wherever you want regardless of the rest of the application. For example, many enterprises insist that their data remain on local servers but want to take advantage of the commodity virtual machine instances within a public cloud.
Decoupling the data layer also allows you to cache. You can store commonly accessed data in cloud provider offered caches (ElastiCache, Memorystore) and CDNs (CloudFront, Cloud CDN). It reduces the amount of database read requests that go to the primary database and minimizes request latency.
And always remember to replicate data! It is crucial to have a primary DB and at least one backup DB, so you are always on fail-safe mode. By maintaining database replications you can automatically reroute traffic in case of a failure at the primary database.
Step 3. Think about performance and scaling
Designing an application is quite easy. But designing an application that can handle overloads and growth is not that easy. If you plan to have millions of users access your application from around the world, you need to factor in performance and scaling to the design process.
Use Microservices
Using the three-tier approach and breaking our app into sperate services running on a combination of different resources provide us with modularity. With modularity, teams can focus on different tiers of the application, making improvements, and deploying changes as quickly as possible. Also, modularization helps us recover quickly from an unexpected disaster by focusing solely on the faulty part.
Based on the type of app, you can define the services you would need and iterate on the definitions as you build the app. For example, a simple e-commerce site can have one microservice handling transactions, another handling inventories, a one for search, and another for user profiles.
Plan to scale
One of the biggest reasons to choose a cloud provider to host your app is the ease of scalability. As your application grows, the amount of resources you need to allocate to it grows.
Scalability is two-fold: horizontal and vertical. Vertical scalability adds extra power to a single resource. For example, increasing CPU, memory, or disk I/O of a computer instance. Horizontal scalability adds more resources to a set of resources. For example, adding more EC2 instances to an existing set of instances supporting an application. Here, you can use a load balancer to distribute the load evenly.
If two EC2 instances are serving the backend of the application and each of the EC2 instances is working at 80% CPU utilization, we can scale the backend tier by adding more EC2 instances to it, so nothing is getting overloaded. We can also reduce the number of EC2 instances when the load is less.
Autoscaling capabilities provided by many cloud providers are instrumental for handling performance while reducing manual workloads for you and your engineering teams. With autoscaling policies in place, your cloud provider can automatically provision or de-provision resources as your application’s scalability needs change. Using ephemeral environments such as containers also allows you to scale quickly. By containerizing your application, you can create or destroy containers as your application scales up or down.
Be highly available
With a traditional on-prem data center, our application is sitting in one geographical location. If there is an earthquake, a flood, or even a power outage in the location of the data center, our application will not be available. By replicating application data in multiple geographical regions through your cloud provider and using load balancers and DNS to automatically reroute traffic in case of failure, allow your users to access the application with minimal downtime and disruptions. It is incredibly important to maintain reliability and credibility. Nobody wants to use an app that is always down.
Be fault-tolerant
Going hand in hand with high availability is fault tolerance. Fault torelance is allowing our infrastructure to adapt comfortably to any unexpected changes in both traffic and health. If a certain percentage of our instances go down, the remaining instances should be capable of handling the increased load. Adding redundancy to the system that accounts for sudden spikes in traffic or sudden failures can build fault tolerance.
If we have two EC2 instances working at 50% each, and if one instance goes down, the other instance will start working at 100% capacity. This level of resource usage may cause it also to fail. By adding redundancy with a new instance, you have three instances working at approximately 35% each. If one instance goes down, the load will be equally divided among the two remaining instances at 50% each, not causing failure due to overload.
Avoid single point of failure (SPOF)
SPOF is a part of a system that, if it fails, will stop the entire system from working. The following image explains SPOF nicely.
By Charles Féval — https://commons.wikimedia.org/wiki/File:SPOF.png
In this diagram, the router is a single point of failure for the communication network between computers. If the router fails, communication between all the computers fail.
Adding redundancy as explained above and automated failover is a way to avoid SPOF. Solutions for SPOF can be quite extensive. Just remember to replicate application components when possible and use automatic failover plans to reroute users in case of a failure.
The following image showcases an app architecture that routes users to a backup data center in case of failure.
Google Cloud Certification
Step 4. Integrate security into the app design
App developers typically wait to add security until the very end of the app designing process. This not only introduces compatibility problems but, in a worst-case scenario, can force you to release an app with security vulnerabilities.
Progressive practices such as DevSecOps are changing the traditional way by integrating security into the app development process from the very beginning.
Cloud provider resources have the latest security protocols built-in, and the security is monitored and maintained by dedicated teams of security engineers. This gives you the added advantage of not having to handle the entire security model on your own. However, it is still a combination of efforts from your side and the cloud providers’ side to make sure that your application is secure.
Isolate networks
Use VPCs (Virtual Private Clouds) with private IPs when possible. VPC is a pool of shared computing resources allocated within a public cloud environment that provides a certain level of isolation between the different organizations using the resources.
Ideally, you should isolate the presentation layer within its private VPC subnet and the data layer in a separate private VPC subnet. First, this approach avoids exposing our layers to the public internet and protect them from the prying eyes of hackers. Second, in the event of a security breach in one layer, separating the layers using VPCs can mitigate the damage.
You can use DNS (Route53, Cloud DNS) to assign a public IP to an application load balancer that users use to access the application. The load balancer can route user requests to application instances that are securely sitting in a private VPC by using private IPs. This technique allows you to detect any attempted attacks at the load balancer level before they infect your application.
For back end servers and databases, use secure components such as bastion hosts. A bastion host is a specialized computer specifically designed to mitigate and withstand attacks. It sits in front of the backend architecture, acting as a proxy for all the communication reaching the backend. In the event of an attack, a bastion host can detect and prevent it from reaching the backend servers.
Use Identity Access Management (IAM)
IAM tools are critical to secure user-based applications. These tools can help you manage user CRUD (create, read, update, delete) operations, keep user data updated across the application services and control user authentication and authorization. You do not want deleted users to have access to their accounts still. You also do not want users being able to access accounts with stolen credentials. For any application that requires user registration and authentication, use cloud provider IAM tools (Cognito, Cloud IAM) or third party IAM tools (Okta, Auth0).
Ensure compliance
Does your app pertain to a regulated industry? Industries such as healthcare, the federal government, education, and financial services have to follow the US and international compliance policies such as HIPPA, FedRamp, and PCI DSS. Compliance can also apply based on specific geographies such as GDPR for users based out of the UK.
Many cloud providers offer resources that are compliant with different regulations and standards. As you work with your cloud provider, always be upfront about your compliance requirements, especially when it comes to storage of sensitive data, levels of security, and encryption.
Step 5: Monitor the performance
Now that your application is designed, built, deployed, and secured, your users are happily using it. However, your work is not over. You need to use a monitoring and analytics tool to ensure that your app is up and running at all times and get alerted as soon as something goes wrong.
Monitoring tools allow you to configure uptime checks (check if the system is up periodically), application monitoring (identify issue within application microservices), log analytics (analyze logs to detect errors), synthetics (synthetically monitor end user-facing components, browser transactions, and APIs) and auto remediate (automatically resolve issues without human intervention).
Cloud providers offer native monitoring tools such as CloudWatch (AWS) and Stackdriver (Google). Many third-party companies such as Datadog also offer monitoring solutions that can be helpful if your application is running on multiple clouds or on hybrid environments (part cloud and part on-prem).
Step 6: Define processes to ensure smooth running
Once your application grows to an enterprise-level, you should consider a few more options to ensure that everything is running smoothly with minimal headaches and manual work.
Continuous Integration/ Continuous Deployment (CI/CD)
You need CI/CD so you and your team can continuously build new features, make improvements, and deploy them to the app with zero downtime. Tools such as Jenkins, GitLab, and CircleCI can provide you with this functionality.
Automated deployment
Using config management tools (infrastructure as a code) such as Chef, Ansible, and Puppet, you can create templates for your application architecture and deploy them as needed. Config templates can replace a lot of manual work engineers traditionally used to do when deploying new infrastructure.
Incident management and troubleshooting pipelines
No matter how many precautions you take issues occur, because that is the nature of the world. Therefore, you need a robust incident management pipeline and a troubleshooting process so you can detect, identify, and remediate issues with the minimum mean time to resolution.
You can use tools such as emails, text messages, Slack, and PagerDuty to alert when your performance monitoring solution detects an issue. Using capabilities of your monitoring tool such as dashboards and logs, you can identify issues, get to the root cause, and resolve them.
Lastly, don’t forget to write post mortems, so any similar issues occurring in the future can be resolved even faster.
That’s it!
Again, the landscape of application development is endless, and it is quite impossible to cover everything (at least for me). However, I hope this article sufficiently gave you a basic understanding of how to design, build, and deploy a modern app in the cloud