One of the first hurdles I faced while starting my FinOps journey was to become familiar with how IT works behind the scenes. I thought I had a decent understanding of technology, but as it turned out, I had no idea of how many components were needed to power Apps behind the scenes, let alone how these interlinked with each other.
In Part 1 of these articles I said that there is only a handful of hardware components that you need to build your infrastructure: Compute, Storage, Network Interfaces and Databases (although this last one really is just another compute), and that it is in the software where all the possibilities open up and services start to being offered. So the question now is, why is this so important? How much software do I really need to achieve my goal? The answer is, a lot. Like, really, a lot lot.
You see, in the past (and specially before the internet) we relied on our desktop computers to be able to handle all operations of a given application. If you remember, before purchasing a software you’d have a set of minimum requirements for it to run on your PC. These are known as fat-client applications and likely to be monolithic (we’ll come back to this later on, don’t google it just yet). These applications, therefore, were self-contained. That CD, DVD or whatever media you bought to install the software contained all the dependencies - packages - that the application needed to run. This also meant that as long as your machine was running, you could use your software without interruption. But that wasn’t always the case, was it? Even then, you will get frustrated when the application froze, became slower, got corrupted or experienced any other kind of issues that prevent you from doing your work.
As the internet developed, things started to change. Now you could ‘do some things’ on the web browser that didn’t require an application installed. Think of your webmail, a chat room or even some small games. As we said in our previous post, these applications are still running on ‘some’ computer, just not yours. Which means that now it is not your problem to have a computer that can ‘handle’ the application requirements. And that was really convenient, now we don’t need to upgrade our laptop every time a new version of the software comes up. I don’t even need to go to a store to purchase software and then install it myself. These days I just open my browser, find the software I want, give them my card details and start using the software. These are now ‘thin-client’ applications, as they run most of their computational services on a remote server. These are also likely to be distributed systems (again, bear with me).
Functional vs Non-Functional Requirements and the Importance of Architecture in FinOps
But having such easy access to our applications doesn’t mean that we gave up on some requirements and expectations. In fact, we depend so heavily on systems these days that our requirements may be even higher than ever. If your business is to run an ecommerce store, you need to be sure that your e-store is available as close to 24/7 as possible. For each minute that your store is down, even for maintenance tasks, you will be losing revenue. If you are in banking, you want to make sure that each transaction gets registered, even if there is a failure in the system, you can’t just ask your client to do that transfer again (let alone telling them that their money disappeared in thin air because of a system hiccup or the internet connection dropped).
So if you are on the other side of the table, and you are the one building and selling the application, you will have a long list of requirements and expectations to meet both functional (what the system does) and non-functional (how the system does it). These are two different but equally important concepts. Functional requirements is what your developers will take care of and that leads, in essence, to your source code (the ‘brain’ of your system). Non-functional requirements, on the other hand, are the conditions and constraints within which your systems are built and, ultimately, dictate how your system is designed. Here software architecture comes in place.
Brief pause. You may be wondering, where is this heading? I thought I would be learning useful computing concepts that would ease my way into FinOps. Fair question. I feel you. But trust me, just for a bit longer. Architecture, in my humble opinion, is quite central to your role as cost controller. I’d argue, they go hand in hand. Yes, of course you will keep an eye for resource waste and discount models, but longer term, it’s the architecture that would make the difference. Balancing requirements always means balancing costs with benefits and architecture evolves with time. Okay, back to the topic.
Software architecture is the combination of three core components: your system’s requirements, the decisions you make, and the designs that you follow. As with everything, there are certain industry standards - or patterns - that you can follow depending on the requirements you need to meet. Needless to say, this is a continuous practice, rather than a one-time piece of work, where you will iterate over time and assess whether or not your previous decisions and designs are still relevant or the most suitable for your goals.
Core Non-Functional Requirements and Infrastructure Components
Let’s start joining the dots. In the last post we said that most services are specialized software running on a compute. Now, we are saying that we have certain design patterns that will help us meet requirements. How do these two work together? Let’s start with non-functional requirements. While there are countless non-functional requirements, we can narrow down the list to five core requirements. These are: Performance, Security, Usability, Reliability and Scalability. The question now becomes how we meet these. Let’s take Scalability as an example. A system that is scalable means that it adjusts in size to meet demand. That can mean adding more disk space in a database, to store more data, more compute power to handle the load of users, etc. In a more analogue example, let’s say that you run your own business for which you have your laptop to run your suite of software of choice. One day you need to expand, so you hire an employee who also needs to use the same systems. You won’t be sharing a laptop, of course, so you will buy another computer and install the software in there. Well, the same happens with software providers, specially those that run on a web browser. The more users they get, the more Compute they will need to meet their demand. This concept is easy to grasp, but there is more to it. If you now have 10 compute instances running your product, how do you make sure that the users are evenly distributed across these instances and avoid overloading a single one of them?
To meet that Scalability requirement, you will need a component in your infrastructure whose job is to distribute users evenly. Enter Load Balancers, a piece of software that handles user traffic and distributes it across different targets. You could deploy another compute instance and install your own software (i.a HAProxy) to do this job or, you can leverage the service that the cloud provider offers (like AWS ELB or GCP Load Balancing). These managed services handle scaling and health checks for you, but be aware that costs can accrue based on traffic volume and data transfer. But this is only one example and real-life systems have lots of complexities. That’s where those architectural patterns and styles come in handy and provide a general guidance as to how to design a system that best meets your needs. I say guidance because, chances are, you will end up adopting part of a design pattern. There is no ‘one size that fits them all’ but these patterns are a great starting point. As you deviate from them - ideally - you will be logging your design decisions so, in the future, you know how you ‘do things’ in your ecosystem.
Architectural Patterns and the FinOps Role
Before we dive into patterns, we need to briefly understand the architecture and some general concepts that describe patterns. At large, there are three ways to ‘organize’ your architecture:
- Big ball of mud → it’s hard to consider a style really, as it just refers to an initial, unstructured system that follows none of the existing best practices. You may be thinking: how or why would I use such a thing? It won’t be a conscious decision, it will probably be the result of just getting started and learning as you go while trying to serve a specific (small) purpose for a small user-base.
- Unitary architecture → these are almost exclusively for software embedded into hardware. Things that won’t change and have a specific purpose. Think of your microwave: it has a limited number of functions, they are always the same and they won’t need any changes for the machine to operate.
- Layered → these have multiple components, each of them fulfilling their own purpose, known as ‘tiers’. The first example of these is 2 tiers architecture (known as client/server) where the user interface is separated from the storage / database (example being your desktop machine running on an office with a central server to store the data). With the popularisation of the Internet and browser-based applications, 3 tier architecture became more common. Similar to the 2 tiers one, you will have a storage tier (database) and a presentation tier (web server), but in this case the logic of the system will be on its own middle tier (application tier).
If you are the FinOps person at our company, and work with engineering to produce systems (regardless of whether these are internal or client-faced) you will probably be dealing with Layered architectures. That doesn’t limit the number of options you will find. You see, layered architecture can follow two patterns: Monolithic (all the code is contained in one deployment) or Distributed (you will have multiple deployments - or components - and they will communicate with each other via access protocols). Each of these patterns will also have many styles. You would have heard of microservices, event-driven, modular, etc. These are all styles - flavours - of these patterns.
As a FinOps person, your role won’t be to decide on the architectural patterns or the styles within each. However, it would be valuable to you to be able to understand some core concepts so you can have meaningful discussions with engineers and architects and, ultimately, be part of the team that makes the decision.
The idea is not for you to be an expert on the computer architecture domain. Different styles will require different components which, ultimately, will translate on either services that are offered by your cloud provider or self-managed versions of them (software that you will run and manage on the compute resources you run). Each of them will have their own pricing model and, to make things more complex, there will be subtle differences between these services that will make them more or less suitable for your needs (example: you know you will need a database in your service, but would it be a relational one, a non relational one, a document one?).
As a professional, you will need to understand your organization requirements and delve deeper into the solutions that you will be implementing. Start at a high level, understand the pricing model first, then the levers that will impact the cost and ultimately what purpose the service fulfils. Then you can research alternatives, how these compare against your current choice and what opportunities for optimising for costs you have.
Over to you now. If you found this article somehow useful, what would you like to see next? Is there any service or pattern that you are most curious about? Let me know down below!
Comments
Post a Comment