I am no DevOps, Engineer nor a Cloud Architect.
Three weeks ago, I joined Brainboard (BB for short 😉) to be a member of a squad team to build a fast-growing community around an all-in-one solution for the Multi-Cloud (Multi-verse), Brainboard. We have the opportunity to impact the Cloud Computing industry overall at a large scale and I intend to understand it, well.
My personal key to unlocking my full potential is to understand every part of the ecosystem, challenge every cause, to finally make my own opinion of things.
To do so, I had to personally, dig into the existing ecosystem, up-driving ideas and startups that raise millions and of course, understand the complexity of information exchange. Between complex definitions, unverified spread knowledge across all channels and multi-facial leaders, it rapidly became a nightmare, trying to bigger my pictured understanding of the Cloud.
It is not an industry, as easy to understand as grocery shopping in less than 10 minutes, but there are some tips and tricks to learn from people who have experience. I am lucky enough to be aside Chafik and Jeremy that are dreamers, believers and doers with combined 20+ years in the industry.
With everything I know about marketing 'bullshit' and Chafik (& the whole tech team)'s knowledge in Cloud Computing and the tech industry, I was determined to crack the system and democratize the Cloud, to everyone.
So, here we go.
As simple as I can get, the Cloud is a virtual storage of information (Cloud Compute = the possibility to buy and execute computing power remotely). The Storage space is arising basis leaders on the most used renting system — the pay-as-you (you as a Business) model of Data, with a big D. Every file you are storing into that virtual space, the owner of this specific Cloud (the Cloud Provider) charges you money (AWS or Microsoft Azure) for it, offering multiple tools to facilitate the migration. There are open-sourced platforms to help bring your application into market faster and less costly, but security arises concerns.
The good aspects of using the 'Cloud' is that Cloud Providers pay the physical space of the Cloud, reducing expenses for businesses (Data Centers, farmers, ...). These complex machines are usually stored into a concrete building, usually thousands of miles away from where you monitor it. These physical infrastructures need much more complex engineering and knowledge for me, as unpredictable weather (SWOT - Strength, Weakness, Opportunity & Threat) for example can come across the cooling system, like we saw this Summer 2021 with France, Netherlands & the US. Some, like Google, are testing an underwater solution and that may be the key to unlock the full potential of the vast Ocean we surf on.
Infrastructure vs. Architecture, what's the difference? A Cloud Architecture (== blueprints) represents how Cloud computing and storage services work together to build something in the Cloud. An Infrastructure is the result of an Architecture, something "virtual" as it's in the Cloud. You can't touch it, but you can use it, connect to it, monitor it, ... Here is a small Analogy you may connect to: Architecture is like building architecture and then infrastructure is the building.
Stephane: How many tools a team use to Build, Deploy and Manage their infrastructure?
Chafik: Between 10 and 15 tools and about 1 month (depends on complexity) across 5 team members.
To connect 2 components in the Cloud, you need to build a logic behind it. Let's say, you want to rebuild Uber. Once a passenger requests for a pick-up, the passenger's information is sent to multiple located-based drivers. Once a driver accepts the ride, a connection is made between the driver and passenger and a nice UX experience is shown on both sides of the application. In this case, which is 99% simplified, a connection between the driver's database and the passenger's database need to be made. This connection is made when building the blueprint of Uber's app.
Like anything in this world, the Cloud architecture of any business needs to be well-organized and sometimes, the development can be complex especially if you are using multiple Cloud computing and storage services in a single heterogeneous architecture, generally called Multi-Cloud. It refers to the distribution of Cloud assets, software, applications, etc. across several Cloud-hosting environments.
Building this system of tasks (workflows that connects one information into another) is indeed the most complex one to master. It requires logic thinking, real-case scenarios and complete understanding of every component of this blueprint you are trying to crack.
These components are, virtual of course, and represent 'your business' library of books you store into the shelves'. Every component plays a critical role in the well-functioning of this system, and scaling it with agility is required.
- Virtual machines are, apparently, a better version of Containers that run programs and operating systems, store data and connect to networks.
- Servers are virtual machines that does the Art of Computing
- Load Balancers are like a triage system that redistribute workload in a specific order, making sure that the weight is not unbalanced.
- Network is the physical definition of the internet we surf on. It's the router you have at home, or in your office, that catches the signal and distribute the information to your phone, car, home, computer or watch.
To push your Blueprint into the real-world (Depict & Deploy) and create an application a user is going to interact with (on an hourly, daily, weekly, or monthly basis); you would need models, policies and methodologies to build it. Existing social-proofed templates are commonly used too. Many exist, some are stone-aged for my taste, but mostly cover 99% of the Cloud:
- Public/ External — part of the Big Cloud (open-source)
- Private / Internal — part of your Cloud, your private little island of information
- Hybrid — A mix of both, which now persists and is more common as it eases data structuring
- On Premises / Internal — In your office, focusing on privacy and control.
Countless paperwork (Resources) to conduct across multiple teams, without visual understanding of who does what and how, is usually required for any architecture. It's similar than building a skyscraper in the middle of Dubai, involving the typography of sand land, among other factors. Each team member (DevOps, Engineers, Cloud Architects) is responsible for a smaller piece of the pie = the blueprint. Sometimes, a DevOps and a Cloud Architect can work on the same function and don't realize (thanks to Internet-based availability of information) they are connecting two different components. As we know the domino effect so well now, one action can affect the other but also can result in another. Complication come across consolidating all these changes, updating the Blueprint as more components pills up and automations is a norm.
Stephane: Lets deep dive into how a team usually function.
Chafik: It's simpler to start with a diagram to understand any team working on an application / infrastructure. Let's start with the basics:
- The Product team (that consists of developers and DevOps, in most cases) uses the infrastructure and send requirements to the Cloud team.
- The Cloud team (that consists of Cloud Architects, DevOps, Network architects under Middle Management) is a bit more complex:
- Cloud Architects analyze & advize during the whole development process
- DevOps (with usually the most knowledge in Terraform) are doers 😉
- Network Architects advise, deploy & manage the infrastructure.
- In smaller teams, Network Architects = Cloud Architects / DevOps = Cloud Architects. Viva Cloud Architects!
The more you grow, the heavier your storage will be (=the more you pay) and, of course, the more you require these tasks (done by a compute-red brain) to be automated and the more complex your Blueprint becomes. Remember, every component intercept with another one, sometimes, multiple ones.
- The more your data grow (quantitatively & qualitatively), the more your data will be valuable & sensible for, for example, the Dark Net. So, security (Cloud Governance) is important. It's the vault of your companies' tech asset (information), stored in the Cloud. We can see today solutions that ensure encryption, data recovery or even offer on-site ownership of the data you preciously collect.
- The physical factor of storing infrastructures into physical data centers is relatively bad for the environment. As the question was raised early 20s, we are still trying to quantify the impact information in the Cloud consume space, then we will be able to quantify the electronic power we consume every minute we send information to someone. For example, sending an email is believed to measure 4 grams of CO2, as a consumption. Imagine all these Slacks that command us to answer on threads.
- The Cloud is complex indeed because of so many new technological advancements on-the-run. The key is to understand them, technically but logically too, and adapt as fast as your competitor. The upcoming tech challenge we face today is to synchronize all these tools, platforms, components or any other direct product-effect and to build the future of the Cloud, for the benefits of businesses, third parties and end-users. Whether we think about AI or Blockchain, an in-depth understanding of the capacities of every/all technology/ies is required.
At Brainboard, we believe in the Cloud-as-an-ecosystem. That means, with all the different components that exist today (& will exist tomorrow), we combine it and offer you a seamless solution to visually think & design, deploy and manage all your Multi-Cloud infrastructures.
It is the next step for understanding the industry inside-out and better use tools for efficient deliveries. Synchronizing a team across different continents is key to productivity. We enable members of the team to think natively Cloud and enable engineers to work on architectures from the beginning. We help bridge the gap between Application and Infrastructure.
So, my job is even more complex as anticipated and, I am lucky enough to work aside a great deal of people like Chafik or Jeremy, that are open to share their expertise with me.
As our mission is to simplify the job of everyone and build the future of the Cloud, I, personally, intend to clear doubts and explain complex knowledge through that Knowledge Base.
In the future multiple non-technical articles I am going to write on Brainboard’s blog, I will try my best to eliminate frictions to anyone, browsing or using our services!
Le Réseau de zéro Cloud Architecture: Cloud Computing, Service Models and Components of the Cloud Simply Explained What is Cloud Architecture? What is cloud architecture? Cloud Computing Architecture: A Comprehensive Guide The Cloud and Cloud Architecture Explained - Computer Stuff They Didn't Teach You #15