Guest post originally published on the Cuemby blog
How to avoid the 503 error!
The dreaded 503 Service Unavailable error is an HTTP status code that technically means the web site’s server is simply not available at this time. Usually, it occurs because the server is too busy, there are too many simultaneous requests or because there is a maintenance window, scheduled or worse emergency.
What the 503 error really means is your application isn’t working and your customers, potential customers, and other interested parties cannot see your information, login to your application, or buy products from you.
In some ways, you have become a victim of your own success, the more activity you have, the more requests to the network, the more the infrastructure needs to scale and then BANG! there’s a crash. 503!
But the crash can be avoided. Just as virtualization gave more resiliency to server infrastructure, containerized services can do the same for cloud infrastructure. But you need to understand it and manage it properly, which is not always easy.
That’s where cloud-native technologies such as Kubernetes come into play. Containers allow you to securely run applications and all of the associated dependencies independently and have no impact on other containers or their operating systems.
That sounds great because you gain scale in resources but those containers need to be managed properly, they really need to be orchestrated properly. For example, scaling the resources of a container vertically gives you more horsepower for the timeframe you need in (simultaneous logins) but there still could be a central chokepoint with entry.
Think about it in real estate terms, if a building has ten floors and a capacity of 100 people per floor you can easily and effectively have 1,000 people in the building at one time. But what if you need 2,000 or even more. You can add resources and “floors” but what if fire code only allows 1,000 people, scaling vertically is doable but it only adds cost and not value.
Worse, what if those 2,000 people all need to enter the building at the same time and there are only two doors? Now you have twice the capacity all entering simultaneously……scenes from the 6 o’clock news every Black Friday!
Kubernetes can not only automate that vertical scale but also provides a simultaneous horizontal scale as well. Now instead of having one building with ten stories, you can have three buildings with four stories and each having a 1,000 person fire code capacity and two entry points.
Now you can have three times the capacity at the same on slightly higher cost and three times the simultaneous points of entry. This works brilliantly but high rises in the city are there because real estate space is at a premium. But that’s the beauty of cloud infrastructure, horizontal real estate is never an issue and Kubernetes allows you to also deploy that application and scale over multiple clouds and even on-premises.
So containers allow you to have multiple instances of the application, and Kubernetes allows you to scale the resources and instances of that application both vertically and horizontally and over multiple clouds and in multiple regions….but how do you automate the multi-cloud aspect? That is where a declarative API, which several firms are working on creating, would come into play by presenting end-users one dashboard to orchestrate over multiple clouds.
Until then organizations like Cuemby can provide this multi-cloud, multi-region experience for you through our CuembyIO platform. (Platform video)