Wow, post number 20. I hope you are enjoying them as much as I am.
Please like, share, and subscribe if you are.
Not That Long Ago
Just a handful of years ago, if you wanted to stand up a website or some sort of mobile application, you needed to purchase millions of dollars worth of hardware and data center space, and then hire a small army of technicians to get everything running. Today, that same capability can be procured with a swipe of a credit card, and might even be free for the first year with any number of hosting providers. And, there’s no need to hire your own technicians because countless providers have emerged that do all of this for you for that swipe of a credit card. But, as with anything, there are pitfalls and risks. Let’s get into what you should be aware of to mitigate some of the risks.
Security
Taking a page from secret and covert organizations the world over, giving your users and stakeholders the minimum amount of information and access is key to lowering the attack surface for hostile actors bent on doing you harm. Granting access and capabilities to a limited number of roles just makes sense. In a world where the inadvertent saving of access keys to GitHub, can lead to $100,000s of billing in a matter of hours, it is essential to make sure that people's access is in line with what they need to do. You are asking for problems if you give every account in your organization access to everything. Give your developers the access they need and no more. While this might slow you down a bit, having 100s of crypto miners spawned via some credential leakage is a headache you don’t want to take on.
Cloud Bursting
The benefit of the cloud is that you only have to pay for the capacity you use. The biggest headache is that you pay for the capacity you end up using. In a world where serverless functions, automatic provisioning, and every megabyte out (and in some cases in), are measured and billed, it can be terrifying to have a service run amok while you are asleep. The web is filled with stories of a slight misconfiguration racking up 10s of thousands of billing when a service runs recursively. Service A calls B calls C which then calls A can get expensive quickly. Being mindful of what might happen and protecting against the endless calling or provisioning of computing, and installing circuit breakers to prevent runaway billing loops is a key architecture consideration. Preventing runaway processing is always key to protecting the precious resources of your organization. Some providers allow you to program alerts or stoppages at specific billing thresholds.
Architecture, and preventing lock-in
All of the hyper scalers have countless building blocks for your software idea. However, it’s important to be mindful of what you should buy vs build, along with how you might replace or move away from a purchased service down the road should your needs change or technology evolves. But there’s always the other side of the coin where you, as a technologist, will be called on to support something for far longer than was anticipated. Ensuring you have the ability to pull the ripcord and move your stack to another provider will at least get you thinking about future-proofing architecture decisions. Being mindful of the billing consequences of your decisions should always enter into the calculus when figuring out what to purchase and deploy.
Using the cloud does not have to be dangerous, but like any number of activities, you should think about the consequences of your architectural decisions. Ensure your developers and administrators have just enough access to do what they need to do, will prevent runaway access from hurting you. Thinking about how to leverage the cloud’s bursting capabilities, while also preventing services from running wild on your billing. Finally, think about if your architectural decisions will lock you in or allow you to grow. And, always think about an escape hatch if something becomes untenable as your needs, billing, or architecture decisions evolve over time.
Thank You
Jim ‘The Designatic’ Tyrrell