SLA Index - Elevating Service Provision and Usage

Issue

In the 2010s, participating in technology forums where many people with a shared interest in programming and sharing online tricks. You would easily see articles about free hosting sharing for those in need. The conditions were quite simple, just leave information such as name, email address, or sometimes even the purpose of use, then after a short time, they will send you all the information via your mail.

In the article, some clearly state the "sponsorship" period or trial period as 1 or several months, or until they can no longer maintain the server. At that time, I was still a student, so I couldn't pass up such attractive opportunities. Having hosting to use, high speed, large capacity, and it's free. Indeed, everything was free!

In reality, after registering and using such services many times, not many operated as promised, or were unusable, had errors, or suddenly stopped working. Well! I had to accept it since I only used it for experimenting with "toy" source codes.

The internet today is vastly different from the past. I no longer see articles sharing hosting like before. Instead, there are articles sharing servers, VPS, or many generous "players" willing to sponsor all server maintenance costs for someone, as long as they meet a few conditions set out. But they mostly share a common point of depending on others. If the system is stable, it's fine, but if one day, the shared server suddenly disappears without a trace, and the data hasn't been backed up, it's like buying trouble.

I learned a lesson that many things require payment to ensure assurance. The more money, the greater the commitment. It's simple! To operate and maintain anything, there must be a team behind it. They work to keep the system stable, and we pay them to do that. But that's not to say free services are synonymous with poor quality. Today, thanks to optimizing operational styles, the cost of running free services is negligible, or maintaining a free package is equivalent to the marketing cost for their service.

1-2 years back, before deciding to use a service from a provider, I usually spend time researching who is behind it. Who created it, which organization operates it, and whether they have a name or standing. Or even "digging" into whether there have been any past scandals related to them. "Oh my, you’re overreacting, just use it, and when problems arise, then deal with it!" Hmm... I've been an internet user long enough to understand such troubles!

Recently, while deploying a new update for the OpenNotas application on Cloudflare Workers, an issue arose. The website continuously redirected to the homepage without any changes related to navigation behavior; if I hadn't checked before hitting "Publish," users of my note app might have faced unfortunate troubles. I opened an issue on Cloudflare's community help page, hoping someone would help find the cause. After a long day of waiting, perhaps everyone was busy with their work, so no one knew or cared about such topics. Fortunately, I had researched some providers similar to Cloudflare and then moved my application to make it work normally again.

Although Cloudflare is very famous and widely used, if you take the time to research, you will find many user posts complaining about Cloudflare's services. I have also been a user of Cloudflare for a long time, back when it was merely providing DNS services along with a few CDN features. In my memory, it was quite poor. Hard to use and often faulty. Thus, I learned another lesson that not everything popular with many users is good. It is good until a problem arises!

All the above reflects a point about user trust in a product or service. A good service provider will satisfy the majority of users. And that satisfaction is often based on the Service Level Agreement (SLA) between the provider and the user.

What is SLA?

According to Amazon, SLA - Service Level Agreement is a contract between a service provider and a customer that specifies the service level the provider commits to deliver. This agreement details metrics like uptime, delivery time, response time, and resolution time. SLA also provides detailed actions when requirements are unmet, such as additional support or discounts.

In short, SLA is a commitment from the service provider to the customer. A trustworthy provider has a set of SLAs that specify the required parameters during use. For example, no one wants to rent a server that operates intermittently, alive today, dead tomorrow, but needs to commit or specify the required uptime for the server, such as up to 99.99% or lower, which must be stated so users know the availability of the service they are about to use.

Complying with SLA brings many critical benefits for both the service provider and the customer, helping build trust, increase operational efficiency, and enhance brand reputation. When the service provider meets the commitments in the SLA, customers will feel secure and trust the service more. Having a high reputation and being positively evaluated in the market. This attracts more new customers, creates competitive advantages, and increases reputation. Clearly establishing expectations between the provider and the customer from the start helps limit disputes over service quality or each party's responsibilities.

AWS is one of the leading cloud service providers with a comprehensive and detailed SLA. AWS has a policy of providing compensation in the form of service credits (a form of reimbursement) when the SLA is breached; customers must submit requests within the stipulated time and demonstrate the actual impact on their systems.

In February 2017, Amazon S3 in the US East region (us-east-1) experienced a major outage that affected many services relying on AWS for several hours. After the incident, AWS compensated customers according to their SLA policy in the form of service credits. In November 2020, AWS Kinesis service malfunctioned for nearly 24 hours, disrupting dependent services like Cognito and streaming services of many companies. AWS also provided Service Credits to affected customers based on downtime and impact.

Thus, it’s not by chance that AWS is used by many individuals and organizations.

Lessons Learned

Before knowing the concept of SLA, what I often saw on some service provider pages or service introductions often emphasized their commitments. For example, a commitment to server uptime up to 99.99%, a money-back guarantee within 30 days of service use... From there, a habit formed of looking for commitment phrases when exploring a service. Although these statements are very simple and concise, they provide a certain level of reassurance.

Since operating this small blog, I always try to bring commitments for readers. For example, previously there was a period of commitment to answering all reader questions, or a tacit agreement to have at least one article per week. Recently, I am implementing another commitment of one short article each day in the Threads section of the blog - where I post personal short shares of the day. Next, I'm progressing towards a commitment to send a weekly or bi-weekly summary newsletter. Although this campaign started over a month ago, due to the low number of subscribers, more critical tasks had to be prioritized. If readers are interested in this feature, please actively subscribe to receive summary newsletters via email right below the article.

Additionally, I'm also striving to commit to updating the OpenNotas note-taking app at least every 2 weeks to fix bugs and enhance user experience.

Conclusion

SLA is an essential agreement for both service providers and users. Ensuring SLA will help providers score points in the eyes of service users and more. However, SLA requires operational capabilities that are not simple and consume many resources. But that doesn’t mean we should overlook it, start with small commitments, no matter how small.