So, you are done with building your small projects that are only used by you (or maybe a few friends). Now you want to go big!! you want to make something for the public. Or you want to start your own startup, your first online business and you really don't want to screw this up you want your app to have zero downtime you want it run perfectly to not crash and you are right. There is nothing more problematic than having your servers crash at production and not take the load of your incoming users
So you explore all the options. You look at all the big websites ( Amazon, Netflix, Uber ) and they all use microservices architecture. Netflix very famously uses 1000s of microservices to run its website. Ok so maybe that's what you need to handle your massive chunks of users... Right... Right???
Well No Not Really.. The reason I am saying this is because microservices are harder to make, test, deploy and monitor. They require more servers and more compute and storage at the beginning stage that what would be taken by your single server monolith. But monoliths may become a problem later on so what should I do? well here are some key points and steps that you should consider before you start building you app.
By the way, if you are very new to this and don't even know what are monoliths and microservices. I would recommend you should check out this article https://www.freecodecamp.org/news/microservices-vs-monoliths-explained/
Pro Tip: Don't Optimize Prematurely
If tomorrow isn't the due date today is not the do date. In software you should avoid premature optimizations because it will slow you down be a technical debt and it might not even work because as you grow you will need to change your directions and goals multiple times. the features that you think works now might not be so needed in the future. you cannot anticipate what your users might need so don't try to bother just build deploy and then see the reaction. As the silicon valley motto says Move Fast and Break Things. it might work better. Also just remember that microservices are peak optimizations they are used by companies which have millions of users and billions if not trillions of api calls per month. They also have teams of tens of thousands of engineers working and contributing continuously and lets be honest that might be your dream but that is not your day. It will happen but it is not happening tomorrow unless you really made something that just reshaped humanity forever (if that happens congrats now people will gladly wait a few weeks till you sort this situation out) but yeah this is the entire point of microservices
Pro Tip 2: Pls understand what microservices really represent
As I said before microservices are peak optimizations they are part of what we call distributed system design. It is built for scale but not just any scale Ultra Massive Scale. Billions and Trillions of API Request per month (Yes Trillions that is 1,000,000,000,000) and maybe even 10 20 or even 1000 times more than that. That is not something you need from very start no matter how fast you are growing this scale will give you at least a couple of years to manage and make decisions around your website. Big companies need to think at that scale but that doesn't mean that you should. (I do wish all of you folks reading that you grow that big but that is not happening in a single day so don't worry about it before you launch or are at a nascent stage )
Now that we have gotten that out in the clear here is a step by step on how you can optimize
Now I will be mentioning a lot of GCP services but almost all cloud companies have similar offerings just with a different name.
Note: For the sake of simplicity I don't add the role of security and monitoring services from the start but In a real world app (which you are planning to make) they are just as important as the main app itself. That is also the reason that I suggest you to start small so that you can give ample time to that as well
Step 0 :MVP
For your minimal viable product I will suggest that you keep it very simple. You can use just a single Compute Engine Instance for your entire stack. You can also use App Engine as well with a containerized app. This is ideal for around 1000 to 2000 users. This reduces costs (Might even be zero with free tier on App Engine) and as you can probably guess is very very easy to setup. It allows you to make it quick and release and test it quick.
But Please note the reason that I call this is a step zero is because even I don't think this is reasonable as if you have a bigger audience or as soon as you make a more formal launch and try to grow with it it will collapse (Here once again App Engine is more scalable it can grow but latency and costs can prove to be a issue). It is something that should only be used for a beta launch.
Step 1: 3-Tier Architecture with CDN
Now, This is where we start getting into a more real launch. This is the standard 3 Tier Architecture. Database and Servers are decoupled. For Servers I will suggest a bigger Compute engine Instance. If you are building containerized apps we are talking about GKE (Google Kubernetes Engine) or App Engine and a database of your choice (Relational or Non Relational is choice that you need to make based on your app). Also every static file (Images, Videos, PDFs, CSS, JS, even some HTML files) should only be served via a CDN this reduces the load on your main servers and also makes your app much faster.
Now for Compute engine it is best to use a Managed Instance Group they will manage autoscaling for you
Similarly this can be achieved with GKE. Now for a GKE vs App Engine the thing is this is something that you need to determine. If you think App engine saves you cost or it might even cost a bit more but that is more important than trying on setting up GKE it mostly matters in that sense.
This design works well for 10000 to 50000 users and is resilient enough where it should not break at any amount of users. The reason that we move on to higher forms of Architecture is due to the costs or latency advantages not purely because your app will break
Step 2: Add Load Balancers
Now that you have so many users. I think its time to be in more than one place. This is the start of distributed design. We will add a Global HTTP Load Balancer and our Infrastructure and Database systems are present in more than one cloud region. This provides your Users with a faster and experience.
The choice of regions have to be based on where your users are ideally you would like to place it closest to where you maximum users are.
Note: I have removed App engine from the choices of Infrastructure System because honestly I don't believe it is very cost optimized at this stage. You could use either GCE or GKE based on your app design.
At this point if all pieces are setup correctly you should easily be able to handle even millions of customers with right no of zones, clusters and machines. Now moving further its all about how can we optimize costs, add new features and make it faster.
Step 3: Adding Caching
As I said before, Now it all about increasing efficiency and going on that point you should setup a cache.
A cache server allows faster retrieval and quicker response times, especially when dealing with high volumes of traffic or in situations where the primary source has limited resources or capacity.
GCP's Memory store is a managed service of Redis.
You can also use bigger databases like Spanner or Big Table if you think you database systems can benifit from this.
Step 4: Adding Cloud Run for Small Steps
Now, Your app is already very big maybe you have some services that don't need that much compute or use time to warrant a full time running compute instance. Could be just a image detection service or a few batch jobs. This is where you should add cloud run and just let them run as separate services rather than trying to fit them into your regular app servers.
Also for the databases you will most likely need PB scale DB's like Cloud Spanner and Cloud Big Table.
While not mentioned here you will also most likely need to build ETL and Big Data analysis pipelines to analyze customer data. Depending on your app use case you will also need stricter security and compliance requirements (Data Retention Laws, Data Security Laws, Audi log Sinks. Disaster Recovery plans etc.) So while the diagram itself does not show much changes there is a lot more intricacies than just having a running app that doesn't crash.
Step 5: At this point. You might as well try microservices.
Yeah!! Now you are big. You most likely have multiple users, performing multiple interactions per second. We are looking at multiple api endpoints, backwards compatibility, separate responses for Mobile and Web Apps maybe even a few enterprise customer services. Essentially your servers are getting anywhere from more than 100000 API requests per second to potentially tens of millions. At this scale (while exceptions do exist) there tends to be a lot of people involved in planning , design and development of whatever it is that you do. So now while monoliths can scale to this point (remember Google, Wikipedia, Stack Overflow are monoliths to this day). The amount of complexity it requires to manage makes sense from a cost and management standpoint to decouple your services down to a bunch of microservices.
Conclusion
Well here are my opinions on why you most likely don't need to start building your app as microservices. I outlined a way on how you can start small and gradually build your app as your demands scale. I think it is a better approach because it allows developers to move fast from public feedback and don't have to hold back, I recommend this approach because as a app starts to see public feedback it tends to change a lot in terms of directions and features So it is better from a design perspective to keep it simple and small from the get go.
Self Promotion:
Thanks for reading if you liked the article pls like and share. Also if you are new to software architecture and would like to know more I am starting a group based cohort where I will personally work with you and a small group to teach you everything about Software Architecture and Design principals. You can fill the form below if you are interested . https://forms.gle/SUAxrzRyvbnV8uCGA
If you stayed reading I have one more tip for you
Pro Tip 3: Don't Optimize Prematurely but it doesn't hurt to think about it
While I absolutely don't recommend that you spend your time making all these complex design choices when your app has like 100 users. Here are some tips that you should try to incorporate from the start
Have a Clean Documentation
Document Everything, You will really don't know when you need it. It makes onboarding new people easier and also it makes it easier for you to get back at your code after working for a few months (You will think that you know everything about your code you wrote it, but trust me few moths down the project you will not remember what you did)
Set some standards for the code you write
Standardize Language Versions, Databases, Libraries and everything that you use and do down to the variable names. You don't want to run into the It works on my machine problem. Your software that you use should have fixed versions. Code should have a standardized naming conventions.
Embrace Modularity
Make your code modular, this may sound simple but a lot of people don't do that which later causes problems in collaboration working. Also it will make it easier to decouple into cloud runs or microservices when you actually decide to make the transition.
Top comments (0)