Wow. Why I’m even bothering to answer this huge question? which always lead to many answers because there is no ideal approach when it comes to cloud. Still, I will allow my human nature and I will try to come up with the best answer possible from my experience of the architecting many cloud applications which are utilizing multiple services provided by Amazon AWS and Google Cloud.

In this post, I will mostly discuss theoretical part which is always interesting. I will write more blogs about most exciting and useful  services provided by cloud providers in later posts in detail.

First, We have to narrow down the concept of ideal cloud architecture and we must define it so we are clear in our mind what we actually mean when we say ideal cloud architecture for the startup? At the end, It is all about increasing profit per dollar you spent.

What is ideal cloud architecture?

I read too much about it when I was new to the cloud. Maybe It was out of obsession and curiosity. So, What I will define are the short conclusion of my understanding, Information I have by going through papers published by companies, cloud providers itself and many blogs. Still, I provided those links at the bottom so you can read it too.

So, Let’s list out the requirements of start-up founders and if not it should be. Please let me know if I missed something. So, we can add it here and make it more general as much as possible. Following are the requirements to say if it is ideal cloud architecture or not:

  1. Technologies used in the product should be easy to learn and adapt.
  2. An application should be scalable without burning bank account.
  3. It should be faster to iterate still ensures stability.
  4. we should be able to roll back between versions.
  5. It should have less complexity so new developers can easily grasp the architecture of cloud.
  6. Deployment process should be less stressful with less or no human inputs.
  7. I don’t need to run server until needed. ( I think this is more of a personal expectation and not the requirement from start-up founders.)
  8. It should load faster without paying little or no extra money on that.
  9. Doors for automation always remain open because things that humans achieving performing steps by steps process can be automated easily.
  10. We don’t want to hunt by the ghost named legacy components. Architecture should be able to embrace new technologies.

Now, I will try to explain each point and solution to fulfil that requirement.In this Article, We are going to discuss following AWS services and how to use it.

  • AWS Compute services

  • AWS Dev Tools

  • AWS Database services

  • AWS Application Integration services

  • AWS storages and content delivery services

Technologies used in the product should be easy to learn and adapt.

This is at the core of any startup because founders may be sure about the idea, But what they want to do and that can be easily described in one or two sentences more than that is not the idea I believe. But one’s you dive inside it. You will iterate your idea many times until it really becomes stable and useful.

Nowadays Every startup using cloud services whether it is AWS, Azure or Google cloud. They have to use cloud services which are more of general services so that they can get people to work on their product easily. But when we say “general”, We will have many cloud architecture to follow, which you can be used but I will suggest mine which passed all satisfy every point we raise above. Following is AWS services we are going to use throughout the blog. I’m using AWS because that is I experience the most but let me assure that you same can be designed for Google cloud or azure by using same available service.

An application should be scalable without burning bank account.

For me, Startup is like doing the trip in your twenties where you want to do everything but you short on money. So, Saving money and utilising every dollar you spent. At the same time, it is true for big companies too. Suppose you have the web application you want a server to serve most requests it can. so you don’t have to spin extra machine. we can shut the instances which are not serving any request. If you need too It should offer you many metrics you can trigger scaling so you able to shut down instances if not needed.

Let me first define what auto-scaling is. Auto-scaling is the process to make your web application always be available on high traffic. You have to code independent component which works as the server and which can be launch as many times as we want without throwing 5XX.

When first time I had to implement auto-scaling for one of my project I was working on, believe me, I tried many technologies which I thought fulfil my need. I tried to combine many technologies like the AWS auto-scaling group with many combinations of other services like code deploy, code build code pipeline and AWS code-commit to deploy my code on the launch of the instance. Also, I tried to create AMI image and just auto scaling group will just launch the AMI image on launch but I knew that this amateur way to do it because you have to create whole new AMI image if you want to make little change in the application. So I move on. Finally, I found AWS beanstalk which is just a wrapper around all technologies I tried to use but it is so integrated a way that ensures stability.

So then I narrow down my exploration to Elastic Beanstalk but elastic beanstalk provides many platforms by programming language and docker.I want agility to choose and do anything I want so I chose docker. Basically, Docker provides a way to package your application with the operating system, system libraries and code. Basically, It is able to give dev/prod parity. In other words, Keep development, staging, and production as similar as possible. Follow this link to know more about Dev/Prod parity. The final solution to our first point is used elastic beanstalk and similar services which basically provides you the way to deploy containers which should be tightly integrated with auto-scaling service which can be triggered on multiple metrics like CPU, requests, latency, memory, network in-out so you can spin up your instance specific to your needs.

It should be faster to iterate still ensures stability.

