The development process has many variables and dependencies, but having resources exactly when you need them is key for ultimate performance. At SashiDo we strive to enable our customers to work at their best without worrying about any limitations.
System scalability is a necessary solution to the problem of increasing load when a business grows. If you have been with us for a while you know that we do offer secure and automated scaling within a range since day one. So far each upgrade was done upon customer request. Until today...
We are super happy to announce that we now offer a sleek new scalability feature in our Dashboard!
Take control of your resources with SahsiDo’s brand new Engines. You can instantly scale horizontally or vertically with a simple click on your dashboard while choosing to have your auto-scale mode on or off. What’s more - you’re able to manage and optimize your usage and costs beyond the standard plans. It’s time to unleash all your power and take your business to the next level!
- The Engine
- How does it work?
- What would it cost?
- Time to Celebrate
- What to expect next?
There are quite a lot of issues one can face with scaling. For starters, too many background jobs can be quite CPU consuming and if capacity is not managed properly this surely affects poorly the quality of service during execution. Another issue most devs often face is slow requests running on the background triggering normal to severe events. And how about big files taking forever to upload? Not to mention that significant downtimes are definitely a showstopper for your business’ growth. Yes...we’ve all been there and we know how painful all this can be!
How do you remove those performance constraints efficiently?
In general, all these issues indicate that there is a performance problem and they most often appear when there is a heavy load, which in turn causes your applications not to work at their best.
Normally you have two ways for scaling your resources when the need is calling. You can either go up(Vertical Scaling) by adding more computing power (CPU/RAM/DISK/IOPS) to your existing server/database or expand out(Horizontal Scaling) by adding more processing units or physical machines into your pool of resources. Which way you go is dependent on your current needs and it is crucial both for your performance levels and your budgeting. Here is a short summary of the pros and cons of scaling in or out:
First off ask yourself the following questions:
- Does your business plan for growth matches the current server system abilities for scaling longterm?
- What is the typical flow of your system user’s actions?
- What bottlenecks does your system have?
- What is more crucial for your system: fault tolerance or high performance?
- Where does the need for scalability appear?
Then once you have a clear overview of your current and future plans for resource usage you can make an informed decision on which direction you should go and when exactly.
What SashiDo offers is a feature that enables you to choose the number of your applications’ engines as well as their memory capacity from a hyper easy to use interface.
Since you’ll be paying per hour charges for your usage, you will be able to test different capacities for very short periods and choose the combo that suits your needs best. You can, for example, stay with the default Standard 1X or scale up to a Standard 2X engine during development and early production when finances are scarce. Once your app kicks off and starts generating more momentum, and of course revenue, you can scale up or out further to fulfill your business' needs and expand its full potential.
We offer an awesome variety of engines for your every need from Standard 1X and 2X that can handle rising numbers of requests to Standard 3X and 4X providing additional capacity for jobs and requests. And finally, the heavy artillery - Performance 1X and 2X when you want to scale up and ease your pain from heavy jobs, slow requests, and traffic spikes.
At the top of the interface you have the Horizontal Scaling functionalities:
- Simple toggle for enabling and disabling auto-scale in a blink.
- A toggle for directly enabling High Availability.
- Visualization in the form of an interactive scale, showing the number of engines you’re currently using.
- Min and Max level indications of the resource range.
- Controlling arrows for an increase or decrease the number of resources.
Then at the midsection, you have a text line showing the number, the type and the combined cost per hour of the engines you’re currently using.
Right below that, you have the Vertical Scaling controlling table. You can see the specifics of each engine type as well as the billing policies. With just one click on your preferred engine type, you can choose to scale up your capacity. Have in mind, that you can run with only 1 type of engines at the same time: e.g. It’s impossible to have a combo of one Standard 3X and one Standard 2X engines running simultaneously. You can either have 2 x Standard 2X or 2 x Standard 3X instead.
And finally, each time you choose a different setup, you’ll be prompted to hit “Save & Deploy” button on the bottom right.
The best thing is that this feature is available in your dashboard 24/7, so increasing your resources is just one click away now.
Something we want to have your special attention on is the Min/Max scale. Our developers especially designed this functionality to provide you with freedom, but at the same time with full control and protection. In short, it is showing the range within which you can change your capacity and resource availability. Don’t get us wrong! It’s not like we want to put you in restraints! Actually, it is the other way around and let us tell you why…
The Min mark gives you the option to choose more than 1 engine when you want to add an additional layer of redundancy and ensure your app’s high availability. This helps a lot when, for example, you know that you have sporadic events with higher activity on your app, but you want to ensure that those are handled without waiting for the HPA(Horizontal Pod Autoscaler) to detect your needs and auto-scale.
On the other hand, the Max mark is there for abuse protection. We want to make you feel safe and secured with using auto-scaling mode, eliminating even the slight chance of getting charged over some crappy code or glitch generating faulty or crazy traffic.
The minimum number of available engines is controlled by you, while the maximum is managed automatically by SashiDo’s system and can be changed upon request as well. So the idea here is not to set limits, but to give you freedom and at the same time have your app working with a fully secured and controlled range of resources. You want your resource range changed? Just send a note to firstname.lastname@example.org
The Horizontal Auto-Scaling is enabled by default, and it provides you with a way to dynamically scale SashiDo resource capacity up or down automatically.
This feature is not only ensuring your apps utmost performance, but it is the ultimate cost saver by having resources available only when they are needed without jeopardizing performance. Meaning you don’t pay for containers just in case or hold your fingers crossed there won’t be demand spikes which your current resources can’t handle.
Having all this in mind you would think why even give the option to set off your auto-scale ... Well, we thought of all possible scenarios, and we want you to have full flexibility to act on demand. For example, imagine you’re in a dev phase and want to squash a bug(we’ve all been there). Now, in this case, you would like to set your app hard with a minimum capacity of running engines (e.g., the default one Standard 1X engine), rather than spreading the load and slowing down performance over multiple engines. This way you can find the issues as fast as possible and run your deployments smoother.
Every SashiDo app includes one Standard 1X engine free of charge, and horizontal auto-scaling is enabled by default.
The following billing model applies to all mCPUs and memory resources upgrades:
*mCPU is Micro Compute Unit,One mCPU = 40 millicores
*Prices exclude VAT
All mCPUs and GB of memory are charged a minimum of 1-hour increments or in other words, partial hours are billed as full hours(e.g. For running 30 minutes with one Standard 2X, you will be billed for 1 hour of usage - $0,046).
Better usage planning, better prices! We offer automatic sustained use discounts and bonus requests based on the percentage of the billing cycle time you've managed to maintain uninterrupted Engine resource usage per app. Those discounts and bonuses are calculated separately for each individual engine that you use. Bonus requests are awarded up to a fixed limit - the more powerful the engine is, the higher the number of free requests you can get.
Considering that a billing cycle is between 28 and 31 days(depending on the calendar month), you’ll need to have above 14-16 days of sustained usage per engine to take advantage of our discounts and bonuses. Below is a detailed description of the different tiers:
- Example: Let’s take that your billing cycle starts on the 1st of Nov 00:00 end ends on 1st of Dec 00:00 November has 30 days and 720 hours. You’ve scaled up and out between the default Standard 1X, to Standard 2X and extra one or two Standard 1X on top of the default engine. Below is the aggregated engines usage for this example:
Based on the above Example you’ve used uninterruptedly Standard 2X with ID SNASnsQEEs for 500 hours which equals 69.4%(about 20 days). This means you’ll get a 10%($2.30) sustained usage discount of the price you’ve accumulated only for the
SNASnsQEEs engine. This will result in your total Engine usage bill going down from $25.484 to $23.184. The amount of sustained usage also fits into the 1st tier where you get 50% of the monthly bonus requests allowance. For Standard 2X engine that would be + 3 Mil Bonus requests.
We always aim to be transparent to our customers, and you can see the accumulated charges in real-time for your apps from your Metrics > Overview Dashboard. Discounts are applied to your invoice at the end of the billing cycle. Bonus requests are deducted from your Extra monthly consumption again at the end of each billing cycle. There is no action needed on your part to enable sustained use discounts or bonus request awarding.
Cool stuff so far, right? We couldn’t wait to release the first version of the Engine, and we already have started working on the Upgrade. A small clue - Transparency - no more wondering how your resources are used, get a clear view.
Stay tuned for more and of course happy coding!
Posted on by:
Beginners guide to Docker
Peter Jausovec -
How to learn web application security
Spyros Argalias -
Build a serverless Quiz in days with React and AWS Amplify DataStore
Deploying a Kubernetes Cluster (AWS EKS) & an API Gateway secured by mTLS, with Terraform, External-DNS & Traefik - Part 1
Aurélie Vache -