3 Points to Consider When Designing a Project on the Cloud • Slash

Table of Contents

Start with Planning

Let’s begin with the apparent obvious point of planning. All good projects begin with a well laid plan, but not all projects succeed based on said plan. In short, make a plan but don’t be afraid to change it as needed as the project unfolds.

It’s important to know what you need, the requirements for the project. Ask yourself, “What does the architecture look like now?” and “What is the architecture runway?” Are you dealing with a high performance system, capable of doing many jobs like an ERP system, or is it a small web application? We must first understand what we are starting with so we can then look at the architecture runway and know how far we can stretch for the project. How far does the client want this development to go? Considering all this, you’ll also need to factor in current trends to ensure you don’t handicap the runway down the line when building in more detailed elements like analytics is necessary.

We will also need to recognize the cost for the desired setup and the value of said setup to clearly explain to the client. Consider whether you need to overkill your setup for minor things or overload a small setup for large work items. All of these considerations should be taken into account in order to properly evaluate the overall cost involved for the project. No one likes hidden fees or in this case finding after the first month of operation that your cloud fees are double or triple what you had planned for.

Knowing your user base size and product valuation will aid in deciding many things during this stage. If you have a small number of users then seemingly, starting with a small amount of cloud space and functionality is feasible as long as your runway is designed to scale properly.

Understand Your Architecture Needs

Performance

There are a variety of application types that require handling many users to few users, chat functionality, heavy data streams, AI/Machine Learning and so on. You want to decide the architecture based on what your application requires in terms of performance needs and for different stages of your application. For example, for the testing stage of the product initially, you want to optimize for cost and reasonable performance so options like static website hosting and Function as a Service such as AWS Lambda or Google Function can be good. At the same time don’t rule out the need to scale the product; as well, at other stages of your application, you require consistent performance 24/7 with options to save on cost with a long term commitment on compute being a necessity. In that case, instead of a Function as a Service approach, you can consider a container orchestration approach with options for reserved instances or long term commitment to be recommended to the client or to scale your product..

Highly Available

Is the product you’re building used by users in a specific region or by a certain platform or group accessible worldwide? The level of availability the client needs must be taken into consideration. Some products may be tailor made for local markets while others are designed to be for the mass global market. Which is your client’s? For example, video streaming sites localize to users based on their regions. Choose the option best suited for the architecture and your client’s implementation goals for their product.

We could consider a single region for local market consumption with proper caching, or otherwise for the whole Asia continent usage, we could consider multiple regions in the continent and optimize for a resource routing policy and also cache mechanism as needed.

Moreover, we also consider data backup / disaster recovery as the availability of the system, whether the application is not critical and you can consider a longer Recovery Time Objective and Recovery Point Object. On the other hand, if your application is very critical and you require a short Recovery Time Objective and low Recovery Point Objective to recover for your application faster, then for example there’s master to master fail-over and real-time replications.

Scalable

As we’ve touched on above a number of times, it should be clear that scalability needs to be thoughtfully judged and determined accordingly. You should always be thinking about the architecture runway like your guiding north star. There are two ways to scale: vertical and horizontal scaling.

Vertical scaling is where you scale the server from a smaller to larger machine. Horizontal scaling is a matter of simply increasing the number of servers. If your application has to compute a lot of information, then vertically is more suited. However, if your application handles a high volume of requests from users, then horizontal scaling is the way to go to avoid any bottleneck issues. Auto scaling can be employed to scale up and down as needed if this fits your project needs.

Secure

Finally you’ll need to consider security for deployment. If you want to roll the product out quickly, you may have to compromise security so balance this carefully. There is a minimum security we really must enforce to protect our application and user data such as complying to proper firewall of the applications, protecting cookies and session data, authorizing the access control correctly, encrypting and never leaving sensitive data in plain text, and limiting the rate-limit to prevent some DDoS attack. You can do even more to protect your application and data as well to comply with adding more audit trails of the cloud activities, scanning the library for vulnerability, enforcing cloud compliance, or applying full public private keys usage to encryption sensitive data. There is so much we could do but it depends on the time available and your application criticality to enforce to a degree that is acceptable for your application to not slow down the time to market. Moreover, if the application is getting more mature, we could apply and design a more secure architecture for implementation on top.

Observe and Monitor

Having the ability to observe the product to see what’s going on and if there are any issues is vital to the success and accurately troubleshooting. Therefore, you should set up the proper log mechanism to capture critical activity, error logging that allows the production support team to react to the problems quickly and eventually setup a log alert and log analytic that allow the team to proactively mitigate possible risks that could happen.

Finally concerning cost, we want to avoid surprises just as we planned carefully above for cost, so we must do so again for future product monitoring and maintenance. Take steps to ensure you’re actively observing what is going on with the budget and how it’s being affected by the product development phases. Taking a proactive approach will help you maintain transparency with your client keeping everyone happy when it comes down to dollars and cents!