In the age of digital transformation, everybody wants to provide new feature as soon as possible, Security update or maybe bug fixes as soon as possible.

Now, Making iterations becomes very fast, It is also easy to set up where we already have many stable services like code build, code pipeline, CI server, code deploy, ECR services are all there to serve our purpose. After putting automated test cases to check every time developer push his/her code to the server code will be checked against all possible scenarios and only then it will give you the approval to merge.

The way we can enable it is we make lots and lots of test cases and then we run test those test cases on any change in the code base. We can configure in such way that if staging branch gets an update then it will automatically build the container image in local, run all test cases and if gets passed then upload it on amazon ECR and also update the configuration on elastic beanstalk in a way that developer just needs to push button. I choose to deploy on consent method because I’m following 12 factor app theory where it suggests that deployment should happen with one’s consent.

If QA approves the version on staging and we can deploy the same image on production by pulling that image from amazon ECR.

we should be able to roll back between versions.

When we have set up to iterate faster it is also possible that we introduce bugs. Emergency exit should always be there to rescue us from that situation. if we can easily roll back to the previous version it is very helpful and less stressful for you developers to deploy the application in production.

We already choose the right technology where we can actually roll back from the dashboard to any earlier version if needed to. We can also swap URL between the environment. So, I will explain the advantages of this in another post in detail.

It should have less complexity so new developers can easily grasp the architecture of cloud.

I think point explains everything that why we need it. I think to be able to do that we have to make component independent as possible so they can start from small and understand it as time goes.

At the beginning of startup does not have things very much organised and most things in production without any documentation. It is necessary that we choose the technology which should not be the thing that everybody uses but it should be understandable, simple in a way that everybody can absorb the detail in few days just playing with it without breaking anything or creating any serious issue in future.

Deployment process should be less stressful with less or no human inputs.

As I said mentioned early, generally, This is the case that when something goes into production, there are many kinds of document sharing happening across the team to make production deployment successful. It usually the case where there is no rollback.

generally, You will see that on the day of releasing new version everybody will just in panic mode. sometimes they to make changes at multiple places, going through all the process before the app gets live on production. There is no door for failing in between because they have to relaunch the instances from backup if they did backup the instances before starting manual deployment

We did actually following this because of the way elastic beanstalk with docker designed. In Elastic Beanstalk, we already keeping the version of the application by storing zip file in the S3 bucket. If anything goes wrong we can redeploy the older version by just pressing few buttons. Same was true for new version deployment we already have automated test cases running on code update. we actually keeping the same state for staging and production so we will more likely to find bugs in staging and ones staging get approved we can deploy that version on production in just a few clicks and not doing the manual code deployment.

I don’t need to run server until needed.

Maybe you will not understand the depth of the sentence if you are coming from traditional two-tier architecture. But startups are not sure about the traffic and we should not waste money on servers that are not utilising enough but architecture still ensures server heavy traffic.

if you are following older architecture where everything is server then maybe you will find that you are running the server for the day where it remains idle for more than 5-20 hours. For example, in case of celery workers It is best design-practice if we detach workers from main servers but sometimes what happens is we don’t need workers all the time may be our tasks are running for few minutes a day. Celery will need the broker and for that, we have to run another rabbitmq or activemq server. So, we can manage workers and schedule tasks.

Instead what we can do here if tasks are less than 300 seconds we can use the serverless architecture which decreases the infrastructure cost down to nothing for above scenario. We can also cut down the cost because we will not need to run broker server too. We can use AWS SQS, AWS SNS services in combination to achieve architecture where we only pay what we are using.

It should load faster without paying little or no extra money on that.

There are services and technology which help us to deliver content, information, video streaming faster while ensuring that don’t break your bank.

Users are so impatient these days. So, Your application needs to be run faster so you can gain and retain more users. The way you can solve this is as follows.

you can use CDN network AWS provides, Another way you can configure is defining geo traffic policy by using the service AWS Route53. Where you can server users from nearest availability zone possible.

Doors for automation always remain open because things that humans achieving performing steps by steps process can be automated easily.

Human hours are always a constant problem so we never want to invest time in things which are providing ROI. So, architecture aways works like the plugin. You should have ability change and make automation of things when you get the time to work on things possible.

We don’t want to hunt by the ghost named “legacy components”. Architecture should be able to embrace new technologies.

Architecture always remains open to using new technology as it requires. Just like there is also legacy cloud component hunts you same as legacy code. So, components should be always detachable when we don’t need it and we don’t have to make an update to the system to remove it. so we can shut down the servers we don’t use. It is the standard way to save time and cost.


Aniket Patel

Bright, Breezy and comartist.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: