In last week's blog post, which you can find here, you learned about hosting and scaling systems. Although you learned a little bit about why you'd want to scale an application, there wasn't a ton of information around it. In this blog post, that'll change.

Figuring out where to host an app and how to properly scale it based on where it's hosted is crucial, especially since you can't tell the future, so you have no idea how large the application will grow and many other unknown factors. In this blog post, you'll learn about how to scale, host, and think about application reliability.

Apps Change Over Time

Many organizations find themselves in a tech-debt-driven scenario where they do a few things:

• Get an MVP of an application ready
• Build on top of that app
• Put duct tape around it to make it work

And poof! Just like that, you have an application that when it needs to change over time, it can't.

The goal for any application is to understand that it will change over time. It will need to run in one place and then run in another place because systems and environments change. It will need to have the ability to take on more load as the user base grows. It'll need the ability to fail over and scale.

When thinking about building an application, or managing it, the question must be What happens if everything changes? Will the app still run?

This is, of course, a very vague question. However, it must be because you never know. Do you think that applications running 10 years ago knew that the option for serverless would be available? Maybe not. However, if an application is built properly, it can run anywhere, so not knowing about serverless wouldn't have mattered.

Build applications with the mindset of this thing will change.

Containers? VMs? Serverless?

Where to host an application has many variables, but the primary ones are:

• Do we have enough people to manage the scalability and maintenance?
• Do we have a data center or a rack somewhere to host servers?
• Do we want the overhead of hosting on VMs or bare metal?
• Do we have knowledgeable engineers that understand the latest systems (containers, serverless, etc.)?

Regardless of the size of the organization, these questions will always make sense. Let's go over two different scenarios.

The first scenario is the startup. They have just enough money in the bank to get by, and everyone is working 18 hours per day, which means they probably don't have the funds to hire a cloud engineer or systems engineer to scale and manage a system that an application is running on. Because of that, serverless would probably make sense. Take the code, throw it up into AWS Lambda, and it runs. No server maintenance. No operating system maintenance. Just maintenance of the code. Of course, there are pros and cons, but it'll depend on the environment.

The second scenario is the organization that's been around for a while and they have the money in the bank/budget to hire engineers. At that point, maybe they'll want to utilize servers on-prem and take the time to learn the cloud, containers, and serverless. Maybe they'll set up AWS Outposts or Azure Stack to get a feel for the cloud, run their apps in a hybrid scenario, and eventually, move the workload to containers or serverless.

There's not a once-size-fits-all model here, which is one of the reasons that there are so many different solutions.

Performance and Reliability Testing

Once you understand how to properly build an application, run the application, and figure out where you want to host it, then the real fun begins. It's time to figure out the reliability of the application.

Why is this important? Simply put; everything is all well and good when the shiny app is running in a demo environment until users start interacting with it. Before you know it, there's a new bug here, a new feature request there, the server in the corner is on fire... fun fun fun.

There will always be a level of unknown, but you can still work towards mitigating that as much as possible. With platforms and tools like Apache JMeter, AWS RUM, LoadNinja, and many others, you have the opportunity to see what'll happen before an application is being used by real users.

If you're building a new application, or you're adding to an existing application, definitely check out performance and reliability testing tools. It can save you a ton of headache down the road.