Merge pull request #449 from tristanbes/feature/fix-docs

fix doc about cold starts

docs/README.md

@@ -116,7 +116,7 @@ This matrix will be updated as Bref and AWS services evolve over time.
             <span class="maturity-icon shadow bg-green-400"></span>
         </td>
         <td class="p-4 text-center">
-            <span class="maturity-icon shadow bg-red-400"></span>
+            <span class="maturity-icon shadow bg-green-400"></span>
         </td>
         <td class="p-4 text-center">
             <span class="maturity-icon shadow bg-orange-400"></span>
@@ -140,7 +140,7 @@ This matrix will be updated as Bref and AWS services evolve over time.
             <span class="maturity-icon shadow bg-green-400"></span>
         </td>
         <td class="p-4 text-center">
-            <span class="maturity-icon shadow bg-orange-400"></span>
+            <span class="maturity-icon shadow bg-green-400"></span>
         </td>
         <td class="p-4 text-center">
             <span class="maturity-icon shadow bg-orange-400"></span>
@@ -152,7 +152,7 @@ This matrix will be updated as Bref and AWS services evolve over time.
             <span class="maturity-icon shadow bg-red-400"></span>
         </td>
         <td class="p-4 text-center">
-            <span class="maturity-icon shadow bg-orange-400"></span>
+            <span class="maturity-icon shadow bg-green-400"></span>
         </td>
         <td class="p-4 text-center">
             <span class="maturity-icon shadow bg-red-400"></span>
@@ -182,39 +182,37 @@ This matrix will be updated as Bref and AWS services evolve over time.
 - **Jobs, Cron**
 
     Jobs, cron tasks and batch processes are very good candidates for FaaS. The scaling model of AWS Lambda can lead to very high throughput in queue processing, and the pay-per-use billing model can sometimes result in drastic costs reduction.
-    
+
     The main limitation at the moment is the lack of documentation on this topic, as well as the lack of native integration with existing queue libraries like Laravel Queues.
 
 - **API**
 
     APIs run on AWS Lambda without problems.
-    
-    Performances are now similar to what you could expect on traditional VPS, with the exception of cold starts that can occasionally add a few hundreds of ms to some requests (usually 0.5% of the requests). While cold starts can be mitigated, those can be a deal breaker with real time APIs where response time is critical.
+
+    Performances are now similar to what you could expect on traditional VPS.
 
 - **API with MySQL/PostgreSQL**
 
-    MySQL, PostgreSQL or Aurora imply using [AWS RDS](https://aws.amazon.com/rds/), which means using a VPC. Because of that cold starts get much worse: around 5 seconds. While this can be acceptable for some scenarios, for most APIs this is a deal breaker. This is why we will rate it "red" for now as this is a "strong limitation". AWS has planned to remove this caveat in 2019.
-    
+    MySQL, PostgreSQL or Aurora imply using [AWS RDS](https://aws.amazon.com/rds/), which means using a VPC.
+
     Read the [full "Databases" documentation](/docs/environment/database.md) to learn more.
 
 - **Website**
 
     Websites can run on AWS Lambda. Assets can be served via AWS S3. That requires a bit of setup but this is documented in the ["Websites" documentation](/docs/websites.md).
-    
-    Performances are as good as any server. Cold starts often have less impact in websites than in APIs: a full page load *and render* in a browser is often a few seconds.
+
+    Performances are as good as any server.
 
 - **Website with MySQL/PostgreSQL**
 
-    Just like with APIs, websites using MySQL or PostgreSQL will suffer from longer cold starts due to VPCs.
-
-    However such delays can be more acceptable on websites than on APIs, which explains why APIs are rated "red" and websites "orange".
+    Performances are as good as any server.
 
 - **Legacy application**
 
     Migrating a legacy PHP application to Bref and Lambda can be a challenge. First, as explained above, the limitations that come with MySQL/PostgreSQL often apply. On top of that legacy applications tend to be extra slow and large which can make performances suffer.
-    
+
     One could also expect to rewrite a good amount of code to make the application fit for Lambda. For example file uploads and sessions often need to be adapted to work with the read-only filesystem. Cron tasks, scripts or asynchronous jobs must be made compatible with Lambda and possibly SQS. Finally there are no case studies or online examples of such a thing being done before (to the extent of our knowledge).
-    
+
     Not impossible, but definitely not the easiest place to start.
 
 ## Getting started