Why Cloud Computing Architecture Components Are Like... LEGO Blocks?
Cloud architecture is like… putting together LEGO blocks and creating wonderful things. It is like having nearly endless opportunities to build your own app.
Sep 27, 2022 | 9 min read
Do you like LEGO? Who doesn't, right?
Recently I received a new Stormtrooper Helmet LEGO set and I was amazed at how fun and easy it was to build it. And on top of that, most LEGO sets give you plenty of possibilities to build something new. Unfortunately, this set didn't inspire any ideas for other builds 🤷 and it hit me that this is a great reference to how cloud architecture is built!
With that, cloud providers are giving us nearly limitless possibilities to build our own application that will serve end-users with these small pieces called services behind the scenes.
Imagine having an application. Usually, it's something you are working on for a longer period of time. Most applications are built with the help of frameworks, libraries, and utilities (you name it) which, joined together with some architecture patterns and specific language syntax, can give you a fully working system. So, an app can be one of the old LEGO Bionicle miniatures that you built in your childhood (I know I did!).
So the next level is cloud infrastructure. As your Bionicle is built and you play with it, you may want to share this joy with others or have these epic battles with other Bionicles. To do so you need to show it to the others. That's where the cloud comes in. With the help of the cloud, you are able to say "Hey! I have this new fancy Bionicle! Let's have some fun together!". Later, you can join these small blocks to create cities or scenes where you will be able to make some fancy fighting scenes.
So you have your figurine and can make nice shows with the help of the cloud but you still lack something, like, some functionalities that are unavailable in your current sets. What are you going to do then? You can buy new Bionicle sets and morph them together into ONE GIANT ROBOT to have superpowers!
This can be referenced as connecting cloud-provided services into your application. You join the currently existing codebase with new pieces and tell them "Now you shall talk with each other as a whole" thanks to which you have a fully working application that runs on one provisioned infrastructure but still gives you plenty of possibilities to split them up into different figurines and connect them with other pieces provided by any other cloud platform or SaaS solution.
But, enough of this long and vague introduction, let's get to more bricks. . . I mean details.
To understand how cloud (and not only!) works we need to have a brief talk about how distinct building blocks are connected and sold. In technical terminology, we can emphasize it as a shared responsibility model which defines who is responsible for what and how services are being provided to the end-user.
This is an old approach of doing things - buy a server, rent some storage, wire it up in some cozy place, then manage it, troubleshoot it, etc. You are basically responsible for all of the pieces by yourself and it's your physical involvement and responsibility for this whole solution stack. As a LEGO analogy - you prepare the idea, get the bricks from LEGO and build everything as you wish from scratch. As well, you will be responsible for each fix or improvement.
The next level represents a bit of help from service providers. You stop worrying about provisioning servers, setting up storage, physical security, connecting everything into the network, or setting up virtualization software, and focus on setting up proper operating systems and provisioning software as you need it.
Brick analogy - you will receive a set of bricks and instructions on how to build it and you are almost free to add new things on top of the provided fundamentals. Infrastructure as a Service is almost limitless when it comes to the possibilities but super rewarding as it takes off plenty of hindrances from your head.
So you wish to focus on what's important, you just want to be able to define an application’s runtime and how data storage should work and then just hit the fire and forget button to have everything connected and hosted for you. Platform as a Service usually gives you time to focus on what matters in your business and removes the need for remembering each and every detail of how it is run and hosted. Imagine that you bought some kind of racing track set. You get all that you need to run a competition, but you still need to have a car(s) to compete. It is your responsibility to buy and modify them as you see fit.
This is the top of the mountain where you just pay for a fully working solution and it’s irrelevant how it's being run, updated, or maintained as a whole. What matters to you is that this is always available to you as you are a paying customer. To make an analogy, imagine a LEGO subscription service provider that sends you fully built LEGO sets for you to play with, with a small "defect" of them being almost entirely glued together. Generally, Software as a Service is mostly what you aim for when building service for end-users, and most of the time you utilize the PaaS and IaaS to make this delivery faster.
Get informed about the most interesting MasterBorn news.
Currently, (as of the day of writing this article) AWS is one of the most renowned cloud platforms on the market. It has smashed the scene with its offering of IaaS, PaaS, and SaaS solutions which are built upon each other! Imagine that, AWS has created an EC2 service (Elastic Compute Cloud) which is a typical VPS server that you can rent from any other provider. Based on that they have built some PaaS solutions such as ECS, RDS, Lambda and others! EC2 is a basic building block for any other services that they provide! Are you familiar with the LEGO City series and these flat tiles that are road/city tiles? Imagine that these are EC2s while everything that you build upon them is PaaS or SaaS solution provided by AWS OR yourself!
Similar to AWS, Microsoft Azure and Google Cloud Platform have similar offerings in terms of services provided (IaaS, PaaS and SaaS - competition, doh!) with their respective names and functionalities. What differentiates them is how you are able to manage them, how granular provided services are, and the proprietary technologies that they run.
Knowing everything I have written before actually takes us to the point where there is only one obstacle (or limitation maybe?) ahead of us, our imagination. With all of these possibilities, what limits us is ourselves. Each LEGO set comes with a manual - a typical representation of what you can build from the bricks provided (check https://rebrickable.com/ for more ideas on the sets that you have in possession!). Usually, you have a list of the bricks and step-by-step instructions. In cloud computing architecture, this can be referenced as good practices and guidelines on how to build and structure an application. But, you can always throw out the instructions and use your imagination and use the provided bricks to do what you see fit. This, of course, can end up with some weird creations, but you are the user and the master of these ideas.
Knowing that, is there anything we can help ourselves with while working on our next great project? Well yes, as always! Do you remember back when LEGO didn't sell a Brick Separator and you always hurt your hands in the process of separating bricks from each other? (At least, I remember it, and I will tell you that it wasn't a fun time). In the cloud world, we can refer to such a tool as Infrastructure as a Code. It allows us to work on the solution in a much more well-managed environment that is easy to boot up and tear down and which provides stable support to any cloud application to come.
The next example is a virtualization software which is actually able to run your project in a scalable way and make your management life easier. Imagine, building the LEGO set you always wanted and then cloning it nine times so that even if you will lose one of them, you would still be able to use nine others.
I have left the best for last. As I have mentioned before, your application is what matters and regardless of how you build it (is it a monolithic app where everything is fitted super tight or a couple of loose microservices or a layered app with distinct frontend and backend) it is what matters and on what you should focus the most. Of course, setting up a robust infrastructure to not worry about in the future is a must. But more important is to make sure that your application does what it should and provides value to you and your users.
I love LEGO. LEGO is fun and I guess I'm not the only one who thinks this way. Recently my colleague Gosia sent me an article showing which brands are the most tattooed logos in the world. The top 4 are Disney, Nintendo, Harley-Davidson and ... LEGO! Ha!
Who would have thought, right?
LEGO gives you so many opportunities and cloud architecture reminds me of picking up blocks and creating cool things. There are a lot of ways to make something unique out of the same blocks. It depends on which blocks you choose, it's your decision and I think it's beautiful.
Table of Content
- Let's dive a bit deeper
- Deeper - cloud infrastructure
- Deeper, I told you - cloud service providers
- Shared responsibility models
- IaaS - Infrastructure as a service
- PaaS - Platform as a service
- SaaS - Software as a service
- Cloud providers and their functionalities
- AWS - Amazon Web Services
- Azure and GCP
- Use your imagination to build and structure your app
- Your application
World-class React & Node.js experts
Serverless Computing - 5 pitfalls to avoid in your project
The top 5 pitfalls of Serverless Computing and how to overcome them. Learn how to avoid problems with Microservices, Timeouts, Vendor Lock, Cold start and Running dry database connections.
React and Redux - 10 examples of successful Web App Development
Almost half of React apps use Redux today. The question is - why is Redux gaining so much steam? And, is React becoming more popular thanks to Redux?
Separation of concerns in modern React apps - key principles and examples
Building React apps, ever wondered where to put that "thing", and how to name it?